Senior / Staff iOS — interview prep
System design & soft skills
refactors · debt · influence · people · incidents · scale
StranglerRFC / ADRDRIPostmortemPsych safetyCoupling
01
Large-scale refactor
Q1!
Avoid boiling the ocean — refactor surgically where pain and active work overlap.
Approach
- Start from pain, not aesthetics — measure with KPIs where you can.
- Prefer incremental change over big-bang rewrite.
- Refactor at seams (modules, services, VMs); separate structure from behavior in PRs.
Ship + improve
- Tie work to business value (speed, reliability, quality).
- Add safety nets before risky moves.
- Use standards so the codebase doesn’t regress.
02
Technical debt
Q2- Debt = risk with interest — pay when cost beats delaying a feature.
- Frame in business terms (lead time, crashes, MTTR), not “ugly code.”
- Quantify · batch small fixes · ring-fence larger paydown with an owner and deadline.
03
Driving architecture change
Q3Influence
- Evidence + options + gradual path — earn trust with small wins.
- Pilot in one team or subdomain; measure before mandating.
- Don’t become the bottleneck — enable others.
Decisions
- RFC (Request for Comments) — a short written proposal you share before deciding so others can react async (comments, concerns, alternatives).
- ADR (Architecture Decision Record) — a small doc that records what was decided, why, tradeoffs, and consequences so future you/others aren’t guessing.
- Use either/both so feedback is async, there’s a named decider and date, and the outcome is easy to find later.
- Accept good-enough interim states.
- Respect sunk cost without blame.
04
Onboarding
Q5Mental model first
- Map data flow, layers, and where networking / persistence / UI live.
- Hands-on tasks + early pairing; safe to ask questions.
System
- Docs: architecture + how we work + good examples.
- Reviews teach why; ramp ownership over time.
- Each hire surfaces gaps — fix onboarding continuously.
05
Production incidents
Q6- Stabilize first — rollback, flag, hotfix; name a DRI (directly responsible individual); keep war room small.
- Diagnose with data — logs, crashes, metrics; communicate impact and ETA without over-promising.
- Minimal fix → validate → controlled rollout → blameless postmortem → systemic follow-ups.
06
Scaling code + team
Q7i
At scale, pain is often inconsistency and unclear ownership — not only raw complexity.
- Code: boundaries, standard patterns, modularity for ownership and testability; watch debt compound.
- Process: review norms, docs, CI/tests, explicit ownership, knowledge sharing.