Concept questionMedium~7 min

Interview question

You are adding a new product feature. How would you define the request and response contract between the UI and API?

Define the request and response contract for a feature

Explains how to design DTOs, response shapes, UI needs, API compatibility, and frontend/backend ownership for a feature.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would start from the user workflow and define explicit request and response DTOs for that workflow. The request includes only fields the user is allowed to set, not internal entity fields. The response includes the data the page needs after the action, such as id, display values, status, permissions, and timestamps. I would document validation errors and normal failure cases so the UI can handle them predictably.

Full answer below

Practice focus

DTO design, UI data needs, compatibility, overposting protection, frontend ownership, API ownership, and contract evolution.

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 full-stack feature often succeeds or fails at the contract boundary. The UI needs enough data to render cleanly, while the API needs controlled inputs and stable behavior.
I would start from the user workflow and define explicit request and response DTOs for that workflow. The request includes only fields the user is allowed to set, not internal entity fields. The response includes the data the page needs after the action, such as id, display values, status, permissions, and timestamps. I would document validation errors and normal failure cases so the UI can handle them predictably.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid returning database entities directly or making the frontend assemble important business state from scattered endpoints. If the screen needs a read model, the API can return a shape designed for that view. For updates, I would separate create and update contracts when rules differ. Optional fields, defaults, and enum values need compatibility thinking so older clients do not break when the backend evolves.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would use OpenAPI, typed client generation, or contract tests where they reduce drift. The contract needs a versioning story for breaking changes and a deprecation path for fields that the UI no longer uses. I would add correlation ids and error codes for support. For security, the API ignores client-supplied authority fields such as owner id, role, status, price, or audit values unless that workflow explicitly permits them. I would also review payload size and screen performance, because a contract that is technically correct can still make the page slow or hard to evolve.

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 EF entities as request and response models.
Letting the UI submit fields it is not allowed to control.
Forcing the frontend to infer workflow state from unrelated calls.
No documented error shape for the contract.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain DTO boundaries.
Ignores overposting and authority fields.
No compatibility plan for contract changes.
Treats UI and API ownership as the same layer.

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 belongs in the response after create?
How would you evolve an enum used by the frontend?
When would you create a screen-specific read model?

Continue practice

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

2 linked

Go deeper

Practice the next layer of the same subject.

Request DTOs OpenAPI Contract

Opening drill

Concept questionMedium~7 min

Interview question

You are adding a new product feature. How would you define the request and response contract between the UI and API?

Define the request and response contract for a feature

Explains how to design DTOs, response shapes, UI needs, API compatibility, and frontend/backend ownership for a feature.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

DTO design, UI data needs, compatibility, overposting protection, frontend ownership, API ownership, and contract evolution.

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 full-stack feature often succeeds or fails at the contract boundary. The UI needs enough data to render cleanly, while the API needs controlled inputs and stable behavior.
I would start from the user workflow and define explicit request and response DTOs for that workflow. The request includes only fields the user is allowed to set, not internal entity fields. The response includes the data the page needs after the action, such as id, display values, status, permissions, and timestamps. I would document validation errors and normal failure cases so the UI can handle them predictably.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid returning database entities directly or making the frontend assemble important business state from scattered endpoints. If the screen needs a read model, the API can return a shape designed for that view. For updates, I would separate create and update contracts when rules differ. Optional fields, defaults, and enum values need compatibility thinking so older clients do not break when the backend evolves.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would use OpenAPI, typed client generation, or contract tests where they reduce drift. The contract needs a versioning story for breaking changes and a deprecation path for fields that the UI no longer uses. I would add correlation ids and error codes for support. For security, the API ignores client-supplied authority fields such as owner id, role, status, price, or audit values unless that workflow explicitly permits them. I would also review payload size and screen performance, because a contract that is technically correct can still make the page slow or hard to evolve.

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 EF entities as request and response models.
Letting the UI submit fields it is not allowed to control.
Forcing the frontend to infer workflow state from unrelated calls.
No documented error shape for the contract.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain DTO boundaries.
Ignores overposting and authority fields.
No compatibility plan for contract changes.
Treats UI and API ownership as the same layer.

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 belongs in the response after create?
How would you evolve an enum used by the frontend?
When would you create a screen-specific read model?

Continue practice

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

2 linked

Go deeper

Practice the next layer of the same subject.

Request DTOs OpenAPI Contract

You are adding a new product feature. How would you define the request and response contract between the UI and API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

You are adding a new product feature. How would you define the request and response contract between the UI and API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper