Day-Of Tactics
Reread the morning of. Pre-loop checklist, structural moves for design and coding rounds, traps to avoid, recovery patterns, questions to ask them, the closing statement.
Pre-loop checklist (90 minutes before)
- Eat and hydrate. Hungry interviewees sound rattled.
- Reread 01 — re-anchor on what the role actually is.
- Reread 02 — re-anchor on posture.
- Skim 14 — last vocabulary pass. The terms should slide off the tongue.
- Pick 3 named past projects you'll cite. Have a one-sentence summary of each ready.
- Rehearse your opening 90 seconds out loud, once.
- Pick 2 questions to ask from below.
- Check your environment. Camera, mic, charger, water, paper for sketches. Stable internet.
- Stand up. Walk. Breathe. Cortisol drops in 10 minutes of movement.
- Open one tab with the JD visible. Close everything else.
Structural moves — the shape of a good answer
Senior interviews reward structure. Random good content underperforms well-organized okay content. Two templates cover 80% of the loop:
The design-round template
When asked to design something — a gateway, an orchestrator, a tool router — walk these stages, out loud:
- Clarify the SLO and workload. "What's the QPS, the latency target, the mix of short vs long context, the error budget?" If they don't have specifics, propose some and check.
- Pick the concurrency model. "Async Rust + Tokio, work-stealing. Bounded channels everywhere for backpressure. tower middleware stack."
- Sketch the data plane. Request flow from edge to backend and back. Where caches sit. Where state lives (Postgres for durable, Redis for ephemeral).
- Handle backpressure. Bounded queues, semaphores per tenant, load shedding under saturation.
- Discuss failure modes. What breaks first under load? Tail latency. KV cache pressure. A flaky backend. For each, what's the response — circuit breaker, hedging, route-away, fail fast.
- Talk about observability. Traces, RED metrics, audit events. How would you debug an incident.
- Mention guardrails. Kill switches, rate caps, idempotency keys, approval gates for high-tier actions.
- Bench and validate. "I'd load-test against representative traffic, watch p99 climb with concurrency, look for the saturation knee."
- Surface the open questions. "Things I'd want to figure out: prefix-cache hit rate distribution, the long-context fraction, whether sub-agents are common enough to need their own pool."
"My structure: clarify SLO, pick concurrency model, sketch data plane, handle backpressure, walk failure modes, observability, guardrails. Tell me where to start."
The coding-round template
- Restate the problem in your own words. "Just to make sure — you want X, given Y, with constraint Z."
- State two approaches and the tradeoff. "Naive is O(n²) and trivial; with a hashmap it's O(n). I'll go with the hashmap unless memory is constrained."
- Sketch the data structures and signatures. Type signature first.
fn rate_limit(&self, key: &str, n: u32) -> bool. - Code in small pieces. Talk while you type. Pause to check assumptions.
- Run through edge cases. Empty input. Concurrent calls. Failure on the network. "What happens if the channel is closed?"
- State the complexity. Time and space.
- Identify the next step. "In production I'd add metrics, an idempotency key, a timeout. Want me to write any of those?"
Practice this template on the problems in 11 until the structure is automatic.
Traps to avoid
| Trap | Why it costs you | Replacement |
|---|---|---|
Reaching for unsafe | Signals you don't trust the safe-Rust ecosystem; very rarely needed in service code. | "I'd want a safe-Rust path first; only unsafe if benchmarks demand it and after extensive testing." |
| Ignoring tail latency | Junior signal. Senior interviewers think in p99/p999. | "My SLO frame is p99 first-token under N ms. Median is a starting point, not the answer." |
| Proposing sync I/O on the hot path | Blocks the Tokio worker; betrays Tokio understanding. | Async every I/O; spawn_blocking for genuine sync CPU work only. |
| Unbounded channels / unbounded retries | Both become OOMs or retry storms under load. | Bounded channels with explicit capacity; retry budgets; circuit breakers. |
| Skipping idempotency | "How do retries work for writes?" without an answer is fatal. | Every side-effecting tool has an idempotency key in scope. |
| Claiming experience you don't have | Interviewers detect it; trust evaporates. | "Closest I've done is X; I'd reason about Y from first principles." |
| Designing without asking about scale | Wastes the round on the wrong tradeoffs. | Always ask: QPS, p99, error budget, request mix. |
| Big-bang refactor as the answer | Senior engineers ship in increments. | "I'd profile first, ship the smallest fix that moves the metric, iterate." |
| Forgetting deadline propagation | Easy to overlook; betrays distributed-systems experience. | "Deadlines, not just timeouts — the request's remaining budget flows through every downstream call." |
| Talking only about happy path | Production interviews are about failure modes. | For every component, name two failure modes and the mitigation. |
Recovery patterns when you're stuck
- You don't know the term. "I haven't used X. My closest reference is Y. Want me to reason about it from there, or would you prefer to give me the framing?"
- You realize your design is wrong mid-answer. Out loud: "Wait — that doesn't handle the partial-failure case. Let me revise. Here's the actual move..." Course-correcting visibly is a senior signal, not a junior one.
- You blanked on a detail. "I'd want to look up the exact tokio call here, but the shape is..." Then keep going. Don't dwell.
- You finished early. "I'm happy with that. Want me to walk through the failure modes I'd worry about, or take it deeper somewhere?"
- You're running out of time on coding. Pseudo-code the rest with comments. State the time complexity. Move on.
- The interviewer pushes back. "Tell me where you'd want this to go differently" — engage their reasoning, don't just defend.
- You misread a constraint. "Hold on, let me re-check — when you said X, did you mean Y or Z?" Better than building 20 minutes on the wrong base.
Questions to ask them
End every round with at least one. Pick situationally; here's a strong set:
- "Where's the AI Infrastructure / Agent Systems boundary in practice today, and where is it the most fuzzy?" Shows you've thought about team topology.
- "What's the current p99 first-token-latency SLO and the dominant tail contributor?" Shows latency-aware thinking.
- "How do you currently handle backpressure between the orchestrator and the inference fleet during a spike?" Shows distributed-systems instinct.
- "What's the audit/replay story for an autonomous agent action a regulator might later question?" Shows you take compliance seriously.
- "Where's the biggest leverage for a new senior engineer in the first 90 days — gateway perf, orchestration reliability, or eval/observability?" Shows you're thinking about impact.
- "What's your on-call rotation like for the gateway?" Shows you take ownership seriously.
- "When something breaks at 2am, who owns it, and what does the post-mortem look like?" Shows you've been there.
- "What's the biggest open architectural question the team is debating right now?" Shows you want to engage with the real work.
Closing statement
When the interviewer says "any final thoughts?" — have one. Specific, not generic.
"Two things stood out to me from this conversation: [specific thing about the role/stack/team], and [specific thing about the problem space]. The piece I'd be most interested in working on first is [thing], because [why it fits your strengths]. I came in interested; I'm leaving more interested. Looking forward to whatever's next."
Avoid generic enthusiasm ("this seems great!"). Specifics show you were paying attention.
After the round
- Within 30 minutes: write down what they asked, what you said, where you felt strong, where you stumbled. Memory degrades fast.
- Within 24 hours: send a short thank-you note to the recruiter (or to each interviewer if appropriate). One sentence on something specific from the conversation. Don't grovel.
- Between rounds: spot-fix one thing from your notes. If you blanked on prefix caching, reread 05. Don't try to fix everything.
- If you don't advance: ask for feedback. Most companies won't give it. Some will. It's worth asking.
- If you do advance: revise your notes, pick the 2-3 things you most want to improve before the next round, and drill those.
Every loop teaches you something about how this particular team thinks. The signal is bidirectional — you're learning whether the team is one you want to join, while they decide about you. Good interviews leave you knowing the answer either way.