Comment by btown
1 day ago
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?