The 60-Minute Trap: Why Modern Live Coding Interviews Filter for the Wrong Thing
Take-homes are being replaced by 60-minute live coding interviews with two engineers watching. Senior developers are publicly pushing back. Here's what that format actually measures — and what you can do instead.
A senior software engineer posted on LinkedIn last week that "software engineering interviews have lost the plot." He wasn't alone — the post picked up hundreds of reactions and comments within hours, overwhelmingly from engineers saying the same thing in their own words. If you're hiring developers in 2026, it's worth listening to what they're actually saying, because the format you're using to evaluate them is generating measurable negative signal you probably can't see from your side of the table.
The complaint, in one line: live 60-minute coding interviews measure pressure tolerance, not engineering judgement. And the people who thrive under artificial pressure are not the same people who write the software you actually want shipped.
What Changed
Five years ago, the default technical hiring flow looked roughly like this: a take-home assignment with written requirements and a scaffolded repo, completed in the candidate's own environment on their own schedule, followed by a technical interview that anchored on what they built. Candidates had time to understand the problem. Reviewers had time to read the code carefully. The conversation was about tradeoffs and judgement, not typing speed.
That format has been quietly replaced at a significant share of tech companies. The replacement is a 60-minute synchronous session — the candidate shares their screen, two engineers watch, and the candidate is asked to complete a coding task live. Sometimes several tasks. Sometimes while verbally narrating their thinking. Sometimes with AI prohibited, sometimes with AI mandated, sometimes with "work how you normally would" — an instruction that is incoherent when two engineers are watching you work.
Some of this drift is understandable. Since late 2024, AI coding assistants have made take-home assignments feel harder to interpret. Recruiters worry that a polished take-home submission no longer signals the candidate's skill — it might signal Claude's or Copilot's. Moving to live synchronous evaluation feels like a way to "see the real person behind the code."
It isn't. It's a way to see a different person — the one who performs well under surveillance — and that person is not usually the senior engineer you want hiring.
What Senior Engineers Are Actually Saying
The current approach doesn't filter for good engineers. It filters for people who perform well in pressure cookers. Those aren't the same thing.
This is the comment that lit up the thread. It's also the one worth reading carefully, because it names exactly what's going wrong.
Engineering, as actually practised, is not a 60-minute timed task. Real software work is mostly these activities, in roughly this proportion: understanding the problem (often the majority), reading the surrounding codebase, making small irreversible decisions about interfaces and data shapes, weighing tradeoffs between correctness and shipping, writing a small amount of code, testing it, and iterating. The first four of those activities do not fit into a 60-minute window with someone watching. They are impossible to demonstrate in that format, because they are activities you do alone, over a longer period, with time to think.
What you can demonstrate in 60 minutes is: raw coding speed on small problems, ability to narrate under observation, composure in timed assessments, familiarity with common interview patterns. All of these have some correlation with engineering skill. None are the skill itself.
This is especially bad for senior candidates
Junior developers are usually fresh from practising coding challenges. Senior engineers have spent years actively unlearning that muscle in favour of slower, more deliberative work. When you put them in a timed live-coding session, you systematically select against the people you most need to hire — the ones who have learned to slow down.
The AI Instruction Problem
The second thing engineers are pushing back on is the incoherent handling of AI assistants inside interviews. The recent LinkedIn post lists three variants, all from real interview experiences in the same month:
- "No AI allowed. 'Write a function in Python to do XYZ.' At a senior level. Seriously." — evaluates a skill the candidate will never use again at work, because at work they will use AI.
- "Mix of AI and no AI. Four tasks with AI (including scaffolding), then two without. 60 minutes. For six tasks." — the pace makes meaningful engineering impossible.
- "Work how you normally would. If you use AI, use it." — except the candidate doesn't normally have two engineers watching, doesn't normally receive verbal instructions, doesn't normally work on a codebase engineered to test them.
The common thread: each of these formats pretends to measure how the candidate works in their real environment, while setting up an environment that is systematically different from the real one. That's not a small epistemological problem. It's the whole problem.
You're not demonstrating how you work — you're demonstrating how you perform under artificial pressure.
What a Better Format Looks Like
The engineers complaining about the current format are not complaining abstractly — they usually describe what they'd prefer, and they describe the same thing. A take-home assignment with clear requirements, completed in the candidate's real environment on their own time, followed by a technical interview that anchors on what they built.
The take-home gives the candidate time to do real engineering: understand the problem, weigh tradeoffs, make judgement calls, test their own work. The follow-up interview is where the signal actually lives — a senior reviewer reading the submitted code, asking the hard questions, probing for whether the candidate understands what they built and why. "You used a repository pattern here — why? What did it give you that a simpler approach wouldn't?" "I see you mocked this external service in tests — how would you handle idempotency if this were the retry path in production?"
That's the interview that separates engineers who write good code from engineers who memorised good-looking patterns. You can't run it in 60 minutes with two people watching the candidate type.
A take-home assignment followed by a technical interview based on that work actually solves it.
"But What About AI?"
The reasonable objection is: if candidates have days to complete a take-home, AI assistants can effectively write it for them. How do you know what the candidate contributed?
You evaluate the output like a senior reviewer would — reading the code, following the commit history, noticing where the seams show, asking the candidate to defend the specific choices in the follow-up conversation. An AI-authored solution without the candidate's understanding falls apart in 15 minutes of code review. An AI-assisted solution from a strong engineer — which is how most professional software is written now — reads differently. The reviewer's job is the same as it always was: assess the artifact and the person's grasp of it.
The industry is slowly arriving at this position. The formats currently in use — live coding with AI prohibited, or live coding with AI mandated, or live coding with ambiguous AI instructions — are all attempts to avoid doing this work. None of them succeed, because the underlying problem is that live 60-minute coding is not the right assay for senior engineering skill, with or without AI.
What This Means For Your Hiring Process
If you're running 60-minute live coding interviews, you are almost certainly losing senior candidates who would be strong hires. You won't see it directly, because the candidates who drop out don't send feedback — they just don't accept the next interview invitation, or they complete your interview, get offered elsewhere, and disappear. The failure mode is silent.
Three things worth considering:
-
Measure whether your current format is filtering out the candidates you want. If your senior-hire funnel has high drop-off between "invited to technical round" and "completed technical round", the format is the likely cause. Senior candidates have choices.
-
Shift the signal to the right place. The technical conversation, anchored on real candidate work, is where engineering judgement surfaces. Not the live-type-this-function moment. Restructure your process to put the weight there.
-
Treat AI the way professional work treats it. Evaluate the output, not the process. If the candidate submits excellent code and can defend every meaningful decision in a follow-up conversation, they are an excellent engineer — the tool they used to type faster is irrelevant.
How MeritDeck handles this
MeritDeck is built around the format this post describes. Candidates complete a take-home assessment in their own environment, in their own time. Claude Sonnet evaluates the submission across 9 dimensions the way a senior code reviewer would — architecture, testing, error handling, code quality, git practices, and more — and produces a structured analysis that recruiters use as the basis for the follow-up technical interview. Every strong candidate also earns a verified Merit Deck credential they can share publicly, regardless of whether this specific role works out. The assessment builds their profile; the follow-up interview extracts the signal. See how it works →
The Thing To Actually Hear
Senior engineers are telling you, publicly and clearly, that 60-minute live coding interviews don't work for them. This is not a complaint about difficulty — senior engineers like hard problems. It's a complaint about what is being measured. If you're hiring for software engineering, you should measure software engineering, which is mostly thought, not typing.
The companies that will win the technical hiring battle in 2026 are the ones who noticed this shift, listened to what candidates are saying, and moved their process to the format that actually captures the signal they need. Everyone else will keep filtering for pressure-cooker performance and wondering why the hires aren't working out.
This post responds to themes raised in a viral LinkedIn post by a senior software engineer in April 2026. If you're an engineer with similar experiences — or a recruiter rethinking your technical hiring flow — we'd love to hear from you. Reach out at hello@meritdeck.com.