Question 1

Walk me through what happens to a value's ownership when you pass it to a function, and how that differs from languages with garbage collectors. Where exactly does the compiler insert the drop?

Accepted Answer

Strong answer covers the single-owner rule, that passing by value moves ownership into the callee's stack frame, and that the compiler inserts a drop at the end of the owning scope. Candidate should contrast this with GC languages where the runtime tracks reachability at runtime and reclaim asynchronously, noting Rust guarantees zero-cost deterministic cleanup.

Question 2

Describe the aliasing rules the Rust borrow checker enforces. What exactly makes the rule 'either one mutable reference or any number of shared references' safe, and how does the compiler verify it at compile time?

Accepted Answer

Strong answer references the XOR mutable aliasing rule and explains that it eliminates data races at compile time. Candidate should explain the borrow checker tracks borrows as non-overlapping regions, cite iterator invalidation as the classic mutable-alias hazard in C++, and note that the rule enables safe concurrent access patterns like multiple readers.

Question 3

The compiler can often elide lifetimes. When does it fail to do so and require you to write explicit annotations? Give me a concrete function signature where elision would be ambiguous.

Accepted Answer

Candidate should state the three elision rules and explain that elision fails when there are multiple input lifetime parameters and the output lifetime cannot be tied to a single input, or when the compiler cannot determine whether the output should live as long as self or another parameter. A good concrete example is fn longest<'a>(x: &'a str, y: &'a str) -> &'a str showing why the return lifetime is ambiguous without annotation.

Question 4

You have a function that accepts something implementing Display. When would you use dyn Display and when would you use impl Display or a generic T: Display? What are the concrete runtime and binary-size tradeoffs?

Accepted Answer

Candidate should explain that generics are monomorphized at compile time giving zero virtual-dispatch overhead but potentially bloating binary size, while dyn Trait uses a vtable pointer for dynamic dispatch with one extra pointer indirection per call. Key decision factors are whether you need heterogeneous collections (requires dyn), whether the type is known at compile time (use generics), and whether you care about binary size in embedded contexts.

Question 5

List the specific operations that require an unsafe block in Rust. What does the language guarantee you keep even inside unsafe, and what guarantees does it drop?

Accepted Answer

Five unsafe superpowers: dereference raw pointers, call unsafe functions, access mutable statics, implement unsafe traits, access union fields. Crucially, Rust's type system, ownership, and borrowing still apply inside unsafe for safe code you write there. The language drops only the guarantees that require runtime checks to uphold. Candidate should note that undefined behavior in unsafe can compromise the entire program, not just the unsafe block.

Question 6

Explain how the ? operator works under the hood. What trait conversions does it call, and how does that enable you to use ? with multiple error types in one function?

Accepted Answer

? desugars to a match that on Err calls From::from on the error to convert to the function's declared error type, then returns early. This means if you implement From and From for your custom MyError, you can ? both in the same function. Candidate should mention anyhow for ad-hoc error aggregation in application code versus thiserror for library errors with defined types.

Question 7

You find an unsafe block around a C library call in a production Rust service. What invariants do you check before approving the change?

Accepted Answer

The answer should make the safety contract explicit: pointer validity, alignment, ownership, aliasing, lifetime, thread-safety, error handling and cleanup responsibilities. Unsafe should be isolated behind a small safe abstraction whose public API prevents callers from violating those invariants. FFI return codes and null pointers need to become Rust Result or Option values immediately. The candidate should mention tests that exercise boundary cases and tooling such as Miri, sanitizers or fuzzing where practical. A weak answer treats unsafe as a local syntax escape hatch rather than a module-level proof obligation.

Question 8

If I have a struct that holds a reference to a string slice, what lifetime annotation do I put on the struct and why? What does the compiler actually check at each use site?

Accepted Answer

Candidate should write struct Foo<'a> { s: &'a str } and explain the lifetime parameter binds the struct's valid region to the referent's region. The compiler checks that any Foo instance cannot outlive the data it points to, preventing dangling references. Should also note that this affects what you can do with Foo when you store it in other structs.

Question 9

What is stored in a fat pointer when you create a &dyn Trait or a Box<dyn Trait>? Draw out the memory layout if you had to implement vtable dispatch by hand in C.

Accepted Answer

Candidate should describe a fat pointer as two words: a data pointer to the concrete value and a vtable pointer. The vtable contains the concrete type's size, alignment, a drop glue pointer, and then function pointers for each trait method in declaration order. Should note that Rust vtables are per trait-impl pair, not per type like C++ vtables, and do not support multiple virtual base pointers. Coercion from &T to &dyn Trait causes the compiler to generate the vtable as a static constant. Candidate should also note that trait_upcasting (stabilised in Rust 1.76) now allows coercing &dyn SubTrait to &dyn SuperTrait when the vtable includes supertrait slots.

Question 10

When you write async fn fetch_data(), what does the Rust compiler actually produce? Describe the generated type and how await suspension points map to enum variants.

Accepted Answer

Candidate should explain that the compiler generates a state-machine enum implementing Future, where each await point becomes a variant capturing only the locals live across that yield point. The poll method is a match on the current state, calling inner futures and transitioning states. Key insight is that the state machine is stack-allocated by default (when not boxed), which is why async tasks are more efficient than OS threads for I/O-bound work. Should note that the generated future must be pinned before it can be polled, which is why spawning or joining a future requires Pin.

Question 11

Explain why the poll method on Future takes Pin<&mut Self> instead of &mut Self. What invariant would break if you could move a Future after pinning it?

Accepted Answer

Candidate should explain that async state machines contain self-referential pointers: a field may hold a pointer to another field in the same struct to avoid re-reading a local across an await. If the struct were moved after those pointers were established, they would dangle. Pin guarantees the value's memory address will not change once pinned. Unpin is an auto-trait for types where this guarantee is unnecessary.

Question 12

Describe how Tokio's multi-threaded runtime picks up tasks and runs them. What is work-stealing and why does Tokio use it? What happens when every thread is blocked in a poll call?

Accepted Answer

Candidate should describe the thread pool where each thread has a local run queue plus access to a global queue and can steal from sibling queues. When a thread exhausts its local queue it steals half the tasks from a random sibling, reducing idle time. Should note that blocking inside poll starves other tasks on that thread and explain spawn_blocking as the escape valve to hand CPU-bound or blocking I/O work to a dedicated blocking thread pool.

Question 13

You use tokio::select! with two futures and one of them completes first. What happens to the other future? What does 'cancellation safe' mean for a future, and how does the Tokio documentation define it?

Accepted Answer

Candidate should explain that the losing branch's future is simply dropped, freeing all its captured state. A future is cancellation-safe if dropping it at any await point does not lose work or leave external state corrupt. Classic unsafe example is a multi-step write or a future that holds a lock across an await. Candidate should mention tokio::io::AsyncReadExt::read_exact as a known non-cancellation-safe operation.

Question 14

By default, what does Rust do with struct field ordering and padding? How does #[repr(C)] change that, and when would you need it in practice?

Accepted Answer

Rust's default repr may reorder fields to minimize size and is not stable across compiler versions. #[repr(C)] fixes field order to declaration order with C-compatible alignment and padding, making layout predictable. Needed when doing FFI with C libraries, writing to binary file formats, or using mem::transmute across type boundaries. Candidate should mention #[repr(packed)] and its alignment hazards.

Question 15

Describe each of tokio's four channel types: mpsc, oneshot, broadcast, and watch. Give me a concrete scenario where you would pick each one.

Accepted Answer

mpsc for fan-in work queues where many producers send to one consumer. oneshot for a single response from a spawned task back to its spawner, like a request-response pair. broadcast for fan-out where every subscriber needs every message, such as config change notifications. watch for the latest-value-wins pattern where readers only care about the current state, like a health check or config snapshot. Candidate should note broadcast has backpressure only through lagging semantics.

Question 16

You have two threads each holding an Arc> and an Arc>. Thread 1 locks A then tries to lock B; Thread 2 locks B then tries to lock A. Walk me through what happens and how you fix it.

Accepted Answer

Classic deadlock via lock-order inversion. Fix options include: enforce a global lock-ordering convention so all threads acquire locks in the same order; combine A and B into a single Mutex<(A, B)>; or use a try_lock with backoff. Should also mention parking_lot::Mutex for better performance than std::sync::Mutex and its lack of poisoning semantics.

Question 17

How should error type design differ between a library crate and an application binary? What problems arise if a library exposes anyhow::Error at its API boundary?

Accepted Answer

Libraries should expose structured error types (typically via thiserror) so callers can match on specific variants programmatically. Exposing anyhow::Error erases type information and forces callers to parse error messages, making downstream error handling fragile and coupling to implementation details. Applications can use anyhow freely since they are the terminal consumer. Should mention the std::error::Error trait as the cross-crate compatibility layer.

Question 18

Your Rust service is using more CPU than expected in production. Walk me through the tools and process you would use to identify the hotspot, from flamegraph generation to reading the output.

Accepted Answer

Candidate should mention cargo-flamegraph or perf on Linux with DWARF debug symbols, setting debuginfo = 1 in release profile to keep symbol names without disabling optimizations. Reading a flamegraph: wide bars are expensive, tall stacks show call depth. Should also mention criterion for micro-benchmarks to isolate a hypothesis and DHAT or valgrind's massif for allocation profiling.

