We're testing stress, not skill

Programming interviews are broken. They test how well you perform under stress — not how you actually build software.

We've turned hiring into a multi-week obstacle course designed to impress ourselves rather than assess anyone. Companies think replicating the Google-style gauntlet gives them prestige. It doesn’t — it just rewards endurance, not competence.

Interviewers also carry an invisible bias: they already know the problem inside out. They’ve solved it before. They’ve seen it done a dozen different ways — right or wrong. Yet they expect candidates to understand it immediately and produce a decent implementation within an hour.

When’s the last time you shipped a feature you didn’t fully understand and merged your first untested thoughts to main? Exactly. It’s not a good test.

The human cost

For candidates, the experience is exhausting. Feedback takes days, sometimes weeks — if it comes at all. Each round feels disconnected from the last. You clear one hurdle only to hear “sit tight while we coordinate next steps,” and the momentum is gone.

I once went through a five-week process where I passed every stage — phone screen, technical round, pairing round, behavioural — and still didn’t get the job. The rejection arrived late on a Friday, the HR equivalent of a cliffhanger. If you’ve ever spent a weekend waiting to ask “why?”, you know how demoralising that feels.

The job market for candidates sucks right now. If it’s a no, be considerate.

Instead of fixing what’s broken, companies keep doubling down on process.

The cargo cult of the Google-style interview

A big part of the problem is imitation. Smaller companies mimic Google’s hiring pipeline because they think it signals rigour. Six stages. Algorithms. Take-home tests. Culture interviews. Calibration meetings. It looks thorough on paper — but without Google’s scale or data, it’s just bureaucracy for its own sake. I don’t do them anymore.

If you’re hiring for a 10-person startup, you don’t need a process built for a 100,000-person company. You’re not Google — and that’s a good thing. You can move faster, decide in hours, and actually remember what a candidate said in round one.

Instead, we’ve copied the ceremony without the calibration. We’ve built processes optimised for optics, not outcomes — and we’re surprised when they fail.

The myth of live coding

This is easily the most bullshit part of the entire process — the most stressful and the least representative.

No live coding exercise is good. Writing code for a brand-new problem while someone watches you triggers a stress response, not insight. It rewards people who narrate confidently while thinking fast, not people who think deeply and work carefully.

I once passed every round at a company owned by Google but missed a couple of things in the coding interview. That was it — no offer. If you can do well in five interviews and still not get the job, is it really worth your time?

Then there’s the one that still haunts me. Early in my career, already intimidated, I showed up to their co-working space. As soon as they rolled out the whiteboard, my heart rate spiked. They asked:

“In Python, given a string, derive all possible sequences of the characters in the string.”

My answer didn’t land:

“Oh, I’d just use itertools.permutations().”

They ended the interview early. I understand the spirit of the question, but come on — you’re building a progressive web app to sell insurance, not the radar system for a fighter jet.

Give me a take-home exercise instead. Let me work in my own environment — where I can debug, test, and use my own shortcuts without fighting your browser IDE.

And if the goal of your sterilised web editor is to stop people using LLMs or searching the web, you’ve missed the point. Programmers are hackers at heart — we’ll find a workaround before the loading spinner stops. I immediately knew how I could’ve bypassed it: pre-prompt an LLM for guidance, screenshot everything, auto-upload it with a script. Easy.

An excellent alternate approach I’ve seen is simple: send a real-world task as a take-home — something your team has already built and merged to main. It shouldn’t take more than an hour. Everyone knows reading code is harder than writing it. Don’t worry if someone uses an LLM for autocomplete — that’s not a disqualifier if they can explain their thinking.

Have them walk through their solution with the team. Let them lead the discussion. You’ll quickly see their depth of experience by what they focus on. You’ll see how they communicate, reason, and respond to feedback — the skills that actually matter on the job.

If you absolutely must do live coding, make it real. Push a commit from your actual codebase and see how they’d approach the same problem — or even improve it. Now you can see how they’d work on your features, and they can decide if your work interests them.

How to fix it

The single best approach I've seen is simple: work on a real problem with the candidate for half a day and pay them for their time. Most companies won’t do this, but it’s the gold standard. Where that's not possible to do, here are some practical tips to improve your process.

Interviews should feel like collaboration, not interrogation.

1. Let candidates use their preferred environment.
   Don’t force them into a browser IDE that breaks their shortcuts and autocomplete. You’re measuring problem-solving, not keybindings.

2. Send a simple repo ahead of time.
   Give them setup instructions and a basic structure so they can get familiar. You’ll save half the session troubleshooting dependencies.

3. Use real problems, not abstract puzzles.
   Tasks should come from your real product — something your team has already implemented and merged to main.
   The ideal format is a short take-home review or enhancement of that feature. Let candidates work however they like, with whatever tools they’d actually use. Then have them explain their approach with your team.

4. Limit rounds to what adds actual signal.
   Three is generous: technical, business skills, culture. Anything more tests patience, not skill.

5. Timebox the entire process.
   Two weeks from first contact to offer is achievable. Anything longer signals indecision — and indecision loses great candidates.

6. Decide faster, communicate better.
   Stack interviews where possible, give immediate yes-or-no decisions, and if feedback isn’t ready, say so — then prioritise sending it. Even a short “we’re still interested, expect next steps tomorrow” keeps people engaged.

Stop optimising for optics, start optimising for signal

We don’t need interviews that impress other engineers. We need interviews that reveal how people think, collaborate, and learn.

The best engineers aren’t the ones who can invert a binary tree on a whiteboard — they’re the ones who ask good questions, work through ambiguity, and build things that last.

Hiring the right people shouldn’t feel like running a gauntlet. It should feel like starting a project together.