Technical interviews do not predict job performance. We have known this for years. Study after study shows that whiteboard coding, algorithm puzzles, and system design interrogations have almost no correlation with how well someone actually does the job.
We keep doing them anyway. Why?
Because we went through them. We suffered. We ground LeetCode for months. We memorised sorting algorithms we have never used professionally. We practiced answering questions about designing Twitter’s backend despite never working at that scale. We did the hazing, and now it is our turn to haze.
This is not a hiring process. It is institutional trauma being passed down generation to generation.
Nobody writes code like this at work
When was the last time you implemented a red-black tree? When was the last time you needed to know the complexity of heap operations off the top of your head? When was the last time you solved a problem on a whiteboard with someone watching while a timer counted down?
Never. The answer is never. That is not how software development works.
At work, you have Google. You have documentation. You have time to think. You have the ability to run code and see if it works. You have colleagues to ask. You have the luxury of writing something bad first and improving it later. You have all the tools and none of the artificial pressure.
Technical interviews strip away everything that makes developers productive and then judge them on what remains. It is like evaluating a chef by making them cook without recipes, ingredients lists, or the ability to taste the food. You are not testing their cooking ability. You are testing their ability to perform under arbitrary constraints.
The algorithm obsession
Big tech companies love algorithm questions. They claim these test problem-solving ability and fundamental computer science knowledge. What they actually test is whether you spent the last three months grinding LeetCode.
I have worked with brilliant engineers who would fail these interviews cold. I have seen mediocre engineers pass because they prepared specifically for this type of question. The interviews select for interview performance, not engineering ability. These are different skills.
The defence is always something like we need some way to filter candidates. Sure. But why this way? Why not test things that actually matter? Code reviews. Debugging. System understanding. Communication. Collaboration. All of these predict job success better than knowing how to implement Dijkstra’s algorithm on a whiteboard.
The algorithm hazing persists because the people who passed it are now the ones conducting it. They believe it works because they are evidence that it works. Survivorship bias dressed up as process.
System design theatre
Then there are system design interviews. Design Twitter. Design Uber. Design a URL shortener. You have forty-five minutes and a whiteboard. Go.
These are marginally better than algorithm questions because they at least relate to actual work. But they are still theatre. Nobody designs systems in forty-five minutes. Nobody designs systems without knowing the actual requirements, constraints, and context. Nobody designs systems while someone watches and judges.
The correct answer to design Twitter is: I do not know, I would need to understand the requirements, talk to stakeholders, prototype some approaches, and iterate based on what I learned. That answer fails the interview. You are supposed to pretend you can architect complex systems on the fly.
So candidates memorise patterns. Load balancers go here. Database sharding goes there. Cache layer in front. Message queue for async work. It is a performance, not a demonstration of ability. Everyone knows the script.
We filter out good people
The worst part of technical interviews is who they exclude. People with anxiety who freeze under pressure. People with families who cannot spend months preparing. People from non-traditional backgrounds who never learned algorithm fundamentals. People who are brilliant at building software but terrible at performing.
These people would be great hires. Many of them are great employees at companies with saner hiring practices. But they cannot get past the gauntlet at companies that treat interviews like competitive sport.
Meanwhile, people who are great at interviewing sail through. They have the time and resources to prepare. They stay calm under pressure. They know the tricks. Some of them are also great engineers. Some of them are not. The interview does not distinguish between them.
What actually works
The best interviews I have experienced, both as candidate and interviewer, looked like actual work. Here is a codebase. Here is a bug. Find it and fix it. Here is a feature request. Talk me through how you would approach it. Here is some code. Review it like you would review a pull request.
These exercises test relevant skills. They give candidates context and tools. They resemble the job. They respect everyone’s time by being obviously related to what the person would actually do if hired.
Some companies do take-home projects. These have their own problems, mostly that they favour people with free time, but at least they let candidates work in realistic conditions. You can Google. You can run the code. You can think without someone staring at you.
The bar for improvement is low. Almost anything would be better than the current system. And yet.
We keep doing it because we did it
That is the real reason. Not because it works. Not because we have evidence. Because we went through it, and we turned out okay, so clearly it must be valid.
This is hazing logic. Fraternities use the same reasoning. Military units use the same reasoning. We suffered, so you should suffer, so the next person should suffer. The suffering becomes the point.
Technical interviews are an industry-wide hazing ritual. We all know they are broken. We all complain about them. We all do them anyway. The seniors who could change things went through the process and unconsciously believe it must be meaningful because otherwise their suffering was pointless.
It was pointless. The interviews are bad. We should stop.
We will not stop. But we should.