What Developer Interviews Got Wrong—And What Modern Teams Actually Test Now

The whiteboard interview is not dead. You can still walk into certain companies, especially in certain geographic markets, and be asked to implement a binary search tree from scratch on a whiteboard while an interviewer watches silently. The format persisted long after the industry developed substantial evidence that it was a poor predictor of on-the-job performance. It took a decade of widespread criticism, a changing talent market, and a few prominent public complaints from respected engineers to start genuinely shifting things.

The shift has happened, unevenly. What replaced the old format isn’t a single new consensus but a patchwork of approaches, some of which are genuinely better, some of which have inherited the same fundamental problem: measuring the wrong things with the wrong proxies. Here’s what actually changed, what didn’t, and what the more thoughtful teams are doing now.

What Was Wrong With the Classic Format

The LeetCode-style algorithm problem interview format — which became dominant at large tech companies in the 2010s and spread to mid-size companies trying to emulate them — had a specific appeal: it felt objective. You either solved the problem or you didn’t. You either got to O(n log n) or you were stuck at O(n²). There was a clear answer, which meant less interviewer subjectivity in the evaluation.

The problems with this were several. First, the problems selected bore almost no relationship to the actual work most software engineers do. Balancing a red-black tree, implementing a dynamic programming solution for the knapsack problem, or finding all subsets of a set — these are genuine computer science problems, and understanding them has some value. But most software engineers, including excellent ones at those same large companies, don’t encounter them in their daily work. The interview was measuring CS competition preparation, not engineering judgment.

Second, and more importantly: algorithm contest performance is highly trainable. Companies like LeetCode, HackerRank, and dozens of prep services built entire industries around teaching people to pass these interviews. The result was a selection process that increasingly selected for people who had invested significant time in interview preparation, not necessarily in engineering skill. This created genuine harm for people who were excellent engineers but couldn’t invest weeks in preparation: parents with childcare responsibilities, people working multiple jobs, people who changed careers later in life, and people who simply found the process alienating and filtered themselves out.

Third, performance in algorithm interviews had documented correlations with factors like educational background, familiarity with competitive programming culture, and available preparation time — all proxies that inadvertently filtered on demographic factors rather than engineering ability.

What Actually Changed

The most significant change at teams that moved away from algorithm-heavy formats is the shift toward work-sample tests. Instead of asking a candidate to solve an abstract problem in a vacuum, you give them something that resembles actual work on the actual codebase or problems relevant to the team. This might be a take-home project, a code review exercise (evaluate this PR and give feedback), a debugging session on a piece of realistic code, or a design discussion about a system architecture problem the team has actually faced.

Work samples have better face validity — they measure something that looks like the actual job — and generally better predictive validity in research on hiring. They also have better candidate experience: developers who are good at their jobs tend to find work sample problems more engaging and fair-feeling than abstract puzzles they haven’t seen in years. The downsides are real too: they take longer, they require more interviewer preparation and calibration, and the subjectivity in evaluating “this person’s approach to the code review” is higher than evaluating “did they get to the right time complexity.” Teams that do this well develop explicit rubrics and train their interviewers; teams that do it badly substitute one form of bias for another.

Take-home projects became popular as an alternative and have also developed a backlash. Asking a candidate to build a complete feature or application in their own time sounds reasonable from the hiring team’s perspective; it gives you a real artifact to evaluate and doesn’t require synchronous interview time. The problem is that “your own time” is unevenly distributed. A junior engineer who is single and has weekends free can put 10 hours into a polished take-home project. An experienced engineer who is caring for young children or elderly parents has much less slack time. The format inadvertently filters on life circumstances rather than engineering ability, and many experienced candidates refuse take-home projects longer than 2–3 hours as a matter of principle.

The Better Formats Teams Are Using

The formats that seem to work best — based on candidate feedback, team satisfaction, and anecdotal retention data — share some common properties: they’re grounded in realistic problems, they let the candidate ask questions and have a dialogue, and they’re evaluated with explicit criteria rather than gut feel.

Collaborative debugging is underused and effective. Give a candidate a real piece of code with a real bug (or a well-constructed realistic one), sit them at a computer with access to documentation and tools, and observe how they approach it. Can they reason methodically? Do they ask clarifying questions? Do they know how to use a debugger? Do they get frustrated and stuck, or do they try multiple approaches? This format is informative about how someone actually works, requires no specialized preparation, and is fairer to candidates who don’t have weeks to spend on LeetCode.

Design discussions — “walk me through how you’d design a URL shortening service” or “how would you architect a notification system” — remain common and remain useful when done well. The key is treating them as conversations rather than tests. The interviewer’s job isn’t to catch the candidate missing the “right” answer; it’s to understand how the candidate thinks about complexity, trade-offs, and failure modes. Candidates who have clearly built real systems at scale demonstrate this naturally. The failure mode is interviewers who have a specific answer in mind and penalize candidates who arrive at a good design by a different path.

Code reviews are probably the most underrated interview format. Every experienced engineer does code review constantly; it’s a genuine job skill that requires understanding of readability, maintainability, security, performance, and team communication. A structured code review exercise — here’s a PR, what do you notice, what would you comment on — tests all of those at once and is something every candidate who has worked on a team has practice with. The exercise doesn’t require memorizing algorithms, doesn’t advantage people who’ve done contest preparation, and produces evaluatable artifacts that interviewers can calibrate on.

What Hasn’t Changed Enough

Interviewer calibration is the persistent failure mode. Good interview formats administered inconsistently produce inconsistent results. When two interviewers evaluate the same candidate’s code review and reach opposite conclusions because they weight different things, the format’s validity disappears into noise. Teams that do structured hiring well invest heavily in calibration: they define explicit rubrics, train interviewers on what good looks like versus average, and build panels with diverse perspectives that cancel out individual biases. Most teams don’t do this rigorously enough.

Reference checks remain largely performative in most of the industry. The standard reference call — “was this person employed here from [date] to [date] and would you rehire them?” — extracts almost no useful information about how someone actually works. Companies with policies against providing substantive references have made this worse. The gap between what reference checks could tell you and what they typically tell you is enormous, and most teams have given up trying to close it rather than developing structured reference check practices that actually work.

AI tool availability has created a new calibration problem. Candidates who complete take-home projects with AI assistance may be demonstrating something genuinely useful (the ability to use AI tools effectively) or may be obscuring weaknesses that would be apparent from unassisted work. Most hiring teams haven’t figured out how to evaluate this clearly, and the evaluations that do exist range from “AI use is fine, evaluate the output” to “candidates caught using AI are disqualified” — positions that reflect different values without necessarily different levels of thoughtfulness.

The Question Worth Asking Candidates

The best signal I’ve seen in interview settings doesn’t come from any particular exercise format. It comes from asking candidates to tell you about a time something they built failed in production and what they did about it. The answer reveals almost everything relevant: do they understand their systems well enough to diagnose failures? Do they take responsibility? Do they learn from it? Do they communicate about it well? Can they explain the technical details clearly to a non-technical person?

Good engineers have stories like that. Engineers who’ve mostly worked on safe, low-stakes projects in carefully controlled environments often don’t — and that’s informative in its own right. The question can’t be gamed by preparation in the same way algorithm problems can. And the answer almost always tells you more about how someone will perform in your actual environment than their ability to reverse a linked list ever could.