Hire for will, then check that they ask the question first

An engineering head at Autodesk would rather hire the candidate who is ten percent worse at coding.

Omkar Srivastava, who came to Autodesk from Microsoft, framed it as skill versus will, and he picks will. His reasoning is simple. A skilled person who does not really want to be there delivers less than someone a little behind who is hungry to learn. The five or ten percent skill gap closes quickly when there is real urge behind it. The gap in willingness almost never closes at all.

He was giving advice to engineering students, but the idea is not really about students. It describes every hire a software team makes, and it matters more now than it did a few years ago. A skill gap is a temporary condition. A willingness gap is a permanent one, and AI tools have just made the first kind cheaper to close while doing nothing for the second.

The gap that closes and the gap that does not

Most hiring processes are built to measure skill, because skill is what is easy to measure. You can set a coding exercise, score it, and compare two candidates on a sheet. Willingness does not fit on the sheet, so it gets reduced to a line about “culture fit” in the debrief, and the decision goes to whoever scored higher.

That gets the economics backwards. Picture two hires six months in. The one who arrived slightly behind but wanted to learn has spent those months closing the gap, because closing it was the point for them. The one who arrived ahead but was coasting is roughly where they started, because nothing pushed them to move. The scoring sheet predicted day one. It did not predict month six, and month six is the hire you actually made.

None of this means skill does not matter. A candidate who cannot do the basics is not a project, they are a risk. The argument is narrower than that: between two people who both clear the bar, the small difference in skill is the one you can fix, so stop letting it decide.

Juniors are supposed to be behind

For students, that flips the usual interview prep. As a new graduate you will be fifty or sixty percent of the way there on skills, and that is expected. Nobody hiring a junior engineer thinks they are hiring a finished one.

That changes what a junior candidate should be trying to show. Pretending to know everything is the wrong strategy, because the interviewer knows it is not true and the pretending is easy to spot. What a candidate can actually control is evidence that they ramp quickly. How they learned the last thing they learned. What they did when they hit something they did not understand. Whether they say “I don’t know that yet, here is how I would find out” instead of bluffing.

For the team doing the hiring, the same point runs the other way. If a junior is expected to be half there, the interview should not be designed to find the one who is sixty percent there instead of fifty. It should be designed to find the one who will be ninety percent there in a year.

Naming the tool before understanding the problem

The second thing Srivastava flagged is one we keep seeing too. Ask a newer engineer a design question and many of them jump straight to a tool. Somebody describes a data flow and the answer comes back “use Kafka” before anyone has asked how much data there is, how fast it moves, or what happens if a message is lost.

The tool might even be right. That is not the problem. The problem is that the answer arrived before the question was understood, so even a correct answer is a lucky one. The engineer who asks three questions and then says “this is small enough that a database table will do” is showing you something far more valuable than the one who named the fashionable component.

The rule that follows is short: basics plus reasoning beats a memorized solution every time. A memorized solution works when the problem matches the one you memorized it for. Reasoning works on the problem in front of you, including the ones nobody has written a tutorial about yet.

Why AI makes the question more valuable, not less

This is where the idea sharpens for teams working with AI tools.

An AI assistant will produce an answer to almost anything, instantly and with complete confidence. That makes the tool-first habit easier to indulge than it has ever been. Anyone can now get a plausible architecture, a plausible query, or a plausible block of code without understanding the problem at all. The answer looks finished. Whether it fits the problem is a separate question that the tool will not ask for you.

So the skill that is getting scarce is not producing an answer. It is framing the problem well enough to know what a good answer looks like, and then checking whether the one you got is it. That is the same habit as asking the question before naming the tool. An engineer who has it uses AI tools to go faster in the right direction. An engineer who does not uses them to go faster in whatever direction the first answer pointed.

It also connects back to willingness. The tools have lowered the cost of learning new things dramatically. Someone who wants to learn can now get an explanation, an example, and a second explanation in minutes. That is a huge accelerant for the hungry hire, and almost no help to the one who was coasting, because they were not going to ask.

How to interview for it

None of this requires a new hiring process. It requires shifting a few minutes of the existing one.

Give an underspecified problem on purpose. Describe something that is missing key facts and see what the candidate does first. Asking questions is the signal. Starting to build immediately is also a signal.

Ask about the last thing they learned on their own. Not what they know, but how they came to know it. People who learn on purpose can describe the process. People who don’t tend to describe a course they were assigned.

Make “I don’t know” a safe answer. Then watch for it. A candidate who says it and follows with how they would find out is showing you the trait you are trying to hire. A candidate who never says it in an hour of questions is either remarkable or bluffing, and it is usually the second.

Let them use the tools, then ask why. If your team works with AI assistants, let the candidate use one during the exercise. Then ask them to explain what it produced and where it might be wrong. Whether they can do that tells you more than whether they could have written it unaided.

Weigh the debrief honestly. When two candidates both clear the bar, say out loud which one is likely to be further along in a year and why. If the answer is not the one who scored higher, decide whether the score is really what you are hiring for.

Skills you can teach

Every team eventually learns that it can teach a willing person almost anything, and that it cannot teach anyone to want to learn. The hiring process should reflect what the team already knows.

Hire the person who asks the question before reaching for the tool, and who wants the job enough to close the gap. The skill will follow. The will does not.