Asking a developer to live-code in an interview is like asking a mechanic to change the oil using tools they’ve never seen before, while you watch over their shoulder and take notes. It tells you nothing about the day-to-day work they’ll actually do. It tells them nothing about the tools they’ll be working with if they get the job. You end up hiring the mechanic who’s great at doing things in the least efficient way possible.
No IDE. No autocomplete. No documentation. No time to think. The skills you’re testing are “can you remember syntax under pressure” and “are you comfortable being watched.” Neither of those is the job.
And the dynamic is impossible. Do you watch in silence while they code? That’s uncomfortable for everyone. Do you talk to them while they think? That might help some people and completely derail others. You don’t know which, because you don’t know them yet. You’re testing how they perform under conditions you can’t calibrate.
I’ve done interviews where searching Google was considered cheating. At most, I could describe the search query I’d make, and the interviewer would describe the results to me. Now we’re changing oil blindfolded, with an arm tied behind our backs, while somebody shouts instructions they’ve read in a Haynes manual through a megaphone.
In some industries, they let people just talk about their experiences. No performative fake version of the job at all. Apparently that’s enough to hire accountants and lawyers and doctors. But developers? We need to see you invert a linked list in real time or how will we ever know.
For me, the conversation is the whole point – and it’s why I like take-home projects instead. Yes, I know the objections.
“They could have someone else do the work.” Yes, they could. They can also do that after you’ve hired them. If someone’s going to coast on other people’s work, a live coding test won’t catch that.
“They could use AI.” Yes, they could. They can also do that on the job. If your hiring process assumes developers won’t have access to the tools they’ll use every day, you’re not testing for reality.
“They could cheat.” We’d have to agree on what cheating even means. Is using documentation cheating? Is looking up syntax cheating? Is asking a friend for advice cheating? At some point you’re not testing competence, you’re testing purity.
Here’s the thing: the take-home project isn’t the test. The conversation afterwards is.
When we talk through the submission, we’re dealing with the candidate’s own code. Not something they saw thirty seconds ago. Not a problem designed to have one clever trick. Code they wrote, with decisions they made, that they can explain.
I ask about tradeoffs. Why did you structure it this way? What would you do differently with more time? What did you leave out, and why? If there’s a weird bit, we can talk about it. If there’s a clever bit, they can explain their thinking.
This tells me far more than watching someone sweat through a binary tree problem on a whiteboard. And we’re actually talking, like we would if they had the job. Not just watching them code in silence, which we’d never do if they had the job.
To make it practical, I set an artificially low time limit and I’m upfront about it. Two hours, say. Get done what you can.
This does a few things. It respects the candidate’s time. It removes the pressure to gold-plate everything. And it gives us something else to talk about: why did you prioritise these features over those? How would you estimate the time to complete the rest?
Now we’re having a conversation about how they actually work. How they make decisions under constraints. How they think about scope and priorities. That’s the job.
Yes, this takes more time than a one-hour live coding session. But it can be done at the candidate’s convenience, not scheduled into an already-packed interview slot. And the signal you get is actually useful.
You’re not finding the person who’s ground LeetCode problems for months. You’re finding the person who can write code, explain their thinking, and have a sensible conversation afterwards. That’s who I want to work with.