Config Validator

Start from brute force

The obvious first draft walks the config: for each key, value in config.items(), look up spec[key], test the value with isinstance, and append any error. It is O(C) time for C config keys and O(E) space for E errors, so speed is not the issue; it is wrong in three ways. A required key that is absent never appears in the loop, so "missing: host" is never reported. A config key the spec does not mention raises KeyError on the lookup. And isinstance(True, int) is True in Python, because bool is a subclass of int, so {"n": true} slips through an int rule.

The approach

Drive the loop from the spec, because the spec is the only place that knows which keys must exist. Each key then goes through three checks in a fixed order, and the first failure stops it: presence, then type, then allowed values. That order is the invariant that gives each key at most one error: a missing key has no type to check, and a value of the wrong type cannot meaningfully be compared with an allowed list.

The reference solution loops over spec.items(). If key not in config, it appends "missing: " + key only when rule.get("required") is truthy, then continues. Otherwise it computes ok from the rule's type t; for "int" that is isinstance(value, int) and not isinstance(value, bool), which shuts booleans out. A failed ok appends "wrong type: " plus the key; a passing one checks value not in rule["allowed"] when the rule has that list. Every error is collected, and sorted(errors) makes the result independent of the spec's key order: the prefixes sort as missing, not allowed, wrong type, then by key.

Walk through an example

Trace the first example, where the spec's keys are visited in the order port, env, debug, host and the list is sorted only at the end.

Complexity

Optimal: O(S + A + E log E) time for S spec keys, A total entries across the allowed lists (each is scanned linearly) and E errors to sort; O(E) space for the error list. Brute force (walking the config) is O(C) time and O(E) space for C config keys, but it cannot see absent required keys.

Edge cases to test

• A present key whose value is null: {"host": null} against a required str rule → ["wrong type: host"], not "missing". The key is there; its value is the wrong type.
• Booleans and integers in both directions: {"n": true} against an int rule → ["wrong type: n"], and {"flag": 1} against a bool rule → ["wrong type: flag"].
• A whole-number float: in Python {"port": 8080.0} against an int rule → ["wrong type: port"], but the TypeScript reference returns [], because JavaScript has one number type and Number.isInteger(8080.0) is true.
• A spec key that names an Object.prototype property: with {"toString": {"type": "str", "required": true}} and an empty config, Python reports "missing: toString", while TypeScript’s key in config walks the prototype chain, finds a function and reports "wrong type: toString". Object.hasOwn(config, key) avoids that.
• Wrong type and outside the allowed list at once: {"env": 5} against {"type": "str", "allowed": ["dev"]} → only ["wrong type: env"]; the allowed check never runs.
• An empty spec accepts any config, and config keys the spec does not mention are ignored: validate_config({"x": 1}, {}) → [].

Common mistakes

• Failing on the first error instead of reporting all of them — that forces slow, one-at-a-time fixing.
• Letting a bad value crash three layers deep instead of validating at the boundary.
• Not distinguishing “missing key” from “wrong type”, so the message is not actionable.
• Checking isinstance(value, int) alone, which accepts True and False as integers.

Follow-ups an interviewer asks next

How would you validate nested configs?

Add an "object" type whose rule carries its own spec, and a "list" type with a rule for its items, then recurse. Pass the path down so messages stay actionable: "wrong type: db.port" or "missing: servers[2].host". The cost stays linear in the number of values checked, and sorting by path keeps the output stable.

How would you catch typos such as "prot" instead of "port"?

Right now an unknown key is silently ignored, so the typo passes; the real key is then reported missing if it is required, or quietly left at its default if it is not. After the spec loop, walk the config’s own keys and emit "unknown: KEY" for any the spec lacks. Python’s difflib.get_close_matches can suggest the nearest spec key in the message.

What changes when the config comes from environment variables?

Everything arrives as a string, so "8080" fails an int rule. Parse before you type-check: int(value) for integers, and an explicit set such as {"true", "1", "yes"} for booleans. Never use bool(value), because bool("false") is True for any non-empty string.

Would you write this by hand in production?

Usually not. JSON Schema has validators in most languages, and Pydantic in Python or Zod in TypeScript cover nesting, defaults, coercion and custom messages, and they report every error at once rather than the first. The design rules are the same ones this exercise teaches: validate at the boundary, check presence before type before value, and collect everything.

Where this shows up

Half of “it doesn’t work at the customer” is a bad config — a missing key, a string where an int belongs, an env that isn’t allowed. Validating up front and failing with a clear list beats a cryptic crash deep in the stack, which is why this is a core forward-deployed and integrations skill: turn config errors into actionable messages at the edge.

Reference solution

def validate_config(config, spec):
    errors = []
    for key, rule in spec.items():
        if key not in config:
            if rule.get("required"):
                errors.append("missing: " + key)
            continue
        value = config[key]
        t = rule["type"]
        ok = (
            (t == "int" and isinstance(value, int) and not isinstance(value, bool))
            or (t == "str" and isinstance(value, str))
            or (t == "bool" and isinstance(value, bool))
        )
        if not ok:
            errors.append("wrong type: " + key)
        elif "allowed" in rule and value not in rule["allowed"]:
            errors.append("not allowed: " + key)
    return sorted(errors)


print(validate_config(
    {"port": 8080, "env": "x", "debug": "yes"},
    {"port": {"type": "int", "required": True},
     "env": {"type": "str", "allowed": ["dev", "prod"]},
     "debug": {"type": "bool"},
     "host": {"type": "str", "required": True}}))
# -> ['missing: host', 'not allowed: env', 'wrong type: debug']

function validateConfig(config: any, spec: any): string[] {
  const errors: string[] = [];
  for (const [key, rule] of Object.entries<any>(spec)) {
    if (!(key in config)) {
      if (rule.required) errors.push("missing: " + key);
      continue;
    }
    const value = config[key];
    const t = rule.type;
    const ok =
      (t === "int" && Number.isInteger(value) && typeof value === "number") ||
      (t === "str" && typeof value === "string") ||
      (t === "bool" && typeof value === "boolean");
    if (!ok) errors.push("wrong type: " + key);
    else if (rule.allowed && !rule.allowed.includes(value)) errors.push("not allowed: " + key);
  }
  return errors.sort();
}

console.log(JSON.stringify(validateConfig(
  { port: 8080, env: "x", debug: "yes" },
  { port: { type: "int", required: true },
    env: { type: "str", allowed: ["dev", "prod"] },
    debug: { type: "bool" },
    host: { type: "str", required: true } })));
// -> ["missing: host","not allowed: env","wrong type: debug"]