A migration broke, the team is struggling with Kubernetes, a deployment failed in the most spectacular fashion. So the interview panel wants someone who has done that exact migration before, been a Kubernetes expert for x years, and knows how to respond to what they do not know.
We turn the current pain into a checklist and look for the person who can check the most boxes.
There is nothing inherently wrong with wanting relevant experience. In some cases it really is a hard requirement. But in other cases, the best person for the job is someone teachable.
Think about it. You solved the immediate issue. Maybe even documented the whole process. But a year from now are those issues still relevant? You may have even moved to an entirely new tech stack, and if you hired a niche expert, they may still have the knowledge and experience to help you. But a teachable candidate still has the ability to learn and adapt to new challenges.
Which candidate are you hiring for?
Consider two candidates for the same role.
One knows 95 percent of what the team needs today. They can be productive on the first morning. They also think the missing 5 percent is unimportant, or someone else's problem.
The other knows 75 percent. They are honest about the gaps and can show you how they closed similar ones in previous jobs.
The first candidate probably wins the interview because familiarity is easy to score. The second requires a judgment call: which one do you want on day 365?
Those numbers are invented, of course, and every role has a competence floor. You cannot substitute curiosity for the skills needed to make a safe production change. I would still prefer an experienced engineer in the middle of a serious incident. Experience is useful precisely because it is compressed failure.
What happens when their answer stops working?
This tends to show up in ordinary conversations before it shows up in a major decision.
Someone mentions that the load pattern has changed. The teachable person wants to see the numbers. The other person repeats that the service has always been fine.
A colleague points out an assumption in a design. The teachable person explains why they made it and checks whether it still holds. The other person hears a challenge to their seniority.
The difference is not politeness. Plenty of pleasant people avoid evidence, and plenty of blunt people learn quickly. The useful signal is whether new information is allowed to alter the person's model.
I pay particular attention to the phrase "I haven't seen that before." Sometimes it means, "show me." Sometimes it means, "therefore it cannot be real."
Why does experience sometimes work against learning?
Because experts are paid to know.
People come to them for answers. Their ability to answer earns trust and status. After enough years of that, saying "I don't know" can feel less like a normal description of the situation and more like giving something up.
You can see the defensive habits that grow around it. The long explanation of why the new approach is unserious. The appeal to how things are done in the real world. The sudden change of subject from whether an idea works to whether the person proposing it has enough experience.
None of this means the expert has become incompetent. Often they are still the most knowledgeable person in the room. The trouble is that correcting their knowledge now carries a social cost. Everyone else has to decide whether the issue is important enough to start the argument. That is how you get the most dangerous engineer: someone with enough experience to be trusted and too much certainty to notice when the experience no longer applies.
Good experts avoid this trap by keeping uncertainty separate from identity. They can make a firm call during an incident and revisit it in the postmortem. They can say, "Based on what we know, this is the move," without quietly changing that sentence to, "I cannot be wrong."
Can an interview actually test for this?
It can do better than trivia.
Give the candidate a problem close enough to their experience that they can reason about it, but do not provide every fact. Let them form an answer, then change one condition: the database is shared with another tenant, the queue can deliver twice, the client may remain offline for a week. Watch the transition.
Some candidates will pause, identify which part of the first answer no longer holds, and work forward again. Others will keep defending the first answer as if consistency matters more than being right. A candidate who says, "That changes it," has given you useful information about how they work.
This should not be a trick. Those reward people who have encountered the trick. Use the kind of change that appears halfway through a real project and ruins a clean design. You are trying to learn how the candidate revises, not how they perform while cornered.
Reference checks can help too. Do not ask only whether the person delivered. Ask about a time they had to abandon an approach, learn an unfamiliar part of the system, or accept that someone more junior had found the flaw. The details of the story are more useful than another general statement about being a fast learner.
What has AI changed?
It has made it easier to produce a credible answer without understanding it well enough to know where it breaks. Fresh output can hide a stale mental model.
A teachable person uses the tool to get oriented, then checks the result against documentation, the codebase, and production. Tactical answers are easier to get, so the work moves toward judgment, verification, and the willingness to revise. That is part of what senior means when AI flattens the tactical layer.
Will the company let them be teachable?
That part is on leadership.
If "I don't know" is punished, people learn to bluff. If changing a decision is treated as weakness, people learn to defend yesterday's answer. You can hire a curious person and train the curiosity out of them surprisingly quickly.
Leaders make learning safer when they show their own revisions without turning them into ceremonies. "I was working from the wrong assumption" is usually enough.
Teams still need conviction. Teachability does not require every decision to remain open forever. It requires enough confidence to act and enough honesty to look again when the facts stop cooperating.
Where this goes next
Previous: Experience Is Compression
Next: What “Senior” Means When AI Flattens the Tactical Layer
The one-line version
Hire for what someone knows, but judge their future by what they do when they encounter something they do not.