Comment by danesparza
1 day ago
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 like to think about it as the tactical allocation of stress. As an interviewer, I do not want the interviewee to be stressed about optics, or about whether they'll "look bad" about needing documentation; I'll encourage documentation/LLM use as long as they do it on the screen, and disarm by giving context about why that doesn't matter.
But I do want to see how they cope with the stress of needing to track and articulate complex control flow and edge cases through their program in a timed environment - that's part of every day if you're building ambitious systems, and it's a skillset that continues to be relevant even in an era of agentic coding. Testing for the response to that stress makes coding interviews highly relevant in my experience.
> But I do want to see how they cope with the stress of needing to track and articulate complex control flow and edge cases through their program in a timed environment - that's part of every day if you're building ambitious systems, and it's a skillset that continues to be relevant even in an era of agentic coding. Testing for the response to that stress makes coding interviews highly relevant in my experience.
I think this is still an apples to oranges comparison though, there is a huge difference between writing code for niche puzzle problems, with somebody looking at you do it, with the pressure to perform to pass an interview. This is unbelievably different from day to day work, even under time pressure.
> But I do want to see how they cope with the stress of needing to track and articulate complex control flow and edge cases through their program in a timed environment - that's part of every day if you're building ambitious systems
Do you really need to code day in day out in an time window of the size of an interview (so 1 hour or 2) in your workplace? Or are you testing for extreme situation like patching a failing live production system?
> But I will ask hard questions to see how well a candidate communicates in a stressful situation
Well, stress fires off old cortex fight-or-flight response. It's like the worst possible test of neocortex capability. Why are you trying to trigger it? Kinda cruel.
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.
Mentally strong and healthy people who do well when challenged are good hires.
> Mentally strong and healthy people who do well when challenged are good hires.
So, you discriminate against disabled people?
2 replies →
These posts are acting like they're looking for a personality that can handle being a combat jet pilot when they write crud that handles 100 requests/day...
Why is the business this stressful in the first place
Not every stress is the same though. Interviews stress != stress on the job.