skip to content

questions

20

An unfamiliar requirement is written in business language; how do you check whether it is a known hard problem in disguise?

level: juniorimportance: must knowfreq 68%

answer

  1. the domain nouns are the disguise
  2. objects, relation, objective
  3. state the decision version, with k
  4. cover, pick, pair, or order
  5. a match is a hypothesis, not a proof

basics

~20 s

Strip the domain nouns and restate the requirement as objects, a relation between them, and an objective. That skeleton — cover everything, pick a subset under a budget, order with no repeats — is what you match against the known catalogue.

solid answer

~50 s

I rewrite the sentence with the business words removed. Promo codes, shifts and delivery windows all become **items**; customers, links and stops become **elements**; "must reach", "must not overlap" and "must follow" become a relation. Then I state the objective in its decision form — *is there a selection of at most k items satisfying the relation?* — because that is the form in which known results are written. At that point the skeleton usually looks like one of a handful of families: cover every element with as few chosen items as possible, choose a subset under a budget to maximise value, or arrange everything in an order with no repeats. Saying which one it looks like, out loud, is the move the interviewer is scoring. It is a hypothesis about the problem, not yet a proof about it.

go deeper

for a junior

Be able to restate a requirement without its business nouns and say which shape it has: cover everything, choose a subset, pair things up, or order them. Naming the shape is the whole expectation here.

for a middle

Explain how you reach the decision version with a threshold k, and why that form is the one known results are written in. Show that you can spot the easy family too, not only the frightening ones.

for a senior

Show the habit under pressure: the rewrite happens in the spike, the candidate name goes in the plan document, and the assumption about input size is recorded as a guard rather than a memory.

for a principal

Make the rewrite a team norm rather than a personal trick. The cost you are managing is a design committed before anyone asked what the problem was, which is expensive to reverse once a schedule depends on it.

## Why the rewrite comes first Requirements arrive in the language of the business: "pick the cheapest set of delivery windows so every order gets one", "assign each engineer to one on-call slot", "find the shortest tour of every depot". The domain nouns are the disguise. Two requirements that read nothing alike can be the same mathematical object, and two that read almost identically — one asking for pairs, one asking for triples — can sit on opposite sides of the tractability line. Until the nouns are gone you are comparing stories, not structures, and you cannot tell which case you are in. This is the first ten minutes of a planning spike, before any code exists. The output is not an algorithm. The output is a **name**, or an honest "it resembles nothing I know". ## The rewrite, step by step 1. **Neutralise the nouns.** Everything you are choosing becomes an *item*; everything that must be satisfied becomes an *element*; everything that connects them becomes an *edge* or a *constraint*. Keep a one-line glossary so you can translate back. 2. **Name the relation.** Does an item *cover* elements? *Conflict* with other items? *Follow* another item in a sequence? *Pair* with exactly one element? 3. **Name the objective.** Minimise a count, maximise a total value, or merely decide whether anything feasible exists at all. 4. **State the decision version.** Convert "find the cheapest" into "is there one of cost at most k?". Hardness results are stated for that yes/no form, and the two forms are linked — you can search over k — so matching either is enough for triage. ## Skeletons worth recognising | Skeleton | Wording you actually see | Known family | |---|---|---| | Cover every element with as few chosen items as possible | "every segment must receive at least one", "every link must be watched" | Set Cover, Vertex Cover | | Choose a subset under a budget, maximising value or hitting a total | "fit the most valuable jobs in the window", "reach exactly this amount" | Knapsack, Subset Sum | | Choose items that mutually conflict with none of the others | "no two selected bookings may overlap" | Independent Set | | Order everything, visiting each once, cheaply | "a route through every depot, back to the start" | Hamiltonian cycle, Travelling Salesman Problem | | Pair each of these with one of those | "each engineer gets one slot, each slot one engineer" | bipartite matching — the routinely easy one | The last row matters as much as the others. A requirement that *sounds* combinatorial because it mentions assignment is often plain pairing, which has polynomial algorithms. Recognising the easy family is half the value of the exercise. ## What the match establishes, and what it does not - It establishes a **working hypothesis** about the general case, strong enough to plan around and cheap enough to state in a spike. - It does **not** prove hardness. A proof embeds a known hard problem inside yours, and that is a separate obligation you take on only if someone disputes the plan. - It says nothing about *your* instances. Hardness is a statement about the worst case across all inputs; the inputs you will actually receive may be small, structured, or both. - It does not survive a changed requirement. Drop one clause and the skeleton can change family, so re-run the rewrite whenever the requirement moves. ## Where the triage goes wrong - **Coding first.** Once an approach is on the whiteboard, everyone argues about the approach instead of the problem, and the match never happens. - **Keeping the nouns.** "Delivery window" carries connotations that suppress the pattern; "item covering elements" does not. - **Treating resemblance as proof.** Two problems can share a shape and differ in the one clause that decides feasibility — a bound of two rather than three, an input that happens to be a tree. - **Assuming novelty.** Most business requirements are decades-old problems in new clothing; the prior should be "this is known", not "this is new". - **Calling anything with many combinations exponential.** Sorting explores an enormous space of permutations and is cheap; the size of the search space alone predicts nothing.

  • The skeleton matches a hard problem, but the real inputs will always be tiny. Does the match still matter?
    Yes, and it changes what you write down. The match tells you the growth is the risk and that the small bound is load-bearing, so it stops being an incidental fact and becomes a recorded assumption with a guard that fails loudly when a caller exceeds it.
  • How do you tell whether you have matched the optimisation version or the decision version of a problem?
    The decision version asks a yes/no question against a threshold — is there a solution of cost at most k — while the optimisation version asks for the best value. Published hardness results are almost always stated for the decision version, and the two are linked by searching over k, so matching either one is enough to triage.
  • What do you do when the skeleton matches nothing you recognise?
    Say so plainly, then attack the parts. Split the objective from the constraints and match each separately; a requirement is often a routine structure with one hard clause bolted on, and isolating that clause is more useful than a verdict on the whole.

