Top 50 Rust Interview Questions for Senior Developers

Section 1: Ownership and Memory Model

1. What is ownership in Rust, and how does it differ from garbage collection?

Ownership is Rust's compile-time mechanism for managing memory without a garbage collector. Every value has a single owner, and when that owner goes out of scope, the value is dropped. Unlike GC, which reclaims memory at runtime through tracing or reference counting, ownership enforces memory safety statically.

fn main() {
    let s1 = String::from("hello");
    let s2 = s1; // s1 is moved, no longer valid
    // println!("{}", s1); // ERROR: value borrowed after move
    println!("{}", s2);
}

2. Explain the difference between move, copy, and clone semantics.

Types implementing Copy are duplicated bitwise on assignment (e.g., integers, bools). Types that are Clone can be explicitly duplicated via .clone(). All other types are moved on assignment, transferring ownership.

let x = 5;       // i32 is Copy
let y = x;       // x still valid
let s1 = String::from("data");
let s2 = s1.clone(); // explicit deep copy

3. When does Rust perform stack vs heap allocation?

Sized, fixed-size values with Copy semantics live on the stack. String, Vec, Box, and other heap-allocating types allocate on the heap when constructed. Stack allocation is automatic and cheap; heap allocation involves the global allocator.

4. What is the `Drop` trait, and can you implement it manually?

Drop defines cleanup logic executed when a value goes out of scope. You implement it for resources that need explicit release, such as file handles or custom allocators.

struct Connection { id: u32 }

impl Drop for Connection {
    fn drop(&mut self) {
        println!("Closing connection {}", self.id);
    }
}

fn main() {
    let _c = Connection { id: 1 };
    // drop runs automatically at end of scope
}

5. How does `Box`, `Rc`, and `Arc` differ?

Box<T>: single-owner heap pointer, zero runtime overhead.
Rc<T>: reference-counted, single-threaded, multiple readers.
Arc<T>: atomically reference-counted, thread-safe, slightly slower due to atomic ops.

Section 2: Borrowing and Lifetimes

6. What are the borrowing rules in Rust?

At any given time, you can have either one mutable reference or any number of immutable references. References must always be valid (no dangling pointers).

7. Explain lifetimes and why they are needed.

Lifetimes are compile-time annotations that describe how long references remain valid. The compiler uses them to ensure no reference outlives its data. Most are inferred, but function signatures sometimes need explicit annotations.

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

8. What is lifetime elision, and what are its rules?

The compiler infers lifetimes when patterns are unambiguous. The three elision rules: each elided lifetime in input becomes its own lifetime; if there's exactly one input lifetime, it's assigned to all elided outputs; if there's &self or &mut self, its lifetime is assigned to all elided outputs.

9. What is the `'static` lifetime?

'static means the reference is valid for the entire program duration. String literals have this lifetime. It does not mean a value is leaked — it means the borrow checker treats it as always valid.

10. How do you handle self-referential structs?

Rust's borrow checker cannot verify self-referential structs directly. Use crates like ouroboros, self_cell, or restructure to avoid self-references, often by storing indices instead of references.

// Avoid: struct that holds a String and a &str into it
// Instead, store offsets:
struct Parsed {
    data: String,
    token_range: std::ops::Range<usize>,
}

Section 3: Traits and Generics

11. What is the difference between traits and interfaces in other languages?

Traits define shared behavior through method signatures and default implementations. Unlike Java interfaces, traits support associated types, associated constants, and can be implemented retroactively. They enable ad-hoc polymorphism and are resolved statically when used as bounds.

12. Explain static vs dynamic dispatch.

Static dispatch uses monomorphization — the compiler generates specialized code for each concrete type, with zero runtime cost. Dynamic dispatch uses trait objects (dyn Trait) and vtable lookups at runtime.

// Static dispatch
fn process<T: Display>(item: &T) { println!("{}", item); }

// Dynamic dispatch
fn process_dyn(item: &dyn Display) { println!("{}", item); }

13. What are associated types vs generic parameters in traits?

