Positioning From Scratch
Mindset before content. How to interview honestly when you have strong systems-Rust experience but limited ML serving — or strong ML infra in Python but limited production Rust.
The mindset
Senior interviews reward posture almost as much as content. The posture that wins for this role:
- Honest about gaps. You can name the things you haven't done.
- Specific about adjacent strengths. You can name the closest thing you have done and reason from it.
- Comfortable reasoning from first principles. When you don't know, you derive.
- Curious in the loop itself. When the interviewer teaches you a concept, you absorb visibly and use it later in the conversation.
None of this requires inventing experience. All of it can be true on Tuesday after a weekend of preparation.
Two common candidate shapes
Most people coming into this loop fall into one of two profiles. Find yours, then read the right subsection.
| Profile | Strong | Soft |
|---|---|---|
| A. Rust systems engineer | Async Rust, Tokio, gRPC, distributed systems, perf optimization | Model serving, LLM specifics, prompt/agent eval, ML pipeline conventions |
| B. ML infra engineer | vLLM/Triton/Ray, Python orchestration, eval frameworks, observability for ML | Production Rust idioms, ownership/lifetimes, async-Rust pitfalls, tower middleware |
Plenty of candidates straddle. The strategy in either case is to lead from strength, name the gap once cleanly, then redirect.
Profile A — strong systems-Rust, light on ML serving
You have shipped Rust services at scale. You can talk about Tokio internals. You haven't called vLLM or designed an inference gateway. Your task: convince them the ML-specific knowledge is bounded and learnable, while your systems instinct is the rarer ingredient.
The story to lead with
"My background is high-scale Rust services — [name them: the order book router, the streaming pipeline, the auth gateway, whatever]. I've operated services at [QPS, p99, scale]. I'm coming to AI infrastructure because the production shape — high concurrency, tail-latency sensitive, lots of fanout — is exactly the systems work I already do, and the LLM-specific layer on top is something I've been ramping on. I've spent the last [N weeks] going deep on vLLM batching, gateway patterns, streaming response design, and agent orchestration. The places I'd be learning on the job are the specifics of how your inference fleet is currently routed and what the agent state model looks like."
What to drill before the loop
- Read the vLLM batching / continuous-batching docs. Be able to explain it in 60 seconds.
- Understand streaming responses (SSE) end-to-end — server emits tokens, client consumes, backpressure, cancellation.
- Know prompt caching and prefix caching at a conceptual level (chapter 05).
- Be able to sketch a ReAct loop on paper. Tool call → result → next thought.
- Understand KV cache (what it is, why prefix caching exists). You don't need to operate it; just sound aware.
Bridging from your strengths
Map your past systems work to the new problem:
| You've done this | It maps to |
|---|---|
| Built a high-QPS HTTP gateway | Inference gateway in front of vLLM |
| Designed retry/circuit-breaker logic | Failure handling for flaky LLM endpoints |
| Streamed events over WebSocket / gRPC streaming | SSE streaming token responses |
| Owned a workflow engine | Agent plan executor |
| Built a job queue / worker pool | Tool-dispatch sandbox |
Profile B — strong ML infra in Python, light on production Rust
You've operated vLLM, built eval harnesses, run model deployments. Your Rust is real but not deep. Your task: convince them the Rust-specific knowledge is closeable on your existing systems base.
The story to lead with
"My background is ML infrastructure — [the model serving stack, the eval pipeline, the orchestrator]. I've shipped [agent system / inference gateway / eval framework] in Python. I'm coming to Rust because the production demands of the next stage — sub-50ms p99, hundreds of thousands of concurrent agent runs — are where Python is the bottleneck, and I want to be the engineer who closes that. I've spent [N weeks] building in Rust — [name your projects: a tonic gRPC service, an async LRU cache, a tower middleware stack]. The places I'd ramp on are idiomatic large-codebase Rust patterns and the specifics of your service framework conventions."
What to drill before the loop
- Ownership, borrowing, lifetimes. Be able to explain why
&mutaliasing is forbidden in 30 seconds. - Tokio basics: runtime, tasks, channels,
select!, cancellation. - Build something nontrivial: a small tonic streaming server, an async rate limiter, a worker pool with backpressure.
Result,?,thiserror,anyhow. Error handling idioms.- The big footguns:
Mutexacross.await, blocking calls in async,unwrap()in service code.
Bridging from your strengths
| You've done this | It maps to |
|---|---|
| Operated vLLM in production | Concrete view of what the Rust gateway must wrap |
| Designed eval datasets | You bring the "what does good look like" intuition |
| Built Python orchestrators | You know the patterns; just porting idioms |
| Owned MLOps observability | Direct transfer to OpenTelemetry/tracing in Rust |
| Handled GPU memory issues | Real production-incident scar tissue, which is rare |
Your opening 90 seconds
Every loop opens with "tell me about yourself." Treat it as a scripted, time-bounded performance you can do cold at 9am or 7pm.
- Anchor — your last role / focus, in one sentence.
- Strength — one specific, concrete thing you ship. (Don't list five.)
- Bridge — why you're interviewing here, in the language of this team.
- Honesty marker — name the gap you'd ramp on. (Don't pretend you have it all.)
- Hook — invite the next question. ("Happy to go deeper anywhere.")
90 seconds. Practice out loud. Time yourself.
Bridging language
Sentences worth memorizing. Pick the ones that fit your situation.
- "My closest production reference point for that is X. The shape's similar — let me reason about how Y would change."
- "I haven't operated [vLLM / a multi-region inference fleet / etc.] myself. I've read [doc / blog / paper] and built [small thing]. Want me to reason about it, or would you rather tell me how you do it and I'll respond?"
- "That's the kind of decision I'd want the Agent Systems team's input on. On my side I'd be thinking about [the infra concern]."
- "My instinct here is [X]. The reason I'd want to test it before betting on it is [Y]."
- "If you'd asked me three weeks ago I'd have said [naive answer]. Reading [thing] / building [thing] changed my mind because [reason]."
Don't bluff — replacement moves
Engineers can tell. Replace bluffing with one of these:
| The bluff | The replacement |
|---|---|
| "Oh yeah, I've used tonic a lot." | "I've built a couple of tonic services as side projects — not at the scale you're running. Closest production thing is [X]." |
| "We had p99 SLOs and stuff." | "At [scale] our gateway's p99 was [N]ms; the dominant cost was [thing], which we fixed by [X]." |
| "I know vLLM well." | "I've read the continuous-batching paper and run vLLM locally for evals; I haven't operated it under production load." |
| "I'd just use [thing] for that." | "My first instinct is [thing]. The risks I'd want to test are [list]. What's the constraint that would make you go a different direction?" |
Every fake confident answer costs trust. Every honest "I haven't done that, here's how I'd reason about it" buys trust. The honest interview goes better, not worse.
What to do in the week before
- Build one thing. Pick a project from 06-applied-patterns or 11-coding-problems and ship it. 2-4 hours. The conversation gets categorically better when you can cite "I built one of these last week."
- Pick 3 named projects from your past and rehearse a 60-second summary of each — problem, your role, scale, key technical decision, outcome.
- Drill chapter 15 out loud, on a 90-second timer per question. Record yourself. Cringe. Re-record.
- Read the one Anthropic / OpenAI engineering blog post on agent infrastructure you haven't read. Mention it in the loop ("I was just reading [X], which framed it as...").
- Sleep. Two nights of real sleep beats two nights of cramming, every time.
Closing the loop honestly
At the end of each round, you'll get "any questions for me?" Two moves that work for the underqualified-but-prepared candidate:
- Ask one technical question from 01-the-role. Shows you've thought about the actual problem space.
- Ask one cultural question — "What does your on-call rotation look like for the gateway?" or "When something breaks at 2am, who owns it, and what does the post-mortem look like?" This is the question of an engineer who plans to take this seriously.
End by naming what excited you. Specific, not generic: "The framing of AI infra as a partner to Agent Systems is exactly the boundary I want to work — I'd be very interested in continuing."