If success in an interview comes down to how many LeetCode examples you can grind through beforehand, then we’re interviewing the wrong thing.
I get it. There has to be some way to determine a candidate’s competency. And when I graduated college, many many years ago, a strong technical interview mattered, because you simply couldn’t Google the answer.
But we’re in 2026. Between search engines and AI now being capable of generating serviceable code, is the real test of a developer’s chops whether they can pressure-code in a 45-minute interview?
For one thing, I’d want to promote a slightly less stressful work environment. But maybe that’s just me.
What I actually want to see
- How do you tackle a problem?
- How do you communicate your thought process?
- How do you fit yourself into an existing codebase alongside other developers?
- Can you connect the technical work to the outcome the company is trying to achieve?
I care less whether you remember the syntax than whether you understand why you’d use it, when you wouldn’t, and the tradeoffs it introduces.
The answer was the questions
I was talking to a developer the other day who wasn’t looking forward to getting back in the job market. He felt he had a lot of prep work to do for the technical interview.
What if they ask me about some technology and how I’d use it in their program?
So I asked him how he’d respond.
“Well, I’d need to know more. What are they currently using in their codebase? Do they have certain patterns they prefer for consistency? I have questions about the purpose and goal of the implementation.”
I smiled and told him that was the answer.
Not the implementation. The questions.
That’s what I’d be looking for. Not whether you can spit out a memorized answer, but whether you can reason your way through a problem while considering the big picture.
As an industry we need to fix the technical part of the interview process. I’d rather have developers brushing up on current patterns and writing code in real projects than studying for a test.