Rust engineer behavioural interview questions

As asked

Describe a situation where the Rust borrow checker rejected a design you initially thought was correct. What was the underlying issue, and what did you do to resolve it?

Sample answer outline

Strong answer describes a concrete scenario such as holding a reference into a collection while also mutating the collection, or a self-referential struct. Candidate explains why the borrow checker was right to reject it (the reference could dangle on mutation), and covers the resolution: splitting the borrow, using indices instead of references, or reaching for RefCell/Rc. Shows understanding that the compiler found a real bug rather than being pedantic.

Expect these follow-ups

• Did the redesign change the API or just the internals?
• Did you ever find that the compiler was wrong and you had to use unsafe?

As asked

Tell me about a time you wrote unsafe Rust in production. What made it necessary, how did you reason about soundness, and what did you do to make sure it would not break?

Sample answer outline

Strong candidate describes a concrete need (FFI, SIMD, self-referential structure) and shows a systematic approach: auditing the invariants the unsafe block must uphold, writing a SAFETY comment documenting them, adding #[deny(unsafe_op_in_unsafe_fn)], and writing tests including fuzz tests with cargo-fuzz or proptest to try to violate the invariants. Shows professional skepticism toward unsafe.

Expect these follow-ups

• Did you ever discover a soundness bug after the fact? How did you find it?
• How do you communicate unsafe invariants to future maintainers?

As asked

Describe a situation where a Rust service or library you worked on regressed in performance. How did you detect it, what did the investigation look like, and what was the root cause?

Sample answer outline

Strong answer names the detection method (criterion regression, flamegraph diff, latency SLO breach in production), describes the investigation (profiling, bisect), and identifies a concrete root cause such as unexpected allocation in a hot path, lock contention, or a regex compiled per request. Shows that the fix was validated with a benchmark and that the benchmark was added to CI to prevent recurrence.

Expect these follow-ups

• How did you make sure the fix did not break any existing functionality?
• What did you add to prevent this class of regression in the future?

As asked

Tell me about a time you encountered a deadlock or livelock in an async Rust application. What symptoms did you observe, what tools did you use, and how did you resolve it?

Sample answer outline

Should describe observable symptoms (all tasks stuck, CPU idle, no progress), and the investigation: tokio-console for live task inspection, checking for sync Mutex held across await, or a channel send/recv cycle. Resolution covers removing the Mutex from across an await point, switching to tokio::sync::Mutex for async-aware locking, or restructuring the channel graph. Shows methodical approach rather than luck.

Expect these follow-ups

• What is tokio-console and what does it show you that logs do not?
• How does holding a sync MutexGuard across an await cause a deadlock?

As asked

Tell me about a code review where you caught a safety or correctness issue specific to Rust's ownership model, unsafe code, or concurrency. What was the issue and how did you explain it to the author?

Sample answer outline

Candidate describes a specific finding such as a missing invariant comment on unsafe code, a race condition from weak memory ordering in AtomicUsize, or a drop order dependency that was fragile. Shows ability to explain the issue clearly to the PR author with a concrete scenario of how it could fail, and a constructive suggestion for the fix. Demonstrates safety culture not just rule-following.

Expect these follow-ups

• How do you balance thoroughness in safety reviews with shipping velocity?
• What tools do you require in CI to catch these issues automatically?

As asked

Tell me about a time you helped a teammate who was struggling with Rust's borrow checker or ownership model. What specific guidance did you give and how did the situation resolve?

Sample answer outline

Candidate describes a specific example such as pairing on a borrow checker fight, explaining ownership with a whiteboard diagram, or writing annotated examples. Shows empathy for the non-linear learning curve of Rust, practical advice given (clone first to make it work, then optimize ownership), and long-term outcomes. Bonus for mentioning resources like The Rust Book, Rustlings, or Jon Gjengset's videos.

Expect these follow-ups

• What is the single biggest mental shift you recommend for developers coming from GC languages?
• How do you explain lifetimes to someone without a C++ background?

As asked

Describe a meaningful open-source Rust contribution: a crate you published, a PR to a well-known Rust library, or a bug report with a reproducer. What Rust-specific design decisions did you make or review?

Sample answer outline

Candidate describes a concrete contribution or crate: the problem it solved, the design decisions made, and something they learned from community feedback such as API ergonomics, semver discipline, or documentation standards. Even a small crate or PR to a major project demonstrates real-world engagement. Red flag if the candidate has never published anything or engaged with the community at all.

Expect these follow-ups

• How do you handle breaking changes and semver in a published crate?
• What docs.rs features do you use to make your crate easy to discover?

As asked

Tell me about a production incident caused by a bug in Rust code you wrote or maintained. What was the impact, what was the root cause, and how did you prevent recurrence?

Sample answer outline

Candidate describes a specific incident: integer overflow in release mode that changed behavior silently, a panic from an unwrap on a path assumed to always be Some, or a race condition in a concurrent data structure. Explains the detection path (alert, log, customer report), the root cause analysis, the hotfix, and the longer-term fix (using checked_add, replacing unwrap with expect or proper error handling, adding a regression test).

Expect these follow-ups

• What monitoring did you add after the incident?
• How did you communicate the incident to stakeholders?

As asked

Describe a Rust library or module API you designed, shipped, and then had to change because it turned out to be wrong. What did you learn about designing with Rust's type system?

Sample answer outline

Strong answer describes a concrete API mistake such as: exposing Clone where the type should not be Clone, returning a concrete type instead of impl Trait making the API hard to change, or using Arc internally but forcing Arc on callers. Candidate explains how the mistake was discovered in use, what the migration cost was, and the principle extracted from it for future API design.

Expect these follow-ups

• How do you use the type system to make illegal states unrepresentable?
• What does the typestate pattern look like in Rust?

As asked

If you have migrated a module or service from C or C++ to Rust, walk me through the process. What was hardest to translate and how did you handle the incremental migration?

Sample answer outline

Candidate describes the incremental strategy: expose a C ABI from new Rust code, call it from the existing codebase, and expand the Rust boundary gradually. Hardest parts often include pointer arithmetic, unions, and callback-heavy APIs with lifetime constraints. Candidate should mention using the Miri interpreter to catch UB in the unsafe boundary code and fuzzing both old and new implementations in parallel during migration.

Expect these follow-ups

• How did you verify behavioral equivalence between the old and new code?
• What did the performance profile look like after migration?

As asked

Describe a situation where you or your team considered rewriting an existing service in Rust, and where there was disagreement about whether to do it. How did you approach the decision and what happened?

Sample answer outline

Strong candidate shows they evaluate rewrites on concrete criteria: performance data proving the existing language is the bottleneck, risk of introducing new bugs, migration cost, team ramp-up time, and maintenance burden. Should demonstrate they pushed back on a rewrite-for-its-own-sake argument and proposed a measured alternative such as partial migration or first optimizing the existing code. Shows technical maturity over Rust enthusiasm.

Expect these follow-ups

• What would need to be true for you to recommend a full rewrite?
• How do you estimate the engineering cost of rewriting a service?