Interview questions: traits, errors, pointers and concurrency

Q1. Generics versus trait objects?

Model answer: "Generics use static dispatch: the compiler makes a specialised copy for each type (monomorphization), so calls are fast and can be inlined, but binaries grow. Trait objects (dyn Trait behind a pointer) use dynamic dispatch through a vtable: one copy of the code, a small cost per call, and they allow mixing types in one collection or choosing the type at run time."

Q2. Option versus Result? When do you panic?

Model answer: "Option means a value may be absent; Result means an operation may fail and carries an error. I return Result for expected failures like bad input or I/O, and use ? to propagate errors. I panic only for bugs or impossible states, and in tests or prototypes. Libraries should rarely panic."

Q3. What does ? do exactly?

Model answer: "On Ok or Some it unwraps the value. On Err it converts the error with From::from and returns it from the current function; on None it returns None. It only works in functions whose return type can carry that early return."

Q4. Box, Rc, Arc, RefCell, Mutex: when each?

Q5. What are Send and Sync?

Model answer: "Send means a value can be moved to another thread; Sync means a shared reference to it can be used from several threads. They are auto traits: the compiler derives them from a type's fields. Rc is neither, because its counter is not atomic; Arc<Mutex<T>> is both when T is Send."

Q6. Does Rust prevent deadlocks?

Model answer: "No. Safe Rust prevents data races, but deadlocks and logic bugs are still possible. I avoid them by keeping lock scopes short, never awaiting or calling unknown code while holding a lock, and taking multiple locks in a consistent order."

Q7. Threads or async?

Model answer: "Async suits many I/O-bound tasks, such as thousands of network connections, on a runtime like tokio with few threads. Threads suit CPU-bound work. Futures are lazy and need a runtime; blocking calls inside async code stall the runtime, so heavy work goes to spawn_blocking or a thread pool."

Q8. Quick-fire snippets

let v = vec![1, 2, 3];
let w = v;
println!("{}", v.len());          // does not compile: v was moved (E0382)

let x: Option<u32> = None;
println!("{}", x.unwrap_or(7));   // prints 7

let s = String::from("hi");
let t = &s;
let u = &s;
println!("{t}{u}");               // prints hihi: two shared borrows are fine

A take-home assignment checklist

• Clear README: how to build, run and test; design decisions.
• cargo fmt, cargo clippy with no warnings, and passing tests.
• Errors handled with Result and good messages; no unwrap on user input.
• Small modules with clear names; logic in lib.rs.
• A few meaningful tests, including edge cases.

Common mistakes

• Saying RefCell makes code thread-safe. It does not; use Mutex or RwLock across threads.
• Claiming async is always faster. It is better for waiting, not for computing.
• Using unwrap everywhere in a take-home assignment. Reviewers notice immediately.