Rust interview questions

What a strong answer covers

• Every value has an owner, and there's only one owner at a time.
• When the owner goes out of scope, the value is dropped, freeing its resources.
• Prevents use-after-free, double-free, and other memory errors at compile time.
• No runtime overhead of GC, no manual `malloc`/`free` calls.
• Enables memory safety without a runtime or garbage collector.

Where people lose the point

• ×Confusing ownership with borrowing or lifetimes.
• ×Suggesting ownership is a runtime concept.
• ×Failing to explain *why* it's beneficial over other memory models.

What a strong answer covers

• Can have multiple immutable references (`&T`) to a piece of data.
• Can have only one mutable reference (`&mut T`) to a piece of data.
• Cannot have mutable and immutable references to the same data simultaneously.
• This rule prevents data races at compile time.
• Ensures data integrity and thread safety.

Where people lose the point

• ×Incorrectly stating that multiple mutable references are allowed.
• ×Not explaining the "why" behind the rule (data races).
• ×Confusing references with ownership transfers.

What a strong answer covers

• Lifetimes are a compile-time concept that ensures references are valid for as long as they are used.
• They prevent dangling references, where a reference points to deallocated memory.
• The borrow checker infers most lifetimes, but explicit annotations are needed when the compiler can't determine the relationship between multiple references.
• Example: A function returning a reference to one of its input references, or a struct holding references.
• Example code: `fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { ... }`

Where people lose the point

• ×Thinking lifetimes are a runtime concept or affect performance.
• ×Failing to provide a concrete example where explicit lifetimes are needed.
• ×Confusing lifetimes with garbage collection or reference counting.

What a strong answer covers

• `struct`s are used to group related data into a single type, where all fields are always present (AND relationship).
• `enum`s are used when a value can be one of several distinct variants, each potentially with its own associated data (OR relationship).
• `struct`s are good for records (e.g., `User { name: String, age: u8 }`).
• `enum`s are good for states or distinct possibilities (e.g., `Option<T>`, `Result<T, E>`, `TrafficLight::Red | Yellow | Green`).
• Enums with associated data are powerful "sum types."

Where people lose the point

• ×Treating enums as simple integer constants like in C.
• ×Not mentioning associated data for enums.
• ×Failing to articulate the "AND" vs "OR" relationship.

What a strong answer covers

• `match` allows executing different code based on the shape or value of a data structure.
• It's exhaustive: the compiler ensures all possible cases are handled (or a wildcard `_` is used).
• Works powerfully with enums, allowing destructuring of associated data.
• Contributes to safety by preventing unhandled states or `null` dereferences (e.g., with `Option` and `Result`).
• Makes code more readable and expressive than nested `if/else` statements.

Where people lose the point

• ×Understating the exhaustiveness guarantee.
• ×Not mentioning destructuring of enum variants.
• ×Failing to connect it to `Option` and `Result` for safety.

What a strong answer covers

• `Option<T>` represents a value that may or may not be present (`Some(T)` or `None`).
• `Result<T, E>` represents an operation that can either succeed with a value (`Ok(T)`) or fail with an error (`Err(E)`).
• Use `Option` when absence of a value is a normal, expected possibility (e.g., `HashMap::get`).
• Use `Result` when an operation can fail due to external factors or invalid input (e.g., file I/O, parsing).
• Both enforce explicit handling of all cases at compile time.

Where people lose the point

• ×Using `Option` for fallible operations that should return an error.
• ×Using `Result` when `Option` is more appropriate for simple presence/absence.
• ×Not emphasizing the compile-time enforcement of handling both variants.

What a strong answer covers

• The `?` operator is syntactic sugar for propagating `Err` variants (or `None` for `Option`) up the call stack.
• It attempts to unwrap an `Ok(T)` or `Some(T)` value.
• If it encounters `Err(E)` or `None`, it immediately returns that error/none from the current function.
• Requires the current function's return type to be compatible (e.g., `Result<T, E>` or `Option<T>`).
• Significantly reduces boilerplate `match` statements for error propagation.

