I’ve been on both sides of the hiring table enough times to know that most tech interviews are a circus. Not the fun kind with acrobats and cotton candy, but the kind where you’re asked to juggle flaming binary trees while three strangers stare at the back of your head. The problem isn’t that companies want to filter candidates—it’s that they’ve built an entire priesthood around filtering for the wrong things. And we all just nod along like it makes sense.
Here’s the blunt truth: if your hiring process tests for skills nobody uses on the job, you’re not hiring engineers. You’re hiring professional interviewees. Those are two very different species, and one of them is terrible at shipping software.
The Whiteboard Industrial Complex
Let’s start with the most obvious offender. You know the scene. A candidate walks into a room, gets handed a dry-erase marker, and is told to invert a binary tree on the spot. No syntax highlighting. No autocomplete. No way to run the damn code. Just a grown adult scribbling pseudocode while three people watch in silence, occasionally jotting notes that probably say “nervous” or “didn’t explain Big O fast enough.”
I’ve been that candidate. I’ve also been the interviewer who had to pretend this was a valid way to assess someone’s ability to build production software. It’s not. It’s a hazing ritual dressed up as rigor. The only thing it reliably measures is how well someone performs under artificial, high-anxiety conditions that have nothing to do with the actual work. When was the last time you fixed a production outage by standing at a whiteboard with no access to documentation, Stack Overflow, or even a linter? Never. Because that’s not how engineering works. We debug with tools. We refactor with tests. We design with feedback loops. The whiteboard gauntlet filters for people who’ve memorized algorithm textbooks, not people who can ship maintainable code. It’s a theater of competence, and the audience is just as trapped as the performer.
The Take-Home Project That Eats Your Weekend
Then there’s the other extreme: the take-home assignment. On paper, it sounds reasonable. “Build a small REST API that does X.” But in practice, it’s a black hole. The spec is always just vague enough that you spend twelve hours over-engineering it, because you know the reviewers will nitpick every missing edge case. You add authentication, rate limiting, a Dockerfile, a CI pipeline, and a README that reads like a PhD thesis. You do this for free, on your own time, while still working a full-time job or interviewing elsewhere. Your weekend? Gone. Your partner? Annoyed. Your cat? Wondering why you haven’t moved from the desk in eight hours.
And for what? The company often doesn’t even give feedback. They ghost you after you’ve poured a weekend into their little puzzle box. Or worse, they reject you because you didn’t use the exact library they happen to like internally—a library you couldn’t possibly know about because you don’t work there yet. Take-home projects aren’t inherently evil. But when they’re unscoped, unpaid, and unacknowledged, they become just another filter for privilege: people who have abundant free time, no caregiving responsibilities, and the emotional stamina to keep jumping through hoops. Everyone else gets filtered out, not because they can’t do the job, but because they have a life outside of proving themselves to strangers.
The Trivia Gauntlet: “What’s the Second Parameter of This Obscure Function?”
Some companies love trivia. They’ll ask you about the inner workings of a JavaScript engine, the exact time complexity of a rarely-used sorting algorithm, or the name of a design pattern that only exists in a 1994 Gang of Four footnote. These questions don’t test your ability to build software. They test your ability to memorize documentation. It’s a pub quiz for people who’ve mistaken recall for intelligence.
I once sat through an interview where the panel spent twenty minutes drilling me on the difference between Array.prototype.slice and Array.prototype.splice. I knew the answer, but I also knew that in any real coding session, I’d just look it up in five seconds. The interviewer nodded solemnly, as if this proved I was worthy. It proved nothing except that we were both wasting our time. Engineering isn’t a closed-book exam. It’s an open-world problem-solving discipline. The best engineers I’ve worked with are the ones who know how to find answers, not the ones who’ve preloaded every possible answer into their skulls. Memory is cheap. Judgment is expensive. Guess which one actually matters when the build is on fire at 2 a.m.
Culture Fit: The Euphemism That Eats Itself
“Culture fit” is the most dangerous phrase in hiring. It sounds warm and fuzzy, like you’re looking for someone who won’t ruin the vibe. In practice, it’s a weaponized ambiguity that lets interviewers reject candidates for reasons they can’t articulate—or won’t admit. Too quiet? Not a culture fit. Too direct? Not a culture fit. Didn’t laugh at the team’s inside joke about tabs versus spaces? Definitely not a culture fit. It’s a gut check dressed up as a value system, and guts are notoriously biased.
What we should be screening for is culture contribution. Will this person make our engineering culture better? Will they challenge our bad habits, bring a new perspective, or spot the bugs in our thinking? That’s a much harder question to answer than “do I want to grab a beer with them,” which is what culture fit often boils down to. Homogeneous teams feel comfortable. They also build mediocre products. Comfort is the enemy of good engineering. You want someone who’ll say “this architecture is a disaster” in their first sprint review, not someone who’ll nod along because they’re just happy to be invited to the party.
The LeetCode Industrial Complex
Let’s talk about the elephant in the room. LeetCode, HackerRank, Codility—these platforms have become the de facto gatekeepers of software engineering jobs. They’re not assessment tools; they’re a parallel economy. Candidates spend months grinding problems that have no relationship to the work they’ll do. Companies buy enterprise subscriptions to filter candidates through a gauntlet of dynamic programming puzzles. Everyone pretends this is normal. It’s not normal. It’s a mass delusion with a SaaS billing model.
I’ve seen brilliant systems engineers fail these tests because they haven’t memorized the trick to solving “Trapping Rain Water II” in O(n) time. I’ve also seen candidates who can reverse a linked list in their sleep but can’t write a coherent commit message or design a database schema. The signal-to-noise ratio is abysmal. What’s worse, these platforms have created a shadow curriculum. Instead of learning how to build real things, aspiring developers spend months optimizing for a metric that has no correlation with job performance. It’s like training for a marathon by only doing bicep curls. You’ll look great in a tank top, but you’re not going to finish the race.
What We Should Be Testing Instead
If you want to hire someone who can do the job, test them on the job. It’s not a radical idea. Give them a realistic, time-boxed task that mirrors what they’ll actually do. Pair them with a future teammate. Watch how they navigate ambiguity, ask questions, and debug when things go wrong. Those are the skills that matter. Not whether they can recite the time complexity of quicksort from memory. Not whether they know the second parameter of some function nobody uses. Can they ship? Can they think? Can they make the codebase better than they found it? That’s the whole ballgame.
Here’s a wild concept: pay them for their time. If your interview process requires more than a few hours of work, cut a check. It signals respect, filters for serious candidates, and removes the ethical stench of asking people to work for free. You’re not a charity. They’re not volunteers. If you can’t afford to pay candidates for a trial project, you can’t afford to hire well. Simple as that.
Also, stop optimizing for false negatives. The industry’s obsession with avoiding a bad hire has created processes that reject perfectly good engineers. A bad hire is expensive, yes. But a hiring process that filters out great candidates because they didn’t memorize a textbook is a slow-motion disaster. You’re not building a team of the best; you’re building a team of the best test-takers. And test-takers are great at passing tests. Shipping software? Not so much.
The Interviewer’s Ego Trip
Let’s be honest: a lot of bad interviews happen because the interviewer wants to feel smart. They ask esoteric questions not to assess the candidate, but to remind themselves (and the room) that they know something obscure. It’s a power move disguised as due diligence. I’ve seen interviewers ask about the internals of a framework that the company doesn’t even use, just because the interviewer read a blog post about it last week. The candidate stumbles, the interviewer nods knowingly, and another qualified person gets shown the door. This isn’t hiring. It’s intellectual bullying with a corporate expense account.
Good interviewers check their ego at the door. They’re not there to prove they’re smarter than the candidate. They’re there to discover what the candidate can do, how they think, and whether they’d make the team stronger. That requires humility, not a pop quiz. The best interview I ever conducted was one where I learned something from the candidate. That’s the sign you’re doing it right—when the conversation goes both ways, and you walk out thinking “huh, I never considered that approach.”
Processes That Scale Exclusion, Not Inclusion
Here’s the uncomfortable part: these broken processes don’t just annoy candidates. They systematically exclude people who don’t fit a narrow mold. If your hiring pipeline is optimized for young, neurotypical, native-English-speaking graduates of top-tier CS programs who can afford to spend months grinding LeetCode, congratulations—you’ve built a monoculture. You’ve also filtered out pretty much everyone else. People with families. People with disabilities. People who learned to code on the job instead of in a lecture hall. People who’d bring exactly the kind of perspective your team is missing.
Diversity in engineering isn’t about checking boxes. It’s about having people on your team who see different failure modes, who question assumptions others take for granted, who’ve solved problems in different contexts. When your hiring process filters for a single archetype, you lose all of that. You also lose people who have actual industry experience but can’t afford to take three months off to study algorithm puzzles. The irony is that many companies claim to value diversity while using hiring processes that are structurally biased against it. They’ll spend millions on recruiting initiatives, then funnel everyone through the same broken gauntlet. It’s like building a beautiful wheelchair ramp that leads to a staircase. The intent might be genuine, but the outcome is still a barrier.
What Actually Predicts Performance
Research on hiring has consistently shown that the best predictors of job performance are work-sample tests, structured interviews, and cognitive ability assessments that reflect real problem-solving—not trivia. Yet the tech industry clings to its whiteboard rituals and puzzle gauntlets like they’re sacred rites. We’ve built an entire mythology around “tough interviews” as a badge of honor. “Our interview process is really hard,” managers say, with a straight face, as if difficulty is the same thing as effectiveness. It’s not. A difficult process that measures the wrong things is just an expensive waste of time.
Work-sample tests are exactly what they sound like: give candidates a representative task, observe how they approach it, and evaluate the outcome. Pair it with a structured interview where every candidate gets the same questions, scored against the same rubric. You’ll get better signal, less bias, and candidates who feel respected—even if they don’t get the offer. Cognitive ability matters, but it’s not measured by asking someone to implement a red-black tree from memory. It’s measured by watching them reason through a novel problem with the tools they’d actually have on the job. That’s the difference between a trivia contest and an engineering assessment. One tests recall. The other tests thinking. Guess which one your production systems depend on.
The Cost of Bad Hiring Processes
Bad hiring processes don’t just hurt candidates. They hurt companies in ways that are hard to measure but impossible to ignore. When you optimize for the wrong signals, you hire the wrong people. You end up with a team that’s great at solving puzzles and terrible at shipping software. You get engineers who can ace a coding challenge but can’t collaborate, can’t communicate, and can’t handle ambiguity. They’ll crush a LeetCode hard in twenty minutes, then spend three days bikeshedding a variable name in a pull request. That’s not a win. That’s a liability with a CS degree.
You also burn out your existing team. Every hour a senior engineer spends conducting irrelevant whiteboard interviews is an hour they’re not mentoring juniors, improving architecture, or fixing technical debt. Multiply that across dozens of interviews per hire, and the cost is staggering. And then there’s the reputation cost. Candidates talk. A company known for absurd hiring practices will struggle to attract experienced engineers who have options. The best people don’t need to jump through hoops; they’ll go where they’re respected. Your hiring process is your employer brand in action. If it treats people like circus performers, don’t be surprised when the audience starts booing.
What Good Hiring Looks Like
I’ve seen it done well. A company gives you a realistic, scoped problem—something that actually happened in their codebase. You work on it for a few hours, with access to the internet, an IDE, and a real environment. Then you walk through your solution with an engineer, discussing trade-offs and alternative approaches. It feels like a collaboration, not an interrogation. You’re not performing. You’re working. And the person on the other side isn’t judging you from a throne; they’re sitting next to you, curious about how you think.
Another approach: a paid trial day or week. You work on real tasks with the team. Everyone gets to see how you operate, and you get to see if the company is somewhere you’d actually want to work. It’s honest, it’s respectful, and it produces far better signal than any whiteboard puzzle ever could. Structured interviews—where every candidate gets the same questions, scored against the same criteria—are also a massive improvement over the free-form “tell me about a time you disagreed with a coworker” style. They reduce bias and make it possible to compare candidates fairly. It’s not rocket science. It’s just treating hiring like the high-stakes decision it actually is, instead of a ritual we inherited from companies that were guessing just as much as we are.
FAQ
Why do companies still use whiteboard interviews if they’re so bad?
Because they’re easy to standardize and scale, and because they give interviewers a false sense of objectivity. Many companies also copy what big tech firms do, assuming those firms must know what they’re doing. In reality, even big tech firms are slowly moving away from pure algorithm gauntlets—but the cargo cult persists. “Google does it” is not a reason. Google also has thousands of engineers and can absorb the inefficiency. Your forty-person startup cannot. Stop copying rituals you don’t understand.
What should I do if I’m asked to invert a binary tree on a whiteboard?
You have options. You can politely ask how this task relates to the actual work you’d be doing. You can suggest an alternative assessment that better reflects real engineering. Or, if the company is inflexible, you can walk away. There are plenty of places that don’t treat hiring like a hazing ritual. Your time and dignity are worth more than a whiteboard marker. Walking away from a bad process isn’t failure—it’s self-respect. And self-respect is a pretty good filter for finding a workplace that respects you back.
How can companies fix their hiring process?
Start by defining what you’re actually hiring for. Write down the skills and behaviors that matter for the role. Then design assessments that directly measure those things. Use work-sample tests, structured interviews, and paid trial periods. Audit your process for bias regularly. And most importantly, train your interviewers to evaluate candidates on job-relevant criteria, not on how well they perform under artificial pressure. If your interviewers can’t articulate why a question predicts job performance, they shouldn’t be asking it. Period.
Isn’t it risky to skip algorithmic questions entirely?
No. Algorithmic thinking is important, but it can be assessed in context. Give candidates a real problem that requires algorithmic reasoning—something they might actually encounter on the job. Watch how they break it down, what trade-offs they consider, and how they communicate their approach. That’s far more predictive than asking them to regurgitate a textbook solution on a whiteboard. The goal isn’t to see if they’ve memorized the canonical answer. The goal is to see if they can think through something messy and come out the other side with a solution that won’t fall over in production.
Hiring is one of the highest-impact activities in any engineering organization. Getting it right means building teams that can solve hard problems, adapt to change, and create products that matter. Getting it wrong means wasting everyone’s time—and that’s the one resource none of us can afford to lose. So maybe it’s time to put down the whiteboard marker, close the LeetCode tab, and start hiring like we actually know what we’re doing.
