Domain knowledge fundamentals

Fewer expensive misunderstandings, and a shorter distance between a business sentence and a correct implementation. Two engineers of equal technical ability will produce different systems in a specialist industry, because one of them asks what happens when the claim reopens and the other discovers it in month nine. The purchase is really insurance against a class of defect that testing does not catch, since a system can be entirely free of bugs and still encode the wrong rule — and that failure surfaces as an audit finding, a regulatory breach or a reconciliation that has been wrong for a quarter. The secondary thing being bought is credibility with the business, because a stakeholder who has to explain their own domain three times stops explaining and starts specifying solutions instead, which is where the interesting engineering judgement is lost.

Because it is discovered late and by someone outside engineering. A technical mistake is caught by a compiler, a test or a monitor within hours, and the feedback names the defect. A domain mistake produces a system that runs perfectly while being wrong, so the loop closes when a regulator, an auditor or a customer notices — typically after the wrong behaviour has been applied to months of real transactions. The remediation is then not a fix but a fix plus a data correction plus an explanation to someone who is entitled to an answer. The multiplier is the accumulated data: a misread retention rule means every record written since the release is now non-compliant, and no deploy repairs that. This asymmetry is the whole reason domain fluency reads as a seniority signal rather than as trivia.

The argument for domain investment is unconvincing in the abstract and obvious once the same defect is costed against a technical one.

Two defects, both shipped in the same release.

TECHNICAL DEFECT
  Cause      an unbounded query on the orders table
  Found by   latency alert, 40 minutes after deploy
  Blast      p99 checkout latency, one afternoon
  Fix        one index, one hotfix deploy
  Total      ~4 engineer-hours, no external exposure

DOMAIN DEFECT
  Cause      "cancelled" was implemented as a terminal state, because
             nobody said a cancellation can be rescinded within 14 days
  Found by   an operations analyst, 11 weeks later, when a customer
             asked why their reinstated policy had no cover
  Blast      2,300 policies cancelled and manually reinstated by
             creating NEW policies with new numbers and new start dates
  Consequences
             - cover gap of 1-6 days on 2,300 policies, some with
               claims in the gap
             - premium recalculated wrongly for all of them
             - regulatory reporting overstated new business by 2,300
             - the audit trail now says the customer bought twice
  Fix        model change, backfill, 2 claims reviewed by legal, a
             report correction, and an explanation to the regulator
  Total      ~14 engineer-weeks plus legal and compliance time

The arithmetic is not the point; the shape is. The technical defect was bounded by the time it took to notice, and noticing was automatic. The domain defect had no detector at all, because the system was behaving exactly as specified and every monitor was green.

The second thing to read from the ledger is that the remediation is mostly not engineering. Once wrong behaviour has been applied to real records, the cost is in reconstructing what should have happened, explaining it to people with authority, and repairing data that other systems have already consumed. A model change is the cheapest line in the block.

Notice where the requirement was: a single sentence nobody said out loud, because to the underwriting team a rescinded cancellation is Tuesday. That is the recurring pattern — the missing knowledge was not obscure to anyone who does the job, it was simply never worth writing down.

The line worth taking from this into an interview is that domain knowledge is a defect-prevention investment with a measurable counterfactual, not a cultural nicety. It buys you the question that would have been asked in week one.

Which of the documented rules are dead letters, which undocumented practice the business depends on, and what actually happens on the exception path. Documents describe the intended process at the moment someone had time to write it down. An expert can tell you that the approval step in the procedure has not been used since 2019, that two named customers have contractual terms overriding the standard rule, that the month-end figure is corrected by hand before it is published, and why. They can also tell you the frequency of each exception, which is the number that decides whether you automate it, tolerate it or refuse it — and frequency is almost never documented anywhere. The most valuable thing they hold is the reason behind a rule, because a rule you can only state is memorised, while a rule whose boundary you can find is understood well enough to design against.

No, and claiming it is the fastest way to be caught out. Tenure inside an industry produces domain knowledge only where the work forced you to ask why; otherwise it produces familiarity with one employer's workarounds. Engineers spend years inside a payments organisation building a notification service and never learn what happens after authorisation, because nothing in their week required it. The honest formulation in an interview is to name the surface you actually saw and the depth you reached: I owned the dispute case lifecycle and can talk about scheme deadlines and evidence retention, I never worked on settlement and would need to read. That answer is stronger than a vague claim to the whole industry, because the interviewer's next question will find the edge of your knowledge anyway and the only variable is whether you found it first.

When the domain is the product, and when depth would narrow you faster than it pays. A team building a database engine, a compiler or a developer tool has its hard problems in the technology, and time spent on an industry vertical returns little. The second case is a career one and worth stating honestly: deep expertise in one vertical, often in one jurisdiction, narrows your market to a small pool and decays when the rules change. Eight years in one country's pensions administration is highly employable inside that pool and awkward outside it. The protections are a portable craft alongside the domain, or a second domain acquired early enough that you own an acquisition method rather than one deep well — and the method is the transferable asset, since the second industry takes months where the first took years.