Associated types specify a single output type per implementation, reducing ambiguity. Generic parameters allow multiple implementations per type with different parameters.

trait Container {
    type Item;
    fn first(&self) -> Option<&Self::Item>;
}

14. What is the `newtype` pattern and why use it?

The newtype pattern wraps a type in a tuple struct to give it a distinct identity, enabling trait implementations for foreign types and preventing type confusion.

struct UserId(u64);
struct OrderId(u64);
// Now UserId and OrderId are not interchangeable

15. How do trait objects interact with object safety?

A trait is object-safe only if all its methods meet certain criteria: no Self in return or argument position (except &self/&mut self), no generic type parameters, and the trait itself has no associated constants with generic types. Object-safe traits can be made into dyn Trait.

Section 4: Error Handling

16. Why does Rust use `Result` and `Option` instead of exceptions?

Rust makes error handling explicit and part of the type system. Result<T, E> forces callers to acknowledge potential failure, while Option<T> represents absence without null pointers. This eliminates a whole class of runtime panics and null dereferences.

17. Explain the `?` operator.

The ? operator returns early from a function if the result is Err, propagating the error. It performs automatic conversion via From when the function's error type differs.

fn read_config(path: &str) -> Result<Config, io::Error> {
    let content = fs::read_to_string(path)?;
    Ok(parse(&content))
}

18. When should you use `panic!` vs `Result`?

Use Result for expected, recoverable failures (file I/O, network, parsing). Use panic! for invariant violations, programming errors, or unreachable states. Library code should prefer Result; application code may panic for unrecoverable conditions.

19. How do you create custom error types?

Use the thiserror crate for library errors or implement std::error::Error manually. For applications, anyhow provides ergonomic error chaining.

use thiserror::Error;

