Every so often, I’ll see someone declare that tech interviewing is “broken”. This is usually a result of a bad experience either as a candidate or as an interviewer. I’m not going to dismiss the fact that the job market is pretty tough right now, and getting an interview can be extremely difficult. But even in the best of times, the interviews themselves have always been a popular target of criticism.

I’ve sat on both sides of the interview table, most recently as a candidate. And after 20 years of experiencing tech interviews, I can confidently say that interviewing has always been broken. It will always be broken. We just have to keep trying to make it the best we can.

That’s not to say interviews haven’t changed a lot. When I graduated, whiteboard coding exercises were just starting to become popular. Now it’s almost antiquated to ask someone to write code on the wall. The algorithmic problems stuck around, but often moved to collaborative coding environments, with the whiteboard reserved for architectural discussions - at least when you could interview in-person.

In the past 10 years or so, I’ve seen algorithmic questions joined by a variety of other code-based exercises. Debugging, reading code, and the also-frequently-criticized take-home test. I’ve been fortunate enough to only have seen “brain teaser” problems (think manhole covers) twice, and once I was asked the far more enjoyable “teach me something”.

Behavioral interviews have also always been in the mix, ranging from a casual conversation, to a set list of rapid-fire questions. More recently, I’ve also seen more and more companies adopting a “resume deep dive” interview, where you discuss a previous technical project in as much detail as possible. While this takes a little skill on the part of the interview, it can provide a great read on how well the candidate actually understands their area of expertise, and can be a pretty fun conversation.

Not only is there a lot of variation in the kinds of questions available in 2026, even within the “cliche” of algorithmic questions, there is huge variation. I once was asked to solve fibbonaci twice in a single week. And on the other side of the coin there are companies that ask complex dynamic programming problems that you really need to have seen before.

There’s no silver bullet format for a technical interview question, no magic list of questions that will guarantee a good signal. As an interviewer, you need to understand why you’re asking any particular question so you can adapt to the endless situations that any given interview question may throw at you. Maybe you have a detailed rubric and a small number of “grades” you can allocate, but there will always be shades of gray.

It’s a balancing act. You’re trying to get maximum signal with minimum time on all sides. You may want to reduce pressure to give a candidate a good impression, or increase pressure to force them to perform at their best or see how they react under fire. You may use problems you’ve seen at your company before since your interviewers understand them and they’re more “realistic”. Or you may want an abstract problem to avoid looking like you’re after “free work”.

Interviewing will never be perfect, it will always suck in some way. As an interviewer, you need to understand the tradeoffs you’re making. As an interviewee, it will help to be aware of the kinds of questions you may be asked, and to read between the lines about what it tells you about the company asking them.