The process that most teams use to hire engineers no longer gives the signal it was built for.
A whiteboard interview tests if a person can write code by hand, alone, under pressure. In 2026, this is no longer the work that an engineer actually does. The work has shifted from writing code to making decisions about code: what to build, how to structure it, where to cut corners, when to stop. Code is the output. The input is thinking. And whiteboard tests only the output, in artificial conditions that don't look like anything real.
Why take-home doesn't fully solve the problem
The obvious reaction is to replace whiteboard with take-home. The candidate does the task at home, at his own pace, with his own tools. You read the code and rate it.
This is a step in the right direction, but it doesn't close the main gap. Because when you read someone else's code, you read an artifact. You don't see the process that led to it. You don't know where the candidate got stuck, what he tried and threw away, which decisions he made without conviction and which ones with full belief. You see the final result. It could be written in an hour with full understanding. Or it could be written in three days with heavy help from another person.
A read-only audit of a repository creates an illusion of objectivity. It seems that "taste in code shows right away", by structure, by commits, by file organization. This is partly true. But "taste" is a slippery word. Very often, what an experienced engineer reads as "bad taste" is just a different taste, a different school, a different set of practices. Rejecting a candidate for "he committed it the wrong way" is not a judgment -- it's a projection of your own preferences.
Take-home without a live talk about it is the same whiteboard -- just with homework instead of a board.
Project + presentation
The process I believe in has four stages: initial screen → talk with hiring manager → project → presentation of the project.
The first two are standard. The third is an extended take-home, with one key difference -- the task must be big enough to give material for a serious talk. Not an algorithm task, not a CRUD endpoint. A mini-product that a person could really build in a few days with an AI agent, but that has enough surfaces for making decisions: architecture, data, styles, API, error handling, tests.
But the center of gravity is the fourth stage, not the third.
The candidate comes to a one-hour session with two engineers. He doesn't code. He presents what he already built. And then he answers questions.
The right questions in this round are the ones that push the candidate out of "I show the result" mode and into "I think out loud about my own work" mode:
- Walk me through the commit history. Which commit was the hardest and why?
- Where did you get stuck the longest, and how did you get out of it?
- Show me the place you are least happy with. What's wrong with it from your point of view?
- What tools and libraries did you consider before picking the ones in the code?
- If I asked you right now to add a specific change in requirements, where would you start and what would break?
The first three test the ability to be honest about your own code. The fourth tests if the candidate really made a choice, and didn't just take the first thing the agent offered. The fifth tests if he understands the system he built deeply enough to predict its fragile spots.
What this catches that whiteboard didn't
Under whiteboard pressure, any normal person hides his weaknesses. This is not a personality trait -- it's biology. When you are being judged, you won't say "I don't know how to do this better". You will fake confidence to the end, even if inside you don't know.
At a presentation of your own project, everything is flipped. You can defend code that you wrote a few days ago in only two ways: through idealization ("everything is done right") or through honest reflection ("here I cut corners, here I didn't know a better solution, here I would redo it"). The first path breaks with one or two well-placed questions. The second is the signal you need.
An engineer who says "I picked this solution because it's faster, even though I know it won't scale well, and here is when I would rewrite it" -- that's the engineer you want. Not because he wrote perfect code. But because he can see his own code from a distance. This is the same skill you need in code review, in tech design discussions, in trade-off talks with the team. Whiteboard doesn't see it at all.
Warnings you can't skip
A strong candidate with offers will not spend 3 days on your test task. And he will be right, if you treat the test task as a free filter.
This process works only under two conditions. The first -- the project is paid. Not symbolically, but at a real hourly rate that this person could get on a contract. If you hire a senior at, say, $100/hour and you ask for 3 days, be ready to pay $2000 to $2500 for this work, no matter if you hire the candidate or not. This costs the company. But it's much less than a bad hire, which this format helps you avoid.
The second condition -- the project replaces several rounds, it doesn't add to them. If you had seven rounds and you add a test task on top, you just made the candidate's time longer without compensating for anything. But if you remove the whiteboard, remove the take-home screen, and keep initial → hiring manager → project → presentation, you give the candidate a shorter funnel in total time, with a chance to show himself more honestly.
The task must be designed so it doesn't look like free work for the company. Don't have the candidate build a feature that will later go to production. Give him a self-contained task, where the result is an artifact in his repo, not in yours.
This works for product roles. Not for all others. I'm writing this about fullstack, frontend, backend, product mobile. For infrastructure, platform, ML/research roles, a three-day project won't reproduce what makes that work hard: scale, legacy, reliability under real traffic. For those, it's probably better to keep the classic funnel with technical deep dive and system design. I don't claim that I know how to fix their hiring better. I just know that this format is not the right tool for them.
But how do you know the candidate actually wrote the code? This is the first question I get when I describe this process to someone. If the candidate builds the project at home with an AI agent, how do you tell if this person wrote the code, or a friend, or a freelancer, or another AI operator?
Short answer -- you don't check the code. You check the talk about the code.
The presentation round is not a formality. It's half of the signal, and the project is the other half. A live session discussing your own code is almost impossible for a person who didn't write it. Not because he can't learn it by heart, but because the questions at the presentation are not about what is written. They are about why it's written this way and not another, what was considered and dropped, what was annoying during the work.
A person who wrote it himself has a history of decisions. He remembers the dead ends he walked into, the alternatives he tried, the compromises he made. A person who got the code ready does not have this history. He can explain what a function does. He can't explain why it wasn't built differently.
This is not a perfect filter. A well-prepared candidate can get around it. But to do that, he has to spend so much time understanding someone else's code that it would be easier to write it himself. The economics of cheating stop working.
I don't claim that this is a perfect process. I claim that it's more honest than the one most teams I've been on use.