skip to content

What decides whether encoding your requirement as instances of another problem is a sound long-term bet rather than writing a direct algorithm?

level: principalimportance: should knowfreq 36%

answer

  1. the translator is what you own
  2. fidelity outlives the first release
  3. requirements that will not encode
  4. who debugs a wrong answer
  5. test the equivalence, not the output

basics

~10 s

Whether the equivalence you claim stays stateable and testable as requirements move. A translator is an owned asset: its value is inherited engine maturity, its risk is a mapping nobody can still justify.

solid answer

~40 s

The bet is not engine versus algorithm; it is **the mapping** versus **the algorithm**, because the mapping is the part your team owns forever. It pays off when the requirement has a stable core that encodes naturally into the target problem, when you can state the yes/no equivalence in one sentence and test it against a slow checker, and when the constraints that arrive later are expressible in the same encoding. It goes bad when each new rule needs a cleverer gadget, when nobody left can explain why a no-instance still maps to no, or when the requirement drifts from a decision into a nuanced objective the target cannot carry. A direct algorithm forfeits the engine's maturity but keeps the domain rules where people can read them.

go deeper

for a junior

Notice that reusing a general engine is a genuine option, and that the translation between your domain and that engine's input is itself code somebody has to maintain.

for a middle

Articulate what the translator must guarantee — the same answer in both directions — and why that guarantee is harder to review than ordinary behaviour.

for a senior

Argue the operational side: how a wrong answer is traced through an encoding, how the no-direction is tested, and where the growth of the map sets the capacity ceiling.

for a principal

Own the long horizon. Price the second and third requirement change, insist on one source of truth for domain rules, and keep a reference path that keeps the equivalence honest after the author leaves.

## What you are actually choosing between Both options end with code your team maintains. The choice is what *kind* of code: - **The translator**: a map from your domain into another problem's instances, plus a decoder back. You inherit an engine that has absorbed far more effort than you could spend, and you own an encoding whose correctness is an equivalence rather than a behaviour. - **The direct algorithm**: logic expressed in domain terms. You forfeit the inherited maturity and own every correctness and performance property yourself, but the rules live where a domain expert can read them. The usual framing — "reuse beats rewriting" — hides the asset that decides the outcome. The engine is not yours; the **mapping** is, and it is where the long-term cost sits. ## What makes the mapping cheap to keep correct 1. **A statable equivalence.** You can say, in one sentence, what a yes in the target means in the domain. If nobody can say it without the original author present, the encoding is already a liability. 2. **A testable equivalence.** Real requests, including a maintained corpus of ones with no valid answer, checked against a slow and obviously correct domain checker. This tests the translation, not the engine. 3. **Headroom in the encoding.** New constraints land as more of what the target already expresses, rather than as a new gadget family. That is the single best predictor of how the next two years go. 4. **A decoder tested with the encoder.** The reduction guarantees the verdict; the arrangement you hand back is your own construction and drifts independently unless the two are one unit. ## Signals the bet is going wrong - Each new rule requires a cleverer construction, and review of it takes longer every time. - Nobody can explain why an instance with no valid answer still maps to an unsolvable target instance — the no-direction has become folklore. - The requirement has moved from "is there an arrangement" to "give me the best arrangement under a nuanced objective", so the decision form no longer answers the real question and the engine is being called in a loop around a threshold. - Instance growth is in a dimension the business keeps increasing, so the map's exponent, harmless at launch, now sets the capacity ceiling. - Incidents cannot be traced: a wrong answer requires reading the produced instance to understand, and that instance is machine-shaped. ## The comparison, stated plainly | Dimension | Translate onto an engine | Write a direct algorithm | |---|---|---| | Where the hard work lives | the engine, inherited | your code, owned | | Correctness argument | an equivalence, harder to review | behaviour, testable in domain terms | | New constraint arrives | may need a new gadget family | usually a new branch | | Ceiling | the map's growth times the engine's cost | whatever you can design | | Debuggability | through the encoding, indirect | direct | ## How a lead should decide Do not decide on the prototype's benchmark; decide on the **second** requirement change. Write down the two or three rules most likely to arrive next and encode them on paper. If they land inside the existing encoding, the bet is sound and the maturity you inherit is real. If even one of them needs a new construction whose soundness you would have to argue from scratch, price that in, because it will recur. Two hedges are worth their cost. Keep the domain rules expressed once, in domain terms, and generate the encoding from them, so the mapping has a single source of truth rather than a second, divergent copy of the requirements. And keep a slow reference path — an exhaustive or brute-force decision for small inputs — permanently in the test suite, because it is the only thing that keeps the equivalence honest once its author has moved on. Finally, be explicit that this is the *reuse* direction. It bounds your problem's difficulty from above and buys an implementation; it is not evidence that the requirement is hard, and it should never be presented to stakeholders as if it were.

  • Which single question would you ask before committing to the translator?
    What are the next two or three constraints likely to arrive, and do they encode inside the mapping we already have? If even one needs a new construction whose soundness must be argued from scratch, that cost recurs, and it usually dominates whatever the prototype benchmark showed.
  • A new rule cannot be expressed in the target problem's encoding. What are the options?
    Extend the encoding and re-establish the equivalence, including the no-direction; enforce the rule outside the engine by filtering or post-checking returned arrangements; or accept that the mapping has reached its limit and move that part of the decision into domain code.
  • What keeps a translation honest after its author leaves?
    A permanently maintained slow reference path — an exhaustive decision for small inputs — plus a corpus of requests with no valid answer. Together they test the equivalence in both directions, which is the knowledge most likely to be lost and least likely to be rediscovered from the code.

saying these in an interview costs you the question

  • Frames the choice as engine versus algorithm, ignoring the mapping
  • Decides on prototype benchmarks rather than the next requirement change
  • Keeps domain rules in two places, code and encoding
  • Has no reference path to check the equivalence against
  • Presents the reuse direction as evidence the problem is hard
  • Assumes a working encoding absorbs future constraints for free