I use a form validation problem as a technical interview question. It's deceptively simple — and the solutions people reach for reveal a lot about how they think.
Then I tried it on Claude, ChatGPT, and Gemini. The results were illuminating, but not for the reasons I expected.
Many form libraries share a common convention: form data is represented as a plain nested object, and the validation function returns an object of the same shape containing the errors. You'll find this pattern in Formik and React Final Form in React, and — full disclosure — in Inglorious Web, my own framework, which ships form handling built in without any extra dependencies.
const values = {
productName: 'VR Visor',
quantity: 1,
homeAddress: { street: 'Long St', zip: '00666' },
shippingAddress: { street: 'Short St', zip: '00777', co: 'Inglorious Coderz' },
billingAddress: { street: 'Wide Plaza', zip: '00888', vat: '1142042' },
}
The validation function should return an object containing all errors found. A starting example:
function validate(values) {
const errors = {}
if (!values.productName) {
errors.productName = 'required'
}
return errors
}
The ask: extend this to validate every field.
Notice that the three address types aren't identical. shippingAddress
requires a co
field. billingAddress
requires a vat
. These differences matter — and how you handle them reveals a lot.
The most common approach I see in interviews is a single validateAddress
function with a type
parameter:
function validateAddress(values = {}, type) {
const errors = {}
if (!values.street) errors.street = 'required'
if (!values.zip) errors.zip = 'required'
if (type === 'shipping' && !values.co) errors.co = 'required'
if (type === 'billing' && !values.vat) errors.vat = 'required'
return errors
}
It works. But every new address type, every new special rule, becomes another branch inside the same function. The differences between types are hidden rather than expressed.
The cleverest answer I ever received in an interview was this:
function validate(values) {
function validateNode(values = {}) {
const errors = {}
for (const [key, value] of Object.entries(values)) {
if (value && typeof value === 'object' && !Array.isArray(value)) {
const nestedErrors = validateNode(value)
if (Object.keys(nestedErrors).length) {
errors[key] = nestedErrors
}
} else if (!value) {
errors[key] = 'required'
}
}
return errors
}
return validateNode(values)
}
No schema, no flags — just a recursive walk of the data shape itself. Elegant, clever, a bit too complex for my taste maybe, but genuinely impressive.
But it has a silent flaw: it only validates fields that are present in values
. If billingAddress
arrives without a vat
key entirely, the error is never registered. The function doesn't know what it doesn't see.
To be clear: the problem here isn't recursion itself. It's that the implementation has no source of truth about what fields are expected. A recursive validator can work perfectly — if it's driven by something that knows the shape of the domain.
Interestingly, this was also the first instinct of all three AIs — Claude, ChatGPT, and Gemini independently reached for this same structure. When I pointed out the missing-key problem, they all reached for the same fix.
Once the missing-key flaw is on the table, the natural repair is to drive the iteration from a schema rather than from the data:
const schema = {
productName: true,
quantity: true,
homeAddress: { street: true, zip: true },
shippingAddress: { street: true, zip: true, co: true },
billingAddress: { street: true, zip: true, vat: true },
}
function validate(values) {
function validateNode(schema, values = {}) {
const errors = {}
for (const [key, rule] of Object.entries(schema)) {
const value = values[key]
if (rule === true) {
if (!value) errors[key] = 'required'
} else {
const nestedErrors = validateNode(rule, value)
if (Object.keys(nestedErrors).length) {
errors[key] = nestedErrors
}
}
}
return errors
}
return validateNode(schema, values)
}
This is technically sound. It handles missing keys, it scales, it's data-driven. All three AIs converged on this pattern independently — and honestly, it's not wrong. If address types were configured at runtime via metadata rather than hardcoded in the codebase, this approach would be the right one. When variability lives in data, a data-driven solution wins.
But here, the schema is just a mirror of the data shape, with true
where values should be. It's a solution to a problem — missing keys — that the composition approach never has in the first place.
function validate(values) {
const errors = {}
if (!values.productName) errors.productName = 'required'
if (!values.quantity) errors.quantity = 'required'
errors.homeAddress = validateAddress(values.homeAddress)
errors.shippingAddress = validateShippingAddress(values.shippingAddress)
errors.billingAddress = validateBillingAddress(values.billingAddress)
return errors
}
function validateAddress(values = {}) {
const errors = {}
if (!values.street) errors.street = 'required'
if (!values.zip) errors.zip = 'required'
return errors
}
function validateShippingAddress(values = {}) {
const errors = validateAddress(values)
if (!values.co) errors.co = 'required'
return errors
}
function validateBillingAddress(values = {}) {
const errors = validateAddress(values)
if (!values.vat) errors.vat = 'required'
return errors
}
No schema. No recursion. No flags. Each address type is its own function, and the shared logic is composed in.
The missing-key problem doesn't exist here — validateBillingAddress
always checks for vat
, regardless of what arrives. But the reason isn't just simplicity: it's that validateBillingAddress
exists because a billing address is a distinct business concept, not because it saves lines of code. The structure of the code reflects the structure of the domain.
When a new address type appears, you introduce a new validator rather than extending a growing set of conditional rules. Modification doesn't disappear — it becomes localized.
The flag, the recursion, and the schema all share the same instinct: find the common pattern and centralize the logic. It's what we're taught. It's what most production code looks like. It's a sound instinct — and sometimes the right one.
The composition approach asks a different question first: where does the variability actually live? If address types are stable domain concepts that belong in code, then composition wins — each type gets its own function, and differences are expressed rather than parameterized. If address types are dynamic, configurable, and driven by external data, then the schema wins.
The problem with the flag, the recursion, and the schema is not that they're wrong — it's that they all assume the answer to that question without asking it.
What's striking is that the cleverest human in the room and three AI models all converged on the same solution independently. In hindsight, this isn't surprising. Programming education spends years teaching us to eliminate duplication and generalize patterns. Large language models are trained on the output of that culture, so they inherit many of the same instincts. This isn't a story about what AI can't do — it's a reflection on what software engineering culture taught both AI and us to reach for by default.
AI can write the composition solution. It just rarely chooses to.
The simplest solution isn't the one that requires the least typing. It's the one that most honestly reflects what the domain is actually telling you.
Next time you find yourself reaching for a flag or a schema, ask: is this variability in my code, or in my data?
The answer changes everything.