Here’s a scene. You stumble on a job listing for a senior backend developer. The description is a clean, honest brief: they need someone to refactor a monolithic payment system before it buckles under traffic, tune PostgreSQL queries that currently run longer than a lunch break, and probably untangle ten years of spaghetti left behind by engineers who fled into management. You read it and think, “Yeah, I can do that. I’ve done that. I still have the scars.”
You apply. What comes next isn’t a conversation about indexing strategies or the trade-off between eventual consistency and screaming at your monitor. What comes next is a gauntlet of puzzles that feel like they were designed by someone who skimmed a hiring book once and then got creative with the torture. You’re asked to invert a binary tree on a whiteboard while three engineers stare at you, silently judging your handwriting. You get a take-home assignment to build a miniature social network, complete with a chat feature, because apparently the company’s actual product isn’t enough work for anybody. You sit through a “cultural fit” interview where someone asks which animal you’d be, and you have to fight the urge to say “a vulture, because I’m circling this process.”
This is technical hiring right now. It’s a cargo cult of complexity, a ritual performance that has almost completely detached from the actual job. We’re not testing for competence. We’re testing for endurance, for a narrow kind of trivia recall, and for the ability to smile while being hazed. The problem isn’t just that these processes are annoying. The problem is that they actively select for the wrong people and filter out the exact engineers you claim you need.
The Whiteboard Theater
Let’s start with the classic: the whiteboard coding interview. The premise is simple. Strip an engineer of their tools—no IDE, no Stack Overflow, no docs, no quiet room, no time to think—and ask them to solve an algorithmic puzzle that has nothing to do with the job. Then judge their fitness for a role building maintainable, production-grade systems based on this performance.
This is like testing a chef by making them butcher a live pig in the dining room while you watch, then hiring them to run your pastry station. The skill being tested is not the skill being bought. The environment is a parody of the actual work environment. The pressure is fake. And the problems are often pulled straight from a canon of puzzles that have been circulating for years, which means you’re not even testing problem-solving ability—you’re testing whether the candidate recently crammed “Cracking the Coding Interview” or grinded LeetCode until their eyes bled.
I’ve watched brilliant systems engineers, people who can debug a kernel panic at 3 AM while half-asleep, get rejected because they couldn’t reverse a linked list on a whiteboard in 20 minutes. When, in the entire history of paid employment, has anyone ever needed to reverse a linked list from memory while a stranger watches? The standard library exists. The internet exists. The ability to say “I’d look that up” exists, and it’s a sign of wisdom, not weakness.
The whiteboard interview doesn’t test engineering. It tests performance art. It selects for people who are good at whiteboard interviews. And then we wonder why our teams are full of people who can recite Dijkstra’s algorithm but can’t write a maintainable module to save their lives.
The Take-Home Project That Ate My Weekend
Then there’s the take-home assignment. On the surface, this seems more reasonable. “Here’s a small problem, go solve it on your own time, with your own tools, and we’ll discuss it.” Sounds fair. Sounds like it might actually resemble work.
But in practice, these assignments metastasize. I’ve seen “small” take-home projects that are essentially unpaid consulting gigs. “Build a URL shortener with analytics, a REST API, an admin dashboard, and deploy it to AWS with a CI/CD pipeline.” That’s not a weekend project. That’s a product. And you’re supposed to do it after your actual job, while also maybe seeing your family or sleeping.
The unspoken expectation is that you will spend 20, 30, 40 hours on this thing. The company gets free labor, a dozen candidates all building variations of the same system, and the hiring manager gets to pick the one who had the most free time and the least boundaries. It’s a filter for desperation, not skill. The best engineers I know would look at a 40-hour take-home assignment and laugh, then go back to their actual lives. The ones who complete it are often the ones with something to prove—which isn’t always bad, but it’s not the same as being good at the job.
And then, after you submit your meticulously crafted project, what happens? In many cases, nothing. You get ghosted. Or you get a one-line rejection two weeks later. No feedback. No discussion. Your weekends, sacrificed to the hiring gods, vanish into the void. This isn’t just disrespectful; it’s a signal that the company doesn’t value your time, which is a pretty good preview of what working there would be like.
The Cultural Fit Inquisition
Ah, culture fit. The phrase itself should make your skin crawl. Ostensibly, it’s about ensuring a new hire won’t disrupt the team’s harmony. In practice, it’s a euphemism for “is this person like us?” And “like us” often means “went to the same schools, shares the same hobbies, and won’t challenge our comfortable assumptions.”
I’ve sat in on culture fit interviews where the questions were so vague and subjective that the decision came down to whether the candidate seemed “sharp” or “enthusiastic” or “a good hang.” These are not job criteria. These are vibes. And vibes-based hiring is how you build a monoculture of agreeable mediocrity.
The irony is thick enough to spread on toast. We claim to want diversity of thought, but we hire for conformity of personality. We say we want people who will push back, who will tell us when we’re wrong, but we reject anyone who doesn’t laugh at our jokes or who seems a little too intense about code quality. The best engineers I’ve worked with were often prickly, opinionated, and deeply weird. They cared about the work, not about being your drinking buddy. And they were invaluable precisely because they didn’t fit the mold.
When you hire for culture fit, you’re not building a team. You’re building a clone army. And clone armies are great at following orders and terrible at innovation.
The Trivia Gauntlet and the Hazing Ritual
Some companies favor the trivia approach. You sit in a room, or on a video call, and a panel of engineers fires questions at you like a verbal pop quiz from hell. “What’s the difference between a process and a thread?” “Explain the CAP theorem.” “What’s the time complexity of a hash map lookup?” “How does garbage collection work in the JVM?”
These questions have answers that can be memorized in an afternoon. They test recall, not understanding. They test whether you’ve recently reviewed a “Top 50 Interview Questions” blog post, not whether you can design a system that handles 10,000 requests per second without catching fire.
And then there’s the hazing element. The questions get harder, more obscure, until the candidate breaks. The panel isn’t trying to find the candidate’s ceiling; they’re trying to find the floor, and then push them through it. It’s a dominance display. “Look how much smarter we are than you.” It’s the engineering equivalent of a fraternity paddle, and it selects for people who are either good at trivia or good at pretending to be humble while being humiliated. Neither of those traits correlates with being a productive colleague.
What We Should Be Testing
So if all of this is broken, what does a sane hiring process look like? It looks like the actual job. Shocking, I know.
If you’re hiring someone to refactor a payment system, give them a small, anonymized piece of a payment system and ask them to refactor it. Pair with them. Let them use their tools. Let them talk through their thought process. Watch how they navigate ambiguity, how they ask questions, how they handle not knowing something. That’s the job. That’s what you need to evaluate.
If you’re hiring someone to lead a team, have them lead a discussion about a real technical decision your team is facing. See how they listen, how they synthesize different viewpoints, how they handle disagreement. Don’t ask them to estimate how many golf balls fit in a school bus. That’s not the job. That’s a party trick.
If you’re hiring someone to write maintainable code, look at code they’ve written. Ask them to walk you through a project they’re proud of and a project they’re not proud of. Listen to how they talk about trade-offs, about mistakes, about what they’d do differently. That tells you more about their engineering judgment than any whiteboard puzzle ever could.
The goal of an interview should be to simulate the work, not to simulate a hazing ritual. It should be collaborative, not adversarial. It should respect the candidate’s time and intelligence. And it should be designed by people who actually do the job, not by people who read a book about how Google did it in 2007.
The Real Cost of Bad Hiring Processes
Bad hiring processes aren’t just annoying. They’re expensive. They waste the time of your existing engineers, who have to sit in on these circus acts instead of doing actual work. They drive away good candidates who have options and self-respect. And they select for a very specific kind of engineer: the kind who is good at interviews.
Being good at interviews is a skill. It’s a skill that correlates loosely, at best, with being good at engineering. It correlates strongly with having a lot of free time to practice LeetCode, with being early in your career before burnout sets in, and with being willing to tolerate arbitrary nonsense without complaint. None of these are the traits you want in a senior engineer who will own critical systems and tell you when you’re being an idiot.
The engineers you actually want are the ones who will look at your six-hour take-home project and say, “No, thank you.” They’re the ones who will push back on your whiteboard puzzle and ask, “How is this relevant to the work I’d be doing?” They’re the ones who have enough experience and enough options that they don’t need to jump through your hoops. And by designing a process that filters them out, you’re left with the hoop-jumpers. And then you wonder why your codebase is a mess and nobody will tell you the truth.
The Fix Is Cultural, Not Procedural
Here’s the uncomfortable part. The reason these hiring practices persist isn’t that nobody knows better. It’s that they serve a psychological function. They make the interviewers feel smart. They create a barrier to entry that makes the club feel more exclusive. They provide a false sense of rigor, a checklist that can be pointed to when a hire goes wrong: “Well, they passed the algorithm gauntlet, so it’s not our fault.”
Fixing this requires admitting that our process is theater. It requires humility from the people designing and conducting interviews. It requires saying, “I’m not sure how to test for what we actually need, but I’m willing to figure it out instead of defaulting to what everyone else does.” That’s an engineering problem. It’s a design problem. And it’s exactly the kind of problem we claim to be good at solving.
Start small. Pick one role. Design an interview loop that mirrors the actual work. Use real problems, not puzzles. Pair with the candidate. Give them a laptop, not a whiteboard. Pay them for take-home work if it’s more than a couple of hours. Give feedback, even if it’s brief. Treat candidates like humans whose time matters. See what happens.
I’ll tell you what happens. You start hiring engineers who can actually do the job. Your team gets stronger. Your interview process becomes a selling point instead of a warning sign. And you stop wasting everyone’s time on a ritual that benefits no one except the people who sell interview prep courses.
FAQ
Why do companies still use whiteboard interviews if they’re so bad?
Because they’re easy to standardize and hard to challenge. A whiteboard puzzle gives a numerical score, or at least a pass/fail signal, that feels objective. It lets companies process hundreds of candidates without thinking too hard about each one. It’s the fast food of hiring: consistent, scalable, and nutritionally void. Changing it requires effort and a willingness to trust human judgment, which terrifies large organizations.
What’s a better alternative to the take-home project?
A paid, time-boxed work simulation. Give the candidate a real, scoped problem that takes 2-3 hours. Pay them for their time. Let them use their own environment. Then have a conversation about what they built, why they made certain choices, and what they’d do with more time. This respects their schedule, tests the actual skills, and gives you a much richer signal than a 40-hour unpaid marathon ever could.
How do you assess “culture fit” without turning it into a popularity contest?
Define what you actually mean by culture. If you mean “shares our values around code review and testing,” then ask about their experiences with code review and testing. If you mean “communicates well during disagreement,” then have a structured discussion about a contentious technical decision and see how they handle it. Make it about behaviors, not personalities. And if you can’t define your culture in terms of observable behaviors, then your culture is just “people we like,” and you should admit that and deal with the consequences.
Isn’t it risky to skip the hard technical screening? What if we hire someone who can’t code?
The risk is that your current screening doesn’t actually prevent that. Plenty of people who pass whiteboard gauntlets and trivia quizzes still can’t code their way out of a paper bag when faced with a real system. A work-sample test—where you watch someone code a real problem in a real environment—is a far better guard against incompetence than any puzzle. And if you’re worried about missing something, remember that you have a probation period. That’s your safety net. Use it.
Look, I get it. Hiring is hard. It’s scary. A bad hire can set a team back months. But the solution isn’t to add more filters; it’s to add the right filters. And the right filters look a lot like the job you’re hiring for. Everything else is just noise, ego, and wasted weekends. Let’s stop pretending that making someone suffer through an irrelevant gauntlet tells us anything useful. Let’s start treating hiring like the engineering problem it is.
