Small product teams hiring for end-to-end ownership, where the loop is short, idiosyncratic, and usually anchored on a take-home or a paired session in the actual codebase. Use this guide to map the interview rounds, scoring signals, common traps, and high-yield questions for startup, scale-up, seed roles.
There is no calibration to hide behind, so the loop is whatever the founder or lead believes predicts performance - most often a practical build, then a conversation about the trade-offs you chose. Breadth is the bar: the same person is expected to ship the feature, its migration, its metrics, and its on-call. Behavioural rounds are less about principles than about tolerance for ambiguity and whether you make decisions when nobody hands you the requirement.
Treat it as a process gap, not a grudge. Find out where and when decisions are made, get your team's constraints in front of the deciders before the meeting through short written proposals with a comment window both time zones can reach, and escalate a specific costly decision, not the people who made it.
Describe your use of AI tools by task, each with its check: reading cited lines, running code, confirming APIs against the docs for your version. Refuse any answer you cannot check cheaply or that is costly to get wrong, keep restricted data out of unapproved tools, and back it with one real catch.
Choose a work sample with real decisions in it that you still understand line by line and are allowed to share. Be ready to admit which parts were other people's or a tool's, what is wrong with it, and what you would change, because the interviewer can open any file and ask why it is there.
Yes, once and briefly, with an assumption attached. In a hypothetical product exercise the scored move is what follows. Separate gaps that change the design from gaps that do not, choose assumptions that keep the problem hard, write them where both of you can see them, and say which parts of the design depend on each.
A single threshold on a single window cannot separate a real outage from a brief spike, so it either pages on noise or misses slow burns. Replace it with multi-window multi-burn-rate alerting: a fast rule that pages and a slow rule that files a ticket, each gated by a short window so a spike that already stopped does not keep paging.
CPU is compressible, so the kubelet throttles it rather than evicting for it. Eviction comes from memory, ephemeral storage or inodes - and which pods die is decided by QoS class, not by who caused the pressure. Check node conditions and eviction thresholds first, then fix the requests and limits so critical workloads are Guaranteed rather than BestEffort.
Name the clock and what it was costing, say which facts you had and which you chose not to wait for, classify the call as reversible or not, act at the level you were authorised to and say so, and record the reasoning at the time so it can be judged on what you knew.
Stabilise first and diagnose second, which usually means reverting the change before you understand it. Take one artefact of evidence on the way out, time-box the decision aloud, communicate impact on a fixed cadence, and treat the incident as open until the damage the deploy caused is repaired.