Hire and Grow Your Crew

TL;DR Hire on "do I like them?" and you hire whoever talks best, then spend months on a poor fit or lose a good junior in a bad first month. How to hire a junior developer fairly: decide what the job needs before you read a CV, ask every candidate the same questions, score each answer alone before the panel talks, and start your hire on a 30-60-90 plan with a buddy.

Do this: Before your next hire, write what the job needs and one scored question for each need.

Part 1, From Best Engineer to First-Time Lead, ended with an empty seat on the checkout crew and Kit's verdict: "You're the lead. You hire." Pip has never interviewed anyone. Two days before the first candidate, she corners Kit by the coffee.

"How do I know who's good in 45 minutes?"

"Decide what good means before they walk in."

Dev Voyage: Uncharted Waters, in five parts:

1. From Best Engineer to First-Time Lead
2. Hire and Grow Your Crew (you are here)
3. One-to-Ones That Matter, and Handling Conflict
4. Manage the Team: Goals, Trust and Delivery
5. Build the Ship You Want to Sail On: Culture and Giving Back

Decide what good means first

The last interview Pip had shadowed ended with Brock saying "I liked her", Ollie saying "I didn't", and nobody able to say why. A vote on a feeling.

So before opening a single CV, Pip wrote what the junior must do in six months, and how she'd test each.

Years of experience, a famous company and a favourite framework aren't on the list. Pip wanted to see how a junior learns, not what they already know.

Same questions, scored alone

Google's re:Work guide to structured interviewing sums up the method: the same questions for every candidate, answers graded on an identical scale, and decisions based on consistent, predetermined qualifications. The guide's reason is blunt. In first encounters we make snap judgments, then spend the interview confirming them.

Pip wrote a rubric for each question before the first interview, and one rule for the debrief: nobody speaks until the scores are written.

Score each 1-4 BEFORE the debrief.  4 strong · 3 solid · 2 borderline · 1 weak

1. Reads unfamiliar code      [ ]  Notes: what they explained, where they got stuck
2. Debugs a failing test      [ ]  Notes: what they tried first, how they used hints
3. Asks for help              [ ]  Notes: did they say what they tried and need?
4. Works with others          [ ]  Notes: how they spoke about a past mistake

Hire / no hire, and the one thing that would change my mind: ______

When Brock scored one candidate 4 and Ollie scored them 2 on the same question, they read their notes aloud. Brock had given a hint Ollie hadn't. The disagreement went back to the evidence, not to a vote.

Interview 3

Three candidates reached the final round. One had the best CV and froze on the failing test. One solved it fastest but blamed "the previous developer" twice. The third was Quill, a young hedgehog fresh from a bootcamp, and he took the longest.

In the debrief, Pip said "Scores first, then we talk." Brock held up his sheet: "Four. With notes." Every interviewer had written the same thing: tried, saw, need.

Hiring ends on day one

The offer isn't the finish line. The hire is done when Quill can do the job. Pip did for him what Kit once did for her:

1. A 30-60-90 plan drafted together in week one, checked every two weeks.
2. A named buddy who isn't the lead. Bun volunteered.
3. A first ticket that walks the whole path, branch to production, in week one.

GitLab's handbook treats onboarding the same way: a structured plan with owners, not a welcome email.

Try it

Before your next hire:

1. Write what the job needs in six months, before any CV.
2. Write one question set and a rubric for each question.
3. Make every interviewer score alone before the debrief.
4. Have a buddy and a first ticket ready before day one.

Quill started on a Monday. By Friday he had fixed two wrong steps in the setup guide and opened his first real pull request, a change to the discount rounding. Brock reviewed it: fourteen comments, the last one "Why would anyone write it like this?". The next morning Quill didn't come to standup. Part 3, One-to-Ones That Matter, and Handling Conflict, is what Pip did that week.

Read this with your AI

Read the post "Hire and Grow Your Crew".
1. I'll describe the role I'm hiring for. Turn it into four testable needs and a question for each.
2. Write a strong, solid, borderline and weak answer for each question, as a rubric.
3. Draft the first-week schedule and a 30-60-90 plan outline for the new hire.