Where people lose the point

• ×Thinking `?` works with any type, not just `Result` and `Option`.
• ×Not understanding that it *returns* from the current function.
• ×Confusing it with `unwrap()` or `expect()`.

What a strong answer covers

• Traits define shared behavior that types can implement (like interfaces).
• They specify a set of methods that a type must provide.
• Enable polymorphism by allowing functions to accept "any type that implements `TraitX`" (trait objects or trait bounds).
• Examples: `Display`, `Iterator`, `Clone`, `Debug`.
• Contribute to code reusability and extensibility.

Where people lose the point

• ×Confusing traits with classes or inheritance hierarchies.
• ×Not explaining how trait bounds or trait objects achieve polymorphism.
• ×Failing to provide common trait examples.

What a strong answer covers

• Generics allow writing code that works with multiple types without duplication.
• Type parameters are specified using angle brackets (e.g., `Vec<T>`, `fn foo<T>(...)`).
• Monomorphization is the process where the compiler generates a specialized version of generic code for each concrete type it's used with.
• This happens at compile time, eliminating runtime overhead.
• Results in "zero-cost abstractions" and performance comparable to manually written specialized code.

Where people lose the point

• ×Thinking generics incur runtime overhead like dynamic dispatch.
• ×Not understanding that monomorphization happens at compile time.
• ×Failing to connect generics and monomorphization to performance benefits.

What a strong answer covers

• `Send`: A type `T` is `Send` if it's safe to transfer ownership of `T` between threads.
• `Sync`: A type `T` is `Sync` if it's safe for `&T` (an immutable reference) to be shared across threads.
• These are marker traits, automatically implemented by the compiler if all components are `Send`/`Sync`.
• They are fundamental to Rust's compile-time prevention of data races.
• The compiler uses these traits to ensure that concurrent access to data is always safe.

Where people lose the point

• ×Confusing `Send` with `Sync` or vice-versa.
• ×Not understanding that they are marker traits checked at compile time.
• ×Failing to explain *how* they prevent data races.

What a strong answer covers

• Use `Arc<T>` for shared *ownership* across multiple threads. `Arc` is atomically reference counted.
• Use `Mutex<T>` for shared *mutable access* to data within a single thread or across threads. It provides exclusive access.
• Combine them as `Arc<Mutex<T>>` to allow multiple threads to own and safely mutate the same data.
• `Mutex` ensures only one thread can hold the lock and access the inner data at a time.
• `Arc` ensures the data is not dropped until all threads are done with it.

Where people lose the point

• ×Suggesting `Rc<Mutex<T>>` for multi-threaded scenarios.
• ×Not explaining why both `Arc` and `Mutex` are needed together for shared mutable state.
• ×Failing to mention the locking mechanism of `Mutex`.

What a strong answer covers

• `Box<T>`: A smart pointer for heap allocation. Single owner, provides indirection. Used for large data, recursive types, or trait objects.
• `Rc<T>`: Reference counted smart pointer for shared *ownership* in a *single-threaded* context. Allows multiple immutable owners.
• `Arc<T>`: Atomically reference counted smart pointer for shared *ownership* across *multiple threads*. Thread-safe version of `Rc`.
• `Box` for unique ownership on heap, `Rc` for shared ownership single-thread, `Arc` for shared ownership multi-thread.
• All manage memory automatically when the last owner goes out of scope.

Where people lose the point

• ×Using `Rc` in a multi-threaded context.
• ×Not understanding the "ownership" aspect of `Rc`/`Arc` vs. `Box`'s indirection.
• ×Failing to mention the heap allocation aspect of `Box`.

What a strong answer covers

