Cargo and on-call, not trivia

Rust interview questions that predict production fit

Stackologists runs Rust interview questions that predict whether someone has operated production systems — not whether they can recite ownership rules from a book.

Borrow-checker quizzes are cheap. Stackologists asks which crate other teams depended on, where unsafe lived, which async runtime carried traffic, and what the last pager taught them. That is the bar before a Rust hire goes forward.

Trivia lists that waste a cycle

• Ownership slogans treated as proof of production skill.
• No question about Tokio or the runtime that actually ran.
• Unsafe skipped as if it were academic.
• No FFI story and no outage the candidate lived through.

Someone can ace a flashcard list and still stall your first sprint. Vague production answers stop the Stackologists match.

Rust interview questions Stackologists asks

Cargo trail and ownership

• Which crate, service, CLI, or board did you ship last — and who else depended on it?
• What broke in production, and what landed in Cargo after?
• What would you refuse to rewrite into Rust without a named machine constraint?

Unsafe and invariants

• Where did unsafe live, and why was it required?
• Who reviewed those blocks, and what invariants did they protect?
• When would you refuse unsafe even if a microbenchmark looked prettier?

Tokio and backpressure

• Which async runtime carried production traffic, and why that one?
• How did you cancel work when a caller disappeared?
• What failed under backpressure, and how did metrics show it?

FFI into C or .NET

• Which host languages did you bind to, and what was the contract?
• What happened when the other side of the FFI misbehaved?
• How did you version that boundary across releases?

wasm32 and no_std

• If you claim Rust WASM, what was the payload cost and the host binding?
• If you claim embedded Rust, which board or RTOS did you ship against?
• What stayed out of scope on purpose — allocator, std, or both?

How Stackologists scores the call

1. 1. Pin the Cargo surface before the call

   Stackologists writes the service, CLI, library, or board you will ship against. Answers are scored against that surface — not against “Rust” as a logo.

2. 2. Probe the unsafe boundary

   What forced unsafe, who reviewed those blocks, and which invariant dies if the boundary moves.

3. 3. Name the async runtime under load

   Tokio or otherwise — how cancellation worked when callers vanished, and what p99 looked like under backpressure.

4. 4. Walk FFI and the last outage

   Which host languages they bound to, how the contract versioned, and what the last pager taught them.

5. 5. Decide seat, crate handoff, or no

   Strong answers plus a stand-up → hire. Strong answers plus a finish date → build. Textbook-only → stop. Stackologists uses that fork.

Disqualifiers that end the conversation

• “Rust” with no crate or system named.
• Only tutorials or Advent-of-Code, no production ownership.
• No answer for unsafe, Tokio, or an incident.
• wasm32 or no_std claimed from a sample project alone.

Stackologists will not force a Rust hire past those answers. An empty seat beats a bad placement.

After the scorecard

If the language choice is still open, read the Stackologists note on Rust vs Go. If the answers are strong and you need a person in stand-up, hire Rust developers on the stack leaf. If you need a finished piece on a date, buy a bounded build instead.

Hire Rust developersRust vs Go