MACRO NEPAL
Rust Interview Preparation: Commonly Asked Questions – Set 1
awiskar acharya
March 10, 2026
4:38 pm

Introduction

This comprehensive guide covers the most frequently asked Rust interview questions, ranging from basic concepts to advanced topics. Each question includes detailed explanations, code examples, and best practices to help you ace your Rust interview.

Table of Contents

  1. Ownership and Borrowing
  2. Lifetimes
  3. Traits and Generics
  4. Error Handling
  5. Concurrency
  6. Memory Management
  7. Common Collections
  8. Smart Pointers
  9. Pattern Matching
  10. Advanced Concepts

1. Ownership and Borrowing

Q1: Explain Rust's ownership rules and how they prevent memory bugs.

Answer: Rust's ownership system has three main rules:

  1. Each value has a single owner at any time
  2. When the owner goes out of scope, the value is dropped
  3. You can have either one mutable reference or multiple immutable references, but not both simultaneously
fn ownership_example() { // Rule 1: s owns the String let s = String::from("hello"); // Ownership moves to s2 let s2 = s; // println!("{}", s); // Error: s no longer valid // Rule 2: s2 goes out of scope here, memory freed // Rule 3: Borrowing rules let mut s3 = String::from("world"); let r1 = &s3; // Immutable borrow let r2 = &s3; // Another immutable borrow - OK // let r3 = &mut s3; // Error: can't borrow mutably with immutable borrows println!("{} and {}", r1, r2); let r4 = &mut s3; // Mutable borrow - OK (no other borrows active) r4.push_str("!"); }

Key Points:

  • Prevents data races at compile time
  • Eliminates dangling pointers
  • No garbage collection overhead
  • Zero-cost abstractions

Q2: What's the difference between passing by value, reference, and mutable reference?

Answer:

fn main() { let x = 5; let mut y = 10; let s = String::from("hello"); // Pass by value (copy for Copy types) take_copy(x); println!("x still usable: {}", x); // Works because i32 is Copy // Pass by value (move for non-Copy types) take_ownership(s); // println!("{}", s); // Error: s moved // Pass by immutable reference let s2 = String::from("world"); borrow(&s2); println!("s2 still usable: {}", s2); // Works // Pass by mutable reference change(&mut y); println!("y changed: {}", y); } fn take_copy(x: i32) { println!("Got copy: {}", x); } fn take_ownership(s: String) { println!("Took ownership of: {}", s); } // s dropped here fn borrow(s: &String) { println!("Borrowed: {}", s); } fn change(x: &mut i32) { *x += 10; }

Key Differences:

  • Value: Ownership transfers (or copy for Copy types)
  • Immutable reference: Borrow read-only access
  • Mutable reference: Borrow read-write access

Q3: Explain the concept of "move" semantics in Rust.

Answer:

#[derive(Debug)] struct Person { name: String, age: u32, } fn main() { // Move with non-Copy types let p1 = Person { name: String::from("Alice"), age: 30, }; // p1 is MOVED to p2, not copied let p2 = p1; // println!("{:?}", p1); // Error: p1 no longer valid println!("{:?}", p2); // OK // Move in function calls let s = String::from("hello"); takes_ownership(s); // println!("{}", s); // Error: s moved // Move in closures let v = vec![1, 2, 3]; let closure = move || { println!("Vector moved into closure: {:?}", v); }; closure(); // println!("{:?}", v); // Error: v moved into closure // Move with Copy types (copy, not move) let x = 5; let y = x; // Copy, not move println!("x: {}, y: {}", x, y); // Both work } fn takes_ownership(s: String) { println!("Took ownership of: {}", s); } // s dropped here

2. Lifetimes

Q4: What are lifetimes in Rust and why are they needed?

Answer: Lifetimes ensure that references are always valid (no dangling references). They're part of Rust's compile-time memory safety guarantees.

// Explicit lifetime annotation fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { if x.len() > y.len() { x } else { y } } // Lifetime in structs struct ImportantExcerpt<'a> { part: &'a str, } // Multiple lifetimes fn complex<'a, 'b>(x: &'a str, y: &'b str) -> &'a str { x } fn main() { let string1 = String::from("long string is long"); let result; { let string2 = String::from("xyz"); result = longest(string1.as_str(), string2.as_str()); println!("Longest: {}", result); // OK here } // println!("Longest: {}", result); // Error if result might refer to string2 // Struct with lifetime let novel = String::from("Call me Ishmael..."); let first_sentence = novel.split('.').next().unwrap(); let excerpt = ImportantExcerpt { part: first_sentence, }; // excerpt's lifetime tied to novel }

Lifetime Elision Rules:

  1. Each parameter gets its own lifetime
  2. If only one input lifetime, output gets that lifetime
  3. If &self or &mut self, output gets self's lifetime

Q5: Explain the 'static lifetime.

Answer: 'static lifetime means the reference is valid for the entire program duration.

// String literals have 'static lifetime let s: &'static str = "I live forever"; // Static variables static GLOBAL: i32 = 42; // Static with lifetime fn returns_static() -> &'static str { "This string is stored in the binary" } // Using 'static with generics fn print_if_static<T: 'static>(t: T) { // T must not contain any non-static references println!("Got static type"); } // Common misconception fn main() { let s = "hello"; // 'static let s2 = String::from("hello").as_str(); // println!("{}", s2); // Not 'static, lives only in this scope // 'static constraints in generics let v: Vec<i32> = vec![1, 2, 3]; print_if_static(v); // OK - i32 is 'static }

3. Traits and Generics

Q6: Explain traits and how they differ from interfaces in other languages.

Answer: Traits define shared behavior, similar to interfaces but more powerful.

// Define a trait trait Summary { fn summarize(&self) -> String; // Default implementation fn summarize_author(&self) -> String { String::from("(Unknown author)") } } // Implement trait for a type struct NewsArticle { headline: String, location: String, author: String, } impl Summary for NewsArticle { fn summarize(&self) -> String { format!("{}, by {} ({})", self.headline, self.author, self.location) } } struct Tweet { username: String, content: String, } impl Summary for Tweet { fn summarize(&self) -> String { format!("{}: {}", self.username, self.content) } } // Trait as parameter fn notify(item: &impl Summary) { println!("Breaking news! {}", item.summarize()); } // Trait bound syntax fn notify_bound<T: Summary>(item: &T) { println!("Breaking news! {}", item.summarize()); } // Multiple trait bounds use std::fmt::Display; fn notify_multi<T: Summary + Display>(item: &T) {} // Where clause fn some_function<T, U>(t: &T, u: &U) -> i32 where T: Display + Clone, U: Clone + std::fmt::Debug, { 42 } // Returning impl Trait fn returns_summarizable() -> impl Summary { Tweet { username: String::from("horse_ebooks"), content: String::from("of course"), } } // Trait objects (dynamic dispatch) fn returns_dynamic(choice: bool) -> Box<dyn Summary> { if choice { Box::new(NewsArticle { headline: String::from("Headline"), location: String::from("Location"), author: String::from("Author"), }) } else { Box::new(Tweet { username: String::from("user"), content: String::from("content"), }) } }

Key Differences from Interfaces:

  • Can provide default implementations
  • Can have associated types
  • Can be implemented for external types
  • Support static dispatch (monomorphization) by default

Q7: What are associated types in traits?

Answer: Associated types allow traits to have placeholder types that are specified when implementing.

// Iterator trait uses associated type trait Iterator { type Item; // Associated type fn next(&mut self) -> Option<Self::Item>; } struct Counter { count: u32, } impl Iterator for Counter { type Item = u32; // Specify the associated type fn next(&mut self) -> Option<Self::Item> { self.count += 1; if self.count < 6 { Some(self.count) } else { None } } } // Another example: Container trait trait Container { type Item; // Associated type fn add(&mut self, item: Self::Item); fn get(&self, index: usize) -> Option<&Self::Item>; } struct MyVec<T> { items: Vec<T>, } impl<T> Container for MyVec<T> { type Item = T; fn add(&mut self, item: T) { self.items.push(item); } fn get(&self, index: usize) -> Option<&T> { self.items.get(index) } } fn main() { let mut counter = Counter { count: 0 }; while let Some(n) = counter.next() { println!("{}", n); } }

Benefits:

  • Cleaner syntax than generic parameters
  • Ensures type consistency across methods
  • Better for single implementation per type

4. Error Handling

Q8: Compare and contrast Option and Result types.

Answer: Both are enums for handling absence of values or errors.

// Option - for possible absence // enum Option<T> { // Some(T), // None, // } // Result - for possible errors // enum Result<T, E> { // Ok(T), // Err(E), // } fn main() { // Option examples let some_value: Option<i32> = Some(5); let none_value: Option<i32> = None; // Safe unwrapping match some_value { Some(x) => println!("Got: {}", x), None => println!("Got nothing"), } // Combinators let doubled = some_value.map(|x| x * 2); let filtered = some_value.filter(|&x| x > 10); let or_default = none_value.unwrap_or(0); // Result examples let success: Result<i32, &str> = Ok(42); let failure: Result<i32, &str> = Err("Something went wrong"); // Error handling with Result match success { Ok(value) => println!("Success: {}", value), Err(e) => println!("Error: {}", e), } // ? operator for propagation fn parse_and_double(s: &str) -> Result<i32, std::num::ParseIntError> { let num = s.parse::<i32>()?; // Propagates error Ok(num * 2) } // Combining Option and Result let result: Result<Option<i32>, &str> = Ok(Some(5)); if let Ok(Some(x)) = result { println!("Got: {}", x); } }

When to use:

  • Option: Simple absence of value (no error information needed)
  • Result: Operation that can fail with error context

Q9: Explain the ? operator and when you can use it.

Answer: The ? operator propagates errors or None values, making error handling concise.

use std::fs::File; use std::io::{self, Read}; use std::num::ParseIntError; // Without ? operator fn read_file_verbose() -> Result<String, io::Error> { let f = File::open("hello.txt"); let mut f = match f { Ok(file) => file, Err(e) => return Err(e), }; let mut s = String::new(); match f.read_to_string(&mut s) { Ok(_) => Ok(s), Err(e) => Err(e), } } // With ? operator fn read_file_concise() -> Result<String, io::Error> { let mut f = File::open("hello.txt")?; let mut s = String::new(); f.read_to_string(&mut s)?; Ok(s) } // Even more concise fn read_file_short() -> Result<String, io::Error> { let mut s = String::new(); File::open("hello.txt")?.read_to_string(&mut s)?; Ok(s) } // With Option fn first_positive(numbers: Vec<i32>) -> Option<i32> { let first = numbers.get(0)?; // Returns None if index out of bounds if *first > 0 { Some(*first) } else { None } } // Chaining multiple operations fn process_data() -> Result<i32, ParseIntError> { let a = "10".parse::<i32>()?; let b = "20".parse::<i32>()?; let c = "30".parse::<i32>()?; Ok(a + b + c) } // Mixed error types (need conversion) fn mixed_errors() -> Result<i32, Box<dyn std::error::Error>> { let file = File::open("data.txt")?; // io::Error let num = "42".parse::<i32>()?; // ParseIntError Ok(num) } fn main() -> Result<(), Box<dyn std::error::Error>> { let result = read_file_concise()?; println!("File content: {}", result); if let Some(x) = first_positive(vec![-1, -2, 3]) { println!("First positive: {}", x); } Ok(()) }

Rules for ?:

  • Can only be used in functions returning Result or Option
  • Converts error types using From trait
  • Returns early on Err or None

5. Concurrency

Q10: How does Rust prevent data races at compile time?

Answer: Rust's ownership system and Send/Sync traits prevent data races.

use std::thread; use std::sync::{Arc, Mutex}; fn main() { // This won't compile - ownership prevents sharing let data = vec![1, 2, 3]; let handle = thread::spawn(|| { // data // Can't capture by default - ownership issues }); // Move ownership to thread let handle = thread::spawn(move || { println!("{:?}", data); // data moved here }); handle.join().unwrap(); // println!("{:?}", data); // Error: data moved // Using Arc for shared ownership let data = Arc::new(vec![1, 2, 3, 4, 5]); let mut handles = vec![]; for i in 0..5 { let data_clone = Arc::clone(&data); handles.push(thread::spawn(move || { println!("Thread {} sees: {:?}", i, data_clone); })); } for handle in handles { handle.join().unwrap(); } // Mutex for mutable shared data let counter = Arc::new(Mutex::new(0)); let mut handles = vec![]; for _ in 0..10 { let counter = Arc::clone(&counter); handles.push(thread::spawn(move || { let mut num = counter.lock().unwrap(); *num += 1; })); } for handle in handles { handle.join().unwrap(); } println!("Result: {}", *counter.lock().unwrap()); } // Send and Sync traits fn send_sync_example() { // Send: Type can be transferred across threads // Sync: Type can be safely shared between threads // i32 implements both Send and Sync let x: i32 = 5; thread::spawn(move || { println!("{}", x); }); // Rc<T> is NOT Send (not thread-safe) // Arc<T> IS Send (thread-safe) // Mutex<T> IS Send + Sync }

Key Points:

  • Send: Type can be transferred across threads
  • Sync: Type can be safely shared between threads
  • Compiler prevents sending non-Send types between threads
  • Prevents data races at compile time

Q11: Explain the difference between Mutex<T> and RwLock<T>.

Answer: Both provide interior mutability across threads, but with different semantics.

use std::sync::{Arc, Mutex, RwLock}; use std::thread; fn mutex_example() { // Mutex: One thread can access at a time let data = Arc::new(Mutex::new(0)); let mut handles = vec![]; for _ in 0..10 { let data = Arc::clone(&data); handles.push(thread::spawn(move || { let mut value = data.lock().unwrap(); *value += 1; })); } for handle in handles { handle.join().unwrap(); } println!("Mutex result: {}", *data.lock().unwrap()); } fn rwlock_example() { // RwLock: Multiple readers OR single writer let data = Arc::new(RwLock::new(0)); let mut handles = vec![]; // Writers for _ in 0..3 { let data = Arc::clone(&data); handles.push(thread::spawn(move || { let mut write = data.write().unwrap(); *write += 1; println!("Writer updated to {}", *write); })); } // Readers for i in 0..5 { let data = Arc::clone(&data); handles.push(thread::spawn(move || { let read = data.read().unwrap(); println!("Reader {} sees: {}", i, *read); })); } for handle in handles { handle.join().unwrap(); } } fn main() { mutex_example(); rwlock_example(); } // Performance comparison fn performance_comparison() { use std::time::Instant; // Mutex with heavy read load let mutex_data = Arc::new(Mutex::new(0)); let rwlock_data = Arc::new(RwLock::new(0)); // RwLock usually better for read-heavy workloads // Mutex better for write-heavy or balanced workloads }

Key Differences:

  • Mutex: Simple, one thread at a time
  • RwLock: Multiple readers or single writer
  • Use RwLock for read-heavy workloads
  • Use Mutex for write-heavy or when simplicity preferred

Q12: What are channels and how do you use them?

Answer: Channels allow communication between threads through message passing.

use std::sync::mpsc; use std::thread; use std::time::Duration; fn basic_channel() { // Create a channel let (tx, rx) = mpsc::channel(); // Spawn producer thread thread::spawn(move || { let messages = vec![ String::from("Hello"), String::from("from"), String::from("the"), String::from("thread"), ]; for msg in messages { tx.send(msg).unwrap(); thread::sleep(Duration::from_millis(100)); } }); // Receive messages in main thread for received in rx { println!("Got: {}", received); } } fn multiple_producers() { let (tx, rx) = mpsc::channel(); // Clone the transmitter for multiple producers let tx1 = tx.clone(); thread::spawn(move || { tx1.send("Message from thread 1").unwrap(); }); let tx2 = tx.clone(); thread::spawn(move || { tx2.send("Message from thread 2").unwrap(); }); // Drop original tx so channel closes when all clones dropped drop(tx); for received in rx { println!("Received: {}", received); } } fn with_result_channel() { let (tx, rx) = mpsc::channel::<Result<i32, String>>(); thread::spawn(move || { for i in 0..5 { if i == 3 { tx.send(Err("Something went wrong".to_string())).unwrap(); } else { tx.send(Ok(i * 10)).unwrap(); } thread::sleep(Duration::from_millis(50)); } }); for result in rx { match result { Ok(val) => println!("Got: {}", val), Err(e) => println!("Error: {}", e), } } } fn sync_channel_example() { use std::sync::mpsc::sync_channel; // Synchronous channel with buffer size 3 let (tx, rx) = sync_channel(3); thread::spawn(move || { for i in 1..=10 { println!("Sending {}", i); tx.send(i).unwrap(); // Blocks if buffer is full println!("Sent {}", i); } }); thread::sleep(Duration::from_secs(1)); // Receive slowly for received in rx { println!("Received: {}", received); thread::sleep(Duration::from_millis(500)); } } fn main() { println!("Basic channel:"); basic_channel(); println!("\nMultiple producers:"); multiple_producers(); println!("\nResult channel:"); with_result_channel(); }

6. Memory Management

Q13: Explain the difference between stack and heap allocation in Rust.

Answer: Stack vs heap allocation with Rust's ownership system.

use std::mem; fn main() { // Stack allocation (fixed size, known at compile time) let x = 5; // i32 on stack let y = true; // bool on stack let z = 3.14; // f64 on stack let arr = [1, 2, 3]; // array on stack (size known) let tuple = (1, "hello"); // tuple on stack println!("Stack size of i32: {} bytes", mem::size_of::<i32>()); println!("Stack size of array[3]: {} bytes", mem::size_of::<[i32; 3]>()); // Heap allocation (dynamic size) let s = String::from("hello"); // String data on heap let v = vec![1, 2, 3, 4, 5]; // Vec data on heap let boxed = Box::new(100); // Box puts value on heap println!("Size of String (on stack): {} bytes", mem::size_of::<String>()); println!("Size of Vec (on stack): {} bytes", mem::size_of::<Vec<i32>>()); // Stack vs heap performance fn stack_performance() { let start = std::time::Instant::now(); for i in 0..1_000_000 { let x = i; // Stack allocation } println!("Stack allocation: {:?}", start.elapsed()); } fn heap_performance() { let start = std::time::Instant::now(); for i in 0..1_000_000 { let x = Box::new(i); // Heap allocation } println!("Heap allocation: {:?}", start.elapsed()); } stack_performance(); heap_performance(); } // Memory layout of custom types struct MyStruct { a: u8, // 1 byte b: u32, // 4 bytes (needs padding) c: u16, // 2 bytes } // Layout: a(1) + padding(3) + b(4) + c(2) + padding(2) = 12 bytes fn memory_layout() { println!("Size of MyStruct: {} bytes", mem::size_of::<MyStruct>()); println!("Alignment: {} bytes", mem::align_of::<MyStruct>()); }

Key Differences:

  • Stack: Fast, LIFO, fixed size, no garbage collection
  • Heap: Flexible, dynamic size, requires explicit management
  • Rust's ownership ensures heap memory is freed when owner goes out of scope

Q14: What is RAII and how does Rust implement it?

Answer: RAII (Resource Acquisition Is Initialization) binds resource lifetime to object lifetime.

use std::fs::File; use std::io::Write; // RAII with custom type struct DatabaseConnection { id: u32, connected: bool, } impl DatabaseConnection { fn new(id: u32) -> Self { println!("Opening database connection {}", id); DatabaseConnection { id, connected: true } } fn query(&self, sql: &str) { if self.connected { println!("Connection {}: {}", self.id, sql); } } } // Drop trait for cleanup impl Drop for DatabaseConnection { fn drop(&mut self) { println!("Closing database connection {}", self.id); self.connected = false; } } // RAII with files fn file_example() -> std::io::Result<()> { { // File automatically closes when going out of scope let mut file = File::create("test.txt")?; file.write_all(b"Hello, World!")?; println!("File written"); } // File closed here // The file is automatically flushed and closed Ok(()) } // RAII with mutex use std::sync::Mutex; fn mutex_raii() { let mutex = Mutex::new(0); { // MutexGuard implements Drop let mut guard = mutex.lock().unwrap(); *guard += 1; println!("Incremented inside scope"); } // Mutex automatically unlocked here // Can lock again let value = *mutex.lock().unwrap(); println!("Value: {}", value); } // Custom RAII type struct ScopedTimer { name: String, start: std::time::Instant, } impl ScopedTimer { fn new(name: &str) -> Self { println!("Starting: {}", name); ScopedTimer { name: name.to_string(), start: std::time::Instant::now(), } } } impl Drop for ScopedTimer { fn drop(&mut self) { let elapsed = self.start.elapsed(); println!("Finished: {} (took {:?})", self.name, elapsed); } } fn main() -> std::io::Result<()> { { let _timer = ScopedTimer::new("database operation"); // Connection automatically closed when out of scope let conn = DatabaseConnection::new(1); conn.query("SELECT * FROM users"); } // conn dropped here, timer dropped here file_example()?; mutex_raii(); Ok(()) }

Benefits:

  • Automatic resource cleanup
  • Exception safety
  • No manual close() or free() calls
  • Prevents resource leaks

7. Common Collections

Q15: Compare Vec<T>, VecDeque<T>, and LinkedList<T>.

Answer: Different sequence containers with different performance characteristics.

use std::collections::{VecDeque, LinkedList}; fn main() { // Vec<T> - Dynamic array let mut vec = Vec::new(); vec.push(1); vec.push(2); vec.push(3); // Fast: O(1) index access let first = vec[0]; // Fast: O(1) push/pop at end vec.push(4); let last = vec.pop(); // Slow: O(n) insert/remove in middle vec.insert(1, 5); vec.remove(2); // VecDeque<T> - Double-ended queue let mut deque = VecDeque::new(); // Fast: O(1) push/pop at both ends deque.push_back(1); deque.push_back(2); deque.push_front(0); deque.push_front(-1); let front = deque.pop_front(); // -1 let back = deque.pop_back(); // 2 println!("Deque: {:?}", deque); // [0, 1] // LinkedList<T> - Doubly linked list let mut list = LinkedList::new(); list.push_back(1); list.push_back(2); list.push_front(0); // Fast: O(1) insert/remove at ends // Slow: O(n) index access // Better for: frequent splits/merges // Performance comparison fn benchmark() { use std::time::Instant; let size = 100_000; // Vec push back let start = Instant::now(); let mut vec = Vec::with_capacity(size); for i in 0..size { vec.push(i); } println!("Vec push back: {:?}", start.elapsed()); // VecDeque push back let start = Instant::now(); let mut deque = VecDeque::with_capacity(size); for i in 0..size { deque.push_back(i); } println!("VecDeque push back: {:?}", start.elapsed()); // VecDeque push front (requires shifting) let start = Instant::now(); let mut deque = VecDeque::with_capacity(size); for i in 0..size { deque.push_front(i); // More expensive than push_back } println!("VecDeque push front: {:?}", start.elapsed()); // LinkedList push back let start = Instant::now(); let mut list = LinkedList::new(); for i in 0..size { list.push_back(i); } println!("LinkedList push back: {:?}", start.elapsed()); } benchmark(); } // When to use each: // - Vec: Most cases, need fast index access // - VecDeque: Need queue/deque operations at both ends // - LinkedList: Rarely needed, only when splitting/merging frequently

Q16: How do you choose between HashMap and BTreeMap?

Answer: Based on ordering requirements and performance characteristics.

use std::collections::{HashMap, BTreeMap}; fn main() { // HashMap - Unordered, average O(1) operations let mut hashmap = HashMap::new(); hashmap.insert("apple", 3); hashmap.insert("banana", 2); hashmap.insert("cherry", 5); println!("HashMap (order not guaranteed): {:?}", hashmap); // BTreeMap - Sorted, O(log n) operations let mut btmap = BTreeMap::new(); btmap.insert("apple", 3); btmap.insert("banana", 2); btmap.insert("cherry", 5); println!("BTreeMap (sorted): {:?}", btmap); // BTreeMap range queries let range: Vec<_> = btmap.range("a"..="c").collect(); println!("Range 'a' to 'c': {:?}", range); // First and last entries if let Some((key, value)) = btmap.first_key_value() { println!("First: {}: {}", key, value); } if let Some((key, value)) = btmap.last_key_value() { println!("Last: {}: {}", key, value); } // Performance comparison fn benchmark() { use std::time::Instant; let size = 100_000; // HashMap insertion let start = Instant::now(); let mut hashmap = HashMap::with_capacity(size); for i in 0..size { hashmap.insert(i, i * 2); } println!("HashMap insertion: {:?}", start.elapsed()); // BTreeMap insertion let start = Instant::now(); let mut btmap = BTreeMap::new(); for i in 0..size { btmap.insert(i, i * 2); } println!("BTreeMap insertion: {:?}", start.elapsed()); // HashMap lookup let start = Instant::now(); for i in 0..size { let _ = hashmap.get(&i); } println!("HashMap lookup: {:?}", start.elapsed()); // BTreeMap lookup let start = Instant::now(); for i in 0..size { let _ = btmap.get(&i); } println!("BTreeMap lookup: {:?}", start.elapsed()); } benchmark(); } // When to use: // HashMap: // - Need fast lookups (O(1) average) // - Order doesn't matter // - Keys are hashable // // BTreeMap: // - Need sorted data // - Need range queries // - Order matters // - When consistent iteration order is important

8. Smart Pointers

Q17: Explain Box<T>, Rc<T>, and RefCell<T>.

Answer: Smart pointers with different ownership and mutability semantics.

use std::rc::Rc; use std::cell::RefCell; // Box<T> - Single ownership, heap allocation fn box_example() { // Box for heap allocation let b = Box::new(5); println!("b = {}", b); // Box for recursive types #[derive(Debug)] enum List { Cons(i32, Box<List>), Nil, } let list = List::Cons(1, Box::new(List::Cons(2, Box::new(List::Cons(3, Box::new(List::Nil)))))); println!("{:?}", list); } // Rc<T> - Reference counting (single-threaded) fn rc_example() { use List2::{Cons, Nil}; #[derive(Debug)] enum List2 { Cons(i32, Rc<List2>), Nil, } let a = Rc::new(Cons(5, Rc::new(Cons(10, Rc::new(Nil))))); println!("count after creating a = {}", Rc::strong_count(&a)); let b = Cons(3, Rc::clone(&a)); println!("count after creating b = {}", Rc::strong_count(&a)); { let c = Cons(4, Rc::clone(&a)); println!("count after creating c = {}", Rc::strong_count(&a)); } println!("count after c goes out = {}", Rc::strong_count(&a)); } // RefCell<T> - Interior mutability (single-threaded) fn refcell_example() { let cell = RefCell::new(5); // Borrow mutably at runtime *cell.borrow_mut() += 1; println!("cell: {:?}", cell); // Multiple borrows checked at runtime { let r1 = cell.borrow(); let r2 = cell.borrow(); // let r3 = cell.borrow_mut(); // This would panic at runtime println!("r1: {}, r2: {}", r1, r2); } // Example with mock objects #[derive(Debug)] struct MockMessenger { sent_messages: RefCell<Vec<String>>, } impl MockMessenger { fn new() -> Self { MockMessenger { sent_messages: RefCell::new(vec![]), } } fn send(&self, message: &str) { self.sent_messages.borrow_mut().push(String::from(message)); } fn messages(&self) -> usize { self.sent_messages.borrow().len() } } let mock = MockMessenger::new(); mock.send("Hello"); mock.send("World"); println!("Messages: {}", mock.messages()); println!("{:?}", mock.sent_messages.borrow()); } // Combining Rc and RefCell for shared mutable data fn rc_refcell_example() { use std::rc::Rc; use std::cell::RefCell; let shared = Rc::new(RefCell::new(vec![1, 2, 3])); let a = Rc::clone(&shared); let b = Rc::clone(&shared); *a.borrow_mut() = vec![4, 5, 6]; println!("shared: {:?}", shared.borrow()); println!("b: {:?}", b.borrow()); } fn main() { println!("Box example:"); box_example(); println!("\nRc example:"); rc_example(); println!("\nRefCell example:"); refcell_example(); println!("\nRc + RefCell example:"); rc_refcell_example(); }

Key Differences:

  • Box: Single owner, heap allocation
  • Rc: Multiple owners (read-only), reference counted
  • RefCell: Single owner, mutable borrows checked at runtime
  • Rc>: Multiple owners with mutability

Q18: What's the difference between Cell and RefCell?

Answer: Both provide interior mutability but with different capabilities.

use std::cell::{Cell, RefCell}; // Cell<T> - Works with Copy types fn cell_example() { let cell = Cell::new(5); // Get and set values println!("Value: {}", cell.get()); cell.set(10); println!("After set: {}", cell.get()); // Update with closure cell.update(|x| x * 2); println!("After update: {}", cell.get()); // Replace let old = cell.replace(20); println!("Old: {}, New: {}", old, cell.get()); // Works with Copy types only // let string_cell = Cell::new(String::from("hello")); // Error: String not Copy } // RefCell<T> - Works with any type, provides references fn refcell_example() { let refcell = RefCell::new(vec![1, 2, 3]); // Borrow immutably { let borrowed = refcell.borrow(); println!("Borrowed: {:?}", borrowed); } // Borrow mutably { let mut borrowed_mut = refcell.borrow_mut(); borrowed_mut.push(4); borrowed_mut.push(5); } println!("After mutable borrow: {:?}", refcell.borrow()); // Try borrow while borrowed let r1 = refcell.borrow(); // let r2 = refcell.borrow_mut(); // This would panic at runtime drop(r1); // Drop before trying mutable borrow let mut r2 = refcell.borrow_mut(); // Now it's fine r2.push(6); } // Practical example: Counter struct Counter { value: Cell<i32>, } impl Counter { fn new() -> Self { Counter { value: Cell::new(0), } } fn increment(&self) { self.value.set(self.value.get() + 1); } fn get(&self) -> i32 { self.value.get() } } // Practical example: Graph with RefCell use std::rc::Rc; #[derive(Debug)] struct Node { value: i32, children: RefCell<Vec<Rc<Node>>>, } impl Node { fn new(value: i32) -> Self { Node { value, children: RefCell::new(vec![]), } } fn add_child(&self, child: Rc<Node>) { self.children.borrow_mut().push(child); } } fn main() { println!("Cell example:"); cell_example(); println!("\nRefCell example:"); refcell_example(); // Counter with Cell let counter = Counter::new(); counter.increment(); counter.increment(); println!("Counter: {}", counter.get()); // Graph with RefCell let root = Rc::new(Node::new(1)); let child1 = Rc::new(Node::new(2)); let child2 = Rc::new(Node::new(3)); root.add_child(child1.clone()); root.add_child(child2.clone()); println!("Root: {:?}", root); }

Key Differences:

  • Cell: Copy types only, no references, O(1) operations
  • RefCell: Any type, provides references, runtime borrow checking
  • Use Cell for simple Copy types
  • Use RefCell when you need references or non-Copy types

9. Pattern Matching

Q19: Explain the different patterns available in Rust.

Answer: Rust provides rich pattern matching capabilities.

fn main() { // 1. Literal patterns let x = 1; match x { 1 => println!("one"), 2 => println!("two"), 3 => println!("three"), _ => println!("anything"), } // 2. Named variable patterns match x { y => println!("Matched: {}", y), // y binds to value } // 3. Multiple patterns match x { 1 | 2 => println!("one or two"), 3 | 4 => println!("three or four"), _ => println!("something else"), } // 4. Range patterns let score = 85; match score { 0..=59 => println!("F"), 60..=69 => println!("D"), 70..=79 => println!("C"), 80..=89 => println!("B"), 90..=100 => println!("A"), _ => println!("Invalid"), } // 5. Struct patterns struct Point { x: i32, y: i32, } let p = Point { x: 10, y: 20 }; match p { Point { x, y } => println!("({}, {})", x, y), } match p { Point { x: 0, y } => println!("On y-axis at {}", y), Point { x, y: 0 } => println!("On x-axis at {}", x), Point { x, y } => println!("({}, {})", x, y), } // 6. Tuple patterns let tuple = (1, 2, 3); match tuple { (0, y, z) => println!("First is 0: {}, {}", y, z), (1, ..) => println!("First is 1, ignore rest"), _ => println!("Something else"), } // 7. Enum patterns enum Message { Quit, Move { x: i32, y: i32 }, Write(String), ChangeColor(i32, i32, i32), } let msg = Message::Move { x: 10, y: 20 }; match msg { Message::Quit => println!("Quit"), Message::Move { x, y } => println!("Move to ({}, {})", x, y), Message::Write(text) => println!("Text: {}", text), Message::ChangeColor(r, g, b) => println!("Color: {}, {}, {}", r, g, b), } // 8. Reference patterns let x = 5; let y = &x; match y { &val => println!("Got value: {}", val), } // 9. @ bindings let id = 5; match id { e @ 1..=5 => println!("Small: {}", e), e @ 6..=10 => println!("Medium: {}", e), e => println!("Large: {}", e), } // 10. Guard patterns let pair = (2, -2); match pair { (x, y) if x == y => println!("Equal"), (x, y) if x + y == 0 => println!("Opposites"), (x, _) if x % 2 == 0 => println!("First is even"), _ => println!("No match"), } // 11. Destructuring nested structures struct Person { name: String, age: u32, address: Address, } struct Address { city: String, country: String, } let person = Person { name: "Alice".to_string(), age: 30, address: Address { city: "New York".to_string(), country: "USA".to_string(), }, }; match person { Person { name, age: 30, address: Address { city, .. }, } => println!("{} is 30 and lives in {}", name, city), _ => println!("Not matching"), } }

Q20: What are match guards and when would you use them?

Answer: Match guards add additional conditions to patterns.

fn main() { // Basic match guard let num = Some(4); match num { Some(x) if x < 5 => println!("Less than 5: {}", x), Some(x) if x == 5 => println!("Equal to 5"), Some(x) => println!("Greater than 5: {}", x), None => println!("None"), } // Multiple conditions let pair = (2, 4); match pair { (x, y) if x == y => println!("Equal"), (x, y) if x + y == 6 => println!("Sum is 6"), (x, y) if x * y == 8 => println!("Product is 8"), _ => println!("No match"), } // Using external variables let threshold = 10; let value = 15; match value { x if x > threshold => println!("Above threshold"), x if x == threshold => println!("At threshold"), _ => println!("Below threshold"), } // Complex conditions struct Person { name: String, age: u32, has_license: bool, } let person = Person { name: "Bob".to_string(), age: 17, has_license: false, }; match person { Person { age, has_license, .. } if age >= 16 && has_license => { println!("Can drive"); } Person { age, .. } if age >= 16 => { println!("Old enough but no license"); } _ => println!("Can't drive"), } // Guards with enums enum Temperature { Celsius(f64), Fahrenheit(f64), } let temp = Temperature::Celsius(25.0); match temp { Temperature::Celsius(c) if c <= 0 => println!("Freezing"), Temperature::Celsius(c) if c >= 100 => println!("Boiling"), Temperature::Celsius(c) => println!("Normal temp: {}°C", c), Temperature::Fahrenheit(f) if f <= 32 => println!("Freezing"), Temperature::Fahrenheit(f) if f >= 212 => println!("Boiling"), Temperature::Fahrenheit(f) => println!("Normal temp: {}°F", f), } // Guards with multiple patterns let x = 4; let y = false; match x { 4 | 5 | 6 if y => println!("yes"), // Guard applies to all patterns _ => println!("no"), } // This is equivalent to (4 | 5 | 6) if y }

10. Advanced Concepts

Q21: Explain the difference between impl Trait and trait objects.

Answer: Static dispatch vs dynamic dispatch.

use std::fmt::Display; // impl Trait (static dispatch) fn returns_impl_trait() -> impl Display { // Can only return one concrete type format!("Hello, World!") } // Can't do this with impl Trait: // fn returns_conditional(flag: bool) -> impl Display { // if flag { // "String literal" // &str // } else { // 42 // i32 - Error: different types // } // } // Trait objects (dynamic dispatch) fn returns_trait_object(flag: bool) -> Box<dyn Display> { if flag { Box::new("String literal") } else { Box::new(42) } } // impl Trait as parameter fn print_impl_trait(item: impl Display) { println!("{}", item); } // Trait object as parameter fn print_trait_object(item: &dyn Display) { println!("{}", item); } // Where clauses with both fn process<T: Display>(items: Vec<T>) -> impl Iterator<Item = T> { items.into_iter().map(|x| { println!("Processing: {}", x); x }) } // Performance comparison fn dispatch_comparison() { use std::time::Instant; // Static dispatch (monomorphized) fn static_dispatch<T: Display>(x: T) -> String { format!("{}", x) } // Dynamic dispatch (virtual call) fn dynamic_dispatch(x: &dyn Display) -> String { format!("{}", x) } let values: Vec<Box<dyn Display>> = vec![ Box::new(1), Box::new(2.5), Box::new("three"), ]; // Static dispatch - different function for each type for v in &values { // Can't use static dispatch here with mixed types } // Dynamic dispatch - works with mixed types for v in &values { println!("{}", dynamic_dispatch(&**v)); } } // Vtable layout trait Animal { fn make_sound(&self) -> String; } struct Dog; impl Animal for Dog { fn make_sound(&self) -> String { "Woof!".to_string() } } struct Cat; impl Animal for Cat { fn make_sound(&self) -> String { "Meow!".to_string() } } fn main() { // impl Trait returns let s = returns_impl_trait(); println!("{}", s); // Trait object returns let obj = returns_trait_object(true); println!("{}", obj); let obj = returns_trait_object(false); println!("{}", obj); // Vec of trait objects let animals: Vec<Box<dyn Animal>> = vec![ Box::new(Dog), Box::new(Cat), Box::new(Dog), ]; for animal in animals { println!("{}", animal.make_sound()); } }

Key Differences:

  • impl Trait: Static dispatch, single concrete type, no runtime overhead
  • dyn Trait: Dynamic dispatch, multiple types, vtable overhead
  • impl Trait can only appear in function parameters and return positions
  • dyn Trait requires pointer indirection (Box, &, etc.)

Q22: What are associated types and when would you use them?

Answer: Associated types define placeholder types in traits.

// Associated type in Iterator trait trait Iterator { type Item; // Associated type fn next(&mut self) -> Option<Self::Item>; } // Implementation with associated type struct Counter { count: u32, } impl Iterator for Counter { type Item = u32; // Specify the type fn next(&mut self) -> Option<Self::Item> { self.count += 1; if self.count < 6 { Some(self.count) } else { None } } } // Generic vs Associated Type trait GenericContainer<T> { // Generic fn add(&mut self, item: T); fn get(&self, index: usize) -> Option<&T>; } trait AssocContainer { // Associated type type Item; fn add(&mut self, item: Self::Item); fn get(&self, index: usize) -> Option<&Self::Item>; } // Generic can be implemented multiple times struct MultiTypeContainer; impl GenericContainer<i32> for MultiTypeContainer { fn add(&mut self, item: i32) {} fn get(&self, index: usize) -> Option<&i32> { None } } impl GenericContainer<String> for MultiTypeContainer { fn add(&mut self, item: String) {} fn get(&self, index: usize) -> Option<&String> { None } } // Associated type can only be implemented once struct SingleTypeContainer; impl AssocContainer for SingleTypeContainer { type Item = i32; // Only one Item type per implementation fn add(&mut self, item: i32) {} fn get(&self, index: usize) -> Option<&i32> { None } } // Graph example trait Graph { type Node; type Edge; fn nodes(&self) -> Vec<Self::Node>; fn edges(&self, node: &Self::Node) -> Vec<Self::Edge>; fn connect(&mut self, from: Self::Node, to: Self::Node, edge: Self::Edge); } struct SimpleGraph { nodes: Vec<u32>, edges: Vec<(u32, u32, String)>, } impl Graph for SimpleGraph { type Node = u32; type Edge = String; fn nodes(&self) -> Vec<Self::Node> { self.nodes.clone() } fn edges(&self, node: &Self::Node) -> Vec<Self::Edge> { self.edges .iter() .filter(|(from, to, _)| from == node || to == node) .map(|(_, _, edge)| edge.clone()) .collect() } fn connect(&mut self, from: Self::Node, to: Self::Node, edge: Self::Edge) { self.edges.push((from, to, edge)); } } fn main() { let mut counter = Counter { count: 0 }; while let Some(n) = counter.next() { println!("{}", n); } // Graph usage let mut graph = SimpleGraph { nodes: vec![1, 2, 3], edges: vec![], }; graph.connect(1, 2, "edge1".to_string()); println!("Edges from 1: {:?}", graph.edges(&1)); }

Benefits of Associated Types:

  • Cleaner API (one type per trait)
  • Type relationships are clearer
  • Prevents multiple implementations for same type
  • Better for type inference

Q23: Explain the Deref trait and deref coercion.

Answer: Deref allows smart pointers to behave like references.

use std::ops::Deref; // Custom smart pointer struct MyBox<T>(T); impl<T> MyBox<T> { fn new(x: T) -> MyBox<T> { MyBox(x) } } // Implement Deref impl<T> Deref for MyBox<T> { type Target = T; fn deref(&self) -> &T { &self.0 } } // Deref coercion example fn hello(name: &str) { println!("Hello, {}!", name); } fn main() { // Basic dereferencing let x = 5; let y = MyBox::new(x); assert_eq!(5, x); assert_eq!(5, *y); // *(y.deref()) // Deref coercion let m = MyBox::new(String::from("Rust")); // &MyBox<String> -> &String (via Deref) -> &str (via String's Deref) hello(&m); // Works due to deref coercion // Without deref coercion, would need: hello(&(*m)[..]); // Multiple deref steps struct Person { name: String, } impl Deref for Person { type Target = String; fn deref(&self) -> &String { &self.name } } let person = Person { name: String::from("Alice"), }; // Person -> String -> str hello(&person); // Mutable deref use std::ops::DerefMut; impl<T> DerefMut for MyBox<T> { fn deref_mut(&mut self) -> &mut T { &mut self.0 } } let mut mybox = MyBox::new(String::from("hello")); *mybox = String::from("world"); // Method calls with deref coercion let s = MyBox::new(String::from("hello")); // len() comes from String, not MyBox println!("Length: {}", s.len()); // Equivalent to: println!("Length: {}", (*s).len()); } // Common Deref implementations fn common_derefs() { // Vec implements Deref to slice let v = vec![1, 2, 3, 4, 5]; let slice: &[i32] = &v; // Deref coercion // String implements Deref to str let s = String::from("hello"); let str_slice: &str = &s; // Deref coercion // Box implements Deref to its contents let b = Box::new(42); let int_ref: &i32 = &b; // Deref coercion }

Deref Coercion Rules:

  • Converts &T to &U when T: Deref<Target=U>
  • Happens automatically in function arguments
  • Works for method calls
  • Multiple deref steps allowed

Q24: What are closures and how do they capture variables?

Answer: Closures are anonymous functions that can capture variables from their environment.

fn main() { // Basic closure let add_one = |x: i32| -> i32 { x + 1 }; let add_one = |x| x + 1; // Type inference println!("{}", add_one(5)); // Capture by reference let x = vec![1, 2, 3]; let print_vec = || println!("{:?}", x); // Captures &x print_vec(); println!("Still have: {:?}", x); // x still usable // Capture by mutable reference let mut y = 5; let mut inc = || y += 1; // Captures &mut y inc(); println!("y = {}", y); // 6 // Capture by value (move) let z = String::from("hello"); let take = move || { // Moves z into closure println!("{}", z); }; take(); // println!("{}", z); // Error: z moved // Closure traits fn call_once<F>(f: F) where F: FnOnce() { f(); } fn call_mut<F>(mut f: F) where F: FnMut() { f(); f(); } fn call_fn<F>(f: F) where F: Fn() { f(); f(); } let mut count = 0; // FnOnce - can be called once let once = || { println!("Once"); // Can't capture mutably }; // FnMut - can mutate captured variables let mut mut_closure = || { count += 1; println!("Count: {}", count); }; // Fn - doesn't mutate captured variables let immut_closure = || { println!("Count: {}", count); }; call_once(once); call_mut(mut_closure); call_fn(immut_closure); // Closure as return value fn make_adder(x: i32) -> impl Fn(i32) -> i32 { move |y| x + y // Need move to capture x } let add_five = make_adder(5); println!("{}", add_five(3)); // 8 // Closure in collections let funcs: Vec<Box<dyn Fn(i32) -> i32>> = vec![ Box::new(|x| x * 2), Box::new(|x| x + 10), Box::new(|x| x * x), ]; for f in funcs { println!("{}", f(5)); } // Performance comparison fn bench_closures() { use std::time::Instant; let data: Vec<i32> = (0..1_000_000).collect(); // Closure let start = Instant::now(); let result: Vec<_> = data.iter().map(|&x| x * 2).collect(); println!("Closure: {:?}", start.elapsed()); // Function pointer fn double(x: &i32) -> i32 { x * 2 } let start = Instant::now(); let result: Vec<_> = data.iter().map(double).collect(); println!("Function pointer: {:?}", start.elapsed()); } }

Closure Capture Modes:

  • By reference (&T): Immutable borrow
  • By mutable reference (&mut T): Mutable borrow
  • By value (T): Takes ownership (with move keyword)

Q25: Explain the difference between Fn, FnMut, and FnOnce.

Answer: These traits define how closures capture and use variables.

fn main() { let mut data = vec![1, 2, 3]; let text = String::from("hello"); // FnOnce - consumes captured variables let consume = move || { println!("Consuming: {:?} and {}", data, text); // data and text moved here }; // Can only call once consume(); // consume(); // Error: moved // FnMut - can mutate captured variables let mut mutate = || { data.push(4); // data captured by &mut println!("Mutated: {:?}", data); }; // Can call multiple times mutate(); mutate(); // Fn - immutably borrows variables let borrow = || { println!("Borrowing: {:?} and {}", data, text); }; // Can call multiple times borrow(); borrow(); // Function that takes different closure types fn call_once<F>(f: F) where F: FnOnce() { f(); } fn call_mut<F>(mut f: F) where F: FnMut() { f(); f(); } fn call_fn<F>(f: F) where F: Fn() { f(); f(); } // FnOnce closure let s = String::from("once"); let once = move || println!("{}", s); call_once(once); // FnMut closure let mut count = 0; let mut mut_closure = || { count += 1; println!("Count: {}", count); }; call_mut(mut_closure); // Fn closure let x = 5; let fn_closure = || println!("x = {}", x); call_fn(fn_closure); // Real-world example: sort_by_key let mut people = vec![ ("Alice", 30), ("Bob", 25), ("Charlie", 35), ]; // Uses FnMut people.sort_by_key(|&(_, age)| age); println!("Sorted by age: {:?}", people); // Custom implementation fn custom_sort<T, F>(slice: &mut [T], mut key_fn: F) where F: FnMut(&T) -> i32, // FnMut can be called multiple times { // Simplified sorting for i in 0..slice.len() { for j in i+1..slice.len() { if key_fn(&slice[i]) > key_fn(&slice[j]) { slice.swap(i, j); } } } } let mut numbers = vec![5, 3, 1, 4, 2]; custom_sort(&mut numbers, |&x| x); println!("Sorted: {:?}", numbers); } // Implementing your own closure traits struct MyClosure { count: i32, } impl FnOnce<()> for MyClosure { type Output = i32; extern "rust-call" fn call_once(self, args: ()) -> i32 { self.count } } impl FnMut<()> for MyClosure { extern "rust-call" fn call_mut(&mut self, args: ()) -> i32 { self.count } } impl Fn<()> for MyClosure { extern "rust-call" fn call(&self, args: ()) -> i32 { self.count } }

Key Differences:

  • FnOnce: Can be called once, may consume captured values
  • FnMut: Can mutate captured state, can be called multiple times
  • Fn: Immutably borrows captured values, can be called multiple times

Interview Tips

Before the Interview:

  1. Review ownership rules - most important concept
  2. Practice writing code on paper or whiteboard
  3. Understand common patterns (Option, Result, iterators)
  4. Know the standard library (collections, concurrency primitives)

During the Interview:

  1. Explain your thought process while coding
  2. Discuss trade-offs between different approaches
  3. Mention error handling and edge cases
  4. Show understanding of performance implications

Common Mistakes to Avoid:

  • Forgetting semicolons in match arms
  • Not handling Option and Result properly
  • Confusing &str and String
  • Misunderstanding move semantics
  • Ignoring lifetime annotations when needed

Additional Resources:

Good luck with your Rust interview! Remember that understanding the concepts deeply is more important than memorizing syntax.

Category : RUST

Leave a Reply

Your email address will not be published. Required fields are marked *


Macro Nepal Helper