## Complement Two candidates solve the same problem. Their final code is nearly identical. One is rated senior and the other mid-level, and the difference is entirely in **which parts each of them decided to write.** That is this dimension. Not how well you use the tool, but what you point it at — and, just as importantly, what you refuse to hand over. Think about the last non-trivial thing you built with AI help. - Which decisions in that work had a real trade-off — where two reasonable engineers would disagree? - Who made those decisions: you, or the model? - If someone asked you to defend them, could you? If the model made them and you could not defend them, you did not delegate the work. You delegated the thinking, and in an interview that is visible within a few minutes. ## The dividing line The line is not about size or difficulty. Plenty of hard code should go to the model, and plenty of trivial code should not. The line is **reversibility of judgment**. A useful test: **if you would expect a follow-up question about it, keep it.** Interviewers probe trade-offs. If the model made the decision, you will be reading your own code for the first time while answering. ## The session moment In the session, per-user limits arrive at minute twenty-four. The whole feature could be one prompt. Instead: > "I'll have it do the per-user bookkeeping — a dict of user ID to bucket, and routing `allow` through it. But I want to own how we evict idle buckets, because that's the part with a real trade-off and it's where this leaks memory if we get it wrong." Look at what that split does. The bookkeeping is genuinely mechanical: wrap the existing bucket in a dictionary, key it by user, route the call. There is one obvious correct shape and no judgment involved. Perfect delegation. Eviction is the opposite. Never evict and you leak memory forever. Evict on a timer and you need to pick the threshold and justify it. Use an LRU with a cap and you get predictable memory at the cost of occasionally resetting an active user's bucket. There is no correct answer — there is a trade-off, and picking a side is the work. **And the interviewer asked about memory growth at minute thirty-six.** The candidate who kept that decision had an answer ready, with reasoning. The candidate who delegated it was reading generated code under pressure. Naming what you will keep is, in effect, predicting which part the interviewer will probe. Getting that prediction right is itself strong evidence that you understand where the difficulty in this problem actually lives — which is most of what "senior" means. ## Say it before you do it Here is the part candidates miss most often, and it is nearly free. Unspoken judgment is unscored judgment. If you silently keep the eviction policy and hand over the bookkeeping, you made exactly the right call and the interviewer has no way to know it was a call at all. From the outside it looks the same as not having thought about it. Say the split **before** you prompt, not after: > "I'll let it handle the dictionary plumbing. The eviction policy I want to write myself." Six seconds. It converts an invisible decision into an observed one, and it is the highest ratio of score to effort anywhere in the round. Saying it afterward — *"I kept the eviction logic myself"* — sounds like justification. Saying it beforehand sounds like a plan. Same information, different signal, because the timing is what proves it was deliberate. ## The two ways this fails ### Backwards delegation The most common failure, and it is oddly consistent: candidates hand over the interesting decision and hand-roll the tedium. It happens because the tedium is *comfortable*. Writing a dictionary wrapper by hand feels productive and requires no thought. Meanwhile the eviction policy is hard, so it goes to the model — which happily produces something plausible. From the interviewer's chair this is unmistakable, and it inverts the seniority signal: you have demonstrated that when work gets hard, you stop making decisions. ### Wholesale delegation The second failure is handing over the entire problem: *"now make it per-user"*, sixty lines back, accepted. Sometimes the code is fine. It still scores badly, for a reason worth being precise about: **the interviewer cannot distinguish it from luck.** You made no visible decisions, so there is nothing to evaluate. A no-signal round is not neutral — it is a no-hire, because the recommendation has to be written from evidence. ## What good looks like by level Expectations scale, and the shape of the scaling is worth knowing. The staff-level move in that session would be raising, unprompted, that a per-user limiter with unbounded user growth is a memory-exhaustion vector before anyone asks about memory — treating it as a design concern rather than a tidy-up. ## Practice this **Drill 1 — Split before you start.** Before your next AI-assisted task, write two lists: *mine* and *the model's*. Then work to them. Notice where you are tempted to cross the line, and which direction the temptation runs. **Drill 2 — The defense test.** After finishing, pick three decisions embedded in the result. For each, state the alternative and why you did not take it. Any you cannot defend was delegated when it should not have been. **Drill 3 — Narrate the split.** In your next mock or recorded practice run, say the split out loud every time before prompting. It feels unnatural for about two sessions and then becomes automatic — which is exactly what you want under pressure. **Drill 4 — Predict the probe.** Before you delegate anything, ask: *what will they ask me about this?* Keep whatever you name. ## What's Next A good split still has to be finished. The next dimension is about the difference between working and done.