#[derive(Debug, Error)]
enum AppError {
    #[error("io error: {0}")]
    Io(#[from] std::io::Error),
    #[error("parse error: {0}")]
    Parse(String),
}

20. What is the difference between `Box<dyn Error>` and concrete error types?

Box<dyn Error> erases the concrete type, useful for quick prototyping but loses type information for matching. Concrete error types enable exhaustive pattern matching and better documentation.

Section 5: Concurrency

21. What does "fearless concurrency" mean in Rust?

Rust's ownership and type system prevent data races at compile time. Types like Mutex<T>, Arc<T>, and traits like Send and Sync encode thread-safety guarantees, so concurrent bugs are caught before runtime.

22. Explain `Send` and `Sync` traits.

Send means a type can be transferred across thread boundaries. Sync means &T can be shared between threads. Most types are auto-derived; Rc<T> is neither Send nor Sync, while Arc<T> is both.

23. How do `Mutex` and `RwLock` differ?

Mutex allows one accessor at a time. RwLock allows multiple readers or one writer. RwLock is better for read-heavy workloads but has higher overhead and potential writer starvation.

use std::sync::{Arc, Mutex};
use std::thread;

let counter = Arc::new(Mutex::new(0));
let handles: Vec<_> = (0..10).map(|_| {
    let counter = Arc::clone(&counter);
    thread::spawn(move || {
        *counter.lock().unwrap() += 1;
    })
}).collect();

for h in handles { h.join().unwrap(); }
println!("Result: {}", *counter.lock().unwrap());

24. What are channels in Rust, and which types exist?

Channels enable message passing between threads. std::sync::mpsc provides multi-producer, single-consumer channels. crossbeam offers multi-producer, multi-consumer channels with better performance and ergonomics.

25. How do you avoid deadlocks in Rust?

Deadlocks can still occur despite Rust's safety guarantees. Best practices: acquire locks in a consistent order, minimize lock scope, prefer message passing over shared state, and use try_lock with timeouts where appropriate.

Section 6: Async and Await

26. What is a future in Rust?

A Future is a value that may not be ready yet. It uses a poll-based model: the executor calls poll, and the future returns Poll::Pending or Poll::Ready. Futures are lazy — they do nothing until polled.

27. Explain the difference between Rust's async model and other languages.

Rust's async is zero-cost and stackless. Unlike Go's goroutines or Python's asyncio, Rust futures compile to state machines with no runtime overhead per task. The runtime is pluggable — tokio, async-std, or smol.

28. What is `Pin` and why is it needed?

Pin<T> ensures a value cannot be moved in memory after being pinned. This is essential for self-referential async state machines generated by async fn, where moving would invalidate internal pointers.

use std::pin::Pin;
use std::marker::PhantomPinned;

struct SelfRef {
    data: String,
    ptr: *const String,
    _pin: PhantomPinned,
}

29. How do you choose between `tokio` and `async-std`?

tokio is the de facto standard with a rich ecosystem, multi-threaded scheduler, and excellent documentation. async-std mirrors the std library API and is simpler. For most production workloads, tokio is recommended.

30. What are the pitfalls of `.await` in locks?

Holding a std::sync::Mutex guard across .await can deadlock if the future is suspended while holding the lock. Use tokio::sync::Mutex for async-aware locking, or restructure to release locks before awaiting.

Section 7: Unsafe Rust and FFI

31. What does `unsafe` mean in Rust?

unsafe disables certain compiler checks, allowing dereferencing raw pointers, calling unsafe functions, accessing mutable statics, implementing unsafe traits, and accessing union fields. It does not turn off the borrow checker entirely — it shifts responsibility to the programmer.

32. When is `unsafe` justified?

Unsafe is justified for FFI with C libraries, implementing low-level data structures (e.g., Vec, LinkedList), performance-critical code that the safe abstractions cannot express, and interfacing with hardware or OS APIs.

33. How do you minimize the unsafe surface area?

Encapsulate unsafe code in a safe API. Document invariants, use debug_assert! for runtime checks, and leverage tools like Miri and loom for testing. The goal is a small, auditable unsafe boundary.

mod safe_wrapper {
    pub fn read_byte(buf: &[u8], idx: usize) -> u8 {
        assert!(idx < buf.len(), "index out of bounds");
        // safe because we verified bounds
        unsafe { *buf.as_ptr().add(idx) }
    }
}

34. What is FFI, and how do you call C from Rust?

FFI (Foreign Function Interface) lets Rust call C functions and vice versa. Use extern "C" blocks to declare foreign functions and #[repr(C)] for compatible struct layouts.

extern "C" {
    fn abs(x: i32) -> i32;
}

fn main() {
    let result = unsafe { abs(-5) };
    println!("{}", result);
}

35. What is `Miri`, and how does it help?

Miri is an interpreter for Rust's mid-level IR that detects undefined behavior, including invalid pointer arithmetic, data races, and uninitialized memory reads. It is invaluable for validating unsafe code.

Section 8: Macros and Metaprogramming

36. What is the difference between declarative and procedural macros?

Declarative macros (macro_rules!) use pattern matching to generate code. Procedural macros (derive, attribute-like, function-like) are Rust functions that operate on token streams, enabling more complex code generation.

37. Write a simple declarative macro.

macro_rules! vec_of_strings {
    ($($x:expr),*) => {
        vec![$(String::from($x)),*]
    };
}

fn main() {
    let v = vec_of_strings!["a", "b", "c"];
}

38. How do derive macros work?

Derive macros implement traits automatically. You annotate a struct or enum with #[derive(MyTrait)], and the macro receives the token stream of the type, generating an impl block. Popular examples include serde::Serialize and Debug.

39. What are the hygiene rules in macros?

Macro hygiene prevents identifier collisions between macro-generated code and the calling scope. Identifiers introduced by a macro refer to items in the macro's definition scope, not the call site, avoiding accidental shadowing.

40. When should you avoid macros?

Avoid macros when a function or trait suffices. Macros hurt readability, complicate debugging, and produce poor error messages. Use them for compile-time code generation, DSLs, or reducing boilerplate that functions cannot express.

Section 9: Performance and Optimization

41. How do you profile Rust performance?

Use cargo flamegraph for visual profiling, perf for Linux kernel-level profiling, and hyperfine for benchmarking CLI tools. For micro-benchmarks, use criterion with statistical rigor.

42. What is zero-cost abstraction in Rust?

Zero-cost abstractions mean you don't pay for what you don't use, and what you do use is as efficient as hand-written code. Iterators, generics, and traits compile down to optimal machine code through monomorphization and inlining.

43. How do you avoid unnecessary heap allocations?

Prefer &str over String in function parameters, use ArrayVec or SmallVec for small collections, leverage Cow for conditional allocation, and reuse buffers with &mut Vec parameters.

use std::borrow::Cow;

fn process(input: &str) -> Cow<str> {
    if input.contains("bad") {
        Cow::Owned(input.replace("bad", "good"))
    } else {
        Cow::Borrowed(input)
    }
}

44. Explain interior mutability and when to use it.

Interior mutability allows mutating data through an immutable reference, checked at runtime. RefCell<T> is single-threaded; Mutex<T> and RwLock<T> are thread-safe; Cell<T> works for Copy types. Use sparingly for patterns like observer registration or caching.

45. What is `#[inline]`, and when does it matter?

#[inline] suggests the compiler inline a function across crate boundaries. #[inline(always)] forces inlining; #[inline(never)] prevents it. Most functions don't need explicit hints — the compiler inlines based on heuristics. Use for hot-path functions in libraries.

Section 10: Idioms and Best Practices

46. What is the builder pattern, and how do you implement it in Rust?

The builder pattern constructs complex objects step by step, handling optional fields and validation. Use type-state builders for compile-time enforcement of required fields.

pub struct Server { host: String, port: u16, tls: bool }

pub struct ServerBuilder { host: Option<String>, port: u16, tls: bool }

impl ServerBuilder {
    pub fn new() -> Self { Self { host: None, port: 80, tls: false } }
    pub fn host(mut self, h: impl Into<String>) -> Self { self.host = Some(h.into()); self }
    pub fn port(mut self, p: u16) -> Self { self.port = p; self }
    pub fn tls(mut self) -> Self { self.tls = true; self }
    pub fn build(self) -> Result<Server, &'static str> {
        Ok(Server {
            host: self.host.ok_or("host is required")?,
            port: self.port,
            tls: self.tls,
        })
    }
}

