Live data from Hacker News

In defense of coding interviews

biggestfish.substack.com

381–390 of 391 posts

Re: In defense of coding interviews

#381
post #378

Earlier quoted context omitted.

By "demonstrating their skills" I meant demonstrate to what extent they have skills, not that they were all very skilled or could do the work. They were nonetheless able to prove what they did know. I've done hundreds of interviews as the interviewer. I've had people seriously panic maybe once or twice in that entire time. I've heard occasionally that the rates for other interviewers were higher (but still low), if t…

> I've had people seriously panic maybe once or twice in that entire time. I think you're making too much of the example of the candidate crying. That is indeed an outlier case, not the norm. But the crying case is an undeniable sign that job candidates can get extremely anxious during an interview, in a way that affects their performance. The issue isn't "breakdowns" per se, the issue is that coding tests are testin…

After they were hired, and we were talking about interview design, and they were proposing questions harder than mine? Seems reasonable to mention if they had to prep then. Later I also pushed back on proposals for things like homework, but others seemed to find that idea acceptable. I guess they'd have mentioned it then.

You seem to be suggesting something totally unfalsifiable - that candidates who do a bad job aren't actually bad programmers, but are just nervous inside in undetectable ways. There's no way I or anyone else can argue against this notion because there's no way to prove a negative like that, but suffice it to say that the sort of issues I'd associate with nervousness - minor slips that they then notice and correct, stumbles, brief moments of forgetfulness etc - are not why people tend to fail interviews. They fail interviews because their coding skills suck.

Re: In defense of coding interviews

#382
post #378

Earlier quoted context omitted.

> I've had people seriously panic maybe once or twice in that entire time. I think you're making too much of the example of the candidate crying. That is indeed an outlier case, not the norm. But the crying case is an undeniable sign that job candidates can get extremely anxious during an interview, in a way that affects their performance. The issue isn't "breakdowns" per se, the issue is that coding tests are testin…

After they were hired, and we were talking about interview design, and they were proposing questions harder than mine? Seems reasonable to mention if they had to prep then. Later I also pushed back on proposals for things like homework, but others seemed to find that idea acceptable. I guess they'd have mentioned it then. You seem to be suggesting something totally unfalsifiable - that candidates who do a bad job are…

> You seem to be suggesting something totally unfalsifiable - that candidates who do a bad job aren't actually bad programmers, but are just nervous inside in undetectable ways.

Heh. It's only unfalsifiable if you ignore a person's previous experience and accomplishments, refusing to acknowledge anything other than your own interview as an accurate gauge of the person's skills.

Also, I'm literally telling you that it happens to me. (And I've heard many people say it happens to them.) So either I'm a liar, or you have to admit that it happens. Go ahead and call me a liar if that's what you want to believe, but I'm not even trying to get a job anymore. I'm happily self-employed now, and my customers also seem very happy with my coding skills.

The term "control your emotions" is somewhat vague. You can hide your emotions, but that doesn't mean you're not experiencing the emotions. An extreme example of that is if you "put on a brave face" after a personal tragedy. You may not cry and break down, but that doesn't mean the sadness doesn't affect you severely. The reason I mentioned therapy is that you'd probably need therapy in order to somehow train yourself to not even feel the emotions in the first place in situations where they arise automatically for you, i.e., to not have certain phobias at all.

> the sort of issues I'd associate with nervousness

Have you considered that you might not have a full understanding and appreciation for human psychology and the wide variance among humans?

Re: In defense of coding interviews

#383
post #382

Earlier quoted context omitted.

After they were hired, and we were talking about interview design, and they were proposing questions harder than mine? Seems reasonable to mention if they had to prep then. Later I also pushed back on proposals for things like homework, but others seemed to find that idea acceptable. I guess they'd have mentioned it then. You seem to be suggesting something totally unfalsifiable - that candidates who do a bad job are…

> You seem to be suggesting something totally unfalsifiable - that candidates who do a bad job aren't actually bad programmers, but are just nervous inside in undetectable ways. Heh. It's only unfalsifiable if you ignore a person's previous experience and accomplishments, refusing to acknowledge anything other than your own interview as an accurate gauge of the person's skills. Also, I'm literally telling you that it…

"It's only unfalsifiable if you ignore a person's previous experience and accomplishments, refusing to acknowledge anything other than your own interview as an accurate gauge of the person's skills."

Which is often the right thing to do unless you have very specific knowledge of that experience e.g. a referral, because so many people flat out lie about their experience and accomplishments. If you can't directly verify it, the accuracy is so low it's best ignored.

