Interview Questions

It does not change how long anything lives. It is a contract: the returned reference is valid for at most the shorter of the two input borrows. The compiler needs it because the body could return either argument, and without the annotation the caller could not tell which input the result borrows from. At the call site, the borrow checker then refuses any use of the result after either input has been dropped.

What they are really testing: The key insight that lifetimes describe relationships between borrows, they do not extend them.

Three rules that let you omit annotations in the common cases. (1) Each reference parameter gets its own lifetime. (2) If there is exactly one input lifetime, it is assigned to every output reference. (3) If one parameter is &self or &mut self, its lifetime is assigned to the outputs. If the rules leave an output lifetime undetermined — two reference parameters and no self — you get E0106 and must write it yourself.

What they are really testing: Whether they know why most code needs no annotations, and can predict when it will.

When it is a short-lived view over data someone else owns — a parser over an input &str, an iterator over a slice. It needs a lifetime parameter, struct Parser<'a> { input: &'a str }, and the struct can never outlive that data, which spreads the lifetime through every type that contains it. For long-lived data — anything stored in a cache, sent to another thread or returned from a service — own the data (String, Vec, Arc<str>) instead. Zero-copy parsing is the main place borrowed structs pay off.

What they are really testing: Judgement: knowing borrowed structs are a performance tool with an ergonomic price.

&'static str is a reference valid for the whole program — string literals, or leaked memory. T: 'static is weaker and more common: it says the type contains no non-static borrows, so a value of it may be kept for as long as its owner likes. Every owned type such as String or Vec<u8> satisfies it. That is why thread::spawn requires F: 'static: the thread can run arbitrarily long, so the closure may own data but not borrow from the caller’s stack.

What they are really testing: A classic confusion; the thread::spawn example shows they understand the practical meaning.

Generics use static dispatch: the compiler generates a copy of f per concrete type (monomorphisation), so calls can be inlined — fastest, at the cost of larger binaries and longer compiles. dyn Shape uses dynamic dispatch: one copy of f, calls through a vtable pointer stored beside the data pointer. Use dyn when you need different types in one collection (Vec<Box<dyn Shape>>), plugin-style extension, or to cut compile time; use generics in hot paths and when the concrete type is known.

What they are really testing: Understanding monomorphisation versus vtables, and being able to name a situation for each.

A trait object must be callable through a vtable without knowing the concrete type, so the trait has to be dyn compatible (formerly called "object safe"). Broadly, its methods must not be generic over types, must not return Self by value, and the trait must not require Self: Sized. Clone is the famous example: clone() returns Self, whose size is unknown behind dyn. Work-arounds: mark the offending method where Self: Sized so it is excluded from the vtable, or add a fn box_clone(&self) -> Box<dyn Trait> method.

What they are really testing: Whether they have hit E0038 in practice and know the escape hatches.

Use an associated type when each implementing type has exactly one natural choice: Iterator has type Item because a given iterator yields one kind of thing, and callers write I: Iterator<Item = u32>. Use a generic parameter when one type may implement the trait many times with different arguments: impl From<u8> for Big and impl From<u16> for Big can coexist. Associated types also make signatures shorter, because users need not name the type in every bound.

What they are really testing: Trait-design judgement beyond syntax.

You may implement a trait for a type only if the trait or the type is defined in your crate. It stops two crates from providing conflicting impls of, say, Display for Vec<u8>, which would make it impossible to combine them. The workaround is the newtype pattern: wrap the foreign type, struct Hex(Vec<u8>);, and implement the trait for the wrapper. The newtype costs nothing at runtime.

What they are really testing: Knowing the coherence reason, not just the rule, and the standard fix.

From<T> defines an infallible conversion; implementing it gives you Into for free, and it is what ? uses to convert error types. TryFrom is the fallible version. AsRef<T> is a cheap reference conversion, so fn open<P: AsRef<Path>>(p: P) accepts &str, String and PathBuf. Default gives a type a zero value and enables ..Default::default() in struct literals. Implementing these standard traits is what makes a type feel native to other Rust code.