47. How do you design ergonomic public APIs in Rust?

Accept impl Into<String> or impl AsRef<str> for flexibility. Return Result for fallible operations. Use #[must_use] on important return types. Provide Default implementations. Avoid exposing internal types in public signatures.

48. What is the difference between `impl Trait` in argument and return position?

In argument position, impl Trait is sugar for an anonymous generic bound. In return position, it represents an opaque type — the caller cannot know the concrete type, enabling future changes without breaking API compatibility.

49. How do you structure a Rust project for maintainability?

Split modules by domain, not by type. Keep lib.rs thin, re-exporting public APIs. Use mod.rs or file-based modules consistently. Separate tests into tests/ for integration and inline #[cfg(test)] for unit tests. Use workspace for multi-crate projects.

50. What are the most common mistakes senior developers make in Rust?

Overusing clone() instead of borrowing or lifetimes.
Reaching for Arc<Mutex<T>> when message passing suffices.
Ignoring Clippy warnings that indicate idiomatic improvements.
Writing overly generic code when concrete types are clearer.
Misusing unsafe without encapsulation or testing.
Holding locks across .await points, causing deadlocks.
Returning impl Trait when a concrete type or boxed trait object is more appropriate.

Conclusion

Mastering Rust at a senior level requires internalizing the ownership model, reasoning precisely about lifetimes and concurrency, knowing when unsafe is justified, and designing APIs that are both safe and ergonomic. These 50 questions span the full breadth of what interviewers expect — from memory fundamentals to async runtime internals and metaprogramming. The best preparation combines studying these concepts with hands-on practice: write unsafe code and validate it with Miri, build a concurrent data structure, implement a derive macro, and profile a real workload. Rust rewards deep understanding with compile-time guarantees that make production systems safer and faster, and demonstrating that depth in an interview signals you are ready for the most demanding systems engineering roles.