Rust interview questions on ownership, borrowing, and concurrency

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.

#[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.

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.

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. 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.

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.

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.

Arc<i32> is Send + Sync because its count is atomic, so it can move to another thread. Plain i32 is Send (and Sync), so it crosses freely. 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. Rc<i32> is explicitly not Send: its non-atomic count would race, so it cannot be sent to another thread, so sending it 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, so sharing it 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.

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. The claim that v must be declared with let not let mut 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.