Hiring and Onboarding Engineers: Loop, JD, Ramp-Up

Hiring is the highest-cost decision a tech lead makes. A wrong hire costs 6-12 months of pain plus the cost of replacing them; a right hire ships value for years. This chapter shows the hiring loop that distinguishes the two and the onboarding plan that turns a hire into a contributor in 90 days.

When does formal hiring process pay back?

Three signals.

The team is growing. First few hires set the bar; later hires either rise to it or drag it down. Process exists to protect the bar.

Bias risk is real. Hiring without a rubric tends to over-hire people who look like the existing team. A structured loop with written rubrics is the single biggest debiasing tool.

Time-to-productivity matters. When the team needs the new hire shipping in 6 weeks, the onboarding plan is what makes that realistic.

If you are a 2-person team hiring 1 person rarely, lighter process works. The discipline pays back when hiring becomes recurring.

What is the cost of weak hiring?

Three failure modes.

Wrong hire. Six months of mismatched output, then the painful exit conversation. Replacement starts the cycle again.

Slow ramp. Right person hired but takes 4 months to contribute meaningfully. Three months of that was avoidable with better onboarding.

Bias drift. Team converges on one type of engineer. Diversity of thought drops; blind spots grow.

What does the minimal hiring loop look like?

# Engineer Hiring Loop — {{ Role Name }}

## Stage 1: Phone screen (30 min, recruiter or hiring manager)
- Resume walk through
- Why interested in this role
- Salary expectation
- Pass criteria: experience matches JD; lives in target timezone

## Stage 2: Technical screen (60 min, engineer)
- 45 min coding (live or take-home review)
- 15 min discussion of their approach
- Rubric: problem decomposition, code quality, communication
- Pass criteria: 2 of 3 dimensions at "strong"

## Stage 3: System design / architecture (60 min, senior engineer)
- 45 min on a system the team actually deals with
- 15 min on past architectural decisions they made
- Rubric: thinks in trade-offs, asks clarifying questions, knows
  failure modes
- Pass criteria: see [system design framework](/system-design/how-to-answer)

## Stage 4: Team fit (60 min, hiring manager + 1 peer)
- 30 min on team values and ways of working
- 30 min on candidate's career goals and feedback to the team
- Rubric: collaboration style match, growth alignment
- Pass criteria: subjective but documented

## Decision (24 hours after final round)
- All 4 interviewers submit written feedback before debrief
- Debrief discusses; hiring manager decides
- Decline candidates within 1 week with feedback if requested

Two details. Each stage has a written rubric and pass criteria. Feedback is submitted before debrief so dominant voices don't sway others.

What does the 30-60-90 onboarding plan look like?

# Onboarding: {{ New Hire Name }}

## Goal: Productive contributor by Day 90.

## Week 1
- [ ] Day 1: laptop, accounts, repo access; intro lunch with team
- [ ] Day 2: read team handbook, [decision log](/tech-pm/decision-logs-and-adrs), recent ADRs
- [ ] Day 3: pair with buddy; explore codebase
- [ ] Day 5: ship one tiny PR (typo fix, doc update, small bug)

## Week 2-4
- [ ] Pick up first small feature ticket
- [ ] Attend all standups, sprint events, retro
- [ ] Shadow one on-call shift
- [ ] First [1-on-1](/tech-pm/one-on-ones) with manager: how is it going

## Week 5-8
- [ ] Own a small feature end-to-end (design, code, test, ship)
- [ ] Take a small on-call rotation slot with backup
- [ ] Attend cross-team sync as observer

## Week 9-12
- [ ] Lead a small project (2-week scope)
- [ ] Run a sprint planning session as facilitator
- [ ] 90-day check-in: what's working, what's missing

## Buddy: {{ Senior engineer name }}
## Manager check-ins: weekly via 1-on-1

The buddy assignment is critical. The manager handles big decisions; the buddy answers "how do I push to production", "who do I ask about the auth service", "is this Slack channel worth muting" - the small frictional questions that slow ramp.

How does hiring scale to multi-team?

flowchart TB
    Need[Hiring need identified] --> Loop[Standard interview loop<br/>4 stages]
    Loop --> Cross[Cross-team feedback<br/>1 partner team interviewer]
    Cross --> Decision[Hiring manager + peer review]
    Decision --> Onboard[90-day onboarding plan]
    Onboard --> Buddy[Buddy from team]
    Onboard --> CrossBuddy[Cross-team buddy<br/>for system context]

At scale, two changes: cross-team feedback in the loop catches hires who would clash with adjacent teams; cross-team buddy during onboarding gives the new hire context beyond their team's view.

What failure modes does this introduce?

• Rubric drift. Same role, different rubric per round, no alignment. Mitigation: hiring manager owns the rubric; reviews it at each loop.
• Take-home homework. Asking 8 hours of unpaid work pre-loop. Mitigation: cap take-home at 90 minutes if used at all; live coding usually beats it.
• Onboarding plan ignored. PDF sent on day 1, never opened. Mitigation: weekly check-ins on the plan in the 1-on-1; buddy reviews at week 2 and 6.
• Single-interviewer veto. One person blocks the hire without written reasons. Mitigation: written feedback before debrief; veto requires articulated rubric failure.

When is formal hiring process overkill?

Two cases.

Hiring a known peer. Bringing in a former colleague you have shipped with - skip stages 3 and 4 if appropriate. The loop is for screening unknowns.

Contractor / fixed-term. A 6-week contractor for a defined deliverable does not need the full team-fit interview. A technical screen plus reference check is enough.

Where should you go from here?

Next chapter: performance and feedback - the structured conversations that follow once the hire is on the team. After that, the artifact chapters (status reports) cover the deliverables that demonstrate progress.