When thinking matters more than memory
I have been on both sides of interviews. As a candidate. And as an interviewer.
The most uncomfortable moment usually appears when an interview slowly turns into an exam. Someone starts asking for definitions. Function names. Lists of terms. The kind of questions where the goal is not to understand how a person thinks, but to check what they remember.
At that point, the interview stops being useful.
What I actually look for
When I interview engineers, I care about one thing: how they think.
Not whether they remember syntax. Not whether they can recite theory. But whether they can reason about a problem, connect pieces together, and move forward when the answer is not obvious.
Tools can be learned. Technologies change. Definitions are easy to look up. The ability to think clearly under uncertainty is much harder to fake.
Memory is not the job
I do not keep every function or method in my head.
If I have not used something for a long time, I forget it. That is normal.
An engineer is not a storage device. What matters is the ability to:
- understand a problem
- ask the right questions
- find information when needed
- apply it correctly in context
Someone who relies only on memory struggles the moment the situation changes.
Someone who can reason adapts.
How I approach interview questions
Instead of asking for facts, I prefer questions that reveal thinking.
For example:
- How would you check that a system not only survives load, but also recovers after it?
- How would you look for a bottleneck if metrics are incomplete or misleading?
- When would you choose a long-running test, and what kind of behavior would worry you?
There is no single correct answer. What matters is the path.
I pay attention to how a person structures the problem, what assumptions they make, and how they react when something does not fit.
About live coding
Live coding is often treated as proof of skill. In reality, it proves very little.
Writing code without access to documentation, search, or tools does not reflect real work. No one operates that way on real systems.
Spending hours on artificial tasks during an interview often replaces more useful discussions. Looking at real scenarios. Analyzing behavior. Talking through decisions and trade-offs. That tells me much more than watching someone type.
The signal I care about
If I need someone who can repeat definitions, I can hire a junior.
If I need someone who can deal with uncertainty, incomplete information, and real systems under pressure, I look for a different signal.
I look for engineers who ask questions, explain their reasoning, and stay calm when the answer is not obvious. That kind of thinking matters far more than memory.