A mechanic hearing "it whines when I turn left" is matching a description to a known fault before touching a tool — the name decides which page of the manual applies, and it is still a hypothesis until a test confirms it.

saying these in an interview costs you the question

  • Starts designing an algorithm before naming the problem
  • Treats a resemblance to a known hard problem as a proof of hardness
  • Assumes an unfamiliar business requirement must be a new problem
  • Keeps the domain nouns, so the structure stays hidden
  • Calls anything with many possible combinations exponential
open as a page

A probe-selection tool claims a proven 2-approximation for total probe cost — what exactly does that ratio promise about any single run?

level: middleimportance: must knowfreq 66%

basics

~20 s

A 2-approximation promises that on every input the returned cost is at most twice the best possible cost. It is a proven worst-case ceiling on answer quality, not an average over inputs and not a statement about running time.

open as a page

In a branch-and-bound search for a minimum-cost plan, what do the incumbent and the bounding function each do to let you skip a subtree?

level: middleimportance: must knowfreq 60%

basics

~20 s

The incumbent is the best complete plan found so far, and its cost is the cut-off. The bounding function computes an optimistic cost for everything still reachable in a subtree; if that is no better, the subtree is discarded unexplored.

open as a page

Why does a solver costing 2^k times n stay workable as the graph grows, when n^k with the same conflict count k does not?

level: middleimportance: must knowfreq 58%

basics

~20 s

The exponent's home decides it. In 2^k times n only the small conflict count k sits in an exponent, so a bigger graph costs a linear factor more. In n^k the graph itself is raised to k, so growth is fatal.

open as a page

What three feasibility verdicts can a triage of an unfamiliar task return, and what evidence does each one need?

level: middleimportance: must knowfreq 58%

basics

~20 s

Routine, hard, or impossible. Routine needs a named polynomial method that fits; hard needs a known NP-complete problem sitting inside the requirement; impossible needs the shape of a question about what an arbitrary program does at runtime.

open as a page

In a search for a vertex cover of size at most k, why does branching on both endpoints of one uncovered edge bound the work at 2^k?

level: seniorimportance: must knowfreq 46%

basics

~20 s

Every edge must be covered, so at least one of its two endpoints is in the cover: a forced two-way branch. Each branch spends one unit of the budget k, so the tree is at most k deep and has at most 2^k leaves.

open as a page

What does an FPTAS promise that a PTAS does not, once you tighten the accuracy parameter from ten percent to one percent?

level: middleimportance: should knowfreq 45%

basics

~20 s

Both schemes take an accuracy parameter and return a solution within that fraction of optimal. A PTAS is polynomial in the input size for each fixed accuracy, but its exponent may blow up as accuracy tightens; an FPTAS is polynomial in the input size and in the reciprocal of the accuracy together.

open as a page

Two runs of one backtracking search on the same input differ by an hour; why does choice order matter that much?

level: middleimportance: should knowfreq 50%

basics

~20 s

The tree an exhaustive search walks is not fixed by the problem; it is created by the order decisions are made. Ordering that forces contradictions near the root cuts enormous subtrees early, while a poor order discovers the same contradictions at the leaves.

open as a page

Your triage calls a scheduling requirement NP-hard; which restrictions hidden in the requirement could pull it back to polynomial time?

level: middleimportance: should knowfreq 46%

