Pinpointing validation errors in nested request data

WHAT THIS TESTS Whether the candidate builds APIs that give clients actionable, location-specific feedback for complex payloads, a hallmark of good developer experience.

A GOOD ANSWER COVERS Use a schema validation library that understands nested shapes and reports the path to each failing field. With Joi you define the array and object schema and call validate with abortEarly set to false so it gathers every error instead of stopping at the first; each error carries a path array like ['items', 2, 'price'] that you render as items[2].price. Zod similarly exposes error.issues with a path, and express-validator supports wildcards such as items.*.price. Map every failure into a consistent response shape, for example an array of objects with field, message, and optionally a code, and return HTTP 400 or 422. Consistency lets the frontend attach messages to the right input.

COMMON WRONG ANSWERS Returning a single generic message like Invalid input that tells the client nothing. Aborting on the first error so users fix issues one at a time. Leaking raw exceptions or stack traces. Using array indexes inconsistently so clients cannot map errors back to fields.

LIKELY FOLLOW-UPS How do you localize messages? How do you keep the error contract stable as the schema evolves? When is 400 versus 422 appropriate? How do you avoid revealing sensitive validation rules?

ONE CONCRETE EXAMPLE A body has items, an array of line items. The third item has a negative price and the first is missing a name. With abortEarly false, the validator returns both errors. The handler maps them to a 400 body like { errors: [{ field: 'items[0].name', message: 'Name is required' }, { field: 'items[2].price', message: 'Price must be positive' }] }, so the client highlights both offending fields at once.