Explain Rust's Ownership and its three compiler-enforced rules

WHAT THIS TESTS: Whether you understand that Rust avoids both garbage collection and manual memory management by enforcing ownership rules at compile time. The interviewer wants to see that you know the three rules by heart and can connect them to real behavior like moving, borrowing, and dropping. They also care whether you grasp why this matters for performance and concurrency.

A GOOD ANSWER COVERS: First, state the three rules clearly: every value has an owner; there can only be one owner at a time; and when the owner goes out of scope the value is dropped automatically. Second, explain that the compiler checks these rules statically so there is zero runtime overhead for memory safety. Third, connect the rules to the stack and heap: fixed-size data lives on the stack while dynamic data like String lives on the heap and is accessed through a pointer stored on the stack. Fourth, introduce moving ownership when assigning or passing values, borrowing via immutable and mutable references, and the role of the borrow checker. Fifth, note that types implementing Copy are exempt from move semantics and remain usable after assignment.

COMMON WRONG ANSWERS: Saying Rust uses a garbage collector or that the programmer must manually call free. Describing ownership as just a smart pointer or reference counting scheme. Claiming that ownership checks happen at runtime rather than compile time. Forgetting that borrowing lets you access data without taking ownership. Confusing a move with a shallow copy and missing that the original variable becomes invalid.

LIKELY FOLLOW-UPS: How does ownership enable fearless concurrency through Send and Sync. What happens when you assign one String to another and why does the original become invalid. How do mutable and immutable borrows differ and why can you not have both at the same time. When would you use clone versus a reference. How does the Copy trait change ownership behavior for primitives. What is a lifetime and how does it relate to borrowing.

ONE CONCRETE EXAMPLE: Imagine a main function that creates a String and passes it to a helper function. If you pass the String by value ownership moves into the helper, the original variable is no longer valid, and when the helper scope ends the String is dropped. If you try to print the original afterward the compiler rejects the code with a borrow checker error. If you pass a reference instead the function borrows the String, the original stays valid, and the compiler guarantees the reference never outlives the owner.