• Declarative macros (`macro_rules!`) are pattern-matching based, defining syntax transformations. They are simpler and more common.
• Procedural macros operate on Rust's Abstract Syntax Tree (AST) and are more powerful, allowing arbitrary code generation.
• Procedural macros come in three forms: function-like, derive, and attribute macros.
• Use declarative for simple, repetitive code generation (e.g., `vec!`, `println!`).
• Use procedural for complex code generation, custom `#[derive]` attributes, or custom attributes (e.g., `serde`, `tokio::main`).

Where people lose the point

• ×Confusing the capabilities or use cases of the two types.
• ×Not mentioning the AST manipulation aspect of procedural macros.
• ×Failing to list the three types of procedural macros.

What a strong answer covers

• FFI code is inherently `unsafe` because Rust's safety guarantees cannot be enforced across the FFI boundary.
• Memory management: Rust's ownership system doesn't apply to C-allocated memory; manual `free` or `drop` might be needed.
• Data types: Ensuring correct type mapping between Rust and C (e.g., `c_char`, `c_int`, `*mut c_void`).
• Null pointers: C functions often return `NULL`, which Rust needs to handle explicitly (e.g., `Option<&T>`).
• Calling conventions: Ensuring the correct calling convention is used (`extern "C"`).

Where people lose the point

• ×Understating the `unsafe` nature of FFI.
• ×Not mentioning memory management differences.
• ×Failing to address type mapping or null pointer handling.

What a strong answer covers

• Unit tests: Small, focused tests for individual functions or modules, typically placed within the same file as the code using `#[test]`.
• Integration tests: Test how different parts of your library work together, placed in a `tests` directory outside `src`.
• Documentation tests: Code examples in `/// doc comments` that are compiled and run as tests, ensuring documentation stays up-to-date and correct.
• Benchmarking tests: Measure the performance of code, using `#[bench]` (requires nightly Rust).
• Fuzzing/Property-based testing: Advanced techniques for finding edge cases by generating random inputs.

Where people lose the point

• ×Only mentioning unit tests.
• ×Not explaining where integration tests are typically located.
• ×Forgetting about doc tests and their importance.

What a strong answer covers

• Closures are anonymous functions that can capture values from their enclosing scope.
• They are represented by three traits: `Fn`, `FnMut`, and `FnOnce`.
• `Fn`: Borrows values immutably from the environment. Can be called multiple times.
• `FnMut`: Borrows values mutably from the environment. Can be called multiple times.
• `FnOnce`: Takes ownership of values from the environment. Can be called only once.

Where people lose the point

• ×Not mentioning the three `Fn` traits.
• ×Incorrectly describing how closures capture variables (by value, by mutable ref, by immutable ref).
• ×Failing to explain the "once" aspect of `FnOnce`.

What a strong answer covers

• `unsafe` is used to opt-out of Rust's compile-time safety checks for specific operations.
• It's necessary for raw pointers, FFI, calling `unsafe` functions, implementing `unsafe` traits, and accessing `static mut` variables.
• It does *not* turn off the borrow checker or other safety checks for the entire block; it only allows specific unsafe operations.
• It does *not* guarantee memory safety; the programmer is responsible for upholding invariants.
• It does *not* prevent data races if `Sync` or `Send` invariants are violated.

Where people lose the point

• ×Believing `unsafe` disables all Rust safety checks.
• ×Not listing specific operations that require `unsafe`.
• ×Failing to emphasize that the programmer takes on the responsibility for safety.

What a strong answer covers

• A Cargo workspace is a set of packages (crates) that share a common `Cargo.lock` and output directory.
• It's defined by a root `Cargo.toml` with a `[workspace]` section.
• Allows managing multiple related crates together, often a library crate and a binary crate that uses it.
• Ensures all crates in the workspace use the same version of dependencies.
• Simplifies development by allowing `cargo build` or `cargo test` to run across all workspace members.

Where people lose the point

• ×Confusing a workspace with a single large crate.
• ×Not mentioning the shared `Cargo.lock` or output directory.
• ×Failing to explain the benefit of managing related crates.