Architecture scenarioHard~12 minC# OOP & Type Design Essentials / 15 of 15

Interview question

What does tell, don't ask mean in object-oriented design, and when can applying it too aggressively make code worse?

Tell, don't ask and practical object collaboration

Moves invariant-sensitive decisions toward the owning object while keeping orchestration, queries, and cross-boundary work appropriately explicit.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Tell, don't ask means asking the object that owns a rule to perform the decision instead of extracting its state and deciding elsewhere. Instead of reading Order.Status, Items, and Total in several services to decide whether cancellation is allowed, I call order.Cancel(reason). The Order checks its state and records a valid transition. The application service still coordinates loading, authorization, persistence, and notifications. The principle moves the decision, not the entire use case, into the entity.

Full answer below

Practice focus

Behavioral APIs, feature envy, invariants, orchestration, query models, command-query separation, and pragmatic collaboration.

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
Tell, don't ask means asking an object to perform a meaningful operation instead of pulling out its state and making its decision elsewhere. It is most valuable when the object owns an invariant that callers could otherwise duplicate or bypass.
Tell, don't ask means asking the object that owns a rule to perform the decision instead of extracting its state and deciding elsewhere. Instead of reading Order.Status, Items, and Total in several services to decide whether cancellation is allowed, I call order.Cancel(reason). The Order checks its state and records a valid transition. The application service still coordinates loading, authorization, persistence, and notifications. The principle moves the decision, not the entire use case, into the entity.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Applying it mechanically can create chatty objects or hide simple read logic behind commands. Reporting and UI queries should project the data they need rather than sending behavior messages to hundreds of objects. Cross-aggregate decisions may belong in a policy or application service because no single object owns all required state. I use the principle to reduce feature envy and duplicated rules, not to ban getters.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I keep command behavior deterministic where practical and make side effects explicit at the application boundary. Domain methods return outcomes or record events rather than sending email or opening transactions themselves. Concurrency still needs database support because two valid in-memory decisions can race. I watch for services that repeatedly inspect another object's internals and for entities that became opaque procedural wrappers. The balanced design lets owners protect rules while read paths remain efficient and orchestration remains visible.

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

Interpreting the principle as never exposing data.
Moving database and HTTP calls into entities.
Using behavior objects for large reporting queries.
Forcing one entity to own cross-aggregate workflows.

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

Details

Several services duplicate the same state checks.
Domain methods trigger hidden external side effects.
Read paths materialize large object graphs unnecessarily.
Entities only wrap service calls without protecting rules.

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.

Is a getter always a design smell?
Where should cross-aggregate rules live?
How should a domain method report failure?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Place domain logic

Opening drill

Architecture scenarioHard~12 minC# OOP & Type Design Essentials / 15 of 15

Interview question

What does tell, don't ask mean in object-oriented design, and when can applying it too aggressively make code worse?

Tell, don't ask and practical object collaboration

Moves invariant-sensitive decisions toward the owning object while keeping orchestration, queries, and cross-boundary work appropriately explicit.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Behavioral APIs, feature envy, invariants, orchestration, query models, command-query separation, and pragmatic collaboration.

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
Tell, don't ask means asking an object to perform a meaningful operation instead of pulling out its state and making its decision elsewhere. It is most valuable when the object owns an invariant that callers could otherwise duplicate or bypass.
Tell, don't ask means asking the object that owns a rule to perform the decision instead of extracting its state and deciding elsewhere. Instead of reading Order.Status, Items, and Total in several services to decide whether cancellation is allowed, I call order.Cancel(reason). The Order checks its state and records a valid transition. The application service still coordinates loading, authorization, persistence, and notifications. The principle moves the decision, not the entire use case, into the entity.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Applying it mechanically can create chatty objects or hide simple read logic behind commands. Reporting and UI queries should project the data they need rather than sending behavior messages to hundreds of objects. Cross-aggregate decisions may belong in a policy or application service because no single object owns all required state. I use the principle to reduce feature envy and duplicated rules, not to ban getters.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I keep command behavior deterministic where practical and make side effects explicit at the application boundary. Domain methods return outcomes or record events rather than sending email or opening transactions themselves. Concurrency still needs database support because two valid in-memory decisions can race. I watch for services that repeatedly inspect another object's internals and for entities that became opaque procedural wrappers. The balanced design lets owners protect rules while read paths remain efficient and orchestration remains visible.

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

Interpreting the principle as never exposing data.
Moving database and HTTP calls into entities.
Using behavior objects for large reporting queries.
Forcing one entity to own cross-aggregate workflows.

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

Details

Several services duplicate the same state checks.
Domain methods trigger hidden external side effects.
Read paths materialize large object graphs unnecessarily.
Entities only wrap service calls without protecting rules.

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.

Is a getter always a design smell?
Where should cross-aggregate rules live?
How should a domain method report failure?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Place domain logic

What does tell, don't ask mean in object-oriented design, and when can applying it too aggressively make code worse?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

What does tell, don't ask mean in object-oriented design, and when can applying it too aggressively make code worse?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper