Rust interview questions and worked answers

Question 1 of 9

What changes when a `String` moves into a function?

Passing a String by value moves ownership to the callee, so the caller cannot use that binding afterward. Copy types such as integers duplicate their bits instead. Borrow with &str or &String when the callee only needs temporary access.

A function that only counts characters should accept a string slice rather than consume a String. A function that stores or returns ownership may accept String. Choose from the operation's ownership need, not from a reflex to clone around a compiler error.

Clone is an explicit duplication operation. For String, it copies the string data, which may allocate. Deriving Copy is only appropriate for types whose values can be duplicated cheaply and without resource ownership semantics.

fn count(s: &str) -> usize { s.chars().count() }

let name = String::from("Ada");
let n = count(&name);
println!("{name}: {n}");

Read the source: The Rust Book: what is ownership? · The Rust Book: references and borrowing

↑ Back to questions

Question 2 of 9

Why can an immutable borrow block a later mutation?

References must not outlive the data they point to, and Rust prevents overlapping mutable access with other active references. End the read borrow before mutation, or redesign the operation so it does not need both access patterns at once.

A map lookup returns &Value, and the program then inserts into the same map. The reference may be invalidated by a mutation that reallocates or changes the map. Use the borrowed value to compute what you need, let the reference's last use end, then mutate.

Non-lexical lifetimes allow a borrow to end after its last use even before the enclosing block ends. This is a compile-time reasoning rule, not a runtime lock. Interior-mutability types such as RefCell move some checks to runtime and can panic on conflicting borrows.

let length = if let Some(value) = map.get("item") {
    value.len()
} else {
    0
};
map.insert("length", length.to_string());

Read the source: The Rust Book: references and borrowing · The Rust Book: interior mutability

↑ Back to questions

Question 3 of 9

What does a lifetime annotation promise?

A lifetime annotation describes relationships among borrowed inputs and outputs. It does not extend an object's storage duration or keep a value alive. The caller must still provide data that outlives every returned reference.

A parser returns a slice into its input, so the result cannot outlive that input. A parser that constructs new text should return an owned String; adding a named lifetime to the signature does not make a local buffer safe to return by reference.

Lifetime elision rules infer common relationships, but a named lifetime is useful when the relationship is not obvious. Avoid reading 'a as a fixed number of seconds: it is a compile-time region relationship chosen by the caller and compiler.

fn first_word<'a>(text: &'a str) -> &'a str {
    text.split_whitespace().next().unwrap_or("")
}

Read the source: The Rust Book: validating references with lifetimes · Rust Reference: lifetime elision

↑ Back to questions

Question 4 of 9

How do `Result`, `?`, and error types shape an API?

Return Result<T, E> for recoverable failure, use ? to propagate it, and choose an error type that preserves the distinctions callers must act on. Convert to presentation text at the application boundary rather than erasing error structure early.

A configuration loader may distinguish a missing file, malformed TOML, and an invalid application setting. A CLI can add the path and command context while retaining a source error. A library should avoid forcing callers to parse a formatted string to identify a condition.

? returns early after converting an error into the enclosing function's error type where a conversion exists. It does not log, retry, or recover. Avoid converting every error to a generic string if downstream code needs to make a different decision.

fn load(path: &Path) -> Result<Config, LoadError> {
    let text = std::fs::read_to_string(path)?;
    let config = toml::from_str(&text)?;
    validate(config)
}

Read the source: The Rust Book: error handling · Rust Reference: question-mark operator

↑ Back to questions

Question 5 of 9

What do Send and Sync promise at a thread boundary?

Send means ownership of a value may safely move to another thread. Sync means a shared reference may safely cross threads: T is Sync exactly when &T is Send. These are safety contracts, not promises about business invariants or throughput.

A trait bound describes behavior a generic function requires. For concurrency, the standard library uses marker traits with no methods to express which values may cross thread boundaries. A struct generally acquires these auto traits from its fields. Rc<T> deliberately lacks them because its reference count is not synchronized; changing a wrapper name does not change that ownership contract.

Arc<T> synchronizes its ownership count, but it does not make arbitrary interior mutation safe. Arc<RefCell<T>> cannot substitute for a properly synchronized shared mutable value. Use a suitable synchronization primitive or keep the value on one thread.

