skip to content

Walk me through how you onboard a new engineer onto your team.

level: seniorimportance: should knowfreq 43%

answer

  1. the ramp outcome and the deadline you set
  2. week one: access, context, a first contact
  3. the first change and why that one
  4. cadence: pairing, check-ins, who they ask
  5. how you learn the ramp is failing

basics

~20 s

Tests whether you have a repeatable ramp or improvise one per hire. Give the outcome you target and by when, the first weeks you run, the first change they ship, and how you fix the ramp.

how to answer

5 beats
  1. the outcome you aim for and by when
    Open with the target, because it frames everything else: what the joiner should be able to do by the end of week one, week two and the first month. Concrete outcomes beat a list of activities.
  2. what you front-load in the first days
    Say what you deliberately give them rather than let them find: access, the one diagram that explains the flow, the failure modes, and the person they are explicitly allowed to interrupt at any time. Keep it to what you personally own.
  3. the first change and why that one
    Name your selection criteria for the first production change: small, real, touching the main path, recoverable if wrong. This beat is where interviewers hear whether you have actually done this.
  4. the cadence while they ramp
    Pairing frequency, check-in rhythm, how review comments change for a joiner, and when you deliberately step back. Say how the cadence tapers, because a ramp with no end is not a ramp.
  5. how you check the ramp worked and adjust it
    Give the signal you watch and one change you made after it. This is the beat most candidates skip and the one that separates a process owner from someone describing a checklist.

your answer

4 story prompts
pick a story
  • Name the last person you onboarded and what they shipped in their second week.
  • Write your ramp as a checklist a peer could run without you tomorrow.
  • Find one thing your onboarding misses that recently bit a joiner.
  • Note the signal that tells you a joiner is behind, not just quiet.

draft and rehearse your own answer in a learn session

go deeper

This probes ownership of team capability and process thinking rather than a single mentoring relationship. Interviewers want evidence that you have run a deliberate ramp, know what makes a joiner productive quickly, and have adjusted the process when it failed someone. A strong answer sounds like a mechanism you could hand over, not goodwill.

at senior level

My target for a joiner on the reconciliation service is that something of theirs is running in production inside two weeks, and that they can explain how a payment record moves through the pipeline without looking at a diagram. Day one is boring on purpose: environment, credentials, and a half-day where I walk the main flow with them on a whiteboard, including the two ways it usually breaks. I name one person as their default interrupt for the first month, and I say out loud that asking after fifteen minutes of being stuck is the expected behaviour, not a failure. The first task is chosen, not offered. I want something real that touches the main path and is cheap to get wrong. For the last person I hired in, that was tightening the retry backoff on the nightly reprocessing job. It went out on day nine, and it happened to take the overnight peak backlog from about 19,400 records to a little over 2,300, which was a nice accident but mostly it meant she had seen the whole path from change to graph. We paired twice a week for the first month, then once, then on request. The signal I watch is what they ask about in week three — if it is still setup and tooling rather than the domain, my front-loading failed, and that is exactly what made me add the whiteboard walkthrough after a previous joiner spent a fortnight guessing.

why this lands

Works because every beat is concrete and owned: a stated outcome, a named interrupt person, selection criteria for the first task, a tapering cadence, and a week-three signal that already changed the process once. It would downlevel if the ramp were only access and documents with no first change named.

at principal level

At group level I stopped trying to run onboarding and started making it survivable when the best mentor is busy. Across four squads the ramp quality depended entirely on who a joiner sat next to, and the spread showed: median time to a first production change ran from nine days on one squad to thirty-one on another. Three things fixed most of it. First, every squad had to publish a one-page path for a joiner's first two weeks, in their own words — I set the shape and refused to write the content, because a ramp nobody on the team authored is a ramp nobody maintains. Second, mentors were named and briefed rather than volunteered by proximity, and I ran an hour with each new mentor on what to hand over and what to answer with a question. Third, we built a sandbox exercise where a joiner drains a deliberately backed-up queue of about 12,400 messages and writes up what they found, which teaches our failure vocabulary in an afternoon. The median across the group came down to eleven days, and the spread between squads mattered more to me than the median. What I did not standardise was the first task, because the squads know their own safe surfaces better than I do, and centralising that would have made it ceremonial.

why this lands

The principal signal is scope and restraint together: a measured disparity across teams, a mechanism that survives individuals, mentors prepared rather than assumed, and an explicit decision about what not to standardise. It would downlevel into a senior answer if it described running one team's ramp personally.

for a junior

You have been onboarded more recently than most, so answer from that side honestly: what actually helped you, what you had to work out alone, and the fix you contributed back — a corrected setup step, a diagram, a note on where the queues live.

for a middle

Speak as the buddy rather than the designer. Show that you took a joiner through their first change deliberately: which task you picked, how much you let them find themselves, and how you checked they understood the system rather than just the diff.

for a senior

Own the ramp for the team. Give a target for time to first production change, the context you front-load versus what you let them discover, who they are told to interrupt, and the specific evidence that told you the ramp was working or not.

for a principal

Treat onboarding as a system across teams: who mentors, how mentors are prepared, what you measure, and how a good ramp survives the mentor being busy. Say what you deliberately standardised and what you left to each team on purpose.

saying these in an interview costs you the question

  • An onboarding that is only documents and access requests
  • No first change named, or one shipped weeks after joining
  • Treating onboarding as HR's job rather than the team's
  • No named person the joiner is allowed to interrupt
  • The same ramp for a new graduate and an experienced hire
  • Never revising the process after a joiner struggled

  • What does their first week actually look like, day by day?
    Have real texture ready — this probe catches people whose process was invented for the interview. Give the concrete sequence: environment and access, a walkthrough of the main flow, meeting the people they will need, a first small task started before the week ends. Say which parts you own personally.
  • How do you onboard someone more experienced than you?
    Show you change the ramp rather than reciting it. Experienced hires need domain context, decision history and permission to challenge, not tutorials. Say how you compress the mechanics, where you deliberately ask for their outside view, and how you avoid both underloading them and dropping them into ownership with no context.
  • What is the biggest gap in your onboarding today?
    Name a real one and what it costs — tribal knowledge about failure modes, a slow access path, a first task that is too shallow. Then say what you have done or planned about it. Claiming the process has no gaps reads as never having watched a joiner struggle.

context