Why I Stopped Asking Whiteboard Coding Questions

What you actually need to know

• Whiteboard coding tests measure the ability to perform algorithmic recall under social pressure. That skill has almost no relationship to what a developer will produce on a real product.
• The best developers I know perform poorly on whiteboard tests and ship production code that other developers describe as the cleanest they have ever worked in.
• The test was designed to handle a high volume filtering problem inside large tech companies. It was not designed for founders evaluating one or two developer candidates.
• What you actually want to know: can they build, can they communicate, do they have judgment, and will they tell you when something is wrong. None of those show up on a whiteboard.
• The paid two week trial replaces the whiteboard and answers every question the whiteboard pretends to answer, plus several it never could.

The core argument

I used whiteboard tests for about two years at the start of my independent practice. I asked the classic questions. Reverse a linked list. Find the two sum. Implement a binary search. I told myself I was being rigorous. What I was actually doing was filtering on a set of skills that have nothing to do with shipping a product, and making the candidates I liked the most the most uncomfortable.

The breaking point was a hire I almost did not make. An engineer who had built three production SaaS products, had a clean GitHub history, and gave the most coherent explanation of an architectural decision I had heard in a year of interviews. She could not get through the linked list reversal without getting flustered. She knew what to do. She could not execute it smoothly under the artificial pressure of the whiteboard with two people watching. I hired her anyway, on a trial basis. She was one of the best collaborators I have had on a technical project. She was nearly filtered out by a test that was measuring the wrong thing.

The reason the whiteboard persists is partly habit and partly the comfort of having a legible signal to point to. If a candidate gets the algorithm right, you can tell yourself you hired well. If they miss it, you can tell yourself you made the right call. The test provides cover. The problem is that the cover is not protecting against the actual risks in a developer hire. The actual risks are: poor communication, bad judgment on architectural decisions, inability to work without supervision, and the tendency to hide problems until they are expensive. The whiteboard catches none of these.

There is also a cultural selection effect that I find troubling. Whiteboard tests favor developers who have recently memorized algorithms, either because they are early in their career and studied computer science recently, or because they have spent time preparing specifically for this kind of interview. Neither of those is a useful signal for a founder who needs someone who can ship a product. The developers who spent the last six months studying algorithm patterns for job interviews are often not the same people who spent the last six months building things.

What to ask instead

Ask them to walk you through a real system. Pick one project from their portfolio and ask them to describe it from kickoff to launch. Not a highlights reel. The full story: what they built first, what surprised them, what they would do differently. The honest version takes four to six minutes and covers more technical ground than a whiteboard problem because it is grounded in real decisions under real constraints.

Ask what worries them about your project. This question is impossible to prepare for and almost impossible to fake. A developer who has been listening to your brief has already started building a mental model of the risk. If they give you a specific, thoughtful concern, you are talking to someone who is paying attention. If they say nothing worries them, they either have not thought about it or they are telling you what they think you want to hear.

Ask them to review a piece of code. Give them a short function or a small schema design, real or constructed, and ask what they would change. This is closer to what they will actually do in the job than any algorithm problem. It also reveals whether they can communicate technical feedback clearly, which is one of the most important things you need to know.

Run a paid trial. Two weeks on a real piece of the product. You learn how they communicate when they are stuck, how they handle feedback, whether they surface problems early or late, and what their actual code looks like in context. This is the test that replaces everything else.

What it requires

What to look for

• They describe a past failure with specificity. The project, the decision, the consequence, and what they learned. No specificity means the story is constructed.
• They slow down on your follow up questions rather than speeding up. Speeding up is a sign of burying the question.
• They offer opinions on the product without being asked. This is engagement, not impertinence.
• They ask about your timeline and your users before they ask about the tech stack. The best developers are curious about the problem first.
• The code in their portfolio is readable by someone who was not there when it was written. That is a better quality signal than any algorithm test.
• They treat the trial as a real engagement, not a performance. They ask questions, flag blockers, and communicate status as if the trial were a production project.

Expert opinion

I stopped asking whiteboard questions when I realized I was optimizing for the wrong outcome. The test gave me a legible pass or fail and it was almost entirely decorrelated from the thing I actually needed to know, which was whether we could build together under real conditions. The paid trial replaced everything and the hiring quality improved in the first cycle. I have not looked back.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

The clearest example from my own practice was a developer I hired for a complex data pipeline project. He had no computer science degree, no famous employer on his resume, and he was visibly nervous in the first call. He had three production projects with real user numbers and a GitHub history that showed consistent work over four years. I ran the project walkthrough question and he spent seven minutes on one of those projects, naming the data modeling mistake in month one, how it surfaced, and what the redesign cost. That answer alone told me more about his judgment than any algorithm problem would have.

The trial confirmed everything the walkthrough suggested. He was direct, he flagged a problem in day three before it became a blocker, and the code he shipped was documented well enough that I understood it without asking him to explain it. The project ran on time. The codebase is still in production two years later. For more on what the trial process should look like and how to structure the vetting beyond the test, the vetting framework covers the full hiring due diligence. For the questions that replace the technical test in the first conversation, the ten questions for non technical founders is the better starting point.

Common mistakes

1. Using the whiteboard as a shortcut to avoid having a real conversation about the candidate's work. The conversation is harder and more useful.
2. Applying big tech interview standards to a one or two person hire. The context is completely different and the filtering logic does not transfer.
3. Rejecting candidates who test poorly but have strong portfolios. The test is measuring nervousness and preparation for the test, not engineering quality.
4. Treating a take home test as sufficient evidence of working style. A take home tests solo output. It does not test communication, which is often the variable that determines project success.
5. Skipping the paid trial to save the hiring budget. The trial cost is the best money in the hiring process.
6. Not reviewing the actual code in the candidate's portfolio before the call. The portfolio review is faster and more predictive than most interview questions.
7. Confusing smooth interview performance with strong working style. Some developers are excellent at performing well in structured conversations and poor at the unstructured reality of a project.

A 21 day plan

1. Days one to three. Stop using the algorithm test. Write three questions based on the candidate's actual portfolio that you will ask in the first call. One about a specific project. One about a failure. One about what worries them about your brief.
2. Days four to seven. Run calls with three candidates. Do not score them on technical answers. Score them on specificity, honesty, and the willingness to give you a real answer to a hard question.
3. Days eight to fourteen. Run a paid two week trial with the best candidate on a real, scoped piece of the product. Pay the trial rate upfront. Evaluate on behavior, communication, and output quality in that order.
4. Days fifteen to twenty one. Make the decision. If the trial was clean, begin the full engagement with a weekly demo cadence in the contract. If it surfaced a concern, either address it directly or move to the second candidate. For more on what the ongoing engagement should look like once you have hired well, the three strikes rule for developers covers what happens when the working relationship starts to break down.