Debugging scenarioMedium~10 minC# and .NET / 3 of 12

Interview question

A method calls a mutating member on a struct returned from a property, but the expected state does not change. What could be happening?

Why mutable structs and defensive copies are surprising

Diagnoses lost struct mutations and explains how readonly access can trigger defensive copies.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A struct is a value, so reading it from a property normally returns a copy. Mutating that copy does not update the struct stored inside the owning object. Readonly fields and in parameters can also cause the compiler to make a defensive copy before calling a member that might mutate the receiver. I would first identify which storage location owns the real value, then avoid mutating a temporary copy. The clearest fix is often to make the struct readonly and return a new value for each change.

Full answer below

Practice focus

Struct copy semantics, property returns, readonly receivers, defensive copies, readonly struct design, and API predictability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A struct can look like a small object while silently being copied at assignments, returns, and readonly boundaries. Mutation against the wrong copy is a correctness bug that can be difficult to see in review.
A struct is a value, so reading it from a property normally returns a copy. Mutating that copy does not update the struct stored inside the owning object. Readonly fields and in parameters can also cause the compiler to make a defensive copy before calling a member that might mutate the receiver. I would first identify which storage location owns the real value, then avoid mutating a temporary copy. The clearest fix is often to make the struct readonly and return a new value for each change.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, if order.Total returns a mutable Money struct, calling a mutating method on the returned value may only change a temporary. An explicit read-modify-write can work: copy the value, create or mutate the new value, then assign it back through a setter. A better value-object design is readonly record struct Money with methods such as Add returning a new Money. That aligns the API with value semantics and makes copies harmless rather than surprising. It also gives callers one obvious new value to assign, compare, or pass onward.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would reserve mutable structs for tightly controlled performance-sensitive code where their storage and copy behavior are obvious. I would inspect generated code or benchmark when a large struct crosses hot method boundaries, because defensive copies can turn an attempted optimization into more work. Marking the type and instance members readonly helps the compiler avoid unnecessary copies and documents intent. I would not convert a domain class to a struct merely to remove allocations; identity, default values, boxing through interfaces, collection behavior, and copy cost all matter. I test property access and readonly call sites, not only mutation on a local variable.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling a mutating method on a struct value returned by a property and expecting stored state to change.
Making a struct mutable because its members resemble a class API.
Using a large struct widely without measuring copy cost.
Assuming in always prevents every copy regardless of member declarations.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Cannot identify the storage location that owns the struct value.
Fixes the symptom by adding setters everywhere without reconsidering value-object design.
Treats readonly as only an API style choice with no copy implications.
Uses mutable structs through interfaces without discussing boxing and mutation of copies.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why can a readonly receiver cause a defensive copy?
How would a readonly record struct change this design?
When is a class a better choice than a struct?

Continue the section

Next in C# and .NET: Boxing and structs

Step 4 of 12

Boxing, unboxing, and interface calls on structs

Opening drill

Debugging scenarioMedium~10 minC# and .NET / 3 of 12

Interview question

A method calls a mutating member on a struct returned from a property, but the expected state does not change. What could be happening?

Why mutable structs and defensive copies are surprising

Diagnoses lost struct mutations and explains how readonly access can trigger defensive copies.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Struct copy semantics, property returns, readonly receivers, defensive copies, readonly struct design, and API predictability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A struct can look like a small object while silently being copied at assignments, returns, and readonly boundaries. Mutation against the wrong copy is a correctness bug that can be difficult to see in review.
A struct is a value, so reading it from a property normally returns a copy. Mutating that copy does not update the struct stored inside the owning object. Readonly fields and in parameters can also cause the compiler to make a defensive copy before calling a member that might mutate the receiver. I would first identify which storage location owns the real value, then avoid mutating a temporary copy. The clearest fix is often to make the struct readonly and return a new value for each change.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, if order.Total returns a mutable Money struct, calling a mutating method on the returned value may only change a temporary. An explicit read-modify-write can work: copy the value, create or mutate the new value, then assign it back through a setter. A better value-object design is readonly record struct Money with methods such as Add returning a new Money. That aligns the API with value semantics and makes copies harmless rather than surprising. It also gives callers one obvious new value to assign, compare, or pass onward.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would reserve mutable structs for tightly controlled performance-sensitive code where their storage and copy behavior are obvious. I would inspect generated code or benchmark when a large struct crosses hot method boundaries, because defensive copies can turn an attempted optimization into more work. Marking the type and instance members readonly helps the compiler avoid unnecessary copies and documents intent. I would not convert a domain class to a struct merely to remove allocations; identity, default values, boxing through interfaces, collection behavior, and copy cost all matter. I test property access and readonly call sites, not only mutation on a local variable.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling a mutating method on a struct value returned by a property and expecting stored state to change.
Making a struct mutable because its members resemble a class API.
Using a large struct widely without measuring copy cost.
Assuming in always prevents every copy regardless of member declarations.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Cannot identify the storage location that owns the struct value.
Fixes the symptom by adding setters everywhere without reconsidering value-object design.
Treats readonly as only an API style choice with no copy implications.
Uses mutable structs through interfaces without discussing boxing and mutation of copies.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why can a readonly receiver cause a defensive copy?
How would a readonly record struct change this design?
When is a class a better choice than a struct?

Continue the section

Next in C# and .NET: Boxing and structs

Step 4 of 12

Boxing, unboxing, and interface calls on structs

A method calls a mutating member on a struct returned from a property, but the expected state does not change. What could be happening?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A method calls a mutating member on a struct returned from a property, but the expected state does not change. What could be happening?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section