What they are really testing: Familiarity with the conversion traits that idiomatic APIs are built from.

They describe what a closure does with what it captured. Fn only reads captures, so it can be called many times, even concurrently. FnMut mutates captures, so it needs exclusive access for each call. FnOnce moves a capture out, so it can be called only once. Every Fn is also FnMut, and every FnMut is also FnOnce. When writing a function that takes a closure, ask for the least you need: FnOnce if you call it once (thread::spawn, unwrap_or_else), FnMut for repeated calls on one thread, Fn only if you must share it.

What they are really testing: Whether they choose bounds from the caller’s point of view, which is the API-design half of the question.

It makes the closure take ownership of every variable it captures, instead of borrowing them. It is required when the closure may outlive the current stack frame: passing it to thread::spawn or tokio::spawn, returning it from a function, or storing it in a struct. For Copy captures it copies. A common pattern is to clone an Arc just before a move closure, so the closure owns its own handle.

What they are really testing: Connecting move to lifetimes and threads rather than treating it as a fix-the-error keyword.

Adapters like map, filter and zip only build a new iterator value; nothing runs until a consumer — collect, sum, for, count — pulls items through. Consequences: a chain with no consumer does nothing (the compiler warns that the adapter is unused: "iterators are lazy and do nothing unless consumed"); the chain processes one item at a time end to end with no intermediate vectors; and take(3) after an expensive map means only three items are ever mapped. After optimisation, a chain usually compiles to the same loop you would write by hand.

What they are really testing: Understanding the pull model and its performance consequences.

iter() yields &T and leaves the collection untouched. iter_mut() yields &mut T so you can change elements in place. into_iter() on an owned collection consumes it and yields T by value, so the collection cannot be used afterwards. A for loop calls into_iter() on whatever it is given, which is why for x in &v borrows and for x in v moves v.

What they are really testing: Precise ownership reasoning in the most common loop in the language.

Box<T>: a single owner of heap data — recursive types (a tree node holding Option<Box<Node>>), large values you want to move cheaply, and trait objects (Box<dyn Error>). Rc<T>: several owners on one thread, with a non-atomic reference count, so it is cheap but not Send. Arc<T>: several owners across threads, with an atomic count. All three give shared (read-only) access; add RefCell or Mutex inside to mutate.

What they are really testing: Choosing by ownership shape and thread boundary, not by habit.

Interior mutability lets you mutate data through a shared reference, with the borrowing rules checked somewhere other than compile time. Cell does it for Copy values by swapping whole values; RefCell tracks borrows at run time — borrow() and borrow_mut() hand out guards, and breaking the one-writer rule panics (current Rust prints "RefCell already borrowed"). try_borrow_mut returns a Result instead. Mutex and RwLock are the thread-safe equivalents. The usual shape is Rc<RefCell<T>> on one thread and Arc<Mutex<T>> across threads.

What they are really testing: That RefCell moves the check to run time — and the failure mode is a panic, so keep borrows short.

Yes. Leaks are memory-safe, so safe Rust does not prevent them. The classic accidental case is an Rc cycle: two nodes holding Rcs to each other keep both counts above zero forever. The fix is Weak for back-pointers (child to parent), which does not keep the value alive and is upgraded with upgrade() returning Option. Deliberate leaks exist too: Box::leak and std::mem::forget. In services, the more common "leak" is an unbounded collection, such as a cache map that is never pruned.

What they are really testing: Knowing the precise guarantee — memory safety, not leak freedom — and the Weak fix.

Cow<'a, B> ("clone on write") holds either a borrowed &'a B or an owned value. It lets a function return borrowed data in the common case and allocate only when it has to change something:

fn escape(s: &str) -> Cow<'_, str> {
    if s.contains('&') { Cow::Owned(s.replace('&', "&amp;")) }
    else { Cow::Borrowed(s) }
}

