Hire

A hire is a bet on how someone will do the job. The traits that matter most (product sense, agency, grit) are hard to see in an interview and easy to see in real work. So the goal of a hiring process is to get as close to real work product as the situation allows, and to discount the signals people use in its place, mainly credentials and confidence.

Rank the traits

In order of weight:

  1. Product orientation. People who understand the business make good decisions when the spec is wrong, and every spec is wrong somewhere.
  2. Agency. Work-seeking behavior: organizing, driving, and delivering without being told. It's hard to coach, so hire for it.
  3. Grit. The main driver of dependability. Duckworth's research supports it, though later work shrank the effect. The anecdata agrees with the original.
  4. Slope. Learning ability and the desire to use it. Someone who stays current is worth more than someone who was current five years ago.
  5. Technical expertise. Table stakes for a technical role. It's last because it's the easiest to verify and predicts the least once the bar is cleared.

The order follows from how the team works. Sprint goals push ambiguity to the front lines, so the team needs people who resolve ambiguity well.

For managers, add emotional awareness, talent development, and conflict resolution. Don't hire a manager who can't give negative feedback.

See real work

Work product is the best evidence: code someone wrote, calls they made, how they behave on a real team. Standard software interviews are low signal for all three, so get as close to the real thing as you can:

  • Paid trial. A month on the team, on real work, shows whether someone is a quick study, seeks out work, asks for help when stuck, and works well with others. The procedure is in Run a one-month paid trial.
  • The first thirty days. When a trial isn't possible (say, an employed candidate won't leave without a full offer), the first thirty days of onboarding are the trial, with a real decision on day thirty.
  • Work sample. Pair on a real bug in the real codebase for ninety minutes, instead of a whiteboard problem.
  • Past work. Ask about things they've shipped: "Tell me about a time the spec was wrong and what you did."
  • References you find. Call someone who managed them and ask the keeper test question: would you fight to keep them?

This is why "hire slow, fire fast" gets it backwards. A longer interview loop adds little evidence, and a month of work adds a lot, so hire fast and make the real decision at day thirty. It's also kinder than six ambiguous months that everyone involved knows aren't working. A candidate who waits two weeks for an answer has learned something about how the team makes decisions.

Discount credentials

  • Top school. A little signal. It shows ambition and work ethic at seventeen.
  • FAANG. Can cut against someone. Functioning in a very large org is as much politicking as doing good work. Startup experience where they were 100% load-bearing says more.
  • MBA. Hit or miss. Useful for strategic roles, less so for individual contributors.
  • Self-taught. Rarer in the Valley. People with a real interest in a thing pursue their own education.

The credential filter has an error you can't see. Well-credentialed hires turn out to be bad at the job, and you never learn how many un-credentialed people you passed on would have been great.

Discount confidence

Interview panels tend to read confidence as competence. For every strong claim ("I built the billing system"), ask what broke, what they'd change, and what it was bad at. Someone who built it has a list. Someone who sat near it has adjectives.