What is the difference between let and var in Swift?

WHAT THIS TESTS: At the senior level, this question screens for depth beyond syntax. The interviewer wants to see if you understand the interaction between declaration keywords and Swift's value-versus-reference semantics, if you can reason about the mutability surface area of an API, and if you default to safety and clarity rather than mutability out of habit.

A GOOD ANSWER COVERS: First, define the core distinction: let creates an immutable binding, meaning the symbol cannot be reassigned, while var creates a mutable binding that can be reassigned. Second, immediately qualify this with type semantics: for value types such as structs and enums, let makes the entire value immutable because the variable is the instance; for reference types such as classes, let only freezes the reference, so the pointer cannot change but the object's properties can still be mutated unless they are themselves declared with let. Third, explain why the community and compiler prefer let by default: it makes intent explicit to future readers, it shrinks the mutable state that must be reasoned about during debugging or concurrency, and it allows the compiler to make stronger assumptions about memory and optimization. Fourth, connect this to thread safety: immutable bindings eliminate an entire class of data races on the symbol itself, though you still need additional synchronization if the referenced instance is shared and mutable.

COMMON WRONG ANSWERS: A major red flag is stating that let makes a class instance completely immutable; this confuses the reference with the instance. Another weak pattern is saying the choice is purely stylistic or that var is fine because you can always change it later; senior engineers should treat unnecessary mutability as technical debt. Finally, do not claim that let improves performance dramatically in every case; the benefit is primarily about reasoning and safety, with optimization as a secondary bonus.

LIKELY FOLLOW-UPS: An interviewer might ask how let interacts with collection types like arrays and dictionaries, which are structs, so a let array cannot have elements appended. They might also ask about class instances stored in a let property and how to make those truly immutable, leading to discussion of private setters or value-type wrappers. A third follow-up could be how this principle scales to protocol-oriented design, where mutating methods are explicitly marked.

ONE CONCRETE EXAMPLE: Imagine a view model struct declared with let viewModel = UserViewModel(name: "Ada"). Because UserViewModel is a struct, the entire value is immutable; calling a mutating method or reassigning viewModel.name will fail at compile time. If instead the view model were a class, let viewModel = UserViewModel(name: "Ada") would still allow viewModel.name = "Grace" because only the reference is frozen. A senior candidate should highlight this difference unprompted and argue that making the view model a struct combined with let is what creates the true immutability guarantee.