What they are really testing: Awareness of allocation-avoidance tools used in real libraries.

Send: a value of this type can be moved to another thread. Sync: a &T can be shared between threads (formally, T: Sync exactly when &T: Send). Both are auto traits — the compiler implements them when every field has them. Rc is neither, because its count is not atomic; RefCell is Send but not Sync; Arc<Mutex<T>> is both when T: Send. thread::spawn requires its closure to be Send, which is how data races become compile errors.

What they are really testing: Understanding that thread safety is encoded in the type system, with concrete examples of types that fail.

Wrap it in Arc<Mutex<u64>>, clone the Arc into each thread’s move closure, lock, update, and let the guard drop to unlock. For a plain counter, Arc<AtomicU64> with fetch_add(1, Ordering::Relaxed) is lighter and never blocks. With scoped threads (std::thread::scope) you can even borrow a local AtomicU64 or Mutex directly with no Arc, because the scope guarantees every thread has finished before it returns.

What they are really testing: Knowing the standard answer, the lighter atomic, and the newer scoped-thread option.

Channels (std::sync::mpsc, or crossbeam and tokio channels) move ownership of messages between threads, so there is no shared data to lock — good for pipelines and worker pools, and easier to reason about. Shared state behind a Mutex or RwLock fits when many threads need to read or update one structure, such as a cache. Prefer bounded channels so a slow consumer applies backpressure instead of growing memory without limit.

What they are really testing: Design reasoning and awareness of backpressure.

Yes. The type system prevents data races, not deadlocks: two threads locking two mutexes in opposite orders can still wait forever, and locking the same std::sync::Mutex twice on one thread may deadlock or panic. Prevent it with a consistent lock order, short critical sections and no locks held while calling unknown code. Poisoning: if a thread panics while holding a std mutex, the mutex is marked poisoned and later lock() calls return Err, warning that the data may be half-updated. into_inner() on that error recovers the guard if you decide the data is still fine.

What they are really testing: An honest account of what Rust does and does not guarantee.

Calling an async fn runs none of its body; it returns a value that implements Future — a state machine the compiler generated from the function. Futures are lazy: nothing happens until something polls them. .await polls the inner future; if it is not ready, the current task yields to the executor, which runs other tasks and polls again when the I/O is ready. Rust ships the syntax and the Future trait but no runtime, which is why services add tokio.

What they are really testing: The poll-based, lazy model — the source of most async surprises.

A tokio runtime runs many tasks on a few worker threads. A task only gives the thread back at an .await, so std::thread::sleep, a blocking file read, a synchronous database driver or a heavy CPU loop stalls every other task scheduled on that thread, and latency spikes across the service. Use the async versions (tokio::time::sleep, tokio::fs), move blocking work to tokio::task::spawn_blocking, and move long CPU work to a dedicated pool such as rayon.

What they are really testing: Production awareness: this is the most common async performance bug.

tokio::spawn may move a task between worker threads, so the future must be Send and 'static. A future is Send only if everything it holds across an .await is Send. The usual culprits are an Rc, a RefCell borrow, or a std::sync::MutexGuard alive across an await. Fix it by dropping the guard before awaiting (put the locked section in its own block), using tokio::sync::Mutex when the lock really must be held across an await, or swapping Rc for Arc.

What they are really testing: Whether they have debugged real async code — this error is nearly universal.

A library exposes a specific error enum so callers can match on the cases: implement Display and std::error::Error, keep the underlying cause available through source(), and add From impls so ? converts lower-level errors. The thiserror crate derives all of that. An application mostly needs to report errors with context, so anyhow::Result (or Box<dyn Error>) with .context("loading config") is simpler. Mark a public enum #[non_exhaustive] so adding a variant is not a breaking change.

What they are really testing: Whether they separate "caller must handle it" from "operator must read it", and know the ecosystem split.