Concept questionMedium~7 minForms & Contracts / 1 of 4

Interview question

How would you implement validation for a full-stack form backed by an ASP.NET Core API and a React or Next.js UI?

Design form validation across UI and API

Explains how client-side validation, server-side validation, DTOs, domain rules, and user feedback work together.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would validate in both places, but with different responsibilities. The UI gives immediate feedback for required fields, formats, length, and simple cross-field rules. The API still validates the request DTO and domain rules because clients can be old, buggy, or malicious. The API returns a consistent validation error shape, and the UI maps field errors back onto the form while also showing a summary for non-field errors.

Full answer below

Practice focus

Client validation, API validation, DTO boundaries, domain invariants, error shape, accessibility, and user experience.

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
Form validation is one of the most common full-stack tasks because the same rule appears in the UI, API contract, and domain model. The design needs fast feedback without trusting the browser as the only guard.
I would validate in both places, but with different responsibilities. The UI gives immediate feedback for required fields, formats, length, and simple cross-field rules. The API still validates the request DTO and domain rules because clients can be old, buggy, or malicious. The API returns a consistent validation error shape, and the UI maps field errors back onto the form while also showing a summary for non-field errors.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid duplicating complex business rules blindly in the frontend. Rules that protect data integrity live on the server, while the frontend mirrors only the rules that improve usability. The contract needs stable field names, error codes, and messages that the UI can display or translate. I would also handle async validation, such as unique names, without blocking every keystroke or treating a stale client check as final.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make validation observable and accessible. Validation failures can reveal confusing UX, a breaking client contract, or abuse. I would track error codes, not raw sensitive field values. The UI needs focus management, aria relationships, keyboard behavior, and clear recovery. For compatibility, new server validation can be additive at first, and contract-breaking rule changes need frontend release coordination, API versioning, or feature flags. I would also add focused regression tests around rules that have broken before, especially required fields, enum changes, conditional fields, and API error mapping.

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

Trusting client-side validation as the final authority.
Returning inconsistent validation response shapes.
Duplicating every business rule in frontend code.
Showing only a generic error when field errors exist.

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

Details

Cannot explain server-side validation after client validation.
No stable error contract between API and UI.
Ignores accessibility for invalid fields.
Confuses DTO validation with all domain invariants.

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.

Which validation belongs only on the server?
How would you display nested field errors?
How would you roll out a new required field safely?

Continue the section

Next in Forms & Contracts: Validation Error Mapping

Step 2 of 4

Map API validation errors to the form UI

Opening drill

Concept questionMedium~7 minForms & Contracts / 1 of 4

Interview question

How would you implement validation for a full-stack form backed by an ASP.NET Core API and a React or Next.js UI?

Design form validation across UI and API

Explains how client-side validation, server-side validation, DTOs, domain rules, and user feedback work together.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Client validation, API validation, DTO boundaries, domain invariants, error shape, accessibility, and user experience.

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
Form validation is one of the most common full-stack tasks because the same rule appears in the UI, API contract, and domain model. The design needs fast feedback without trusting the browser as the only guard.
I would validate in both places, but with different responsibilities. The UI gives immediate feedback for required fields, formats, length, and simple cross-field rules. The API still validates the request DTO and domain rules because clients can be old, buggy, or malicious. The API returns a consistent validation error shape, and the UI maps field errors back onto the form while also showing a summary for non-field errors.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid duplicating complex business rules blindly in the frontend. Rules that protect data integrity live on the server, while the frontend mirrors only the rules that improve usability. The contract needs stable field names, error codes, and messages that the UI can display or translate. I would also handle async validation, such as unique names, without blocking every keystroke or treating a stale client check as final.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make validation observable and accessible. Validation failures can reveal confusing UX, a breaking client contract, or abuse. I would track error codes, not raw sensitive field values. The UI needs focus management, aria relationships, keyboard behavior, and clear recovery. For compatibility, new server validation can be additive at first, and contract-breaking rule changes need frontend release coordination, API versioning, or feature flags. I would also add focused regression tests around rules that have broken before, especially required fields, enum changes, conditional fields, and API error mapping.

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

Trusting client-side validation as the final authority.
Returning inconsistent validation response shapes.
Duplicating every business rule in frontend code.
Showing only a generic error when field errors exist.

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

Details

Cannot explain server-side validation after client validation.
No stable error contract between API and UI.
Ignores accessibility for invalid fields.
Confuses DTO validation with all domain invariants.

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.

Which validation belongs only on the server?
How would you display nested field errors?
How would you roll out a new required field safely?

Continue the section

Next in Forms & Contracts: Validation Error Mapping

Step 2 of 4

Map API validation errors to the form UI

How would you implement validation for a full-stack form backed by an ASP.NET Core API and a React or Next.js UI?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you implement validation for a full-stack form backed by an ASP.NET Core API and a React or Next.js UI?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section