Hiring well

35 minAdvanced

Hiring well

A hire shapes your team for years, and most hiring mistakes are made before the first interview. This lesson walks through one real loop, the senior backend engineer for the Partner app, from the role scorecard to the candidate's first 30 days.

By the end you can

Write a role scorecard: a one-line mission, the outcomes the hire will own in a year, and 4 to 6 competencies
Build structured interviews with the same questions and written scoring anchors for every candidate
Design a loop where each interviewer owns certain competencies and one step is a work sample close to the real job
Run a debrief where written scores come first, bias has fewer ways in, and the decision follows the evidence
Close the candidate honestly and plan their first 30 days

The everyday picture

A busy restaurant needs a new grill cook for Friday nights. The owner could chat with each applicant for half an hour and pick the one she liked most. Good restaurants do something else. First they write down the job: run the grill alone for 120 covers on a Friday, keep the station clean, and train the weekend helper. Then every applicant cooks the same three dishes in the real kitchen during a short trial shift. Three people taste, and each one scores one thing on a card (taste, speed, cleanliness) before anyone says a word.

When the scores are compared, the cook who talked best in the chat often turns out to be slow on the grill, and a quiet applicant turns out to be the fastest and cleanest. Hiring engineers works the same way. Decide what the job is, watch people do a piece of it, score each part on its own, and write before you talk.

Start from a role scorecard

Most job ads are a wish list: "7+ years, Kotlin, Go, Kafka, Kubernetes, fintech experience, strong communicator". A wish list does not tell interviewers what to look for, so each one checks their own idea of a good engineer. Five interviewers then interview for five different jobs, and the debrief becomes an argument about taste.

Geoff Smart and Randy Street's Who: The A Method for Hiring (2008) starts every hire from a scorecard with three parts:

Mission. One or two sentences on why the role exists. If you cannot write it, you are not ready to hire.
Outcomes. What will be true in about a year if the hire goes well, written so you could check it. "Owns the invoicing module" is vague. "By month nine, the invoicing module is built, deployed and supported in-house, and Lagoon's support contract can end" can be checked. Most roles have three to five outcomes worth writing; rank them.
Competencies. The 4 to 6 skills and behaviours the person needs to reach those outcomes. Mark each one as must-have or nice-to-have, and write one line on what good looks like.

Write the outcomes first and derive the competencies from them. That order removes many false requirements. If the outcome is safe wallet payments, the competency is "designs payment flows that stay correct when calls fail or repeat". A particular message queue product is something a strong engineer learns in a month, so it does not belong on the list. Years of experience is a weak stand-in for the real competency, and it shuts out people who learned fast.

Then share the scorecard. Your tech lead, your manager and the HR partner should agree it before the role opens, because every later step depends on it: the job ad, the screening questions, the interview plan, the debrief and, after the hire, the 30-day plan. A scorecard also lets you say no to a pleasant candidate with a clear reason: "strong engineer, weak on the two must-haves this role needs".

Quick check

Dara wants the Partner app job ad to require "5 years of Go". The team's payments service is in Go. What is the best response?