Look, I get it. Hiring is hard. You want to find the mythical 10x engineer who can recite Knuth from memory, build a compiler in a weekend, and still have time to grab a beer with the team. But somewhere along the way, we turned technical hiring into a circus sideshow. We’re asking candidates to invert binary trees on whiteboards, solve riddles about burning ropes, and take home assignments that are basically unpaid consulting gigs. Meanwhile, the actual job is debugging a CSS grid in a legacy codebase and figuring out why the build pipeline broke again. The disconnect is so wide you could drive a truck through it.
I’m Fritz Muller, and I’ve been on both sides of this mess. I’ve been the candidate who spent a weekend building a REST API for a fictional pizza delivery service, only to get rejected because I didn’t use the exact ORM the interviewer preferred. I’ve also been the engineer sitting in a hiring meeting, watching my colleagues debate whether a candidate’s failure to solve a dynamic programming puzzle in 45 minutes means they can’t write maintainable React components. It’s absurd. The problem isn’t just that these tests are annoying—it’s that they actively filter for the wrong people and create teams that are great at puzzles and terrible at shipping software.
The Whiteboard Theater
Let’s start with the classic: the whiteboard coding interview. You’re standing in a conference room, marker in hand, while three engineers stare at you. They want you to reverse a linked list. On a whiteboard. With no syntax highlighting, no autocomplete, and no ability to run your code. This is supposed to simulate how you’ll perform on the job. But when was the last time you wrote production code on a whiteboard? Never. Because that’s not a thing. We have IDEs. We have Stack Overflow. We have the ability to think for more than 30 seconds without someone judging our handwriting.
What this actually tests is your ability to perform under a very specific, artificial kind of pressure. It favors people who have practiced whiteboard problems obsessively—often at the expense of building real things. I’ve seen candidates nail a perfect O(log n) solution to some tree traversal problem, then struggle to set up a basic dev environment on their first day. The whiteboard gauntlet selects for competitive programmers, not collaborative engineers. And unless your company’s product is competitive programming, that’s a mismatch.
The defense is always the same: “We’re not testing for the right answer, we’re testing for problem-solving approach.” Fine. But you can test problem-solving with a real-world scenario. Give me a buggy code snippet and ask me to debug it. Ask me to design a small feature and talk through trade-offs. Don’t make me stand at a wall like a naughty schoolchild and derive a red-black tree from scratch. That’s not engineering; that’s hazing.
The Take-Home Project Trap
Then there’s the take-home assignment. On paper, it sounds reasonable: “Here’s a small task, go build it in your own time, and we’ll review it.” In practice, it’s a monster. I’ve seen take-home projects that ask for a full-stack application with authentication, database migrations, a responsive frontend, and a detailed README—all due in 48 hours. That’s not a “small task.” That’s a weekend of unpaid labor, and it disproportionately filters out people who have lives outside of coding. Parents, caregivers, people with side projects or actual hobbies—they’re all at a disadvantage.
And let’s be honest: many companies don’t even review these projects thoroughly. I’ve submitted take-home assignments that I poured 20 hours into, only to get a one-line rejection email with no feedback. Or worse, I’ve been on the other side, where the hiring manager skims the repo for five minutes and makes a snap judgment based on whether the candidate used the “right” folder structure. The signal-to-noise ratio is terrible. You’re not evaluating their ability to do the job; you’re evaluating their willingness to sacrifice a weekend for a chance at a job.
There’s also the plagiarism problem. Candidates can easily copy solutions from GitHub or pay someone to do the assignment. So you’re not even getting a reliable signal. Meanwhile, the candidate who actually did the work is exhausted and resentful before they’ve even started. Great first impression.
The Riddle Me This Interview
Some companies love logic puzzles. “How many golf balls fit in a school bus?” “Why are manhole covers round?” These questions were popularized by certain big tech firms and then copied by everyone else, like a bad meme. The stated goal is to test creative thinking. The actual result is testing whether the candidate has read the same interview prep books as the interviewer.
I once had an interviewer ask me to estimate the number of gas stations in the United States. I gave a reasonable Fermi estimate, walking through population density, car ownership rates, and average station capacity. The interviewer nodded, then told me the “correct” answer was something he’d memorized from a blog post. He wasn’t interested in my reasoning; he was interested in whether I’d read the same blog post. That’s not an interview. That’s a trivia night with higher stakes.
These questions also favor a certain personality type: the quick-thinking, confident bullshitter. The kind of person who can pull a number out of thin air and defend it with a straight face. Is that really the trait you want to optimize for? I’d rather have the engineer who says, “I don’t know, but I’d look it up and get back to you with a real answer.” That’s the person who won’t deploy untested code to production at 4:55 PM on a Friday.
The Culture Fit Charade
“Culture fit” is often code for “people like us.” It’s the most subjective, bias-prone filter in the hiring process, and it’s usually disguised as a casual chat. You’ll get questions like, “What do you do for fun?” or “Tell me about a time you disagreed with a coworker.” The interviewer is looking for someone they’d enjoy having a beer with. But hiring for beer compatibility doesn’t build strong teams; it builds homogeneous ones.
Real culture fit should be about values and working style, not hobbies and personality mirroring. Does the candidate care about code quality? Do they handle disagreement constructively? Do they take ownership of mistakes? These things can be assessed with structured behavioral questions, not a vibe check over coffee. But structured interviews require effort and training, and most companies would rather wing it and trust their gut. The problem is, guts are full of unconscious bias.
I’ve seen teams reject perfectly qualified candidates because they “didn’t seem like a good fit,” which translated to “they were quiet” or “they didn’t laugh at our inside jokes.” Meanwhile, the charismatic candidate who aced the culture chat turned out to be a nightmare—all talk, no commits. Culture fit should be about how someone works, not how they entertain you during a 30-minute conversation.
The Algorithmic Gauntlet
Let’s talk about the LeetCode obsession. Companies act like the ability to solve a medium-difficulty dynamic programming problem in 20 minutes is a prerequisite for writing a CRUD endpoint. It’s not. Most software engineering is integration, debugging, reading other people’s code, and making sensible trade-offs. It’s rarely about finding the optimal solution to a toy problem with artificial constraints.
Algorithmic interviews favor people who have time to grind LeetCode—often students or people between jobs. They penalize experienced engineers who are busy actually building things. I’ve worked with brilliant systems architects who would fail a LeetCode hard because they haven’t touched a red-black tree since college. But they can design a distributed system that handles millions of requests per second. Which skill do you actually need?
The irony is that many companies using these tests don’t even have algorithmically challenging work. They’re building yet another SaaS dashboard, not a new database engine. But they cargo-cult the FAANG interview process because it makes them feel prestigious. It’s like requiring a Michelin-star cooking test for a line cook at a diner. Sure, it’s impressive if someone can do it, but it has nothing to do with whether they can handle the breakfast rush.
The Real Job Preview
So what should hiring look like? It should look like the job. If the job involves debugging, give them a broken piece of code and a debugger. If the job involves code review, give them a pull request and ask for feedback. If the job involves system design, give them a realistic scenario and talk through trade-offs. This isn’t rocket science—it’s just treating candidates like future colleagues instead of puzzle-solving contestants.
Work-sample tests are the gold standard. They’re structured, job-relevant, and consistently shown to be one of the best predictors of future performance. They also give candidates a realistic preview of the work, which helps them self-select. If someone looks at your codebase and runs screaming, that’s a good outcome for everyone. Better to find out now than two weeks into onboarding.
Structured behavioral interviews also work. Ask every candidate the same questions, based on the competencies you actually need. Score their answers against a rubric. It’s not sexy, but it’s fair and effective. And it doesn’t require anyone to balance a binary tree on a whiteboard while humming the Star-Spangled Banner.
The Cost of Bad Hiring
Bad hiring processes don’t just waste candidates’ time—they cost companies real money. A bad hire is expensive, but so is rejecting good candidates for stupid reasons. Every false negative is a missed opportunity, and in a tight labor market, those missed opportunities add up. You’re not just losing that candidate; you’re losing everyone they tell about your ridiculous interview process. Word gets around. Your employer brand takes a hit.
And let’s talk about the internal cost. Senior engineers spend hours designing puzzles, conducting interviews, and debating candidates. That time could be spent mentoring, architecting, or actually writing code. Instead, they’re playing gatekeeper in a process that’s optimized for false negatives. It’s a massive tax on your engineering organization, and most companies don’t even measure it.
There’s also the diversity cost. Processes that favor competitive programmers, trivia buffs, and fast-talkers systematically filter out people who don’t fit that mold. That includes many women, older engineers, career-switchers, and neurodivergent folks. If your hiring process produces a monoculture, don’t be surprised when your team lacks diverse perspectives. And don’t blame the pipeline—blame the filter.
What We’re Actually Testing
Let’s be brutally honest about what these interviews really measure. Whiteboard algorithm challenges test how much free time you had to grind LeetCode. Take-home projects test how much unpaid labor you’re willing to do. Logic puzzles test whether you’ve heard the question before. Culture fit interviews test how similar you are to the interviewer. None of these reliably predict job performance.
What they do predict is compliance. They select for people who are willing to jump through arbitrary hoops without questioning the process. They select for people who have the privilege of unlimited free time. They select for people who perform well under artificial, high-pressure conditions that have nothing to do with the actual work. If that’s what you want, great. But don’t pretend you’re hiring the best engineers.
The best engineers I’ve worked with are curious, methodical, and collaborative. They ask questions. They admit when they don’t know something. They’re not necessarily the fastest coders or the smoothest talkers. But they build systems that work, they fix problems without creating new ones, and they make the people around them better. You won’t find them by asking how to shuffle a deck of cards in O(n) time.
FAQ
Q: Aren’t coding challenges necessary to filter out people who can’t actually code?
A: There’s a difference between a basic coding exercise and a LeetCode hard problem. A simple, job-relevant task—like fixing a bug in a small codebase or writing a function that processes data—can filter out non-coders without selecting for competitive programmers. The goal is to find the minimum viable signal, not to see who’s memorized the most algorithms.
Q: What if our company really does need strong algorithm skills?
A: Then test for that, but do it in a realistic context. If you’re building a database engine, sure, ask about B-trees and write some low-level code. But even then, let the candidate use a computer, an IDE, and reference materials—because that’s how they’ll work on the job. The artificial constraints of a whiteboard interview don’t test real ability; they test interview preparation.
Q: How do we assess problem-solving without puzzles or brainteasers?
A: Give them a real problem. Show them a messy codebase and ask how they’d refactor it. Present a system design scenario with trade-offs and ask them to walk you through their thinking. Use pair programming on a simplified but realistic task. These methods test problem-solving in context, not abstract puzzle-solving skills.
Q: Isn’t culture fit important? How do we assess that fairly?
A: Culture fit is important, but it should be about values and working style, not personality. Define what “fit” means for your team—collaboration, ownership, communication style—and design structured questions around those dimensions. Score every candidate against the same criteria. This reduces bias and ensures you’re hiring for the culture you want to build, not the culture you already have.
Hiring is broken because we’ve optimized for the wrong things. We’ve built processes that are great at identifying people who are good at interviews, not people who are good at the job. The fix isn’t complicated: stop testing for trivia, stop hazing candidates with whiteboard performances, and start evaluating the skills that actually matter. Give people a realistic preview of the work. Treat them like future colleagues, not contestants on a game show. The engineers you want are the ones who can build, debug, and collaborate—not the ones who can recite CLRS from memory. So unless your company’s product is a book of algorithm puzzles, maybe stop hiring for that.
