Comparison questionMedium~7 minC# OOP & Type Design Essentials / 13 of 15

Interview question

When would you model something as a record, a normal class, or a record struct in C#?

Choose between records, classes, and record structs

Chooses a type shape from identity, value semantics, mutation, copy cost, default values, and serialization boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I use a normal class for an object with identity and a lifecycle, where two instances can hold the same data but still represent different entities. I use a record class for value-oriented reference data when equality by components and non-destructive with updates are useful. I consider a record struct for a small value that benefits from value-type storage and copy semantics. I usually make value-oriented types immutable so their equality and hash behavior remain stable.

Full answer below

Practice focus

Identity and value semantics, generated equality, immutability, with expressions, shallow copies, struct copy cost, default values, and domain modeling.

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
The syntax is less important than the meaning of equality and change. A type representing an entity has different semantics from a value that can be replaced by another equal value.
I use a normal class for an object with identity and a lifecycle, where two instances can hold the same data but still represent different entities. I use a record class for value-oriented reference data when equality by components and non-destructive with updates are useful. I consider a record struct for a small value that benefits from value-type storage and copy semantics. I usually make value-oriented types immutable so their equality and hash behavior remain stable.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
An Order entity is normally a class identified by OrderId; two orders are not equal merely because their current fields match. An Address or Money value can be a record when its components define equality. A small readonly record struct Percentage(decimal Value) can work when default value, validation, and frequent copying are acceptable. A with expression performs a shallow copy, so referenced mutable members are still shared unless the model prevents that mutation.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Records do not automatically create a valid domain model: generated equality includes selected state, constructors still need invariants, and record inheritance has runtime-type equality rules that may surprise a hierarchy. Structs always have a default zeroed value, so I avoid a record struct when that default cannot represent a valid or safely detectable state. Large structs increase copy cost and can box through object or interface boundaries. In production I check serializer and ORM behavior, because tools may bypass constructors or expect mutable members. I choose the simplest type whose equality, ownership, and update semantics remain correct across collections, persistence, and API contracts.

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

Using records for database entities only to get shorter property syntax.
Assuming with performs a deep copy of referenced members.
Choosing a record struct when its default value is invalid and hard to detect.
Including mutable identity fields in generated value equality and dictionary keys.

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

Details

Cannot state whether the modeled concept has identity or value equality.
Treats every record as immutable regardless of its declared properties.
Uses a large struct without considering copies, boxing, or call boundaries.
Lets persistence tooling define domain semantics accidentally.

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.

What does a with expression copy?
Why can the default value make a struct awkward for domain modeling?
How does record inheritance affect equality?

Continue the section

Next in C# OOP & Type Design Essentials: Equality and hash codes

Step 14 of 15

Equality, GetHashCode, records, and dictionary keys

Opening drill

Comparison questionMedium~7 minC# OOP & Type Design Essentials / 13 of 15

Interview question

When would you model something as a record, a normal class, or a record struct in C#?

Choose between records, classes, and record structs

Chooses a type shape from identity, value semantics, mutation, copy cost, default values, and serialization boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Identity and value semantics, generated equality, immutability, with expressions, shallow copies, struct copy cost, default values, and domain modeling.

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
The syntax is less important than the meaning of equality and change. A type representing an entity has different semantics from a value that can be replaced by another equal value.
I use a normal class for an object with identity and a lifecycle, where two instances can hold the same data but still represent different entities. I use a record class for value-oriented reference data when equality by components and non-destructive with updates are useful. I consider a record struct for a small value that benefits from value-type storage and copy semantics. I usually make value-oriented types immutable so their equality and hash behavior remain stable.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
An Order entity is normally a class identified by OrderId; two orders are not equal merely because their current fields match. An Address or Money value can be a record when its components define equality. A small readonly record struct Percentage(decimal Value) can work when default value, validation, and frequent copying are acceptable. A with expression performs a shallow copy, so referenced mutable members are still shared unless the model prevents that mutation.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Records do not automatically create a valid domain model: generated equality includes selected state, constructors still need invariants, and record inheritance has runtime-type equality rules that may surprise a hierarchy. Structs always have a default zeroed value, so I avoid a record struct when that default cannot represent a valid or safely detectable state. Large structs increase copy cost and can box through object or interface boundaries. In production I check serializer and ORM behavior, because tools may bypass constructors or expect mutable members. I choose the simplest type whose equality, ownership, and update semantics remain correct across collections, persistence, and API contracts.

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

Using records for database entities only to get shorter property syntax.
Assuming with performs a deep copy of referenced members.
Choosing a record struct when its default value is invalid and hard to detect.
Including mutable identity fields in generated value equality and dictionary keys.

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

Details

Cannot state whether the modeled concept has identity or value equality.
Treats every record as immutable regardless of its declared properties.
Uses a large struct without considering copies, boxing, or call boundaries.
Lets persistence tooling define domain semantics accidentally.

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.

What does a with expression copy?
Why can the default value make a struct awkward for domain modeling?
How does record inheritance affect equality?

Continue the section

Next in C# OOP & Type Design Essentials: Equality and hash codes

Step 14 of 15

Equality, GetHashCode, records, and dictionary keys

When would you model something as a record, a normal class, or a record struct in C#?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

When would you model something as a record, a normal class, or a record struct in C#?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section