Technical Interviews Reject the Wrong Engineers | by Fayner Brack | May, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Technical Interviews Reject the Wrong Engineers

20 years of observation, 50 years of research, and a framework for measuring the interview instead of the candidate

Fayner Brack

12 min read·<br>May 11, 2026

Listen

Share

The Skill Spectrum: A representation of Dreyfus Model of Skill Acquisition applied to an expert candidate versus an Advanced Beginner interviewer

Want to come back later? Save this to readplace.com.<br>fagnerbrack.com | Reader View<br>View on Readplace.

readplace.com

Most companies treat hiring like a filter. Put candidates through enough rounds, ask enough questions, and the good ones will survive. The problem is that the filter is broken. It selects for the wrong things, rejects people it can’t evaluate, and costs more when it fails than most teams realize.<br>I’ve spent over 15 years observing and researching technical interviews. I’ve watched brilliant engineers get rejected because they didn’t solve a problem the way the interviewer expected. I’ve watched mediocre engineers get hired because they had practiced the right LeetCode patterns. And I’ve watched companies repeat this cycle while citing a “cost of a bad hire” statistic that, as it turns out, no one can trace to an actual source.<br>This post is about what the research says, where the common tools break down, and a framework I built to measure interview quality itself.<br>The cost of getting it wrong is… wrong?

You’ve probably seen the claim that the U.S. Department of Labor estimates a bad hire costs 30% of first-year earnings. I went looking for the original source. There isn’t one. No DOL publication, no report title, no URL. Every article cites the last in an infinite loop. The same is true of the “80% of turnover is due to bad hiring decisions” figure attributed to Harvard Business Review. No specific HBR article contains that number.<br>This is not surprising, it's the same effect as The Learning Pyramid. A bunch of trusted sites repeating the same thing they heard somewhere else with no reference to the original impirical sources.<br>The real research is less dramatic but more useful.<br>The Center for American Progress reviewed 30 case studies in 2012 and found the median replacement cost across all positions is about 21% of annual salary [1]. For workers earning under $75K, that number holds. For senior roles, it climbs to 213% [1].<br>But replacement cost is the wrong frame for engineering teams. The more useful finding comes from Housman and Minor’s 2015 Harvard Business School study of 50,000 workers across 11 firms [2]. They found that avoiding a toxic worker generates roughly twice the return of hiring a star performer. A toxic worker costs about $12,489 in direct replacement. A top-1% performer adds about $5,303 in value [2]. And toxic behavior spreads. When one joins a team, peers become more likely to behave the same way.<br>The biggest hiring risk is not missing a great candidate. It is letting a destructive one through.

The reason this matters: most interview processes are designed to find talent. Few are designed to detect toxicity, and the two goals require different signals.<br>Whiteboard interviews test whether a candidate can perform under observation while solving a problem they’d normally Google. A 2020 study by Behroozi et al. found that candidates given traditional whiteboard interviews with an observer performed at half the level of those who solved the same problems privately [3]. All women in the public condition failed. All women in the private condition passed [3].<br>This is not a talent filter. It is an anxiety filter.<br>Pair programming interviews are better, but they carry their own distortion. Pair programming was designed as a collaborative practice for producing code, not for evaluating a stranger’s skill under time pressure. When I pair with a colleague on my team, we share context, vocabulary, and trust. An interview has none of those. The candidate is performing while being watched by someone who holds power over their career. Calling that pair programming is like calling a job interview a conversation.<br>The deeper issue is tacit knowledge. Most of what a skilled engineer knows is not something they can articulate on demand. They recognize patterns. They sense when a design will cause problems in six months. They make tradeoffs that feel obvious to them but are invisible to someone at a different skill level. Standard interviews are built to test explicit knowledge: can you explain this algorithm, can you describe this pattern, can you walk through your reasoning.<br>The candidates who perform best are those who are good at talking about code, which is a different skill from writing it.

Some companies try to add science to the process with personality assessments. The two most popular choices in tech hiring are the Myers-Briggs Type Indicator and...