The post has been translated automatically. Original language: English
Hiring senior developers in 2026 is harder than it looks — and not for the reasons people expect.
The problem isn't a shortage of candidates who can write code. The problem is that code is no longer a reliable signal of seniority.
When everyone has Copilot or Cursor open, a mid-level engineer can produce output that looks like senior work. Correct syntax, reasonable structure, tests passing. The take-home task comes back in 20 minutes. The CV looks strong.
And then they join the project. And you find out pretty quickly.
What I've noticed — and what we've had to adapt to — is that code itself has stopped being a reliable filter. What matters now is the thinking underneath it. Can this person explain why they made the decision they made? Can they work inside a messy legacy codebase where AI is basically useless because there's no clean context to feed it? What do they do when requirements change halfway through?
We've shifted how we evaluate. Less "write this function," more "here's something someone else built — what's wrong with it and how would you approach it?" Or just: what questions do you ask before you start?
The strongest developers I've seen lately aren't the ones avoiding AI. They're the ones who use it better than everyone else — because they understand the domain well enough to know when the output is wrong.
AI is a powerful accelerator. But without a strong foundation, it becomes a very confident generator of hard-to-debug mistakes.
We've adjusted how we evaluate specialists accordingly. The bar hasn't lowered — it's just moved to a different place.
What's changed in how your team evaluates technical candidates? 👇
Hiring senior developers in 2026 is harder than it looks — and not for the reasons people expect.
The problem isn't a shortage of candidates who can write code. The problem is that code is no longer a reliable signal of seniority.
When everyone has Copilot or Cursor open, a mid-level engineer can produce output that looks like senior work. Correct syntax, reasonable structure, tests passing. The take-home task comes back in 20 minutes. The CV looks strong.
And then they join the project. And you find out pretty quickly.
What I've noticed — and what we've had to adapt to — is that code itself has stopped being a reliable filter. What matters now is the thinking underneath it. Can this person explain why they made the decision they made? Can they work inside a messy legacy codebase where AI is basically useless because there's no clean context to feed it? What do they do when requirements change halfway through?
We've shifted how we evaluate. Less "write this function," more "here's something someone else built — what's wrong with it and how would you approach it?" Or just: what questions do you ask before you start?
The strongest developers I've seen lately aren't the ones avoiding AI. They're the ones who use it better than everyone else — because they understand the domain well enough to know when the output is wrong.
AI is a powerful accelerator. But without a strong foundation, it becomes a very confident generator of hard-to-debug mistakes.
We've adjusted how we evaluate specialists accordingly. The bar hasn't lowered — it's just moved to a different place.
What's changed in how your team evaluates technical candidates? 👇
