Very well written and so true. It's not even normal stress, which is fine, it's high stakes stress, plus sometime working under the duress of being insulted.
I once went to a job interview with Google. I built one of the first local (Global to the Netherlands) search engines of the Netherlands, but the guy in the cowboy hat at Google asked me to write a binary search with a marker and a whiteboard. I never write with my hand, I always use keyboards. Plus I'm being insulted to write a binary search when I designed and build a search index and retrieval engine.
[I did the binary search but was not happy with the whole process that did not want to even look at what you had actually done before, because that would take away the baseline they wanted].
I guess they must have been looking for cowboys. Tip for interviews, take your cowboy hat, just in case..
Your cool prior work got you the interview. The interview is to interrogate how you think and small problems are the best way to do that. You're sounding a bit arrogant, as if writing binary search is beneath you. Possible that they marked you as a bad culture fit if you acted that way in the interview.
> We can’t change the fact that live coding is a common practice in tech interviews. But we can try to mitigate the stress it causes.
Yes, we can. Don't do them. But, we have to replace them with something that works. That means none of these poorly constructed take home projects that are almost universally either drastically over scoped, criminally under specified, or both.
Probably another case of trying to measure something difficult, and people usually substitute that problem for an easier or more accessible one. Checking if a person can work under pressure and sensing their emotions and ability to deliver is easier to assess. This pattern comes from Thinking, Fast and Slow.
Live coding does suck - worst off, even if you ignore that it biases to stress tolerance, it tests "leet code" skills for things like reversing a list. Most actual development work involves things like, design work, managing a large codebase, debugging, reasoning through systems, etc.
That said, does anyone have a good alternative? If somebody has open-source work and portfolios, there's a great window into their work, but that's probably an unfair expectation.
I don't think those explanations are mutually exclusive.
Yes, there's a large cohort of "senior" software engineers who can't actually code. They bullshit their way into jobs until they're fired and then apply for the next one. These are the people you want to filter out with live coding.
But also, someone can fail a live coding interview for reasons other than belonging to that group.
Having been on the other side of the table ...
Live coding interviews measure how the brain works under stress -- you are absolutely correct. So do other interview questions. Interviews suck in general for this reason.
I won't use live coding questions (usually) because I don't see much value in trying to code under that much stress.
But I will ask hard questions to see how well a candidate communicates in a stressful situation (which I think is a far more valuable indicator of their brain's "default" mode in stress). I want a candidate that talks honestly about stuff -- especially the stuff they don't understand -- even in a stressful situation. Sometimes stress can bring out the asshole in somebody -- and that's an immediate red flag.
I do simple questions similar to the quoted LinkedIn post. (So less leetcode and more "do you know how to code anything".) While I can agree it is harder under stress, what is the alternative to knowing if someone can code at all? (My pass rate is similar to the quoted LinkedIn post.)
I have done the entry interview as well. For example have had very good conversations with managers who were applying for senior IC roles. They then go and fail the tech interview basic "can you do write and execute a python hello world script from the command line".
I have serious problems with the concept of working under stress... or duress is more like it. Unless you are in a first responder, ER doc/nurse, or in a warzone. The job should not be stressful. Companies that operate this way and overlook the abuse it causes their employees, are broke, fucked, evil, etc.
Once in an interview I asked someone to go to the whiteboard for a coding exercise and her body language showed an enthusiasm and fearlessness that in hindsight I realized I'd never seen before. She practically sprung up out of the chair.
Most people, even the good ones, show a little hesitance when starting. Which isn't really necessary, most people do fine. I'm not trying to get them to fail, I'm trying to get them to succeed. I want to see if they're smart and understand the problem and the direction of a solution. Not if they miss any semicolons or don't recall some arcane data structure.
She was one of the best hires I made. Coding interviews can also measure attitude and confidence.
I must be in the minority, but I enjoy live coding exercises. I also enjoy Advent of Code and though I never make the leaderboard, its fun to challenge myself on time.
> Some companies genuinely care about this. Some even mention it in their job descriptions. They want candidates who perform well under pressure.
Who are these self-important employers?? I mean, outside of Ops and live incident response, are there really that many software engineer roles that require someone to perform well under pressure? It seems a false and egotistic narrative. If you need a software builder to perform under pressure then you've got systemic issues of a type not solved with software. You need better management or better work practices.
Absolutely. Some of my favorite coworkers would never pass a modern, top company interview which I can pass, and not because they are worse in general, but due to stress management. When I am working in one of those that has no hiring shortcuts, I just can't recommend them, because they will fail. In a small enough company, I can say "hire this person sight unseen, and if they aren't good, it's 100% on me", and then they are successful. My time working with them is far more valuable at skill matching than any interview.... but that's not how we do things in most places, because the fear that people will recommend the otherwise incompetent is high, and for good reason. There would have to be consequences for recommending a bad candidate like that.
Now, that doesn't mean that stress management cannot be part of the job: I've worked in the hellish places where an on-call rotation meant at least 4 calls off-hours, and some which needed resolutions in 10 minutes or less from the pagerduty call. Someone with bad stress response is not going to be doing great at that kind of live diagnosing, with possibly many millions for the company on the line. But the number of positions like that, where you are a cross between a developer and an ER doctor are much less common than places that have none of those demands, yet give you a series of leetcode mediums and hards. They might as well be testing for height, or how much you can bench press. It filters, but it does not help.
I used to do tech screening in my previous job and not only it measured stress, it was awfully biased against older people. We lost so many senior people that I really wished I could work with because they weren’t used to jumping through the hoops and loops of leet code questions (in my country leetcoding is fairly new). Then there were other younger candidates that were pretty mid but knew all the answers to leet code and design questions and ended up getting the job.
Measuring stress tolerance is an important when hiring.
A good employer takes care of their worker even if they have problems, but they also want to weed out as much of them before hiring. The value of worker is not revealed when they are at their best. Fragile workers with anxiety perform well only small amount of time.
Live interviews are generally excellent at revealing how individuals perform when placed outside their comfort zone. If you perform well in a live interview, be it for coding or any other skill, you are likely to perform even better reality.
a.) yes b.) depends on where you're working, but in the startups I worked in, with incidents and critical bugs and being pressured permanently by product managers, even shouted at by the CEO, being stress resistant was part of the job.
I firmly believe that the only good proxy for how well one can do the job is doing the job. Even if there are good proxies for doing the work, why would you choose to use a proxy when you can just do the work? And if you're work is some complicated that you can't break off some piece of it and do it in an interview, maybe you're making stuff too hard for no particular reason.
Let's say you need someone who can lift 10 kilograms:
- Good interview: "Please lift this 10 kilogram bucket by the handle."
- Not Good interview: "As a proxy for your overall strength, please take off your pants, squat, pick up this 1 kg bucket by clenching the handle with your butt cheeks, and then stand. We know this isn't a real test of your strength, but we want to see how you perform under pressure."
EDIT: what I mean by doing the job, I mean test the skills used on the job. See if a chef knows their way around a kitchen & actually cook something. See if a customer support rep has good written & verbal communication skills in a mock support interaction. See if a phone screening can do phone screens. Stuff like that.
It usually takes significant time for someone to get up to their base level of effectiveness in a new organization, so I don't really think this is better, in fact it's much worse because "doing the job" includes a lot of ancillary things like familiarizing oneself with the tools, metrics, codebase, etc.
Much better to just have a live coding test that tries to measure your communication, effectiveness at working on a problem, and your raw coding skills.
I just had an interview like this and I don't think I did well. It was a dumb stupid coding problem that, naturally, should have been easy, and it took me forever. I honestly don't know if I'll hear back from them at this point. :/
At least reading this post has helped me regain some of that lost self-esteem. Thanks for sharing it. <3
Even with practice, dev interviews are a crapshoot.
Sometimes you will knock it out of the park, only to fail at the next round because of something silly. And other times you don't do anything special and get moved to the next round (or even hired).
I'd just keep interviewing and try not to take the interviews seriously.
As with everything, it depends. Live coding interviews work. They’re not the best candidate experience, but they work at Meta, Google scale, minimizing false positives better than most other formats. What makes them stressful is the lack of interviewer training and the abstract, puzzle-like nature of the problems, which you can really only solve if you’ve spent time studying (e.g., LeetCode) or you’re fresh out of college or academia.
I’ve worked in the assessment space for 6 years and have seen many hiring processes, from Fortune 10 companies to startups hiring their first engineers. The range of signal required, "how much time can my engineering team spend with a candidate", and how much candidate experience you can get away with, is huge. I’ve also been a candidate myself and failed many live coding interviews. It made me feel terrible about myself. The last time for a role at Ycombinator (the interviewer was super nice).
When I work on my product, I try to view it through the lens of empowering candidates to show their skills and potential. I encourage our customers to use assessments that somewhat resemble on-the-job skills. I don’t like the phrasing “real work” anymore. An assessment shouldn’t be unpaid labor, it should be a way for candidates to demonstrate that they can do the job and handle future work thrown at them, and for hiring managers to feel confident extending what are often very high salaries in tech.
With AI, unfortunately, short take-homes (what I prefer as a candidate, using my own tools and editor) are becoming harder to maintain as a fair signal due to AI assistance. I’ve seen companies move back to onsite, and competitors deploy all kinds of proctoring and invasive monitoring.
The perfect solution, in my view, would be an assessment where the candidate feels relaxed and able to perform at their best, with their own editor and configuration, knowing that every other candidate in the pool has the same constraints in terms of time and tooling. It’s a tough problem to solve. I think about it daily and have not come up with a solution.
Some of the best engineers I've ever met are always false positives. They get nervous in live interviews. I don't think one can say live coding interviews work so matter of factly when it's eliminating some top, top computer scientists.
Yeah, in my admittedly limited experience the grade I assigned in a live code test (slightly more than fizzbuzz, but no tricks or algorithms required) matched up very closely with real world performance.
I even have knowledge of some of the fails as people higher up the chain decided to hire them anyway. They didn't do well from the feedback I received.
I am lucky to have never had a live coding interview, because I would utterly crumple. Not proud to say and something I should work on, but it’s very real.
121 comments
[ 5.6 ms ] story [ 91.3 ms ] threadI once went to a job interview with Google. I built one of the first local (Global to the Netherlands) search engines of the Netherlands, but the guy in the cowboy hat at Google asked me to write a binary search with a marker and a whiteboard. I never write with my hand, I always use keyboards. Plus I'm being insulted to write a binary search when I designed and build a search index and retrieval engine.
[I did the binary search but was not happy with the whole process that did not want to even look at what you had actually done before, because that would take away the baseline they wanted].
I guess they must have been looking for cowboys. Tip for interviews, take your cowboy hat, just in case..
To date, I've never gone on to regret hiring someone who blitzed the in person coding exercise.
Yes, we can. Don't do them. But, we have to replace them with something that works. That means none of these poorly constructed take home projects that are almost universally either drastically over scoped, criminally under specified, or both.
That said, does anyone have a good alternative? If somebody has open-source work and portfolios, there's a great window into their work, but that's probably an unfair expectation.
Yes, there's a large cohort of "senior" software engineers who can't actually code. They bullshit their way into jobs until they're fired and then apply for the next one. These are the people you want to filter out with live coding.
But also, someone can fail a live coding interview for reasons other than belonging to that group.
I won't use live coding questions (usually) because I don't see much value in trying to code under that much stress.
But I will ask hard questions to see how well a candidate communicates in a stressful situation (which I think is a far more valuable indicator of their brain's "default" mode in stress). I want a candidate that talks honestly about stuff -- especially the stuff they don't understand -- even in a stressful situation. Sometimes stress can bring out the asshole in somebody -- and that's an immediate red flag.
I have done the entry interview as well. For example have had very good conversations with managers who were applying for senior IC roles. They then go and fail the tech interview basic "can you do write and execute a python hello world script from the command line".
Most people, even the good ones, show a little hesitance when starting. Which isn't really necessary, most people do fine. I'm not trying to get them to fail, I'm trying to get them to succeed. I want to see if they're smart and understand the problem and the direction of a solution. Not if they miss any semicolons or don't recall some arcane data structure.
She was one of the best hires I made. Coding interviews can also measure attitude and confidence.
Who are these self-important employers?? I mean, outside of Ops and live incident response, are there really that many software engineer roles that require someone to perform well under pressure? It seems a false and egotistic narrative. If you need a software builder to perform under pressure then you've got systemic issues of a type not solved with software. You need better management or better work practices.
Now, that doesn't mean that stress management cannot be part of the job: I've worked in the hellish places where an on-call rotation meant at least 4 calls off-hours, and some which needed resolutions in 10 minutes or less from the pagerduty call. Someone with bad stress response is not going to be doing great at that kind of live diagnosing, with possibly many millions for the company on the line. But the number of positions like that, where you are a cross between a developer and an ER doctor are much less common than places that have none of those demands, yet give you a series of leetcode mediums and hards. They might as well be testing for height, or how much you can bench press. It filters, but it does not help.
A good employer takes care of their worker even if they have problems, but they also want to weed out as much of them before hiring. The value of worker is not revealed when they are at their best. Fragile workers with anxiety perform well only small amount of time.
Live interviews are generally excellent at revealing how individuals perform when placed outside their comfort zone. If you perform well in a live interview, be it for coding or any other skill, you are likely to perform even better reality.
Should it be that way? No. Was it that way? Yes.
Let's say you need someone who can lift 10 kilograms:
- Good interview: "Please lift this 10 kilogram bucket by the handle."
- Not Good interview: "As a proxy for your overall strength, please take off your pants, squat, pick up this 1 kg bucket by clenching the handle with your butt cheeks, and then stand. We know this isn't a real test of your strength, but we want to see how you perform under pressure."
EDIT: what I mean by doing the job, I mean test the skills used on the job. See if a chef knows their way around a kitchen & actually cook something. See if a customer support rep has good written & verbal communication skills in a mock support interaction. See if a phone screening can do phone screens. Stuff like that.
Much better to just have a live coding test that tries to measure your communication, effectiveness at working on a problem, and your raw coding skills.
At least reading this post has helped me regain some of that lost self-esteem. Thanks for sharing it. <3
I’ve worked in the assessment space for 6 years and have seen many hiring processes, from Fortune 10 companies to startups hiring their first engineers. The range of signal required, "how much time can my engineering team spend with a candidate", and how much candidate experience you can get away with, is huge. I’ve also been a candidate myself and failed many live coding interviews. It made me feel terrible about myself. The last time for a role at Ycombinator (the interviewer was super nice).
When I work on my product, I try to view it through the lens of empowering candidates to show their skills and potential. I encourage our customers to use assessments that somewhat resemble on-the-job skills. I don’t like the phrasing “real work” anymore. An assessment shouldn’t be unpaid labor, it should be a way for candidates to demonstrate that they can do the job and handle future work thrown at them, and for hiring managers to feel confident extending what are often very high salaries in tech.
With AI, unfortunately, short take-homes (what I prefer as a candidate, using my own tools and editor) are becoming harder to maintain as a fair signal due to AI assistance. I’ve seen companies move back to onsite, and competitors deploy all kinds of proctoring and invasive monitoring.
The perfect solution, in my view, would be an assessment where the candidate feels relaxed and able to perform at their best, with their own editor and configuration, knowing that every other candidate in the pool has the same constraints in terms of time and tooling. It’s a tough problem to solve. I think about it daily and have not come up with a solution.
I even have knowledge of some of the fails as people higher up the chain decided to hire them anyway. They didn't do well from the feedback I received.