The 10-Minute Test: How I Know If an Engineer Can Actually Build

People assume a recruiter who isn't an engineer can't judge one. They're half right. I can't review your code. But within ten minutes of sitting down with an engineer, I usually knew whether they could build what a founder needed.

The ten minutes were only the first filter, though. Here's what happened in them, and what happened after.

The first ten minutes

At Tesla, I wanted to know three things early.

What was their motivation for joining Tesla? What did they feel they needed to do their job? And were they scrappy enough to work somewhere with very few resources?

That last one mattered more than anything. Early Tesla didn't have much. If you needed something, you had to build it. So when I asked what someone needed to do their job, I was listening for which way the answer pointed. A list of things other people would have to provide told me one thing. An answer about what they'd go figure out on their own told me another.

What a yes sounds like

After the first few minutes, I'd ask about their work, and certain kinds of answers kept showing up in the people who turned out to be builders.

"The request was vague, so I talked to the people who had the problem before deciding what to build." That's curiosity about solving the right problem.

"I owned this part. My teammates handled these other pieces." They can name their contribution and still give credit.

"I started with a small prototype to test our biggest assumption." They know how to make progress without betting everything on an unproven idea.

"My first approach didn't work. Here's what the evidence showed, and here's what I changed." And the best ones kept going: "After launch, we measured the results and found we needed another adjustment." Their ownership doesn't stop at delivery.

None of these phrases is proof on its own. The proof comes when I say, "Give me a specific example," and they can walk me through what they did, why they did it, what happened, and what they'd do differently today.

What a no sounds like

The warning signs are just as recognizable.

"I just built what I was told." Could they explain the problem, or tell when a requirement needed clarifying?

"We built the whole platform." If every follow-up answer stays at "we," I can't find the person in the story.

"We used it because it's the latest technology." I want to hear why it fit the problem and what it cost them.

"It failed because product didn't understand the requirements." Blame without any reflection is a problem for everyone who'll work with them.

"I've never really made a mistake." Everyone has. The question is whether they learned anything.

What I watch for is a pattern: vague ownership, weak reasoning, blame, little interest in how things turned out. One awkward answer isn't enough. Some excellent engineers just need a more specific question, or a minute to find the words for their work.

I didn't judge alone

This is the part people miss about a non-engineer evaluating engineers. You don't do it by yourself.

It starts at the recruiting kickoff. I'd sit down with the hiring manager and the engineering team to agree on what the role actually required, what someone at that level should know, and what evidence would show they were ready. Together we wrote the screening questions and defined what strong answers sounded like. That gave me a real basis for deciding who moved forward.

Before the onsite, candidates got a take-home assignment with a clear time limit, calibrated to the level of the role. In the onsite, the live exercises reflected the actual work. We wanted to see how someone approached a problem, clarified assumptions, took feedback, and worked through uncertainty. How they reasoned mattered as much as the answer.

My goal was to bring at least five strong candidates to the onsite. If none of them made it through, I brought the team back together to ask hard questions. Were we screening for the right things? Were our expectations aligned? Were we giving candidates a fair chance to show what they could do? (It's the same question I wrote about in what recruiting for Elon Musk taught me: qualified isn't the bar.)

When we got it wrong

People are dynamic, and no process removes the uncertainty. In twenty years of tech recruiting, some of it in the hardest hiring markets there are, there were times our strategy was simply wrong.

What saved us was that the managers and their teams had bought in. Hiring was a shared effort, not something recruiting did to them. That let us be methodical: count the wins, and take the losses apart until we understood them.

Adding a teammate is one of the most important things a team ever does. I push teams to work hard at it, because the right person makes the whole effort flourish. I call it people gardening.

We ask candidates to show curiosity, judgment, and the ability to adapt. We owe them the same.

We're all artists

People ask whether building things myself with AI has changed how I see engineers. Honestly, no.

We're all artists. Engineers are writing their own songs, and I'm still writing mine, in code now and still with my band. We have the same appetite for adventure and the same drive to make something that changes the game. That's what I was listening for in those first ten minutes, all along.