Rust Interview Questions

String owns a heap allocation and does not implement Copy, so let b = a is a move: ownership transfers to b and a is invalidated at compile time. Using a afterward is a use-after-move, and the borrow checker rejects it before the program ever runs — there is no runtime garbage or panic, just a compile error (borrow of moved value: a). Contrast a Copy type like i32, where let b = a duplicates the bits and both stay usable. To keep both String handles valid you must a.clone() (a deep copy) or borrow with &a. This compile-time move tracking is what lets Rust free each allocation exactly once without a garbage collector.

On Err(e), ? returns from the enclosing function immediately with that error, after converting it via the From trait into the function's declared error type — here both sides are io::Error, so no conversion is needed. On Ok(v) it unwraps to v and execution continues. ? is not unwrap: it never panics (that's option b's mistake); it propagates. The From conversion is the key feature — it lets you write ? across many underlying error types as long as your function's error type implements From for each, which is why Box<dyn Error> or a custom error enum with #[from] derives are common return types. ? only works in functions that return Result, Option, or another Try type.

Rc<T> updates its strong/weak counts with plain non-atomic integer operations, so concurrent clones/drops from multiple threads would race and corrupt the count — Rust prevents this statically by making Rc neither Send nor Sync, so the compiler rejects moving or sharing it across threads. Arc<T> (Atomically Reference Counted) uses atomic operations for the counts and is Send + Sync when T: Send + Sync, so it compiles in threaded code. The tradeoff is that atomics cost more than plain increments, which is exactly why Rc still exists — use it for single-threaded sharing and pay nothing for synchronization you don't need. Note Arc only makes the count thread-safe; mutating the inner T still needs a Mutex/RwLock.

A generic fn draw<T: Shape> is monomorphized: the compiler stamps out a separate, concrete copy of draw for each T it's called with, and each call dispatches statically — the exact method is known at compile time, so it can be inlined, with zero runtime indirection. &dyn Shape is a trait object: a fat pointer (data pointer + vtable pointer) where the method is looked up through the vtable at runtime (dynamic dispatch). Static dispatch is typically faster per-call and inlinable but can bloat binary size with many monomorphized copies; dynamic dispatch keeps one copy and lets you store heterogeneous types (e.g. Vec<Box<dyn Shape>>) at the cost of an indirect call and lost inlining. Choosing between them is a classic Rust performance-vs-flexibility tradeoff.

Arc<i32> is Send + Sync because its count is atomic, so it can move to another thread (a). Plain i32 is Send (and Sync), so it crosses freely (e). Mutex<Vec<u8>> is Sync when its contents are Send, so &Mutex<...> can be shared across threads — that's the whole point of a mutex (c). Rc<i32> is explicitly not Send: its non-atomic count would race, so it cannot be sent to another thread (b is wrong). RefCell<i32> is Send but not Sync: its runtime borrow flags aren't atomic, so a shared &RefCell across threads could double-mutably-borrow undetected — Rust forbids it (d is wrong). These two marker traits are auto-derived structurally, and the borrow checker uses them to make data races a compile error rather than a runtime bug.

True. Adapters such as map, filter, take, and enumerate are lazy — each just returns a new iterator struct that wraps the previous one; no element is touched until a consumer pulls values through. Consumers include for loops and methods like collect, sum, count, fold, and for_each. A direct consequence: a chain of adapters with no consumer is a no-op (the compiler even warns iterators are lazy and do nothing unless consumed). Laziness is also what makes adapter chains a 'zero-cost abstraction' — the compiler fuses the whole chain into a single tight loop with no intermediate collections, so iter().map().filter().sum() allocates nothing in between and is as fast as a hand-written loop.

This is shadowing, not mutation. Each let x = ... introduces a brand-new immutable binding that happens to reuse the name x, hiding the previous one — no mut is needed and there is no compile error (option d). In main's scope, x becomes 5, then 6. The inner block shadows again with x * 2 = 12 and prints 12; that inner binding is scoped to the block, so when it ends the outer x (still 6) is visible again and the second println! prints 6. Output: 12 then 6. Shadowing differs from mut reassignment in two ways that matter: it can change the variable's type (let s = s.len();), and the original value isn't altered — useful for staged transformations of an input.

