Hacker News Reader

Comment by Nbox9 | Hacker News Reader

I think a lot of this is because our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’. Every technical interview feels like rolling the dice in proving I am a competent developer. Giving me 50 minutes in a high pressure situation in an environment i am unfamiliar with and people I just meet will never product my best results, and then add to the fact that I could be asked any question, and my ability to answer is it being ranked against other candidates. Maybe someone else _just_ did a similar question in another interview and it’s fresh on his mind. Maybe someone spend their entire career focusing on just this type of problem given in the interview, but the question in the interview is only partly related to the actual job.

View on HN

I did an interview with Reddit - whom I hope sees this comment - and they not only provided zero information about the context of the tech interview in advance, or whether it would be one, but also the interview itself was like playing a random version of tech Jeopardy, but without the category columns, and very few of the questions had anything to do with the job I would be doing.

I have over 20 years of programming experience, am a founder, and have worked for multiple venture backed startups. That includes hiring countless developers, so I get both sides of the situation. And my partner is also a tech recruiter for a top tier HFT / market maker, so I know what a demanding but respectful hiring process looks like.

Reddit’s hiring process converted me from a fan of the site into someone that thought the entire organization was second tier - which obviously it is in terms of monetization - but also in how they treat people compared to the FAANGs. And a year later the role is still open.

Maybe they don't really want to fill it.

I had a similar interview with a different company last year. Three guys and me on a Zoom call with me sharing my screen trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career. When I got stuck they just stared at me. They would not give me any hints whatsoever. They just stared at me.

When the interview was over I thought, "Is this how working with these guys is going to be?" If I ran into a problem and went to them for help, would they just stare at me, waiting for me to figure it out on my own?

They didn't extend an offer to me and, based on my performance in that interview, I can't say I blame them. I'm not sure I would have accepted if they had, however. That experience really left me with a bad taste in my mouth and a low impression of that company.

We as an industry really REALLY need to figure out a better way of conducting interviews.

"Is this how working with these guys is going to be?"

Unfortunately, yes. Young engineers are terrible at communication and working with others. Partly due to workplace incentives and partly because you must realize that entire generations have grown up with computers and not people.

I don't think this deserves the downvotes it is getting simply because there is some truth to the comment.

A good friend of mine worked with a young developer recently who was excited about what he was able to generate with a single npm command. When my friend, who has been writing software longer than this guy has been alive, calmly pointed out that the npm command had just generated 400 files and thousands of lines of code that didn't actually solve their problem, this guy got mad and went to complain to their manager.

I'd be mildly ticked-off, too. The senior guy was being an ass.

I can easily imagine how it went down.

"Wow! I can do so much with so little!"

"Everything you just generated is wasteful and meaningless."

The right way is to encourage that enthusiasm and guide them toward doing more useful work with the same power they just discovered.

We only have your telling of your friend's telling of the story. This is rhetorically similar to saving a 50% quality jpeg as a 20% quality jpeg.

In a cut-throat environment, where 10% of people are PIP'ed, it is expected: your senior colleagues are not going to help you, will lead you down a wrong path, etc. That way, the tribal knowledge will be with them, and they can outshine any new employee.

In your interview case, they should have given you hints, even if they want to not hire you later.

That’s not how 10% attrition works at any notable company.

Pray tell, can you clarify what's incorrect in the above description?

I had an extremely similar experience recently and it really shook me up for a few days. Same amount of time in the industry as you.

Looking back there's no way I would have fit in there, but damn did that interview screw me up for a while.

Nothing about tech interviews is a signal for what happens inside the company, aside from you having the dual role of giving tech interviews while you forgot to factor that into your sprint planning

You’re making the same mistake at vetting them that they’re making at vetting you

The interview is signal from the actual company - it's definitely got some information about what's inside.

You are simply determining that you are okay with false negatives

Which is exactly why they do irrelevant interview brainteasers as well

This problem is a two way street in the tech sector, in case anyone wanted to fix it. The candidates alone are making the same mistake and bringing it to the company

Is a "false negative" a positive?

Its a quadrant. Positive, Negative, False Positive, False Negative

It is a determination that something should be rejected, when it really should have been accepted.

Similarly, a false positive is something that was accepted, when it should have been rejected.

