--- title: "Hire and Grow Your Crew" author: "Harry" published: 2026-10-31T04:50:50.065Z updated: 2026-10-31T05:08:36.536Z category: "Career & Teams" tags: [] canonical: "https://fxblog.dev/posts/how-to-hire-a-junior-developer" --- # Hire and Grow Your Crew ## Key takeaways - Write down what the job needs before you read a single CV; otherwise you hire whoever talks best. - Ask every candidate the same questions and score each answer against a written rubric. - Each interviewer scores alone before the panel talks, so the loudest opinion does not decide. - For juniors, test how they learn and debug, not what they already memorised. - Hiring ends on day one of onboarding: a written 30-60-90 plan and a named buddy make the first month work. > **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. | The job needs | How she tests it | | ---------------------------- | -------------------------------------------------- | | Reads code they didn't write | Walk through a short, real function and explain it | | Debugs calmly | A failing test, 20 minutes, thinking out loud | | Asks for help well | Watched during the debugging exercise | | Works kindly with others | One behavioural question, the same for everyone | 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. ![The hiring loop: write what the job needs, ask everyone the same questions, score alone, then discuss; a split panel goes back to the evidence, not to a vote](https://fxblog.dev/media/01a1904b-81e7-7610-af04-fd0797b0f097/1600) _Score first, talk second_ Pip wrote a rubric for each question before the first interview, and one rule for the debrief: nobody speaks until the scores are written. ```text 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. > **Note** > > **Quill:** It rounds before it adds the tax. Tried two cases; one fails. Does tax go before or after the discount? > **Brock:** ...That's the right question. 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. > **Tip** > > Spend the first few minutes putting the candidate at ease; re:Work's interviewer training starts with building rapport. Nervous people debug worse, and you're measuring the debugging. ## 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 ```text 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. ``` > **Success** > > You can run a fair interview, decide on evidence, and give a new hire a first month that works. Next: **One-to-Ones That Matter, and Handling Conflict**. ## FAQ ### What should I look for when hiring a junior developer? How they think through a problem they have not seen, how they ask for help, and whether they can explain their own code. Experience matters less than learning speed and honesty about what they do not know yet. ### What is a structured interview? An interview where every candidate for the same role gets the same questions, and each answer is scored against the same written rubric. It makes candidates comparable and reduces decisions made on first impressions.