basics

~20 s

Look for structure the general problem lacks: an input shaped as a tree or a line of intervals, two of something where the hard version needs three, or a genuinely small integer bound. Each turns open search into forced or tabulated work.

open as a page

Tours over sites whose costs obey the triangle inequality admit a 3/2 guarantee, while arbitrary edge costs admit no constant factor unless P = NP — what makes the difference?

level: seniorimportance: should knowfreq 38%

basics

~20 s

The triangle inequality lets an algorithm skip an already-visited site without paying more, so a cheap structure spanning all sites can be converted into a tour of comparable cost. With arbitrary costs, missing connections can be priced so high that any constant-factor approximation would decide Hamiltonicity.

open as a page

Why does encoding a hard scheduling problem for a mature satisfiability solver usually beat writing your own backtracking search?

level: seniorimportance: should knowfreq 45%

basics

~20 s

A mature solver contributes decades of search engineering you will not reproduce: constraint propagation, conflict analysis that learns a clause and jumps back, activity-driven branching and restarts. Your remaining job is the encoding, and the encoding then becomes the thing to get right.

open as a page

How does shrinking a size-k vertex cover instance to an equivalent one whose size is bounded by k alone pay off?

level: seniorimportance: should knowfreq 38%

basics

~20 s

It moves the whole graph out of the expensive factor. Polynomial-time reduction rules return an equivalent instance of size bounded by k, so the exponential search afterwards runs on something the size of k squared, not on the graph.

open as a page

Reporting a requirement as NP-hard to stakeholders — what must that verdict carry to be honest and actionable?

level: seniorimportance: should knowfreq 42%

basics

~20 s

A usable verdict names which version of the problem was triaged, the evidence tier behind it — matched against a known problem, or proved — the input sizes and exactness it assumes, and what would overturn it. The label alone is not a plan.

open as a page

Choosing between a proven 2-approximation and an in-house heuristic that landed within three percent on last quarter's probe data, what belongs in a written cost commitment?

level: principalimportance: should knowfreq 32%

basics

~20 s

Only the proven factor belongs in the commitment, because it holds on inputs nobody has seen yet; measured closeness describes one past distribution. The strong plan runs both, returns the cheaper answer, and certifies each run against a computable lower bound.

open as a page

Your overnight run must return a plan by morning: how do you choose between a deadline-stopped exact search and a local-search heuristic?

level: principalimportance: should knowfreq 38%

basics

~20 s

Decide by what has to be defended. A deadline-stopped exact search returns a plan plus a proven interval containing the optimum; a local-search heuristic returns a plan and no claim at all. Where nobody needs the certificate, the heuristic scales further.

open as a page

A design assumes conflicting entries stay under a dozen however large the dependency graph grows, so how do you decide whether to commit to a parameterized solver?

level: principalimportance: should knowfreq 30%

basics

~20 s

Ask what enforces the dozen. A parameterized plan is sound when a specification or a physical limit caps the parameter, measured in production and guarded at runtime; if only observed data caps it, the design needs a documented fallback for the day it does not.

open as a page

What does calling an optimisation problem APX-hard rule out, given that it may still admit a 2-approximation?

level: seniorimportance: nice to knowfreq 26%

basics

~20 s

APX-hardness rules out an approximation scheme: unless P = NP there is a fixed threshold factor that no polynomial-time algorithm can beat, so accuracy cannot be dialled arbitrarily close to optimal. It does not rule out a constant factor, which such problems often have.

open as a page

Why does splitting a 40-item exhaustive subset search into two halves of 20 reduce the work from about 2^40 to about 2^20?

level: seniorimportance: nice to knowfreq 28%

basics

~20 s

Each half has only 2^20 subsets, so both are enumerated cheaply. One half is stored in a structure keyed by its partial contribution, and each subset of the other half is matched against it. The exponent halves; storing 2^20 entries is the price.

open as a page

Why is finding a clique of size k not expected to admit a cost of f(k) times a polynomial in n?

level: seniorimportance: nice to knowfreq 24%

basics

~20 s

Brute force over all k-subsets gives n^k, which is XP, and nothing better in shape is known. Finding a k-clique is hard for the class W[1], so an f(k) times polynomial algorithm would collapse W[1] into FPT - widely disbelieved.

open as a page

Triage cannot settle whether an unfamiliar requirement is easy or hard inside the spike's timebox — what do you commit to?

level: principalimportance: nice to knowfreq 30%

basics

~20 s

Commit to the reversible option: build behind a boundary, guard the input sizes you can defend, and record the unresolved question where the requirement lives. The two wrong calls cost differently, and the expensive one surfaces late, under real data.

open as a page