If you have a sufficiently high candidate pool. you can (for a while, at least) live with an interview process with a relatively high false negative rate (that is, x% of the time you don't hire people you should have).

If it is typically quick to go from "in through the door" to "is a productive member of the team", it may be that you can live with a high false positive rate (that is, y% of the time you hire people you shouldn't have).

Honestly, these are the reasons I don't look for a new position.I make "good" money, but by no means great. I have the benefit of 20 years tenure and apparent stability in my current role. Trading that for more stress in hiring and gambling more stress in daily work doesn't balance the potential salary increase.

I've never understood the heavy emphasis on in-interview coding or brain teasers. To the extent that I've participated in the hiring process (both as an IC and a manager), 80% of the interview is assessing culture/personality/ethic fit; that is, the basic "do I want to work with this person" question.

The technical competence check is all retrospective, hearing them talk about prior projects and what the design and implementation process was like, how decisions were made, what the challenges were and how they were handled, any regrets/learnings. And most of that is just digging in far enough to confirm that the person was actually a first-class participant in it with a deep understanding, and not a bystander. Any whiteboard stuff would be "show us how the system worked" as a last-ditch check on basic communication skills.

You know, I was nodding my head in agreement as I read this when something occurred to me.

This all requires that the interviewer be willing to interact deeply with the candidate. Our profession has a (well deserved, I think) reputation for having a high percentage of people who really don't like interacting with others on a peer level.

Is it likely that a large part of the problem is that we have people doing interviews who really shouldn't be? I mean, if your typical response to talking to another technical person is immediately to try to one-up them, then you're going to be a really shitty interviewer. And that's exactly the personality type I see being described over and over in these anecdotes.

Not sure about English, but in my language we have a saying "The fish stinks from the head"

I can tell you, with quite substantial sample size from me directly and from people I deeply trust that every time we encountered an interview like this, we later found out that the company culture was really bad.

Those are not the kind of people you want to work with.

For clarity, is the "like this" in your comment referring to brain teaser technical one-upmanship interviews, or the less structured style that is focused on getting to know the person and having them describe in their own words the projects in their past?

I was referring to this:

> I had a similar interview with a different company last year. Three guys and me on a Zoom call with me sharing my screen trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career. When I got stuck they just stared at me. They would not give me any hints whatsoever. They just stared at me.

> Not sure about English, but in my language we have a saying "The fish stinks from the head"

English has this expression too, except it's "The fish rots from the head". (Which, when you think about it, makes more sense.) What's your first language?

> if your typical response to talking to another technical person is immediately to try to one-up them

The psychological reality behind all this is even worse.

The interviewer is not looking for new colleagues, he is looking to improve his own self-esteem and rank. The reward for rejecting a candidate is a feeling of superiority and an appearance of being irreplaceable.

The interviewer and the candidate have opposing goals, and the interviewer can randomly change the rules at any point.

Ugh, that's horrifying. I don't think I've been the interviewer and not felt the exact opposite, like "I'm desperate to have more people on the team ASAP; do we satisfice here and make it work or hold out?"

But then I've always been interviewing for my own future colleagues/boss/reports. I guess the dynamics could be different if you're in a huge company and just generically interviewing for new cogs that might get slotted anywhere.

I'm in semiconductor design not software but my goal is always "I've got way too much work, is this person good enough that after a few months of training they will be able to do some of my work so I can get more sleep?"

If the person is smarter than me even better! Instead of spending time teaching them maybe I can learn from them and get into their network so that if I ever need a job in the future they can help me out.

this is very well put, indeed both parties are set up to fail: - the interviewer has an incentive to fail the candidate, whereas the interest of the employer is to actually hire someone eventually.. - the interviewee is rated on something that has little resemblance to the actual job (difficult to succeed when you're not told what the admission criteria are...).

Some years back I wrote a post about interviewing, from the point of view of the _interviewer_. I emphasised that during the interview, the candidate is the most important person in the world.

It only later dawned to me that our industry has a non-trivial fraction of people for whom empathy is a foreign concept. They're not sociopaths, because those folks can at least feign empathy - we're talking about individuals who can't see themselves in another person's situation at all. On top of that, we don't really provide actual interview training to engineers either. Out of all the people I personally know in London, only one (1) has received formal interview training.

Is it any wonder that the interview gauntlet is such an awful experience for pretty much everyone?

That seems like a reasonable approach if you have the right skills for it. My problem with such an approach would be that I'd not feel comfortable to make an overall evaluation of a person based on a short interaction. Having a clear cut process with well defined metrics provides me with more confidence that I'm evaluating candidates fairly. Without it I'd be worried that my rating would be too biased by superficial stuff like how they dress etc. Something that at least in psychology research seem to mbe a lot more common than many people think. In general, looking too much at cultural fit would feel I'd risk "hiring my friends" rather than based on what value they could contribute.

That is a risk, definitely. And I think that kind of thing is probably in part why Google and others who followed them ended up where they did— wanting a system that was completely impersonal, quantifiable, and which could be said to be 100% meritocratic.

Which is noble, I suppose. But clearly lots of people still felt that it was unfair and alienating; closer in spirit to a hazing than a good-faith evaluation.

> I've never understood the heavy emphasis on in-interview coding or brain teasers.

Here's why https://blog.codinghorror.com/why-cant-programmers-program/

I guess, but I would hope that kind of thing could/would be smoked out in the course of a discussion following these kinds of prompts:

- Tell us about the approach you took with the take-home coding challenge. Why did you break up the functionality in the way that you did (modules/classes/functions)? What kinds of constraints or requirements would cause you to make a different call here?

- Tell us a debugging war story. What was the bug, how did you discover it and come to eventually understand the root cause? Any challenges with reproduction? What steps were taken to prevent it from happening again?

- Pick a feature of XXX programming language and explain how it contrasts with approaches taken in other languages. What do you like about it? It is more productive, efficient, safer, more explicit? What are the tradeoffs and how do you balance these? What kinds of projects would have you prioritizing using a language/ecosystem with this capability?

Someone incapable of writing a fizzbuzz program is not going to be able to bluff their way through an interview like this. Obviously you need to be committed to listening and exploring the space with the other person as opposed to flexing and looking for the "right" answer, but that's just part of the discipline of being a good interviewer and not a jackass.

I have found that a 30-minute discussion on a random variety of technical topics (including questions such as those posted above) is sufficient to determine whether someone has required technical expertise.

Coding exercises entirely miss the point, because writing code is the easy part. The hard part about good software engineering is being able to rapidly acquire problem domain expertise and knowing which engineering design choices enable rapid, scalable, and maintainable development to solve the problem. That's why companies using code exercises to screen candidates are generally not worth the interviewee's time to work for - it indicates that the interviewers don't understand the problem domain, either, and (by extension) that company is mired in mediocrity.

I've had code exercise interviews. I'm quite happy that I have never had to work for one of the companies that used them. I have never given a code exercise interview, and I've been quite pleased with the candidates that have responded and worked with me.

i've had similar experiences over the phone.

"How would you pull in data from an arbitrarily long -- maybe never-ending -- source of data in Python?"

me : "What kind of data? What is it used for? How should it be represented afterwards?"

Silence on the other end , followed by "Well that's up to you."

I then fumble out a few ways to do it (verbally), to a recruiter that doesn't seem to understand anything that i'm saying -- he's probably reading a question from a script and pattern-matching what I say to the supposedly correct answer given to him in the same script.

Finally it ends with "Oh, that's interesting. ...We'll get back to you." , and the interviews that go this direction -- they never get back to you; you've already lost.

I'm not spouting gibberish, i've been at this for a long time; i'm just not spouting out whatever tech-jargon that their company supports and is needed to conform to his script, and quite honestly the person on the other end of the phone call seems to be universally under-equipped to judge anything remotely CS related.

It's a really weird/ephemeral/surreal experience. Imagine a surgeon being appointed to a position at a hospital because the secretary quizzed him on some flash cards (flash cards provided by Acme Sharp Scalpels), and the surgeon -- by chance -- prefers Acme Sharp Scalpels, and so mentions that brand. Instant hire according to the flash cards.

That's a lot like what it's like when a technically-accurate developer gets passed over for one that blithely mentions popular software packages (pandas/tensorflow/whatever is popular this week) without any real technical knowledge on how to achieve the goals wanted by the hiring party.

> "How would you pull in data from an arbitrarily long -- maybe never-ending -- source of data in Python?"

The answer to this question is to use a generator. If you don't know this, then both people are going to wish that they had that half hour of their life back.

Is this a good question? If you want somebody with a lot of Python expertise, then knowing about generators is a good thing.

If I was interviewing a candidate, and they didn't know this, then I would just find a pleasant way to move on after a minute or two. If this is the only interviewing question, then that makes me happy, because this company has a flawed process, and is leaving some great talent for me to hire.

It's not a big deal if you didn't know this at the time. You might not have known what a generator was, and the person interviewing probably wasn't very good at interviewing people.

How about asyncio streams.py?

That seems like a good answer too.

I think that's only applicable if you are reading from a socket. Although I don't know too much about asyncio streams.py, so I'm not going to get a job at this company.

> > "How would you pull in data from an arbitrarily long -- maybe never-ending - source of data in Python?"

> The answer to this question is to use a generator. If you don't know this, then both people are going to wish that they had that half hour of their life back.

That's funny...I've implemented more than my share of such things in a long career, and my first intuition for an answer to the question, as phrased, was to implement stream sampling. It never even occurred to me that the answer might be a syntactical feature of the language (and yes, I know what generators are).

According to you, I'd be so wrong that I'm a waste of time.

Do you see the problem yet? It isn't theoretical. I've hit this kind of situation with so many interviewers that I'm actually more nervous when I'm sitting across from someone who is clearly on their first or second job out of school. They're asking (unclear) questions in the "python syntax" category, and I'm thinking about the engineering consequences of consuming an endless stream of data...

> According to you, I'd be so wrong that I'm a waste of time.

I don't think so, because you actually know about generators. If you were hiring for people who had a lot of Python experience, but didn't know about generators, that would be a bad sign. You would probably want to ask a some other questions, so you would have a more complete picture of what the candidate knows.

My main point is that the company's interview process is flawed.

> I don't think so, because you actually know about generators.

Sure, but will the OP give me a chance to demonstrate, or simply flip the idiot bit as soon as I don't give the expected response? In the context of a phone interview, I probably wouldn't get anywhere near discussion of python generators in an answer to this question. I'd probably say something like:

"For an infinite stream, my main concern is system resources, which are never infinite...I'd want to use something like stream sampling to calculate the desired metrics, but it's hard to know the right solution without more information about the problem."

Far too many interviewers hear that as weasel-wording, and simply disengage. It's even worse when the interviewer thinks they're asking a clear question about python syntax. It takes a high level of self-awareness to know that you might be the problem when you're the interviewer.

An experienced interviewer might engage with that, but many folks don't have the patience to listen to an unexpected response, nor the respect for the candidate to give them the benefit of the doubt. As I said, this pattern isn't theoretical. I've been on the interviewer end of this kind of pattern many times before.

> My main point is that the company's interview process is flawed.

Agreed on this.

This is a sign that the interview questions aren't there to actually assess technical ability, but are geared towards excluding anyone who hasn't travelled in the right circles. The employer isn't looking for someone skilled, they are looking for someone who is pre-filtered to think a certain way and know certain things.

Maybe. I tend to think that's a cynical take. Never assume malice when incompetence will suffice.

This is a...youthful...industry, and a lot of junior people (with "senior" titles!) are out there doing interviews. It takes experience to become a good interviewer, and if you've never had that experience, you don't know what you don't know.

No malice is needed. Just incompetence at hiring and defaulting to the kinds of measures that don't actually determine if the person has any aptitude.

How does "use a generator" answer this question? A generator can yield an endless amount of data, but if they ask "our customers buy things 24/7 on our website, how would you pull the endless orders into Python?" and you said "a generator", I'd think you were trying to guess the teacher's password ( https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-t... )

It surely matters if the data source is push or poll or something else, matters if it's a lot of data or a trickle, matters if you need all of it or if you can miss some (and how much), if the source buffers it or doesn't. I'd expect discussions about message busses, queueing, buffering (maybe ring buffers), data stores (maybe SQL or No-SQL), as well as concurrency or parallelism expecting the question could move to "and what if there was 1000x more data?". "Process stock market data" needs more than "read a temperature every minute".

Or at least for a candidate to ask about some of them and be told "this isn't so complicated", not "it's up to you". If it's only asking whether you can loop over a generator instead of trying to read all the data up front, the question could surely be more focused?

The question is garbage as phrased to be sure, but I think the auxiliary context matters a lot in this type of questions. Mentioning "python", when databases are language agnostic, heavily implies the answer is a language feature. Furthermore the way the question is asked (reading from a script) also implies there is a specific non-open-ended answer.

I still answered the question in my head on a whim, half-expecting it to be false, it's a really vague formulation. Sounds like the interviewer was randomly browsing language features and cutting and pasting random descriptions from whatever tutorial. Or maybe the company was using python generators in a really specific "data pulling" niche that the answer seemed extremely obvious to the technical team writing the questions and they forgot that outsiders are not wired to think of the same patterns.

>>The answer to this question is to use a generator.

Wrong answer.

The heap data structure would be a right way to go about representing such data.

>>If you don't know this, then both people are going to wish that they had that half hour of their life back.

Same in your case now.

> trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career.

that describes 2/3rds of the 'codility' tests I've been given in a few scenarios (toptal used it to weed me out). The couple of jobs I've been in where I was explicitly barred from ever asking any clarifying questions, or talking to business/SME folks about the problem at hand... I left those pretty quickly. I guess it serves to weed out people who have some hard-wired dependency on talking to people to clarify requirements.

Never understood this way of interviewing. I get shit now and then for helping people too much in coding exercises, but if someone has reached the point where they are obviously not going to progress why not nudge them along and see how they respond?

I've found that the ability to receive and act on guidance with a certain degree of humility is a much better signal of someone's potential than how many algorithms they've memorised.

Interviewing is hard.

It takes a lot of practice to know what level of assistance to provide at what time. A coworker once showed me a technique of keeping a google doc with the problems, as well as a step-by-step of the solution and the times at which they should be at that step. It always seemed to work out well for the candidates, as even a poor candidate would finish the problem at like 55 minutes into a 60 min interview.

Even with that, getting a person to see what they should be doing next, without telling them explicitly, is definitely a skill you develop with practice. I think you're right in erring on the side of too much assistance. You get to see much more of how the candidate works if you can skip over the part where they are getting stuck on something.

Yes some people just need a nudge in the right direction to carry the task through to completion. And some need to be pushed along the entire way. In either case they don't leave the interview feeling humiliated having floundered in the face of smug silence.

It is one of those common tropes, "interviewing is hard", that seems to justify the inevitability of poor attitude, wasting time of interviewees (remember the interviewers are paid for those hours) and a painful process for basically anyone. I often interview for my company/group and yes, it is challenging in one hour to find out "life, death, and miracles" of some guy who is being interviewed, but it is especially challenging when the interviewer is in a bad mood, does not want to be there, or sees interviewing as a nuisance, and he is looking for a reason to make someone fail. I worked at a FAANG and I got offers from FAANGs-adjacent companies, so I am not one of those you-cannot-win-at-this-game-so-you-complain people. I saw: someone stopping the interview for unexplained reasons after the first 45 minutes, an interviewer at a blue company looking at my private parts for a good part of 45 minutes, multiple people interviewing while doing something else in person or virtually, recruiters (those were the fronts, the hiring managers were responsible) dragging the process forever and then say no with zero explanation. Is it really "hard" doing better than that?

> and see how they respond

Actually being able to take a hint and work with the interviewer is a strong signal that a candidate, while maybe not the best for the job, has growth potential.

Right, one can note in the feedback that they got questions X,Y and Z but needed more than average / normal / acceptable level of hints. Better than sitting there staring down the interviewee in silence for 30min like a psycho. Then again.. it says a lot about tech management, doesn't it?

Reading all of these accounts of horrors in HackerNews I feel my idea of creating a "TOEFL for Developers" would be perfect.

(I am hesitant to describe my idea, but WTH, I'm currently not in a position to act on it, and they say ideas are dime a dozen so...):

For those of you for whom English is not your first language, you surely know what TOEFL is: Test of English as a Foreign Language. The private company provides a test where they evaluate a person for proficiency on different sets of English skills: Reading, Writing, Speaking, general comprehension. At the end of the test they give you a score for each of those and then a general score.

Now, the nice thing about the TOEFL score is its reputation: When you are going to study into a University (from Oxford to Liverpool, from Harvard to Queensland), if you are not a native English speaker, the university asks you to take a TOEFL (or equivalent) and get a score higher than X. As long as you provide that score, the university won't ask any questions. They don't doubt your English proficiency skills.

I want to do something like that but for development: Sure, University thought you CS101, CS201, etc. But what companies are looking for are specific skills (similar to say, https://sijinjoseph.netlify.app/programmer-competency-matrix... or https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhC... ). These very concrete skills that can be concretely measured.

I want this becase I've been dealing with recruiting, interviewing and also being interviewed for most of my career. And in my experience setting up a "recruiting wheel" in a company or startup is very painful. Most developers don't know how to perform interviews. Or don't care (who has time for that?). As an Engineer manager, having to comb through 400 resumes a week is time consuming and unproductive.

So I imagine a scenario where, there is this proverbial "Full Stack Developer" certification authority which is independent, very reputable and unbiased: They won't tell me if X or Y developer will make it into my team. They will tell me how does the person score in "Algorithms/Data Structures" or "Micro Services development" or "Frontend development" and then I will choose whether I want to hire them or not (according to my current requirements). That way, I only have to do a culture-fit interview and that's it.

In the past I have dealt with "Sourcing Agencies" that try to do something like that: They do the 1st technical interview, and they say that there will be alignment to what I want. But that was not the case: They send me 2 candidates and get very surprised when I reject one and not the other. And I feel our objectives are not aligned, so everybody is frustrated. Moreover, I don't want to have to deal with hiring agencies. And paying 1 to 3 salary months is too fucking expensive.

Now, as a candidate/developer: I would love to have a "TOEFL" like certificate that I can show, with my proficiency. That way, I can "look for a job" passively. I don't have to be making countless of code interviews showing one time after another what I know. I only do it ONCE for an authoritative company, and everybody else can check my qualifications there.

Companies like Microsoft or TripleByte have tried to do something like that, but the problem is again that they do other things: Their interests clash. Why would I trust LinkedIn? That's why TOEFL monetization make sense: The candidate has to pay for it.

I am aware there are some certifications: Oracle whatever, Microsoft whatever, AWS whatever. But those are either too specific/niche (WebLogic Server 12c administration exam) or they are only a "badge" (AWS Cloud Engineer) that doesn't tell you that much.

There is opportunity here for disruption. And I know that the problems that I've faced are faced by countless of other CTOs/Technology Heads.

certification authority which is independent, very reputable and unbiased

That is a big ask. There have been many attempts at CS-adjacent certifications, some of them government sponsored, but none of them find widespread use. The ones I've personally encountered were grossly out of date (e.g. a C++ assessment that didn't mention templates at all, in 2012), and weren't even mentioned during interviews by the company that demanded them.

It's not just a matter of trust, either. Our industry is incredibly conceptually diverse, despite the common current of abstract patterns that underlies everything. There is no specific or generic skill test that won't be out of date in a year, and forcing the required degree of standardization on our industry to make that possible would effectively destroy it.

In the mean time, the only organizations incentivized to keep their assessments up to date are the vendors themselves, who as you note, have conflicting interests. And at root, if you want to be even slightly more generic than a vendor certification, you are basically trying to test for intelligence and adaptability.

They should. My university had a minimum TOEFL score requirement. The number of grad students who passed that requirement, but then couldn't write a coherent English sentence to save their lives was still incredibly high.

> my idea of creating a "[standard aptitude test] for Developers"

Already exists. https://news.ycombinator.com/item?id=27662804 Don't you have apprenticeships in your country?

I am compelled to write all the list of things why it will not work :) unfortunately I don't have that much time in my life. Don't take it as putting you down, I would love to see such thing working and live in real world, so look at it as problems that would need to be solved while aiming for grand solution.

First, there are wrong incentives at play, good guys currently don't need that as they mostly are employed and look for jobs passively. Good guys don't care about certificates and you want to certify good guys so your certificates mean something and can build trust. Weak guys will be spending money to cheat their way around just to get passing grade, which will cost money to prevent.

Then you have hiring managers that will not use this exam as good enough just to hire a person unless there is big company that would do the same. So you have chicken and egg problem, because no one will trust your certification and to get the trust someone would have to use it.

My idea is that you cannot effectively hire at scale. I could hand pick maybe 5 devs/year for my company, getting to real numbers in my small company I can see that we can hire maybe 2 developers per year. When We hire someone it worked for me with simple questions and attitude check. I don't see a way to hire 100 good developers in 1 year, that is not possible. Maybe at a scale you can hire 10-20 good developers a year but you have to have 3-5 people involved full time - and ideally those 3-5 people should be nice and technical - where in the end you don't want to use them only for hiring because those are probably your best developers with soft skills.

For that competency matrix - that is something you can do when you have developers inside of the company and you can observe them for at least 6 months. Good luck getting that in practical testing setup for 2 or less hours. I also find those kind of matrices terrible and not useful for evaluating people or projects. I work on a project where we were not fitting in anything of what was in the matrix .. yet we were delivering good quality for business all the time, while teams that were stuck on their "competency matrix" trying to improve meaningless points ended up disbanded and not working anymore in the organization.

> Now, as a candidate/developer: I would love to have a "TOEFL" like certificate that I can show, with my proficiency. That way, I can "look for a job" passively. I don't have to be making countless of code interviews showing one time after another what I know. I only do it ONCE for an authoritative company, and everybody else can check my qualifications there.

One interesting thing about TOEFL is that it is, arguably, correct and complete. I.e when using the English language you use 100% of the skills the test measures, and the test measures all skills necessary to thrive in English. That's why you only need do it only once (every X years).

Engineering skills as defined by those matrices are so much more open ended that you'd need specific matrices tailored for different positions. E.g. a front end developer doesn't need to know what a linked list is. Then you end up moving away from the idea of ONE authoritative test.

Also worth noting that wherever I've seen it used, TOEFL is usually a mere checkbox to tick, and there are other, more thorough measures of skill involved.

My honest opinion, at this stage in my career I don't have any patience at all for explaining technical concepts. Its almost never a one off, once you have to hold someones hand, you always do. And if you don't, they are creating technical debt.

  > We as an industry really REALLY need to figure out a better way of conducting interviews.

maybe i'm naive but, how about just ask the candidate to make a mini version of what they would actually do irl?

if your an app dev: make me an app that does x, you have 60 min

if your a rails dev: make me a site that does y, you have 2hrs

if your a pdm: make me a spec and tickets for a system that does z

maybe i'm missing something but it shouldn't be too hard should it?

It's all the potential criteria around the request that makes just that one piece more complex than it seems.

For example; "Make me a site that does x, you have 2 hours" Do I need to build the app in front of you? Problematic because how often does one build an entire web site in a couple of hours, while someone is standing over their shoulders scrutinizing every keystroke?

Do I take it home and do it? If so, how do I prove to you that I did the work?

Do you care what framework I use? Do you care if I use Open Source code?

What design should I use? Where do I get the site assets from?

If I'm building this site for you, are you paying me for that time?

Then there's the non-technical parts missing from an interview like that:

How does such an exercise tell you that I'm the kind of person you want to work with?

How does such an interview provide me an opportunity to ask you question? It tells me nothing about you or your company which is every bit as important as you finding out about me.

I could absolutely never ever make anything with people staring at me. I need to be alone with my PC.

Had a colleague have a similar interview with Reddit for an infosec/appsec role. They said it was a shit show, no feedback, never heard back. Sourced through an external recruiter, so Reddit is burning some recruiter's time churning through candidates. Picked up by someone in finance at similar comp a few days later.

They're too busy writing self congratulatory blog posts on their hiring process to have time to improve it.

https://alexgolec.dev/reddit-interview-problems-the-game-of-...

It's a good signal for me when I'm presented with silly brain teasers like this in interviews, especially when the technology of the company isn't that great.

I'm interviewing you too, so give me something that reflects the problems you solve as a team, otherwise my assumption is your office is full of white boards containing puzzles of the day and your tech is all 3rd party libs.

I wouldn't actually class this as a brain-teaser. It is a non-trivial[1] problem that doesn't require an "aha!" moment to get right. It is amenable to multiple ways of reaching a correct solution. It has interesting follow-up questions. It also stands a minimal chance to actually discover (some) of the way a candidate thinks. It is also implementing the VM for a Turing-complete computational model.

It may also be that anything work-related is actually too long to fit into a limited interview time.

Now, a trivial, brain-teaser, question would be "you have an NxM matrix, and you can either go left or up. How many paths are there from the lower left, to the upper-right corner?"

I consider it a brain-teaser because if you write code that contains any matrix manipulation or searching, you have basically failed. There is a closed-form expression for the number, so...

[1] By "non-trivial", I basically mean that there are multiple correct solutions.

That's actually a nifty problem in itself, I don't see anything wrong. Of course I have learned that the actual "proposition" of whatever problem is not what is right/wrong in an interview.

The way I would apply that problem interviewing someone is: We have 1 hour. Here is this problem (to which of course I know the solution to already).

How would you solve it? Let's solve it together so that I can see your decisions, your code, do you use exceptions? do you use specific type of exception for different errors? do you split functionality in a lot of functions? do you know nifty language tricks (maybe a bit of code golfing or functional constructs if JavaScript or Ruby).

The problem comes when the "interview problem" is passed from the creator to the "mid-level" Engineer who now has to do the interview. For them it becomes: "Ok, you gotta implement this in one hour", and they don't know the nuances or reasons for the problem.

I've seen this first hand with an equivalent problem. I had all this nice interview process that I applied, and the first time I shadowed one developer so that he could do the interview, he was just looking at the poor interviewee fail due to nerves, with the aim to evaluate him only on the merits of how far a set of working code did he had.

I interviewed for a director of engineering role there — met the CTO, very informal ahead of the actual interview loop. Recruiter said they would follow up. Crickets. I followed up. Silence.

It was quite weird.

As someone passively looking, thank you for this. I'll remove Reddit from my list. That is unacceptable. I do 5 interviews a week on average for my company, and if we did that to candidates, heads would roll.

As an interviewer your two objectives are:

1. Ensure the candidate has an excellent experience

2. Collect data points

In that order. Sometimes we run into candidates who make the second item difficult. They fail to complete the specific technical problem. They can't speak about their experiences in detail. We need to drag data out of them screaming. It doesn't matter, your priority is to ensure they feel respected, and leave thinking they WANT to work there.

The last technical interview I did was for Facebook, and say what you will about them, it was a great experience. Before the interview they actually gave me a couple paragraphs about what I was going to be tested on. Needless to say, I nailed it. :D

> I have over 20 years of programming experience, am a founder, and have worked for multiple venture backed startups.

Do you want a pat on the back or something?

Probably not? They most likely want you to know they've been in other interviews in the past, and this one was particularly egregious?

The implication is that they aren't new and they've had ample opportunity to be humbled and grow. That their perspective is the result of experience. Thats all.

I also interviewed with Reddit, although it was a few years back at this point.

I thought I nailed their code challenge and expected to continue through the process, but after that session that was pretty much the last I heard from them. It was pretty disappointing.

One of my buddies gave me this useful insight once: the impression you give your candidates, even the ones you don't end up hiring, will likely be the last impression you'll get to make on that candidate and the tech world is very small. Negative experiences will impact how candidates perceive your company and word of that experience will spread. Always be respectful to the candidates. If nothing else, they took the time out of the day to meet with you and go through various obstacles, etc.

It's too bad your experience was so negative. That's going to be a datapoint in my mental dataset of companies to consider when the time comes.

> Reddit’s hiring process converted me from a fan of the site into someone that thought the entire organization was second tier - which obviously it is in terms of monetization - but also in how they treat people compared to the FAANGs.

And from a completely non-technical persons perspective Reddit is incredibly disorganized at the executive management and corporate level. The amount of turnover, controversy, business model revamps, etc. for a 16 year old company with the hype they have is unique and unprecedented. It's not surprising whatsoever that their hiring practices are similarly disjointed.

I interviewed for a front-end dev position (it was my first ever interview in the industry, I vomited before I got there so it was a pretty crazy day).

I come in. The front-end guy starts asking me questions to try and solve something he is working on. No-one else is there yet. He is asking me about why a JS compiler is removing his comments, I say I don't know, I have never had that issue before...I make an off-hand comment that I use React and most of my JS code doesn't have comments because I am just working on projects by myself, and I don't do a lot of library code...the manager comes in at this point, and proceeds to berate me about why commenting is essential. I say: I use comments where they are needed. Off he goes, again.

Interview starts. Manager proceeds to go through a series of questions designed to expose my ignorance. None of which are related to the job. One classic was him explaining to me that database normalization made no difference to the size of the database because "the data is all the same on the disk" (which is, ofc, not accurate...I tried to explain, he just kept repeating that over and over...he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin). For some reason, there was also a back-end guy there who, upon hearing that I built something in Java, proceeded to launch into a series of questions on internals of Java (for example, he asked me what the difference was between certain versions of Java and the size of the heap...perhaps unsurprisingly, he also got some of this stuff wrong but began laughing when I said I thought X was Y).

The only two questions that I had about front-end dev were: the front-end guy trying to ask me to help solve an issue he was having (before the interview, when no-one was there), and a question about the value of this in arrow functions (which I got wrong, but is also an excruciating thing to try and explain, so I don't think the guy knew whether I got it wrong...it is a terrible question). That was it.

>He is asking me about why a JS compiler is removing his comments

Huh ? language parsers remove comments because they're comments, that's literally by definition. Are you (or your past interviewer) using "comments" in a different sense ?

(Also, not trying to be a pedant on you I swear, but technically JS is traditionally interpreted. Most mature runtimes have compilers but it's not part of the API. It's just a juvenile pet peeve of mine when language implementations are generically referred to as compilers.)

>he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin

I sincerely hope from my heart of hearts that company or department is in it's well deserved position in the depths of the toilet now, or at any rate that specific person.

I actually can't remember the details. I believe we were talking about Babel...so, technically, a transpiler. Or it actually could have been one of those code bundlers (I seem to remember they were using browserify...this was a while ago but I believe most people were already using webpack then...JS...what a mess).

Actually can't find him at the company anymore. But the company isn't doing too well (although they seem to have moved into a nicer office). Revenue down 50% last year (from a small number to an even smaller number), costs up 60%, losing substantially more money than they have revenue, the operations guy who did my interview isn't there anymore either...true "tech company things". I didn't the impression that the company was that bad, they were more "much steam, no fire".

> it was my first ever interview in the industry, I vomited before I got there so it was a pretty crazy day

I'm really sorry to hear this, that sounds incredibly stressful. The worst part about stress in technical interviews is that even under good interviewing conditions (which you clearly didn't have) it can really hobble a candidate to be stressed.

I hope this experience (or this HN post) doesn't scare you away from programming or interviewing at software companies in general. Those guys sound like jerks. There are good companies and decent coding interview routines out there.

My favorite interview surprise was when I was asked to craft a presentation on an interesting project and be prepared to discuss it. When I got on site, it turns out they wanted me to present it cold to the entire dev team of 50+ people.

Reminds me of how too long ago they ended up hiring someone with a very controversial background, and quickly backpedaled on the decision. Seems like they need to take a long look at their hiring practices

I have a not dissimilar background and what you describe is exactly what caused me to throw up my hands and leave the tech world. It's just not worth the BS.

What do you do now? I'm looking to stay in tech (for now), but I'd really like to get out of web development at the very least. Though, I'm not entirely sure where to even begin my long journey.

My educational background was CS and business, I spent 23 years in a wide range of technical, managerial, and consulting roles, and now I sell real estate in two states (our market spans a state line). Would be happy to chat anytime about career ideas.

That's very kind of you, I think I will take you up on that offer. I've only been in the field for like 5 years as of next month. Do you have a preferred form of contact?

Sure - see my profile.

> In an environment I am unfamiliar with

I had an technical interview with a company early last week, we did a shared session using VS Code. The interviewer wrote the function signature, and I filled out the implementation. I did great, according to the interviewer, and moved to the next set of interviews.

The next interviewer, which turned out was also technical, ended up opening up a shared Google Docs to write code it. I asked if I could just share my screen in my own editor, but they couldn’t give me permissions to do that. I was given an extremely vague question. When I asked questions, he told me to stop because he was holding out for next iterations of my implementation (again, in a Google Docs). Given no structure and an absurd environment, I completely bombed it. And to top it off, instead of getting an email saying they were not interested in me, they just ghosted me all together. A complete waste of time. I wish them luck in their endeavor to find the best engineer to write code in Google Docs, since that is apparently what they are interviewing for.

reminds of of the systems design interview I had with Google, the interviewer had his webcam off, barely spoke English and had me trying to make diagrams of system architecture in google docs with no reference of what he was actually looking for

it was like sitting in a confusing nightmare for an hour

This is when you open a can of BS and just spray it everywhere. Go for the most esoteric and ridiculous design that you can. Elaborate on the minutia of your design at the finest level. Puff your feathers and flaunt your genius. Both bore and impress your interviewer at the same time.

I suppose I could have, I'm not 100% sure he was paying attention to me

either way I ended up getting a cooler job somewhere else so maybe it was a good thing in the end

"If you can't dazzle them with facts, baffle them with bullshit"

I had an interview with Gitlab like that years ago. Here, write some chef with only the vaguest spec - even after quizzing the interviewer to ascertain requirements.

Had a similar Google interview ~10y ago, shared GDoc. Phone connection was poor, interviewer refused let me try another line. I'd ask clarifying questions and he'd just keep acting annoyed and saying "Are you done yet?"

Frankly the most annoying interviewer I ever encountered. Served as a low water mark and inspiration for me to be as helpful, thoughtful, and kind as I could be in the next 100 phone screens/interviews I conducted for my employees.

FWIW, I've been to many a Google campus and know many employees there, so I think this was an outlier.

I wonder if you are marked as never-interview-again if you leave mid interview citing reason X.

I'd almost rather physically writing on a whiteboard than using something like Google Docs to pseudo code in. I don't know how someone even remotely technical would think that was OK.

I’d be very tempted to end things right there… or use the most obnoxious font I could find.

> next set of interviews

I really dislike when companies do this. It's very time consuming and psychologically/emotionally draining.

Leave a review on glassdoor please

The first time I interviewed at Google I didn’t make it past the phone screen. I bombed a question about an appropriate length of a Bloom filter because I hadn’t recently been thinking about Bloom filters, and I was summarily rejected for onsites. The second time I interviewed I was asked a number of questions that I was perfectly “primed” to answer. Because those were in my brain’s cache, I was able to get through the full interview loop with a “hire” recommendation.

My focus is security, and so the second time around I got Travis Ormandy as an interviewer. I was able to impress him well enough with my IPSec foo to make it onsite. Then I got asked a question I had already been asked in another interview with another company, and I was able to knock that out of the ballpark (I mentioned I already knew that question, but the interviewer wanted me to answer it anyway). Then I got asked a question that used recursion, and because I took a graduate course on induction and recursion within the past year, that was effortless for me. Then I got asked a question that involved a kernel feature, and because I happened to recall the Linux kernel list macros and semantics (something I couldn’t repeat now over 10 years later), I really impressed that interviewer.

I ended up having a really successful part of my career at Google, even though I ended up not really writing much code when all was said and done. However what code I did write was highly impactful.

Looking back, things could have gone very differently if I had gotten a different set of interviewers and/or questions. The questions I got just happened to coincide with what was “paged in” to my “working memory,” so to speak.

this needs to be one of the highest rated comments squarely due to how much luck (or gruelling prep) is involved in effectively memorizing answers, i.e. the issue with technical interviews to begin with.

> I bombed a question about an appropriate length of a Bloom filter because I hadn’t recently been thinking about Bloom filters, and I was summarily rejected for onsites.

I've never even heard of a Bloom filter, so I know how I would have done.

Bloom filters are really cool for space-efficient "have I never seen this before?" lookups. If that is a question that code you write frequently have to answer, Bloom filters may be a good choice. The Wikipedia page actually seems as if it's not too horrible,

Yeah the amount of trivia folks like to throw out, and the assumptions made based on them is absolutely absurd.

I've ran into "OMG he didn't know that!" responses when one dev disapproves of a candidate. Inevitably I ask "Really how often do you need to know that? and if you needed to wouldn't you just google it and be done?" but we assume it means so much more and there you go.

Then someone else gets hired and they knew the trivia, but can't apply it or worse only really knew the answer and not the ramifications... or they just can't wrap their mind around / don't care to think of second order effects or whatever.

That all makes sense, and it bothers me, too, but they do hire somebody eventually, which implies that somebody can produce quality results in 50 minutes in a high pressure situation in an environment they're unfamiliar with and people they just met.

>implies that somebody can produce quality results in 50 minutes…

This is more a random fluke as much as sampling bias. Akin to someone either getting lucky or someone who is coming from a very similar environment. This isn’t a measurement that guarantees someone is competent, rather it’s a guarantee that someone is coming from just as incompetent an environment as you have.

You know the company is on a good trajectory when the new hires are a little less incompetent than the past hires.

Note: This depends on hiring style. Some companies have a bar and everyone who meets that bar is hired. Other companies are hiring for a position that gets one person...

These results may be "curved".

If you give the same easy test with no pressure and everyone is sufficiently good, then it was a waste of everyone's time.

In such an approach, you do something that is sufficiently hard that you're able to identify the people who are the better performing ones along with a reasonable idea of how well they work under pressure (because that will happen at some point).

Is it testing the right thing? Probably not. However, we still haven't found "the right thing" that is able to scale, respectful of the time of the candidate, not too intensive on the interviewer, and minimizes biases in hiring (same set of questions to all candidates, same grading scale).

> Is it testing the right thing? Probably not. However, we still haven't found "the right thing" that is able to scale, respectful of the time of the candidate, not too intensive on the interviewer, and minimizes biases in hiring (same set of questions to all candidates, same grading scale).

Maybe because the concept of a test is flawed? It seems to me like every company that uses a whiteboard test gives out the same tests anyways.

What are they really trying to test? If someone understands common algorithms and data structures? I dont see why that couldnt be determined by a simple interview with an engineer. A test might be useful for a HR recruiter who doesnt have a computer science background, but those tests are usually conducted by other engineers anyways.

The whiteboard thing just seems to me like an arbitrary hazing ritual.

Or they have have a really high hackerrank score and know the answer already.

Or they just hire the guy they knew through their network. A lot of "how to beat the tech interview process" advice is about how to break down the door with a battering ram when you don't have the key.

This is basically the advice I give everyone I know when it comes to things like this, "If you're going through the front door, you've already lost."

My experience has been that this applies to recruiting, hiring, BD, sales, fundraising, etc. Anywhere that there's a systemic principal-agent problem.

This is fairly true. The easiest side-door if anyone is wondering is a recruiting firm. At least with those there is already a somewhat simple contract in place that helps get rid of poor people.

I am wondering if the entire interview process should just be pay them for 2 weeks and see if they stick.

> If you're going through the front door, you've already lost.

I've heard that advice in various forms but I must say (anecdote incoming) - in my own 30 year career, the best jobs I've ever had were the random ones that I just applied for and the worst ones were the ones that somebody I knew from before recruited me in from outside.

hmm, I guess I can say a reasonably good one and the worst one ever that almost made me quit programming came about this way. The same guy recruited me in both places.

How many jobs have you had? You talked about the best and the worst. Can you comment on the relationship between (y-axis) quality of job and (x-axis) strength of personal connection before you joined. If you plotted a scatterplot, what relationship would you find?

I've changed jobs ten times since 1992. As it works out, exactly half of them I was recruited into by an internal reference and the other half I found on a job board like Monster or LinkedIn. By far, the two best were relatively large organizations that I applied to cold, and the two absolute worst were actually the ones I was most actively recruited into by former co-workers. I suspect that the problem in both of the latter cases was that they worked so hard to bring me in that they ended up overselling me - I'm good, but I'm also a human who has two kids to look after. On the other hand, if I'm "just" the best candidate from the pile of resumes, expectations seem to be reasonable.

Very few people hired at big tech enter through their network without a technical screen.

Speaking only of ICs:

From principal engineers down, there's a technical screening. Distinguished engineers? Maybe. But then you're speaking about Guido van Rossum, James Gosling types.

I was a hiring manager at Facebook, and even when there was someone we specifically wanted to hire, they still had to do the same coding interviews that a new college grad has to do.

Or their standards drop enough to hire someone

I have done that in the past, and I've failed miserably in the past as well.

Am I on the top of my game right then and not stressed about anything and the questions out of the random million possible questions that could come up are ones that I just happen to have had on my mind recently? Then I ace the interview.

The last time that happened it was in a big international consulting company, they then put me through 5 other interviews afterwards, each one telling me I would hear something back in the next couple days.

The last one I got told couple more days, they didn't call me back for nearly two weeks. Then they call: Hey Bryan, we would complete the offer process now hope you're still interested?

Uhm unfortunately I got an offer last week for a 6 month consulting project, sorry but I had to take it because they said they couldn't wait to see how this turned out.

on edit: clarification.

I have known of many positions that stayed open for years until the position or company disappeared.

This is a great point.

In many other fields (medicine, law) people study a standardized body of knowledge, take a standard test and then get a license so they can do something others cannot.

However, this doesn't prevent a lot of awful and a lot of great people getting through. You would still need to interview a lot of them. I wonder if it sets a minimal level.

For the top law firms, things are pretty straightforward. You have to pass the bar, there's the school you went to, your class rank at the school, internships and clerkships, and then associates are largely up or out.

I assume it actually works pretty well but there's obviously a huge amount of gatekeeping involved.

> I think a lot of this is because our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’

Someday soon we may accept that what gets classified as software engineering is actually an amalgamation of skills from an entirely different set of titles/careers, most of which treat software creation and management as a tool and means to an end.

I don't generally consider a blacksmith and a welder to be the same occupations. You can lump them under metalworker, but would you really expect the interview process for these roles to be at all similar?

If they were applying in the tech industry you would. Might as well lump in metallurgist, chemist, materials scientist, and sheet metal workers because we do this in the tech industry. Everyones a generalized set of specialists rolled into one.

It's because there isn't one. So much professional advice seems to be based around a SV/FAANG mode of operations, but that just doesn't apply to a good 90% of the industry. Most tech work is done on line of business software, not megascale internet companies. Building high-design marketing websites is completely different from enterprise SaaS is completely different from infrastructure is completely different from video games is completely different from desktop software. Not just requiring different tech skills, but different personalities and working styles.

True. Furthermore, many of these FAANG sites work terribly and are ridiculous to navigate. Where is the logout button? Oh, they purposely hid it several levels deep under a strange tiny icon menu where users won’t find it … so users stay logged in and they can be tracked by the advertising markers.

Or, why did the screen just scroll down and lose my place in the paragraph? Oh, they loaded an ad in the middle of the document and the page re-rendered itself causing jerks and fits on the screen. Nice job FAANG site!

Or try performing a sort of items by price or whatever other criteria … doesn’t work because the website wants the user to see the “suggested” items no matter what search criteria was desired y the user.

And …

This really is the problem. And I think it leads to a lot of the dysfunctional interview behavior that we've all seen. Interviewers are having to make up their own evaluation methods but really haven't thought through what the acceptance/rejection criteria should be.

I mean, we have things like the SWEBOK (https://www.computer.org/education/bodies-of-knowledge/softw...) that could be used to build a set of interview questions and acceptable responses, but does anyone use it for that?

The best interviews I've had, either as the interviewer or the candidate, have been when there was a discussion and a free flow of information in both directions. Unfortunately, it seems that in a lot of places, this degrades quickly into a hazing ritual.

It really would be nice to have some kind of license at this point. For interviewees, it sucks because you basically have to take your license exam for each company you apply to. Interviewers have to administer this exam, and they may not be that good at doing that either. They’re more interested in getting to know candidates and hearing about their experience.

I had an interview with a company a few years ago -- on paper it looked like a perfect match. During the interview things seemed to go well, but things took a turn for the worse with the technical lead's interrogation.

He asked five or six questions related to C and C++ undefined behaviour, a very open-ended one about a technology I'd never used. I answered as best I can, but always opened with "I'd be referring back to the C standard and opening a JIRA task to fix the code". We got on to how I'd fix the code -- remove the UB, but only if there's a unit test covering it. What if there are no unit tests? What if there's no JIRA? Lots of what-if-maybes.

A few days later I was on a 3-way call with the recruiter and one of the guys that interviewed me. They spent the whole thing telling me how "any decent developer" should have known what the UB would result in, shouldn't have to refer to standards or books... and on and on. But as a courtesy, they'd be happy to make an offer.

Half the minimum posted salary, no benefits. It was right in the middle of the minimum wage and the "living wage" lines.

I declined politely, and the recruiter hung on the call...

"Wow. I don't know what to say. That's never happened before... do you mind if I share the recording of that call with my manager?"

They were still advertising to fill several positions when I last stumbled across them on Glassdoor a few months ago...

I thought the actual thing with C (and probably C++) UB is that, well, pretty much ANYTHING is allowed to happen (by the standard)? Including, but not limited to, nasal daemons.

this is advice i give to a lot of people trying to get into the business or switch jobs. no matter how prepared or qualified you are, every interview is a roll of the dice. maybe the interviewer is in a bad mood. maybe you're in a bad mood. maybe there's a communications barrier. maybe there's some organizational issue (too many candidates in pipeline, re-org, etc.) that causes the bar to temporarily be set extremely high. It's ultimately a numbers game and it doesn't make sense to get too invested in one company or read too much into one result

It doesn't help that so many concepts on CompSci show up in different places under different names and labels.

I haven't participated in technical interviews in a long time, but when I was asked to do it, I made it a point to throw as many lifelines as I could until I got a satisfying answer. For instance, if want to know if the person understands generics and they can't answer the question outright then I'll ask them about C++ templates. Similarly, if someone can't describe the term "idempotence" I'll ask them "can you tell me what makes a function pure".

Mind you those terms aren't interchangeable but if you catch one it should be trivial to understand the latter.

Even if someone's never heard of idempotence, it's enlightening if you can get them to discover it for themselves by asking questions like, "What happens if this request gets sent twice due to a network issue?"

I think it's because software varies vastly in complexity and spans many domains. Every software engineering role may use a generalized skillset to a degree, but I feel like there can never be one all-encompassing bar that can effectively cover the requirements of every role.

You mean like Law?

The same would apply for law and medicine, but those fields have chosen to make a requirement where specialists do have to be generalists first and have to learn and be examined on the whole field.

Becoming a specialized divorce lawyer still requires you to pass certification on things like criminal law and constitutional law (among many other things), you won't be permitted to practice law if you know just your specialty, no matter how well you know it.

Becoming a heart surgeon still requires you to pass certification on pharmacology and gynecology (among many other things), you won't be permitted to practice medicine if you just know your specialty, no matter how well you know it.

But for software workers we do accept that you can ignore many related (and even relevant) fields and just learn only one niche of technology - we could make an all-encompassing bar, but it would be a major change and I'm not sure if we would want that.

>our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’.

They even do this crap to people with CS degrees. If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.

I started in this field in 1997. The interviews were more old fashioned, a few tech questions, see if you were an oddball, then they'd get back to you. If you didn't work out, they would just fire you. Pretty simple.

> If a 4 year CS degree isn't enough

If it's not enough for an employer, it's because that employer devalues what's taught in most CS programs. Granted, there's a significant mismatch between CS degree work and real world work, but that's true in lots of engineering. Ask any engineer in whatever subfield how much time they spend solving differential equations. I mean, great that I learned how to balance a binary tree and write a heapsort in my DS&A class, but have I ever needed to do that at work? Other than to pass some stupid coding interview?

> They even do this crap to people with CS degrees. If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.

Not all CS degrees are created equal I'm afraid.

A CS degree often doesn't have jack to do with being a professional software engineer

> If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.

I’ve interviewed many people with 4 year CS degrees who can’t really code. I’m not sure how this happens, but it definitely does. I disagree that having a CS degree should excuse candidates from coding interviews.

My current company works predominantly with 2 major programming languages: Python and JavaScript. This is made very clear when advertising our open software engineering positions. Despite this fact, we once had a CS graduate (from a top-tier US university) who applied and was unable to write a for loop in either language. Yes, that's right: a for loop.

recently interviewed with Robinhood. Their phone screen started with a system design interview, but man I felt so uncomfortable using the tool that they had shared. The interviewer created a text box in the tool and copy pasted a multi paragraph question. The font sizes were little too big, I had to constantly scroll up and down to read the question. After brief introductions, giving previous work/project summary, understanding the question, stating and clarifying my assumptions, writing down product requirements, identifying tech stack, I was already 25 minutes in for 50 minutes interview and from there on I was told to speed up and within the next 20 minutes, I was asked to make it scale, fault tolerant and all this even before I could properly illustrate and communicate my design. It was very confusing to be constantly switching between different design paradigms before being able to explain one. As expected I didn't clear it but at the very least the recruiter later did follow up and I communicated my feedback on the interview. Hopefully they take these feedback and make the interview process better.

Your comment explains why the variance is high; it doesn't explain why the mean should be low.

In other words, there flipside of what you said is that sometimes you'll excel and be offered the job on very attractive terms.

> I think a lot of this is because our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’.

Credentialing organizations already exist[1], but none have lobbied the US government to prevent the uncredentialed from practicing.

Perhaps it's time. If none of the existing orgs are good enough, start a new one.

1. https://www.computer.org/product/education/professional-soft...

I’d be happy if some organizations started accepting a credential in lue of a coding interview, and just did a design/architecture and cultural interview.

People here are suggesting credentialing as if it will remove interview requirements rather than simply add a new hoop to jump through. I do not believe required credentialing solves the interviewing problem at all. You see it today with the certifications that already exist in the market. They aren't worth the paper they're printed on. Anyone can trivially study and pass the certification tests and still never have implemented a system, nor even have basic programming ability.

Adding a new hoop is the desired effect, and it does solve at least one problem. If you're at a tech company or some other org that interviews well, you might not have seen it yet.

Many devs are not good at their jobs. They mean well, but they can't solve basic problems without looking at stack overflow. And by "basic", I don't mean leetcode, I mean iterating over a collection.

> Anyone can trivially study and pass

Yes! At that point, I would know that the guy sitting next to me did at least some amount of studying of the fundamentals.

A real credential with teeth would likely eliminate plenty of the "Does this person know anything at all" element of current tech interviews. I've interviewed people who didn't even know what a for loop was or the difference between the stack and the heap. If there was a piece of paper which said that the candidate knows at least the bare minimum about software development, you could at least start the interview at a more advanced (or domain-specific) level.

I doubt hospitals interviewing senior doctors need to ask them basic anatomy questions, or law firms needing to ask candidates the difference between tort and criminal law. Tech could benefit from this minimal minimal bar.

Just turn the Leetcode-style data structures/algorithms segment into the basis of this credential, so it at least doesn't have to be repeated ad nauseam each time an applicant interviews with a different company, despite having the least relevance.

Triplebyte was trying to do this a while ago, weren't they? My last observations from a year and change ago suggested they were running into what might have been signaling equilibrium issues / risk aversion, but I'd be curious if there's other perspectives around.

That's what Triplebyte is attempting to do, yep. But it does seem like a considerable challenge and they're still figuring out their product. Also feels like for an industry-scale problem like this, it would require a consortium of the major employers (not just FAANG but large companies from Microsoft to Intel to Oracle and beyond) to hash out some sort of standard, not to mention a body representing the engineers (if not a SWE union, at least something like the IEEE/ACM) and the academic institutions that provide the education.

One wonders what the history of how the credentials in medicine or law were forged.

What is the interview process like for architects? Lawyers? Surgeons?

I can't speak for architects, but there is a very high bar for licensing for them. For lawyers, I had a friend at a top tier firm that interviewed with another and had to do a full doc review- essentially doing several hours of actual work. They were moving to a small boutique firm outside of "big law" so this may have been somewhat outside the norm.

> I’d be happy if some organizations started accepting a credential in lue of a coding interview

Sure, but what credential exists that both is reliable enough to support that use and would remain reliable enough once it became used that way, even in a specific narrow subfield of development?

A majority of Silicon Valley-style tech is now using data structures/algorithm interviews, so it already is a de facto credential.

Didn’t this exist with the PE designation in software engineering in the US?

https://www.nspe.org/resources/pe-magazine/may-2018/ncees-en...

Yep. It existed for a while. It was canceled (as noted in the article) because not enough people were taking it.

I looked at it briefly but realized that I would need to study a significant amount of engineering aspects (how much water can flow through this pipe type engineering) to be able to pass the first exam.

For people who are developers, while the ethics, principals, rigor and similar type aspects of the PE exam process are useful, that it is still focused on being a PE first and a PE with an Software specialization second means that most people who are software developers would not be able to pass it or find use in the additional engineering principals that it provides (you wouldn't want me to sign off of a building design... well, maybe if I studied enough to pass the FE exam first...)

So, first I'd have to take the FE Electrical and computer exam... https://ncees.org/wp-content/uploads/FE-Electrical-and-Compu... or go with the other disciplines exam - https://ncees.org/wp-content/uploads/FE-Other-Disciplines-CB...

Either way, there's a lot of material there that I don't know and I don't imagine most CS new grads would have a clue on.

And that's just the FE exam. After four years of under a PE, then the PE exam - https://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pd...

It's just not worth it.

Reply on news.ycombinator.com