Article
Why I Don’t Like The Old Way Of Doing Interviews
Old-school interviews reward memory and pressure, not real engineering. In the AI era, clear thinking, tradeoffs, and problem-solving matter far more than trivia.
I don’t think the old interview style is very good at finding great developers.
In the AI era, it makes even less sense to judge people mainly by whether they can write code from memory or recite theory like a textbook.
The Problem With Old Interviews
A lot of traditional interviews still reward the wrong things.
They ask candidates to:
- Memorize syntax
- Solve trick questions under pressure
- Reproduce algorithms they may never use at work
- Explain theory in a way that sounds impressive instead of useful
That might tell you who is good at interviewing.
It does not always tell you who is good at building software.
Real work is messy, collaborative, and context-driven.
Most developers are not sitting alone in a silent room writing the perfect solution from scratch in 20 minutes.
Why Code Memory Is Not The Goal
I don’t care if someone remembers every method name or obscure edge case from a language specification.
That is not the hard part of the job anymore.
In real life, developers have:
- Documentation
- Search
- Internal examples
- Team conventions
- AI tools for syntax, boilerplate, and explanations
What matters more is:
- Understanding the problem
- Choosing a reasonable direction
- Evaluating tradeoffs
- Debugging and adapting when things change
A developer who knows how to think can learn syntax quickly.
A developer who only memorizes syntax often struggles when the problem becomes unfamiliar.
What Actually Matters In The AI Era
AI changed the game.
If a developer can use AI well, they can move dramatically faster - but only if they understand what they are doing.
That’s why I would rather ask:
- How would you approach this problem?
- What would you clarify before starting?
- What are the tradeoffs between these solutions?
- How would you test this?
- What could go wrong in production?
- How would you break this into smaller steps?
Those questions reveal how someone thinks.
They show whether a person can reason about:
- Architecture
- Debugging
- Maintainability
- Product constraints
- Real-world tradeoffs
That feels much closer to actual development work than writing a sorting algorithm from memory.
Thinking Beats Trivia
A lot of “theory” questions are really just trivia disguised as engineering.
I don’t think it’s useful to ask people to explain obscure details they’ll forget immediately after the interview.
It’s far more valuable to discuss realistic problems:
- A bug in a feature
- A slow page load
- A messy API response
- A component getting too large
- A bad frontend/backend data flow
Now you’re seeing decision-making instead of stress performance.
And decision-making is what matters most on the job.
Better Interview Questions
If I designed interviews, I’d focus more on practical thinking and less on memory tests.
Questions like:
- You’re joining an existing codebase and need to add a feature. How do you start?
- This API is slow. What would you check first?
- How would you structure this feature so it stays maintainable in 6 months?
- A bug only appears in production. How do you investigate it?
- Product and design give conflicting requirements. What do you do?
These questions are better because they show how someone handles uncertainty.
They also let candidates explain reasoning instead of trying to guess the one answer the interviewer wants.
Why This Matters More Now
Years ago, writing code from scratch during interviews made more sense.
Today, that’s not how most developers work.
Modern development involves:
- AI assistance
- Shared codebases
- Frameworks and libraries
- Teams and product constraints
- Faster delivery cycles
So interviews should reflect that reality.
We should evaluate:
- How people think
- How they work with tools
- How they reason through ambiguity
Not whether they can perform memory exercises under stress.
What A Good Interview Looks Like
A good interview should feel like a conversation about solving real problems.
It should help you understand:
- How the person thinks
- How they communicate
- How they handle uncertainty
- How they break down problems
- How they react when they don’t know something
That tells you far more than watching them grind through a whiteboard puzzle.
Final Thought
I’m not saying code and theory don’t matter.
They do.
But in the AI era, the better question is no longer:
“Can you memorize and reproduce this?”
It’s:
“Can you think clearly, make good decisions, and work through real problems?”
That’s the kind of developer I want to hire, work with, and become myself.