As for your experience, I'm glad to hear you're now happily self employed (so am I!). How are you proving your skills to customers, if you can't handle job interviews? Or are you making a product?

"Have you considered that you might not have a full understanding and appreciation for human psychology and the wide variance among humans?"

I have an average such understanding, having lived an average life. But the problem remains: someone who claims to be able to do a job fine but can't demonstrate that capability when asked, is from an employer's perspective best avoided. That isn't a flaw in the interviewing process, that's the point of it! The reasons why someone can't demonstrate it are irrelevant because there's no better alternative available, and anyway, someone who can't handle the pressure of a job interview is very likely to crack in other situations. You claim it's not true and there's something psychologically unique about interviewing, but, I don't really believe this and clearly neither do other people doing hiring.

Re: In defense of coding interviews

#384
post #382

Earlier quoted context omitted.

> You seem to be suggesting something totally unfalsifiable - that candidates who do a bad job aren't actually bad programmers, but are just nervous inside in undetectable ways. Heh. It's only unfalsifiable if you ignore a person's previous experience and accomplishments, refusing to acknowledge anything other than your own interview as an accurate gauge of the person's skills. Also, I'm literally telling you that it…

"It's only unfalsifiable if you ignore a person's previous experience and accomplishments, refusing to acknowledge anything other than your own interview as an accurate gauge of the person's skills." Which is often the right thing to do unless you have very specific knowledge of that experience e.g. a referral, because so many people flat out lie about their experience and accomplishments. If you can't directly verif…

> Which is often the right thing to do unless you have very specific knowledge of that experience e.g. a referral

You're missing the forest for the trees. This is not a job interview, it's just the two of us talking, and I'm stating that many people who are not stage performers experience "stage fright" in an audition-style interview, which severely but only temporarily hinders their performance.

If you acknowledge this fact, then you have to start to wonder whether audition-style interviews are accurately measuring skill level, or whether they're mainly measuring anxiety. And you may have to reevaluate whether a flubbed interview indicates that a candidate "can't code" and is a "faker", as opposed to just freezing from stage fright.

This is not even to claim that there are zero liars out there. But you have to wonder about the percentage of liars, if there are alternative explanations for poor interview performance. The level of paranoia in hiring programmers seems totally absurd to me.

> How are you proving your skills to customers

I am making a product, as well as contracting sometimes. But nobody wants to test me. They trust my experience and aren't ultra-paranoid that I might be a faker who can't code.

> if you can't handle job interviews

This is not accurate. I can handle job interviews. I'm not good at auditions. An audition is a very specific kind of interview, and rather perverse for hiring people who mainly work sitting by themselves.

> That isn't a flaw in the interviewing process, that's the point of it!

Disagreed. It seems that coders tend not to recognize how coding test interviews are not the norm in the world for interviews. They're quite unusual. Most people don't have to audition for a job. An interview is a two-way street: both the interviewer and interviewee are trying to determine whether the job is right for them, and whether they want to work together. A test is very one-sided.

Re: In defense of coding interviews

#385
post #362

Earlier quoted context omitted.

If you have to prepare for the interview, doesn't that suggest the assessment isn't representative of day-to-day programming skills? In fact, it suggests the exact opposite. With zero preparation, I could go to an interview with you right now and tell you anything you wanted to know about designing a database schema, how to get any kind of data out of that schema, how to make that data available via an API, how to ca…

As a sibling commenter pointed out, you just described a CRUD app. Web/mobile applications. It's not hard to do those. And I suppose for most business cases out there, writing data to the DB and reading it back later is all it takes. However, there's plenty of other problems where the skillset you mentioned falls short. For instance, you talked about designing a database schema. Do you know how to design and build a…

I once worked on a system that included a SQL-ish interpreter (starting from an ANTLR-based parser and all the way to distributed plan execution). I don't remember discussing it in interviews in the last five years. Even at places such as Dremio or Imply. In all fairness, I _once_ got an offer when one interview in the process included sketching an ANTLR grammar for a calculator in a plain text editor.

Re: In defense of coding interviews

#386

Earlier quoted context omitted.

Also a ton of important software was written as a giant mess of spaghetti code, or with horrible security vulnerabilities.

I've never been tested on my ability to not write spaghetti code or write security vulnerabilities in my 15 years doing many many interviews. Unless you're suggesting that knowing the performance of a loop helps with that?

What I'm suggesting is that "Important software has been written by people who couldn't/didn't do X" is not a very strong indication that X is not a valuable quality that employers should want in their engineers.

Re: In defense of coding interviews

#387
post #13

