Concept questionMedium~7 minApplication Architecture Essentials / 3 of 15

Interview question

An interface has file-system, cloud-storage, and read-only implementations. What must remain true for callers to substitute them safely?

Liskov substitution and behavioral contracts

Explains substitutability through inputs, outputs, side effects, and failure behavior rather than inheritance syntax alone.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Each implementation must honor the interface's documented behavior: accepted inputs, returned results, failure cases, and important side effects. A subtype should not require stronger preconditions or provide weaker guarantees than the abstraction promises. If read-only storage cannot support WriteAsync, throwing NotSupportedException may show that the interface combines capabilities that should be modeled separately.

Full answer below

Practice focus

Behavioral contracts, preconditions, postconditions, exceptions, side effects, capability modeling, and misleading inheritance.

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
Polymorphism is safe only when implementations preserve the contract callers rely on. Matching method signatures is not enough if one implementation rejects normal inputs or changes the meaning of success.
Each implementation must honor the interface's documented behavior: accepted inputs, returned results, failure cases, and important side effects. A subtype should not require stronger preconditions or provide weaker guarantees than the abstraction promises. If read-only storage cannot support WriteAsync, throwing NotSupportedException may show that the interface combines capabilities that should be modeled separately.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would split contracts such as IBlobReader and IBlobWriter when consumers need different capabilities. The cloud implementation may have eventual consistency or transient failures that the file implementation does not. Those semantics must either fit the shared contract or be exposed deliberately. Tests should be written against the contract and run for every implementation, covering missing objects, overwrite rules, cancellation, and error translation rather than only happy-path return values.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would include operational behavior in the contract where callers depend on it. Idempotency, concurrency, ordering, durability, and retry safety can make two syntactically compatible implementations observably different. I avoid promising stronger semantics than every implementation can provide; sometimes separate ports or an explicit capability result is more honest. When replacing an implementation, I compare telemetry and failure modes behind a controlled rollout. Substitution is successful when callers need no provider-specific branches and the system still preserves its business invariants under failure.

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

Treating matching signatures as a complete contract.
Using NotSupportedException for a normal advertised operation.
Hiding materially different consistency guarantees.
Testing implementations separately without shared contract tests.

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

Details

Callers check concrete implementation types.
One provider requires undocumented input restrictions.
Retrying one implementation duplicates writes.
Provider exceptions leak through the application boundary.

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.

When should an interface be split by capability?
Can different consistency models share one contract?
What belongs in a contract test suite?

Continue the section

Next in Application Architecture Essentials: Interface segregation

Step 4 of 15

Interface segregation at application boundaries

Opening drill

Concept questionMedium~7 minApplication Architecture Essentials / 3 of 15

Interview question

An interface has file-system, cloud-storage, and read-only implementations. What must remain true for callers to substitute them safely?

Liskov substitution and behavioral contracts

Explains substitutability through inputs, outputs, side effects, and failure behavior rather than inheritance syntax alone.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Behavioral contracts, preconditions, postconditions, exceptions, side effects, capability modeling, and misleading inheritance.

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
Polymorphism is safe only when implementations preserve the contract callers rely on. Matching method signatures is not enough if one implementation rejects normal inputs or changes the meaning of success.
Each implementation must honor the interface's documented behavior: accepted inputs, returned results, failure cases, and important side effects. A subtype should not require stronger preconditions or provide weaker guarantees than the abstraction promises. If read-only storage cannot support WriteAsync, throwing NotSupportedException may show that the interface combines capabilities that should be modeled separately.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would split contracts such as IBlobReader and IBlobWriter when consumers need different capabilities. The cloud implementation may have eventual consistency or transient failures that the file implementation does not. Those semantics must either fit the shared contract or be exposed deliberately. Tests should be written against the contract and run for every implementation, covering missing objects, overwrite rules, cancellation, and error translation rather than only happy-path return values.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would include operational behavior in the contract where callers depend on it. Idempotency, concurrency, ordering, durability, and retry safety can make two syntactically compatible implementations observably different. I avoid promising stronger semantics than every implementation can provide; sometimes separate ports or an explicit capability result is more honest. When replacing an implementation, I compare telemetry and failure modes behind a controlled rollout. Substitution is successful when callers need no provider-specific branches and the system still preserves its business invariants under failure.

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

Treating matching signatures as a complete contract.
Using NotSupportedException for a normal advertised operation.
Hiding materially different consistency guarantees.
Testing implementations separately without shared contract tests.

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

Details

Callers check concrete implementation types.
One provider requires undocumented input restrictions.
Retrying one implementation duplicates writes.
Provider exceptions leak through the application boundary.

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.

When should an interface be split by capability?
Can different consistency models share one contract?
What belongs in a contract test suite?

Continue the section

Next in Application Architecture Essentials: Interface segregation

Step 4 of 15

Interface segregation at application boundaries

An interface has file-system, cloud-storage, and read-only implementations. What must remain true for callers to substitute them safely?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

An interface has file-system, cloud-storage, and read-only implementations. What must remain true for callers to substitute them safely?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section