Question 19

Rust iterators are described as zero-cost abstractions. What does that mean concretely? Show me why calling .filter().map().collect() on a Vec can produce the same assembly as a hand-written loop.

Accepted Answer

Each iterator adapter is a struct with state, and the entire chain is resolved at compile time through monomorphization and inlining. The compiler sees through the layer of closures and structs to produce a single loop with no heap allocation. Candidate should contrast this with Java streams or Python generators which carry overhead from dynamic dispatch or interpretation. Should note that the Rust compiler relies on LLVM's optimization passes for final loop fusion.

Question 20

Explain where unit tests and integration tests live in a Rust project. What can an integration test access that a unit test cannot, and when would you choose each?

Accepted Answer

Unit tests live in the same file as the code under #[cfg(test)] modules and can access private items. Integration tests live under tests/ and only have access to the public API, making them better for verifying the crate as a black box. Should mention that integration tests for a library crate each compile as a separate binary. Should also cover doc-tests and the -p flag for running tests in a workspace.

Question 21

Describe how the tracing crate differs from the log crate. How do spans and events work together, and what do you gain by using tracing in an async Tokio service versus plain log macros?

Accepted Answer

tracing introduces spans which have a lifetime and can be entered/exited, making them async-aware: a span attached to a task follows the task across await points automatically. Events are point-in-time log messages that inherit context from the current span. In async code this means logs automatically carry request IDs or user IDs from an outer span, which plain log macros cannot do since they have no context threading.

Question 22

You have a mono-repo with a binary crate, a library crate, and a proc-macro crate. How do you structure this as a Cargo workspace and what problems does the workspace Cargo.toml solve for shared dependencies?

Accepted Answer

Workspace Cargo.toml lists all member crates; cargo builds the whole graph and caches shared compilation artifacts. The [workspace.dependencies] table lets you pin a dependency version once and reference it with workspace = true in member Cargo.tomls, preventing version drift. Should mention that proc-macro crates must be their own crate compiled for the host, and that cargo test/clippy can be run across all members in one command.

Question 23

Walk me through using sqlx to run a parameterized query against Postgres in an async Rust service. What does the compile-time query checking buy you and what does it cost?

Accepted Answer

sqlx::query_as! macro sends the query to a real database at compile time (via DATABASE_URL), verifies column names and types, and generates a typed row struct. This eliminates an entire class of runtime type mismatch errors. Cost is that you need a live database or offline snapshot (sqlx prepare) during CI. Candidate should cover connection pooling with PgPool, the acquire pattern, and transaction handling.

Question 24

You need to serialize a Rust enum where each variant must map to a specific string key that does not match the variant name, and the JSON must omit None fields. How do you configure serde to handle this without writing a full manual Serialize impl?

Accepted Answer

Use #[serde(rename = "key")] on each variant, #[serde(skip_serializing_if = "Option::is_none")] on fields, and #[serde(rename_all = "snake_case")] for global renaming. Candidate should also mention #[serde(tag = "type")] for internally tagged enums and when you would fall back to impl Serialize manually, such as for heterogeneous binary formats or when the field structure depends on runtime data.

Question 25

You are reviewing a Rust codebase with several unsafe blocks written by a former engineer. You suspect one of them may have undefined behavior but you are not certain. What do you do?

Accepted Answer

Candidate should describe a systematic approach: run Miri (cargo miri test) to catch UB the sanitizer can detect, add SAFETY comments explaining the assumed invariants, write tests that stress the code paths under Miri, and consider running cargo-fuzz or proptest to hit edge cases. Should also mention that if Miri cannot run the code (FFI) they would isolate the unsafe boundary and add assertions around the invariants.

Question 26

Your Rust project's CI clean build time grew from 3 minutes to 25 minutes over six months. The team is complaining. How do you diagnose the problem and what strategies do you use to bring it back down?

Accepted Answer

Diagnose with cargo build --timings to see which crates take longest. Common culprits: proc-macro crates that became heavyweight, a new dependency that brings in a large dependency tree, or loss of incremental caching. Strategies: use sccache with S3 for artifact caching, cargo-hakari to pre-build a unified feature set, split a large crate, replace heavy derive dependencies with lighter alternatives, tune codegen-units in debug mode.

Question 27

A Rust service has been in production for a week and its RSS has grown from 50 MB to 800 MB with no traffic increase. Rust is supposed to manage memory automatically. What are the possible causes and how do you investigate?

Accepted Answer

