Should we test what a candidate doesn’t know?

— Alternative assessments

When evaluating a candidate, most people are concerned about AI usage. Statements like “Using AI is prohibited and will lead to disqualification” are the norm. This happens because we are still convinced, whether consciously or subconsciously, that a candidate must know every single concept by heart, without relying on external sources.

But this kind of approach is becoming increasingly senseless, because what can be done by a machine shouldn’t be done with greater effort by a human. Nobody, unless they are a hipster, would write books with a typewriter; and surely editors wouldn’t accept a stack of sheets to edit. But when it comes to coding, candidates are still expected to code in Notepad, without auto-completion, and - above all - without AI.

In 2026 the real skill is not knowing how to implement Dijkstra’s algorithm by hand. In fact, it’s not even knowing that Dijkstra’s algorithm exists. Every LLM can tell you that, with useful examples of real use cases. The real skill is approaching a topic you don’t fully understand, building the foundation to grasp it, and building something new. This is what we should aim for. This is what genuinely empowers us as developers.

My idea of a solid coding assessment in 2026 works as follows. Ask the candidate to implement something close to what they claim to know, but not entirely overlapping. If they know JavaScript, use Python. If they know Python, use C++. Ask them to build an implementation from scratch, or to spot a logical flaw in an existing program. Don’t focus on idiot trick questions like whether code returns a TypeError or an Exception: who cares? If it doesn’t work, it doesn’t work; the micro-details don’t matter. Judge how candidates reason, not what they have memorized. Reward intelligence over rote learning.

“But if you don’t know the technical details, you can’t tell if the AI is wrong!”. Only someone unfamiliar with AI would make this claim. This is not to deny hallucinations, but hallucinations rarely involve syntax. And if they do, the LLM will catch and handle the errors faster than you. LLMs are damn good at syntax; they spot details that no human engineer would catch in the same amount of time. Where LLMs can fail is architecture; and architecture is not about rote knowledge, it’s about reasoning and intelligence.

We should select people for their intelligence and their ability to solve real-world problems, not for their skills in competitive programming; we must retain mastery over what we do best, and not fight machines in areas where they are already superior.