How to Pass a Rust Interview: Advanced Questions and Answers

How to Pass a Rust Interview: Top Advanced-Level Questions

Rust is a systems programming language gaining popularity due to its safety, performance, and lack of a garbage collector. If you have already mastered the basics and are preparing for an interview for a Senior or Middle Rust developer position, you will encounter questions that go beyond simple syntax. In this article, we will break down key advanced topics that often appear in technical interviews.

We will cover four blocks: ownership and borrowing, lifetimes, unsafe code and macros, as well as advanced multithreading. Each section contains real questions and code examples.

1. Ownership, Borrowing, and Mutability Rules

Question: Explain how the ownership mechanism works in Rust. What is the difference between &T, &mut T, and Box<T>?

Answer: Ownership is the foundation of memory safety in Rust. Each value has exactly one owner. When the owner goes out of scope, the value is dropped. Borrowing (&T) allows temporarily "lending" a reference to data without transferring ownership. Mutable borrowing (&mut T) grants the right to modify the data, but only in the absence of other references.

Box<T> is a smart pointer that allocates memory on the heap. It transfers ownership, which distinguishes it from simple references.

fn main() {\n    let mut s = String::from("Hello");\n    let r1 = &s;      // immutable reference\n    let r2 = &mut s;  // Error! cannot have &mut and & simultaneously\n    // println!("{}", r1);\n}\n

Question: What is the "rule of one mutable borrow"?

Answer: At any given time, a value can have either one mutable reference or any number of immutable references, but not both simultaneously. This prevents data races at compile time.

2. Lifetimes — How the Compiler Understands That a Reference is Valid

Question: Why are lifetime annotations needed? Provide an example where they are mandatory.

Answer: Lifetime annotations ('a, 'b, etc.) help the compiler verify that all references are valid. They are mandatory when a function returns a reference tied to one of the input parameters, and the compiler cannot infer the lifetime automatically.

// Function returns the longest string\nfn longest<'a>(x: &'a str, y: &'a str) -> &'a str {\n    if x.len() > y.len() { x } else { y }\n}\n\nfn main() {\n    let s1 = String::from("long");\n    let result;\n    {\n        let s2 = String::from("short");\n        result = longest(&s1, &s2); // ok\n    }\n    // println!("{}", result); // Error: s2 is dropped\n}\n

Question: What is "lifetime elision"?

Answer: The compiler automatically adds lifetime annotations in simple cases. For example, for the method fn first_word(s: &str) -> &str, the compiler understands that the output lifetime equals the input lifetime. Elision works according to three rules described in the Rust book.

3. Unsafe Rust and Macros

Question: When is the use of unsafe justified? What operations are only available inside unsafe blocks?

Answer: unsafe is used for operations that the compiler cannot verify: dereferencing raw pointers, calling external functions (FFI), accessing mutable static variables, and implementing unsafe traits. However, unsafe does