Peter Mourfield

What separates a great hire from a regrettable one? I’ve been on both sides of that question more times than I’d like to admit.

I was rereading Joel Spolsky’s “Smart and Gets Things Done” recently, and it reminded me how simple his framework really is. He boils it down to two things: is this person smart, and do they get things done? Over the years, I’ve landed on my own version of that filter. I look for three qualities: problem-solving aptitude, the drive to ship, and a growth mindset.

Let me walk through each one, including how I actually try to spot them in an interview.

Problem-Solving Aptitude

I don’t mean “intelligence” in some vague, hand-wavy sense. I mean: can this person hold a problem in their head, break it apart, and work through it while you watch?

Spolsky makes a useful distinction here. He says the best programmers have an easy aptitude for dealing with multiple levels of abstraction simultaneously. That’s what I’m looking for. Not whether someone can recite the difference between a hash map and a tree map, but whether they can reason through a problem they haven’t seen before.

In my experience, the best signal is how a candidate thinks out loud during a coding exercise. I’ll give them a problem and tell them I care more about their approach than the final answer. The strong ones start asking clarifying questions. They sketch out edge cases before writing a line of code. They catch their own mistakes mid-sentence and correct course.

The ones I worry about jump straight to code without asking a single question, or they freeze when the problem isn’t one they’ve memorized.

One thing I’ve learned the hard way: don’t confuse knowledge with aptitude. I once passed on a candidate who didn’t know our tech stack well, and I later realized I’d screened out someone who could have learned anything we threw at them. Spolsky warns against this too. He says the Quiz Show Interviewer, the type who asks trivia questions and gives points for correct answers, is the second worst kind of interviewer. Any specific skill set will be obsolete in a few years. You want someone who can learn.

The Drive to Ship

A developer’s job isn’t to write code. It’s to ship code. Perfect software never ships.

I believed that for years before I could actually articulate it. Early in my career, I worked with a developer who wrote beautiful, well-architected code. But nothing ever made it to production on time. There was always one more refactor, one more abstraction layer. Meanwhile, another developer on the team wrote code that was solid but unglamorous, and her features were consistently the ones that went live on schedule. The difference wasn’t talent. It was orientation.

When I’m interviewing, I look for evidence that someone has actually delivered something end-to-end. I’ll ask about a recent project and listen for whether they describe the work in terms of what shipped or in terms of what they built. There’s a difference. Spolsky puts it bluntly: “Smart but doesn’t Get Things Done” people often have PhDs and work in big companies where nobody listens to them because they are completely impractical.

Neil Roseman, former VP at Amazon, uses a framework called STAR (Situation, Task, Action, Result) to dig into this. He’ll take a specific line from a resume and ask the candidate to walk through what they actually did, then keep drilling. It’s a good technique. When I’ve borrowed it, I’ve found that strong candidates can trace their contribution from problem to deployment. Weaker candidates describe the team’s work and can’t isolate what they personally drove forward.

A Growth Mindset

I’ve written about growth mindset before, and I keep coming back to it. Carol Dweck’s research at Stanford found that people who believe their abilities can be developed through effort and feedback consistently outperform those who treat ability as fixed — not because they start with more talent, but because they keep working and learning when things get hard.

I’ve hired people with strong technical chops who plateaued because they weren’t interested in learning anything outside their comfort zone. And I’ve hired people with gaps in their knowledge who became some of the strongest engineers on the team within a year, because they actively sought feedback and treated every code review as a chance to get better.

In an interview, I’ll sometimes ask: “Tell me about a time you were wrong about a technical decision. What happened, and what did you do?” The answer tells me a lot. Candidates with a fixed mindset get uncomfortable or redirect to a story where they were ultimately right. Candidates with a growth mindset will tell you honestly what they missed, what they learned, and how it changed their approach going forward.

I also pay attention to curiosity. Spolsky says one of his top signals is passion. When candidates talk about a project they care about, they forget they’re in an interview for a moment. They lean forward, they talk faster. That kind of energy usually comes from someone who genuinely enjoys learning.

What Doesn’t Matter as Much

It’s worth saying what I’m not screening for. I don’t care whether a candidate knows our specific stack. I don’t care whether they can reverse a linked list on a whiteboard under pressure (though Spolsky might disagree with me there). I don’t weight pedigree heavily. Some of the best developers I’ve worked with came from non-traditional backgrounds.

What I do care about: Can they think? Do they ship? Are they still learning?

If the answer to all three is yes, everything else is trainable.

Resources

• Smart and Gets Things Done by Joel Spolsky
• The Guerrilla Guide to Interviewing (version 3.0) by Joel Spolsky
• The Anatomy of the Perfect Technical Interview from First Round Review (Neil Roseman)
• re:Work Guide: Structured Interviewing from Google