A value type holds its data directly, while a reference type holds a reference to an object on the heap. Assigning a value type copies the whole value, and assigning a reference type copies only the reference.
Changing one copy of a value type leaves the other copy alone. Two reference-type variables can point at the same object, so a change made through one shows up through the other.
Value types include int, bool and char. Every struct and enum is a value type too.
Reference types include any class and string. Arrays and delegates are reference types too.
Value types default to zero, false or null in every field. Reference types default to null.
A local value-type variable usually sits on the stack, but a value-type field lives inside its containing object, on the heap.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
If a method reassigns a class parameter to a new object, does the caller see it? What if it changes a field instead?Field changes show to the caller. Reassigning the parameter does not, because the method got a copy of the reference. Only ref changes that.
What is boxing, and why should you care about it?Casting a value type to object or an interface copies it into a new heap object, and unboxing copies it back. Name the allocation cost in hot loops.
When would you pick a struct over a class?Small, immutable data that acts like a single value, such as a point or an amount. Note that a large struct costs more to copy on every assignment.
string is a reference type. So why does changing one string variable leave another one alone?Strings are immutable, so every change builds a new string and points the variable at it. The other variable still sees the old object.
Do value types always live on the stack? Where else can they end up?No. Fields of a class, array elements, boxed values and captured locals sit on the heap. Placement is a runtime detail, not the definition.
What you can say
A value type holds its data directly, while a reference type holds a reference to an object that lives on the heap.
So assigning a value type copies the whole value, and changing one copy leaves the other copy alone.
Assigning a reference type copies only the reference, so two variables can point at the same object, and a change made through one shows up through the other.
Value types include int, bool, char and every struct and enum, and reference types include any class, string, arrays and delegates.
Their defaults differ too, since a value type starts with every field at zero, false or null, and a reference-type variable starts as null.
I'd treat the stack rule as a rule of thumb, because a local value type usually sits on the stack, but a value-type field lives inside its containing object on the heap.
Weak answers to avoid
Says value types always live on the stackThat's wrong for fields inside a class, array elements and boxed values. Lead with what assignment copies, and treat stack versus heap as the usual case only.
Calls string a value typestring is a reference type. It only behaves like a value because it is immutable, so say that instead of guessing from how assignment looks.
Confuses reference types with passing by refPassing a class to a method still copies the reference. Reassigning the parameter doesn't touch the caller's variable unless the parameter is marked ref.
Lists types but never explains copyingNaming int and class shows recall, not understanding. Say what assignment copies and describe the shared-object effect, since that is what causes real bugs.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
