How do you onboard a new developer?
What is being assessed
Structure and maturity: you own the team's outcome, not just your own code. "They'll figure it out, we have a README" is a red flag for a senior role.
Answer skeleton
- Before day one: access (repository, CI, TestFlight, tracker), a laptop with Xcode and certificates, an assigned buddy.
- Day one: build the project from a clean clone (if it doesn't build within an hour, that is your tech debt), a 30-minute architecture and module overview, where the code and review guidelines live.
- Week one: a small isolated task with a visible result (a bug, a UI tweak) → first PR → paired review with comments that explain "why", not just "how".
- Month one: tasks that ramp up, participation in planning, a 1:1 with feedback in both directions: what is unclear in the project, what gets in the way.
- Metric: time to the first merged PR and to the first independent feature.
Example answer
S: A mid-level developer with no experience of our stack (TCA + SwiftData) joined a team of three.
T: I needed to get them delivering features on their own within a month without slowing the rest of the team.
A: A week before they started I compiled an access checklist and updated the onboarding doc: module map, "what a typical feature looks like", where the tests are. On day one they built the project in 40 minutes and fixed a UI typo — first PR the same day. Then I handed out tasks that each touched one new layer: view first, then reducer, then storage. I reviewed the first five PRs personally with detailed explanations, and we had a 15-minute "what was confusing" call every Friday.
R: After three weeks they closed a feature on their own; after two months they onboarded the next hire using the same document. A side effect: the document exposed two places where the project only built on the "veterans'" machines.