Implementing an unsafe trait manually is a proof obligation. Safe callers and other unsafe code may rely on that implementation. An incorrect unsafe impl Send or Sync can make safe-looking callers invoke undefined behavior. Prefer types whose fields allow correct automatic derivation; never add an unsafe implementation merely to silence a compiler error.

use std::rc::Rc;
use std::sync::Arc;

fn require_send<T: Send>() {}
fn require_sync<T: Sync>() {}

fn main() {
    require_send::<Arc<String>>();
    require_sync::<Arc<String>>();
    // require_send::<Rc<String>>(); // does not compile
}

Read the source: Rustonomicon: Send and Sync · Rust std Arc thread safety

↑ Back to questions

Question 6 of 9

When do you need `Arc<Mutex<T>>`, and what does it cost?

Use shared ownership only when multiple owners are part of the design. Arc shares ownership across threads; Mutex provides synchronized mutable access. Prefer single ownership and message passing when they express the relationship more directly.

A metrics registry may be shared by worker threads and updated under a mutex. Every lock adds coordination, and holding a guard across unrelated work can serialize requests or create deadlocks. Keep the critical section small and define a lock order if multiple locks are required.

Arc makes reference counting thread-safe, but it does not make the contained value safe to mutate by itself. Rc<RefCell<T>> is for single-threaded shared ownership with runtime borrow checks; it is not a thread-safe substitute. Reference cycles can keep Rc allocations alive.

let counts = Arc::new(Mutex::new(HashMap::<String, usize>::new()));
let worker_counts = Arc::clone(&counts);
std::thread::spawn(move || {
    let mut counts = worker_counts.lock().expect("counter lock poisoned");
    *counts.entry("ok".into()).or_default() += 1;
});

Read the source: The Rust Book: shared-state concurrency · The Rust Book: reference cycles

↑ Back to questions

Question 7 of 9

Does an `async fn` run as soon as it is called?

No. Calling an async function creates a future that describes work; the future progresses when it is polled by an executor, commonly through .await. Rust's async syntax does not select or provide the runtime that schedules I/O and tasks.

A service can accidentally construct a future and never await or spawn it, so the operation never runs. A Rust async runtime crate supplies the executor and often the I/O driver. Choose one runtime boundary for an application unless a concrete integration requires more.

At each .await, a future may yield so other tasks can progress. Blocking CPU work or a blocking system call on an executor thread can stall unrelated tasks. Move blocking work to an appropriate blocking pool or dedicated thread, and bound that pool.

async fn lookup() -> Result<Record, Error> {
    client.get_record().await
}

// The application runtime must await or spawn lookup().

Read the source: The Rust Book: futures and async syntax · Rust standard library: async keyword

↑ Back to questions

Question 8 of 9

What can the Rust type system not prove for you?

The compiler checks types, borrowing, and trait constraints, but it cannot prove that the program implements the intended business rule. Unit, integration, and documentation tests check those observable expectations.

A discount function can compile and still apply the wrong threshold. Test boundaries such as one cent below, at, and above the threshold. Unit tests can access private helpers in a module; integration tests exercise the public crate API from an external test target.

Use property tests or fuzzing where input space is large and invariants are clear, but keep a small set of readable examples for the business contract. Tests can also be wrong, so tie them to an independently stated expectation.

#[test]
fn discount_starts_at_threshold() {
    assert_eq!(discount_for(9_999), 0);
    assert_eq!(discount_for(10_000), 500);
}

Read the source: The Rust Book: writing automated tests · The Rust Book: test organization

↑ Back to questions

Question 9 of 9

How do you verify that a Rust optimization helped?

Use a representative benchmark and profiler, keep the toolchain and workload fixed, and compare repeated measurements. A successful compile says nothing about whether the change improved latency, throughput, allocation, or memory use.

An endpoint allocates many temporary strings. Benchmark the full transformation with realistic record sizes, profile to confirm allocation is material, then compare the changed version. If the request is dominated by network wait, a faster parser may not change observed latency.

Cargo profiles control optimization and debug information. Compare like with like, normally a release-style build for throughput. Avoid inferring speed from source-level operations or a single timing run affected by machine load.

cargo test --release
cargo bench --bench parse_records

Read the source: Cargo build profiles · Cargo bench command

↑ Back to questions

Keep exploring