I used to defend coding interviews, until I had an interview about a month ago, and the leetcode questions came off as kind of insulting. I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.

Yeah I can see why it seems insulting but have you ever interviewed a lot of people. When I started interviewing I started off by jumping into what I considered to be not insulting questions, but I very quickly learnt how awkward that can be if the candidate just had no clue. Now I start with for loops and preface it with "apologies if this seems too simple" or something like that. You would be surprised how many peo…

Nowadays when I interview people, I try and come up with an example that feels like a "real" problem you'd realistically solve on the job, but isn't too hard, usually something involving building an index or some basic concurrency. It's still not perfect, but I do work pretty hard to try and make the problems feel fair and actually something you'd do on the job. I also generally don't concern myself with compiler/syntax errors unless they're extremely egregious, since I think those errors can typically be explained by nerves and realistically won't be much of a blocker in a real job.

I really hate the contrived problems that interviewers pull from HackerRank and its ilk. Even if you could glean useful information from watching someone program a knight hopping around a phone dial pad (a real problem I've gotten, which I'm highly skeptical of its utility), it comes off as pretty irritating to the interviewee. You're not solving little programming riddles on day to day work, you're solving engineering problems, and I think that these leetcode questions don't reflect that.

I think there's evidence of this too; you can study for these leetcode questions and get better at them, so what exactly are we testing? You're not testing the person's experience, you're testing how long they spent on hackerrank the night before, or how many interviews they had recently.

Re: In defense of coding interviews

#388

Earlier quoted context omitted.

It is definitely about the coding skills. It is too easy to bullshit and there is a financial incentive to do so. Also many people with genunine 10 years of experience are not too good at coding.

Many people with genuine 10 years of experience do not care for stupid leetcode question they could obviously solve given some quiet and time. The idea that everything boils down to answering some intro to programming questions quickly is absurd.

While providing a syntactically correct, optimal solution to a given problem is important (this was reiterated many times during my recent interview process at a FAANG), it is also important to be able to demonstrate the ability to synthesize an approach to solving a problem to which you don't already know the answer. That is, how to solve a problem.

These questions, while certainly aimed at identifying core competency areas, are also an opportunity for the candidate to demonstrate an aptitude for problem solving. Nobody really cares "how many piano tuners operate in Seattle". What they care about is, given that kind of question, how a candidate responds. You might be surprised by the number of people totally unable to even generate a reasonable estimate:

- How many people live in Seattle? - What percentage have pianos? - How often does a piano need tuning? - How long does it take to tune a piano? - How many pianos can be tuned per work day (given commuting time)? - etc.. driving towards a number.

Did the candidate attack the problem and even attempt to solve it? Did they use metrics? The list goes on... Most LC-style questions (save the "aha! moment" ones) have a similar impetus, but are also much more practical and efficient because they test for many things at once.

And if I'm being honest... most FAANGs aren't looking for engineers that require quiet and time to solve problems. They are looking for elite engineers who can write a solution nearly as fast as the problem is presented (I'm obviously exaggerating a little bit here). The difficulty of the questions presented to me (6 technical interviews) were what I consider semi-trivial. I was able to describe the solution-space within seconds of reading the prompt and code an optimal solution nearly as fast as I could type in all cases. It honestly made me wonder about how poorly the average programmer must perform such that these were the questions they needed to evaluate my potential.

Another commenter posted this article [0] about the interviewing philosophy back in the early '00s. I found it very enlightening, and reassuringly, while reading through it I knew the answer to nearly every question (and could expand upon the topics) just off the top of my head. I'm not trying to sound arrogant here but the idea that a FAANG, who pays top-dollar for engineers, would settle for "10 years experience" as a suitable replacement for "demonstrates ability" is what's absurd. A false positive is way more costly than a false negative.

[0] https://sites.google.com/site/steveyegge2/five-essential-pho...

Re: In defense of coding interviews

#389
post #384

Earlier quoted context omitted.

"It's only unfalsifiable if you ignore a person's previous experience and accomplishments, refusing to acknowledge anything other than your own interview as an accurate gauge of the person's skills." Which is often the right thing to do unless you have very specific knowledge of that experience e.g. a referral, because so many people flat out lie about their experience and accomplishments. If you can't directly verif…

> Which is often the right thing to do unless you have very specific knowledge of that experience e.g. a referral You're missing the forest for the trees. This is not a job interview, it's just the two of us talking, and I'm stating that many people who are not stage performers experience "stage fright" in an audition-style interview, which severely but only temporarily hinders their performance. If you acknowledge t…

Thanks for being so patient.
Post reply on HN