/en/blog · writing
Why interviews should test engineering thinking and the maturity of solutions, not the capacity for memorization.
Stop conducting "rote memorization" interviews.
In real work, no one writes code "in a vacuum."
A developer:
And that's normal.
👉 Therefore, a normal interview should allow all of this.
The paradox is that access to tools doesn't hide weak candidates - on the contrary, it quickly reveals them.
Someone might perfectly explain:
But at the same time, they might:
What's truly important:
👉 Their "taste" = what they will bring to the product every day.
The same stack yields two results:
The difference isn't in the language or the framework. The difference is in the engineering approach.
What's important is not "what was generated," but:
Without this, you're not an engineer. You're just an operator.
Interviews should test:
Not memorization.
And training should be about:
In short:
👉 A good developer is not someone who knows. But someone who can figure things out and make decisions under uncertainty.