Thanks for this Gábor but posts like these without acknowledgement of the time commitment required by candidates and companies, and the repeatability and trainability of live coding interviews, feels like we're not advancing the conversation.
Likewise to all those posts out there about AI cheating---no solutions offered :)
Thanks for highlighting that. I think many would say that such an interview is difficult to execute in practice: how can I show you code from my FAANG job I’m no longer working at?
Or that such an approach collects more system design signal than problem solving and coding signal.
Or that it’s hard to assess how much of such solutions came from you vs your colleagues.
Or that such interviews entrench existing biases—the problems I solved at FAANG might be inherently more interesting than what someone solved at a folded startup but that doesn’t make you a better engineer.
Or that calibrating between candidates and training interviewers to make consistent decisions is more challenging with such a setup.
It’s not that you’re wrong about any of this, it’s just that technical interview approaches exist on a spectrum of options in a few dimensions and choosing a point along those continuums involve tradeoffs.
You're absolutely right—there are tradeoffs, and no silver bullets.
I’m not arguing that live coding is useless, but rather that we often rely on it too heavily, without balancing it with other signals that reflect how someone truly works on a team.
You bring up some valid challenges—access to past code, bias, calibration—and I think these are exactly the kinds of things we should talk more about.
If we agree that the current system has flaws, then it's worth exploring more balanced approaches. Even simple changes like collaborative problem walkthroughs or take-home assessments with structured discussions can go a long way.
Live coding does not make sense. We start from a premise: if you are applying for the role X, is because you are ready for it.
- If you are a junior software engineer 👉🏼 You know coding and are willing to face challenges
- if you are a software engineer 👉🏼 On top, you know best practices and understand and propose how to solve business problems
- If you are a senior software engineer / Tech Lead 👉🏼 On top, you ensure your team follows best practices, and lead the solutions in your team and nearby immediate organization
- If you are a staff software Engineer, 👉🏼 On top, you solve cross-functional problems in the engineering organization.
Let's set the expectations clearly during the interview, so the candidate understands if she/he is ready for it.
That said, during the interview, let's focus on how the candidate solves problems that will have to deal with on a daily basis.
Thanks Marcos, love how clearly you broke this down.
Totally agree, expectations should match the role. If we’re hiring someone to solve real-world team problems, the interview should reflect that.
The further someone is in their career, the more their value comes from how they lead, collaborate, and solve—not just how fast they can write a for-loop under pressure.
I disagree with the conclusions, though. Life has lead me to different ones:
1. Live coding used to feel scary to me. Now it feels exciting to be challenged on the spot. Perception is huge, so is reframing things.
2. Stress-testing people is totally ok. We do that with systems too, even though they rarely experience peak load. We still want to know what they are capable of.
3. Coding interviews aren't about the solution AT ALL! They are about exposing your brain to the other person: how you think, what types of questions you ask, where you take the conversation, etc.
Thanks for this Gábor but posts like these without acknowledgement of the time commitment required by candidates and companies, and the repeatability and trainability of live coding interviews, feels like we're not advancing the conversation.
Likewise to all those posts out there about AI cheating---no solutions offered :)
Thanks for highlighting that. I think many would say that such an interview is difficult to execute in practice: how can I show you code from my FAANG job I’m no longer working at?
Or that such an approach collects more system design signal than problem solving and coding signal.
Or that it’s hard to assess how much of such solutions came from you vs your colleagues.
Or that such interviews entrench existing biases—the problems I solved at FAANG might be inherently more interesting than what someone solved at a folded startup but that doesn’t make you a better engineer.
Or that calibrating between candidates and training interviewers to make consistent decisions is more challenging with such a setup.
It’s not that you’re wrong about any of this, it’s just that technical interview approaches exist on a spectrum of options in a few dimensions and choosing a point along those continuums involve tradeoffs.
No silver bullets is what I’m saying :)
Thanks for the thoughtful follow-up, Austen.
You're absolutely right—there are tradeoffs, and no silver bullets.
I’m not arguing that live coding is useless, but rather that we often rely on it too heavily, without balancing it with other signals that reflect how someone truly works on a team.
You bring up some valid challenges—access to past code, bias, calibration—and I think these are exactly the kinds of things we should talk more about.
If we agree that the current system has flaws, then it's worth exploring more balanced approaches. Even simple changes like collaborative problem walkthroughs or take-home assessments with structured discussions can go a long way.
Appreciate your perspective.
Thanks Austen for sharing your opinion.
There's a section at the very end of the article where I explain how this could be done better: https://techleadmastery.substack.com/i/160333661/how-to-do-it-better
I'm 100% aligned with your arguments Gábor.
Live coding does not make sense. We start from a premise: if you are applying for the role X, is because you are ready for it.
- If you are a junior software engineer 👉🏼 You know coding and are willing to face challenges
- if you are a software engineer 👉🏼 On top, you know best practices and understand and propose how to solve business problems
- If you are a senior software engineer / Tech Lead 👉🏼 On top, you ensure your team follows best practices, and lead the solutions in your team and nearby immediate organization
- If you are a staff software Engineer, 👉🏼 On top, you solve cross-functional problems in the engineering organization.
Let's set the expectations clearly during the interview, so the candidate understands if she/he is ready for it.
That said, during the interview, let's focus on how the candidate solves problems that will have to deal with on a daily basis.
Thanks Marcos, love how clearly you broke this down.
Totally agree, expectations should match the role. If we’re hiring someone to solve real-world team problems, the interview should reflect that.
The further someone is in their career, the more their value comes from how they lead, collaborate, and solve—not just how fast they can write a for-loop under pressure.
Appreciate you adding this perspective!
I loved reading this!
I disagree with the conclusions, though. Life has lead me to different ones:
1. Live coding used to feel scary to me. Now it feels exciting to be challenged on the spot. Perception is huge, so is reframing things.
2. Stress-testing people is totally ok. We do that with systems too, even though they rarely experience peak load. We still want to know what they are capable of.
3. Coding interviews aren't about the solution AT ALL! They are about exposing your brain to the other person: how you think, what types of questions you ask, where you take the conversation, etc.