Rust prevents use-after-free but not logical leaks. Causes: unbounded Vecs or HashMaps growing without eviction, Rc<RefCell> cycles that the reference counter never reaches zero, Sender held alive preventing a channel from closing, a cache with no size limit. Investigation: use DHAT or heaptrack to profile allocations over time, look for monotonically growing allocation sites. For Rc cycles, switch to Weak references or restructure ownership.

Question 28

You maintain a crate with 500 downstream users on crates.io. You need to add a required method to a public trait. What are your options and how do you minimize breakage?

Accepted Answer

A new required method on a public trait is a semver-breaking change requiring a major version bump. Options to avoid the major bump: add a default implementation (non-breaking, but limits what the method can guarantee), use a sealed trait pattern to prevent external implementors (then a minor bump is safe), or introduce a new trait that extends the old one and provide a blanket impl. The #[non_exhaustive] attribute applies to structs and enums, not to traits directly. If a major bump is unavoidable, coordinate with major downstream users, provide a migration guide, and keep the previous major version in a maintenance branch for a transition window.

Question 29

You receive an alert that your Rust service crashed with 'index out of bounds: the len is 3 but the index is 3'. You have no stack trace in the logs. What do you do immediately and what do you change to prevent this?

Accepted Answer

Immediately: enable RUST_BACKTRACE=1 or RUST_LIB_BACKTRACE=full in production, ensure the release binary has debuginfo = 1 so the backtrace resolves to file/line. Investigate the message: an off-by-one on a slice access. Fix: use get() returning Option instead of direct indexing where the length is not guaranteed. Prevention: add bounds checks as assertions in tests, use cargo-fuzz to probe boundary conditions, configure panic = 'abort' or a panic hook that logs context before crashing.

Question 30

cargo audit reports a RUSTSEC advisory for a transitive dependency three levels deep in your dependency tree. The vulnerability is a potential integer overflow in a parsing function. What do you do?

Accepted Answer

First determine whether you actually call the vulnerable code path. Use cargo tree to find which of your direct dependencies pulls in the vulnerable crate. Check the advisory for the safe version range and try cargo update -p --precise . If the direct dependency has not released a fix, open an issue or fork. If the vulnerability is in an unused code path you can temporarily add the advisory ID to .cargo/audit.toml to suppress until the upstream fix lands, documenting why.

Questions

Explain Rust ownership and move semanticsRole-specificeasyVery common

As asked

Sample answer outline

Expect these follow-ups

How does the borrow checker enforce aliasing rules?Role-specificeasyVery common

As asked

Sample answer outline

Expect these follow-ups

When do you need explicit lifetime annotations on functions?Role-specificmediumVery common

As asked

Sample answer outline

Expect these follow-ups

dyn Trait vs impl Trait: when to pick eachRole-specificmediumVery common

As asked

Sample answer outline

Expect these follow-ups

What does unsafe actually allow you to do?Role-specificmediumVery common

As asked

Sample answer outline

Expect these follow-ups

Error handling: ? operator and From conversionsRole-specificeasyVery common

As asked

Sample answer outline

Expect these follow-ups

Review an unsafe Rust boundaryRole-specifichardCommon

As asked

Sample answer outline

Expect these follow-ups

Struct with a reference field: lifetime placementRole-specificmediumCommon

As asked

Sample answer outline

Expect these follow-ups

Describe a fat pointer's memory layoutRole-specifichardCommon

As asked

Sample answer outline

Expect these follow-ups

What does the compiler generate for an async fn?Role-specifichardCommon

As asked

Sample answer outline

Expect these follow-ups

Why does Poll require Pin and what does Pin guarantee?Role-specifichardCommon

As asked

Sample answer outline

Expect these follow-ups

How does Tokio's multi-threaded runtime schedule tasks?Role-specifichardCommon

As asked

Sample answer outline

Expect these follow-ups

Cancellation safety in tokio::select!Role-specifichardCommon

As asked

Sample answer outline

Expect these follow-ups

How does #[repr(C)] change struct layout?Role-specificmediumCommon

As asked

Sample answer outline

Expect these follow-ups

Tokio channels: mpsc, oneshot, broadcast, watchRole-specificmediumCommon

As asked

Sample answer outline

Expect these follow-ups

Arc<Mutex<T>> patterns and deadlock risksRole-specificmediumCommon

As asked

Sample answer outline

Expect these follow-ups

Error type design: libraries vs applicationsRole-specificmediumCommon

As asked

Sample answer outline

Expect these follow-ups

Profiling a Rust binary for CPU hotspotsRole-specificmediumCommon

As asked

Sample answer outline

Expect these follow-ups

What makes Rust iterators zero-cost?Role-specificmediumCommon

As asked

Sample answer outline

Expect these follow-ups

Unit tests vs integration tests in RustRole-specificeasyCommon

As asked

Sample answer outline