RefCell<T> moves Rust's borrowing rules from compile time to runtime: it tracks an internal borrow flag and lets you take &/&mut through borrow()/borrow_mut(). Here the immutable borrow a is still alive (it's used later by println!) when borrow_mut() is called, so the dynamic check sees an outstanding shared borrow and panics with already borrowed: BorrowMutError rather than allowing aliasing. This compiles (so option b is wrong — the static borrow checker can't see the conflict, that's the whole reason RefCell exists), but blows up at runtime. The lesson: RefCell buys interior mutability at the price of converting borrow violations from compile errors into panics, so you must keep borrow scopes short (often by ending one in its own { } block) to avoid overlap.

Vec::with_capacity(10) allocates room for 10 elements up front but creates an empty vector, so len() is 0 initially and only counts elements actually pushed — here 2. capacity() reports the allocated slots, which stays 10 because two pushes fit comfortably within the reserved space; no reallocation happens. So it prints 2 10. The distinction is real-world important: len is how many elements exist, capacity is how many fit before the next growth. Reserving capacity with with_capacity (or reserve) when you know the size avoids repeated reallocate-and-copy cycles as a Vec grows (Rust's growth strategy typically doubles capacity), which is a common, cheap performance win in hot loops.

let first = &v[0] takes a shared (immutable) borrow of v, and that borrow is still live because first is used in the final println!. v.push(4) requires a mutable borrow of v, but Rust's aliasing rule forbids a &mut while any & is outstanding. This isn't pedantry: push may reallocate the Vec's backing buffer when capacity is exceeded, which would leave first pointing at freed memory — a classic iterator-invalidation / dangling-pointer bug that the borrow checker turns into a compile error instead. Option b is backwards (mut is required for push); the real fix is to use first before mutating, or copy the value out (let first = v[0];, since i32 is Copy) so no borrow outlives the mutation.

unwrap/expect panic on the error case, so they're fine in tests, prototypes, and spots where the success case is a guaranteed invariant — and expect is the better of the two because its message documents why the call can't fail. Production code that must stay up should instead propagate the error with ?, branch on it with match/if let, or fall back with combinators like unwrap_or_else. A strong answer ties this to Rust's split between recoverable errors (returned as Result) and unrecoverable bugs (panics). The real-world cost of careless unwrap is a service that crashes on the first malformed input.

Lifetime annotations are purely a compile-time device: they express relationships between reference lifetimes so the borrow checker can guarantee a returned reference never outlives its source, with zero runtime cost. Functions usually omit them thanks to elision — default rules that infer the obvious cases. longest needs an explicit 'a because its output could borrow from either argument, so the compiler can't elide which input it ties to; 'a says the result is valid only as long as both inputs are. A good answer names dangling-reference prevention and elision; this is a hallmark senior-level Rust topic because the syntax intimidates but the underlying idea (don't return a borrow that can dangle) is simple.

Box<T> is owned, single-owner heap allocation with automatic cleanup on drop. The interview-critical use cases are: enabling recursive types (which would otherwise have infinite size), cheaply moving large values by pointer, and holding unsized trait objects for dynamic dispatch. A common follow-up is contrasting it with Rc/Arc (shared ownership) — Box is the one-owner case with no reference counting. Knowing the recursive-type use (Box<List>) is the detail that separates a memorized answer from real understanding.

At the end of a scope, Rust drops local variables in reverse order of declaration — last-in, first-out — so c drops first, then b, then a. This LIFO order exists because a later value may borrow from or depend on an earlier one, so unwinding in reverse keeps those dependencies valid while each Drop runs. (Fields within a single struct, by contrast, drop in declaration order, top to bottom.) Knowing the order matters for RAII guards: if a MutexGuard and a value that uses it are in the same scope, their declaration order decides which lock is released first, and getting it wrong can deadlock or release a resource too early.

#[derive(...)] is the attribute that asks the compiler to auto-implement common traits structurally — Clone, Debug, PartialEq, Hash, Default, and others — saving you the boilerplate of writing each impl by hand. Deriving Debug lets you print a value with the {:?} specifier (or {:#?} for pretty, multi-line output) in println!/format!, which is the standard way to dump a struct for debugging. Note {} (Display) is not auto-derivable — you must implement Display yourself, because the human-facing representation is a deliberate design choice, whereas Debug's programmer-facing one can be generated mechanically.