Rust Developer interview questions

A variable binding cannot be assigned a new value unless it is declared with mut.

• let count = 1 creates an immutable binding, so count = 2 is rejected.
• let mut count = 1 allows later assignment while keeping the value's type unchanged.
• Immutability by default makes intended state changes explicit and easier to reason about.

Shadowing creates a new binding with the same name, while mut permits changing the value of one existing binding.

• A new let can change the value's type because it introduces a distinct variable.
• A mutable assignment must keep the type established when the binding was declared.
• Shadowing is useful for staged transformations when the old value is no longer needed.

Rust's scalar types are integers, floating-point numbers, booleans, and characters.

• Integer types include signed i8 through i128 and isize, plus unsigned u8 through u128 and usize.
• Floating-point values use f32 or f64, and bool contains true or false.
• char is a four-byte Unicode scalar value, not a single UTF-8 byte.

usize is the natural type for memory sizes and collection indices because its width matches the target platform's pointer width.

• Slice and array indexing expects usize.
• A fixed-width type such as u32 is preferable for a file format or protocol that requires exactly 32 bits.
• Conversions between integer types should be explicit because a value may not fit the destination type.

A tuple stores a fixed number of values that may have different types, while an array stores a fixed number of values of one type.

• Tuple elements are accessed by constant positions such as value.0 or through destructuring.
• An array type includes both element type and length, such as [u8; 16].
• Arrays are stack-allocated values and can be borrowed as slices for APIs that accept varying lengths.

A statement performs an action without producing a usable value, while an expression evaluates to a value.

• Function calls, match blocks, if blocks, and ordinary blocks can all be expressions.
• The final expression of a block becomes that block's value when it has no trailing semicolon.
• Adding a semicolon usually turns an expression into a statement whose value is the unit type ().

Ownership lets Rust manage memory and prevent invalid access without requiring a garbage collector.

• Every value has an owner that determines when the value is dropped.
• Assignments and function calls can transfer ownership, so the old binding may no longer be usable.
• Borrowing provides temporary access without transferring ownership.

Each value has one owner, there can be only one owner at a time, and the value is dropped when its owner leaves scope.

• Ownership can move from one binding to another for non-Copy values.
• A reference borrows a value and does not become its owner.
• The compiler enforces these rules before the program runs.

Assigning a String normally moves its ownership to the new binding.

• String owns heap data, so copying only its stack metadata into two owners would risk a double free.
• After the move, the original binding cannot be used unless ownership is returned.
• Calling clone creates an independent String when both values are genuinely needed.

Passing an argument follows the same ownership rules as assignment: non-Copy values move, while Copy values are copied.

• A function that takes String by value owns it and may drop it before returning.
• Taking &str or &String borrows the data instead of consuming the caller's value.
• Returning the value can transfer ownership back, but borrowing is usually clearer when consumption is unnecessary.

Copy means assignment and argument passing duplicate a value implicitly instead of moving it.

• Simple scalar types and tuples containing only Copy values commonly implement Copy.
• A type that implements Drop cannot also implement Copy because implicit duplication would conflict with unique cleanup.
• Copy is intended for cheap bitwise duplication and must be explicitly implemented or derived for user-defined types.

Clone performs an explicit duplication through the clone method, while Copy allows implicit duplication on assignment and argument passing.

• Clone may allocate memory or run custom logic, as it does when duplicating a String's buffer.
• Every Copy type must also implement Clone, but many Clone types are not Copy.
• Calling clone should express a real need for another owned value rather than silence an ownership error automatically.

A value is dropped when its owner leaves scope, unless ownership was moved elsewhere first.

• Rust calls the Drop implementation and then releases the value's owned resources.
• Local variables are generally dropped in reverse order of their creation.
• The std::mem::drop function can end ownership explicitly before the surrounding scope ends.

Borrowing gives temporary access to a value through a reference without transferring ownership.

• A shared reference has type &T and permits reading the borrowed value.
• A mutable reference has type &mut T and permits changing the borrowed value.
• The owner remains responsible for dropping the value after all borrows end.

At a given time, Rust permits either any number of shared references or one mutable reference to the same value.

• Shared references allow concurrent reading but not mutation through those references.
• An exclusive mutable reference prevents other references from observing a value during mutation.
• These rules prevent data races and invalidated references at compile time.

Mutation through &mut T is permitted because the reference grants exclusive mutable access to its target.

• The original value must be declared mut before code can take a mutable reference to it.
• Rebinding a variable that stores a mutable reference is separate from mutating the referenced value.
• Function parameters written as value: &mut T can mutate T without taking ownership of it.

Rust rejects a reference that could outlive the value it points to because using it would access invalid memory.

• A local value is dropped when its owner leaves scope.
• Returning a reference to that local value would leave the caller pointing to released storage.
• Returning an owned value transfers valid ownership to the caller and is the usual solution.

A lifetime is the region of code for which a reference is valid.

• The compiler compares lifetimes to ensure a borrowed value outlives every use of its reference.
• Most lifetimes are inferred and require no written annotation.
• A lifetime annotation describes relationships between references but does not make any value live longer.

An annotation is needed when the compiler must know which input borrow the returned reference is tied to.

• A signature like fn longest<'a>(x: &'a str, y: &'a str) -> &'a str states that the result is valid for their shared usable lifetime.
• The annotation does not require both arguments to have identical concrete lifetimes.
• It prevents the returned reference from being used longer than either possible source allows.

The lifetime parameter records that an instance of the struct cannot outlive the data referenced by one of its fields.

• A field such as text: &'a str ties the field's validity to 'a.
• The compiler then prevents the struct from remaining in use after text's source is dropped.
• Owning a String instead removes that borrowing relationship but changes allocation and ownership semantics.