Common Rust Interview Questions

Rust interviews rarely test syntax trivia; they test whether you understand the memory model that makes Rust different from every language you've used before. Interviewers probe ownership, borrowing, and lifetimes because these concepts are unique to Rust and cannot be answered by pattern-matching against C++ or Java knowledge. This set of questions covers the topics that come up again and again in technical screens: ownership and moves, the borrow checker's rules, the smart pointer family (Box, Rc, Arc, RefCell), stack versus heap allocation, the Copy trait, Result versus Option, the ? operator, why Rust is memory-safe without a garbage collector, static versus dynamic dispatch, zero-cost abstractions, and the String/&str split. Knowing the mechanics is necessary but not sufficient — you should also be able to explain *why* Rust made each design choice, since that reasoning is exactly what separates a memorized answer from a confident one.

Ownership is Rust's system for managing memory without a garbage collector. Every value has exactly one owner (a variable); when that owner goes out of scope, the value is dropped and its memory freed automatically. The three rules are: (1) each value has one owner, (2) there can only be one owner at a time, and (3) when the owner goes out of scope, the value is dropped. These rules are enforced entirely at compile time, so there is zero runtime cost for tracking ownership.

When a heap-allocated value like a String or Vec<T> is assigned to a new variable or passed to a function, Rust transfers (moves) ownership rather than deep-copying the data. The original variable becomes invalid, and the compiler rejects any later use of it. This prevents double-free bugs: if both variables owned the same heap memory, dropping both would try to free it twice. Moving instead of copying by default also keeps assignment cheap — it's just a pointer/length/capacity copy, not a full data copy.

At any given time, you can have either exactly one mutable reference (&mut T) or any number of immutable references (&T) to a value, but never both simultaneously. References must also always be valid — Rust will not let a reference outlive the data it points to. This 'one mutable XOR many immutable' rule is what prevents data races and iterator invalidation at compile time: if no one else can read a value while you're writing to it, there's no way for two parts of the program to see inconsistent state.

Box<T> is a simple heap allocation with a single owner — use it when you need a value on the heap (e.g., recursive types, trait objects) but ownership semantics stay the same as any other value. Rc<T> (reference counted) allows multiple owners of the same heap data in a single-threaded context, tracking a count of live references and freeing the data when the count hits zero. Arc<T> is the atomic, thread-safe equivalent of Rc<T> for sharing data across threads. RefCell<T> provides 'interior mutability' — it lets you mutate data even through an immutable reference by moving the borrow-checking from compile time to runtime, panicking if the one-mutable-XOR-many-immutable rule is violated at runtime. They're often combined, e.g. Rc<RefCell<T>> for shared, mutable, single-threaded data or Arc<Mutex<T>> for the multi-threaded equivalent.

The stack stores values of a known, fixed size in last-in-first-out order and is extremely fast to allocate and deallocate — pushing and popping is just moving a pointer. The heap stores data of unknown or dynamic size (like a String or Vec<T> that can grow); allocating there requires the allocator to find free space and return a pointer, which is slower. Rust's type system tracks exactly which values live where and encodes ownership rules around it, so heap allocations always have a clear single owner responsible for freeing them, and stack values are simply copied or moved without any allocator involvement.

Types that implement Copy (simple stack-only types like integers, floats, bool, and char, plus tuples/arrays of Copy types) are duplicated bit-for-bit on assignment instead of being moved. Because copying is cheap and there's no heap resource to double-free, the original variable remains valid after the 'copy'. A type can implement Copy only if all of its fields are also Copy and it doesn't implement Drop, since Drop implies the type manages a resource that must not be silently duplicated.

Option<T> represents a value that may or may not be present — its variants are Some(T) and None — and is used when absence isn't necessarily an error (e.g., looking up a key that might not exist). Result<T, E> represents an operation that can succeed or fail, with variants Ok(T) and Err(E), and is used when you need to communicate *why* something failed. Both replace null and unchecked exceptions with values the compiler forces you to handle explicitly via pattern matching, .unwrap(), or combinators like .map() and .and_then().

The ? operator, used on a Result or Option inside a function that returns a compatible Result/Option, unwraps the Ok/Some value and lets execution continue, or immediately returns the Err/None from the enclosing function. It's syntactic sugar for the common 'propagate the error up' pattern, converting error types along the way via the From trait so you don't need to write manual match statements at every fallible call site.

Rust enforces memory safety at compile time through ownership, borrowing, and lifetimes instead of checking it at runtime. The compiler proves that every reference is valid for as long as it's used, that mutable and immutable access never overlap, and that every heap allocation has exactly one owner responsible for freeing it. Because these checks happen during compilation, there is no runtime cost, no GC pauses, and no non-deterministic collection cycles — the tradeoff is that some valid-but-hard-to-prove-safe programs are rejected, and you sometimes need escape hatches like RefCell, Rc, or unsafe for patterns the checker can't reason about statically.

Generics use static dispatch: the compiler monomorphizes the generic function, generating a specialized copy for each concrete type used, so the call is resolved and can be inlined at compile time with no runtime overhead — at the cost of larger binary size. Trait objects (dyn Trait, typically behind &dyn Trait or Box<dyn Trait>) use dynamic dispatch: the concrete type is erased and method calls go through a vtable lookup at runtime, which allows heterogeneous collections of different types behind one interface but adds a small runtime indirection cost and disallows inlining.

It means high-level constructs — iterators, generics, closures, async/await — compile down to code that is as efficient as the equivalent hand-written low-level code, with no additional runtime overhead for using the abstraction. For example, a chain of .iter().map().filter().sum() typically compiles to a tight loop comparable to a manual for-loop, because the compiler can fully inline and optimize the generic, statically-dispatched calls. You only pay for what you use, and what you do use costs no more than writing it by hand.

String is an owned, growable, heap-allocated UTF-8 string type — it owns its buffer and can be mutated or resized. &str (a string slice) is a borrowed, immutable view into UTF-8 text, which could point into a String, a string literal (stored in the binary), or any other UTF-8 buffer. Function parameters are usually written as &str for flexibility (a String can be borrowed as &str via deref coercion), while String is used when you need to own or build up text over time.