Concept questionHard~9 minProduct Features / 15 of 19

Interview question

Two users edit the same record. How would your full-stack feature avoid silently losing changes?

Handle stale form data and concurrency conflicts

Explains stale edit detection, row versioning, conflict UI, refresh behavior, and safe update contracts.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would include a concurrency token, such as a row version or updated-at value, when the form loads. The update request sends that token back. If the database row changed since the user loaded it, the API returns a conflict response instead of overwriting the newer change. The UI explains that the record changed, shows the latest data, and lets the user reload, compare, or reapply their edits depending on the domain.

Full answer below

Practice focus

Optimistic concurrency, version tokens, update DTOs, conflict responses, merge UX, and user recovery.

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
Stale forms are where frontend convenience and backend correctness meet. The system needs to protect data without giving users a mysterious failure.
I would include a concurrency token, such as a row version or updated-at value, when the form loads. The update request sends that token back. If the database row changed since the user loaded it, the API returns a conflict response instead of overwriting the newer change. The UI explains that the record changed, shows the latest data, and lets the user reload, compare, or reapply their edits depending on the domain.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would make the conflict response useful. It can include current server values, changed fields, and the user's submitted values where safe. For simple records, reload-and-retry may be enough. For longer forms, field-level merge UI or draft preservation can save work. Partial updates help, but they do not remove the need for concurrency checks when fields interact or when business rules depend on the whole record.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would track conflict rates because frequent conflicts can mean the workflow needs locking, assignment, drafts, or better collaboration design. Some resources need pessimistic locking or a checkout model, but that adds stale locks and support work. I would ensure audit history records both successful changes and rejected stale attempts where useful. API clients need clear status codes and error shapes so the UI never treats a concurrency conflict as a generic failure. I would test the same conflict through the API and UI so the backend protects the record and the frontend gives a clear recovery path.

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 last-write-wins without noticing data loss.
No concurrency token in the edit contract.
Discarding the user's submitted values after a conflict.
Showing a generic error for a recoverable conflict.

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

Details

Cannot explain optimistic concurrency.
No user recovery path after conflict.
Partial update is treated as a complete conflict solution.
No monitoring of frequent conflicts on important records.

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 would the conflict response contain?
When would you use pessimistic locking?
How would you preserve user edits after conflict?

Continue the section

Next in Product Features: Flagged Feature Release

Step 16 of 19

Release a full-stack feature behind a feature flag

Opening drill

Concept questionHard~9 minProduct Features / 15 of 19

Interview question

Two users edit the same record. How would your full-stack feature avoid silently losing changes?

Handle stale form data and concurrency conflicts

Explains stale edit detection, row versioning, conflict UI, refresh behavior, and safe update contracts.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Optimistic concurrency, version tokens, update DTOs, conflict responses, merge UX, and user recovery.

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
Stale forms are where frontend convenience and backend correctness meet. The system needs to protect data without giving users a mysterious failure.
I would include a concurrency token, such as a row version or updated-at value, when the form loads. The update request sends that token back. If the database row changed since the user loaded it, the API returns a conflict response instead of overwriting the newer change. The UI explains that the record changed, shows the latest data, and lets the user reload, compare, or reapply their edits depending on the domain.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would make the conflict response useful. It can include current server values, changed fields, and the user's submitted values where safe. For simple records, reload-and-retry may be enough. For longer forms, field-level merge UI or draft preservation can save work. Partial updates help, but they do not remove the need for concurrency checks when fields interact or when business rules depend on the whole record.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would track conflict rates because frequent conflicts can mean the workflow needs locking, assignment, drafts, or better collaboration design. Some resources need pessimistic locking or a checkout model, but that adds stale locks and support work. I would ensure audit history records both successful changes and rejected stale attempts where useful. API clients need clear status codes and error shapes so the UI never treats a concurrency conflict as a generic failure. I would test the same conflict through the API and UI so the backend protects the record and the frontend gives a clear recovery path.

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 last-write-wins without noticing data loss.
No concurrency token in the edit contract.
Discarding the user's submitted values after a conflict.
Showing a generic error for a recoverable conflict.

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

Details

Cannot explain optimistic concurrency.
No user recovery path after conflict.
Partial update is treated as a complete conflict solution.
No monitoring of frequent conflicts on important records.

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 would the conflict response contain?
When would you use pessimistic locking?
How would you preserve user edits after conflict?

Continue the section

Next in Product Features: Flagged Feature Release

Step 16 of 19

Release a full-stack feature behind a feature flag

Two users edit the same record. How would your full-stack feature avoid silently losing changes?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Two users edit the same record. How would your full-stack feature avoid silently losing changes?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section