Your count of a build matrix's jobs exceeds what the pipeline actually schedules, so how do you locate the double count?

seniormust knowfreq 52%

answer

which job is reached twice
count claims a one-to-one map
overlap, order, symmetry
shrink axes and enumerate
canonical key, then bucket

basics

~20 s

Find the object your enumeration reaches twice. The usual causes are cases that are not disjoint, an order imposed on something that has none, and a symmetry never divided out. Give each job one canonical name, count names, and compare.

solid answer

~50 s

Treat the count as a claim about a map: every counted item corresponds to exactly one scheduled job. A count that runs high means the map is many-to-one somewhere. Work through the three usual causes in order. First, overlapping cases: a job matching two of the rules you added gets counted twice, which breaks the disjointness the addition rule needs. Second, imposed order: counting a pair of axes as ordered when the object is unordered reaches every object twice. Third, undivided symmetry: an arrangement with a rotation or relabelling that yields the same object. Then confirm it empirically — shrink every axis to two options, enumerate by hand, and compare with the formula. Finally, fix the structure rather than the number: make the cases disjoint, or give every job a canonical key and count distinct keys. Scaling a total to match reality hides the case you have not understood.

Treat the count as a claim about a map: every counted item corresponds to exactly one scheduled job. A count that runs high means the map is many-to-one somewhere. Work through the three usual causes in order. First, **overlapping cases**: a job matching two of the rules you added gets counted twice, which breaks the disjointness the addition rule needs. Second, **imposed order**: counting a pair of axes as ordered when the object is unordered reaches every object twice. Third, **undivided symmetry**: an arrangement with a rotation or relabelling that yields the same object. Then confirm it empirically — shrink every axis to two options, enumerate by hand, and compare with the formula. Finally, fix the structure rather than the number: make the cases disjoint, or give every job a canonical key and count distinct keys. Scaling a total to match reality hides the case you have not understood.

code

pseudocode · 9 lines

pseudocode

// counting jobs that need the special runner
count = 0
for each job in matrix:
  if job.os is legacy:    count = count + 1
  if job.arch is legacy:  count = count + 1

// a job that is legacy on BOTH axes fires both guards,
// so the two cases are not disjoint and the sum rule
// does not apply as written

go deeper

for a junior

Know that a count can be wrong in two directions, and that the smallest useful test is to shrink every axis to two options and list the results by hand.

for a middle

Explain the three causes of an over-count — overlapping cases, imposed order, undivided symmetry — and show that the addition rule needs cases no single job can satisfy twice.

for a senior

Run the diagnosis on a real pipeline: canonical key per job, bucket, find the duplicate, then repair the structure rather than the number. Resist concluding the scheduler is at fault before the model is checked.

for a principal

Insist that the matrix is defined so the count is verifiable by construction, because a number nobody can reproduce becomes the basis for budget and coverage claims that no one can audit.

A count is a claim about a correspondence

When a formula and a pipeline disagree, one of them is describing a different set. The productive first move is to state the correspondence the formula assumes, in words: every item my enumeration produces corresponds to exactly one job the pipeline schedules, and vice versa. A count that comes out high means that map is many-to-one: at least one job is produced by two different routes through your enumeration. A count that comes out low means it is not onto: some job has no route at all.

That framing turns a vague 'the number looks wrong' into a search for a specific object, which is a question you can answer.

The three ways a count runs high

Cases that are not disjoint. You added the counts of two families, and some job satisfies both rules. The addition rule requires every object to fall in exactly one case; nothing warns you when it does not.
An order imposed on an unordered object. You counted ordered selections when the object is a set. Each underlying object is then reached once per ordering.
A symmetry never divided out. The object has a transformation that produces the same object — a rotation of a ring, a swap of two interchangeable slots. Each object is reached once per symmetry.

And two ways it runs low, worth checking once the high causes are excluded:

A case never written. A whole family of jobs sits outside the enumeration — a scheduled family nobody put in the model.
A restriction that is not real. You assumed an axis was constrained when the pipeline permits it.

Symptom	Likely cause	Fix
Count is exactly twice reality	an unordered pair counted as ordered	divide by the number of orderings, or enumerate one representative
Count is high by a small, irregular amount	overlapping cases in a sum	redefine the cases so no job matches two
Count is high by a clean factor of n	a symmetry of n equivalent forms	divide out the symmetry, or anchor one position
Count is low	a missing family, or an assumed restriction	list the families the pipeline actually defines

The diagnostic routine

Shrink the problem. Reduce every axis to two options. The formula should still apply, and now the full enumeration is small enough to write on a page.
Enumerate by hand and compare. If the formula and the hand list disagree at this size, the defect is in the model, not in a large-input edge case.
Give every object a canonical key. Sort the parts, name the axes explicitly, fix a starting point for anything cyclic. Two routes that produce the same object now produce the same key.
Bucket by key and look for buckets of size greater than one. The keys with two entries name the duplicate, and the two entries name the two routes that reached it.
Read the two routes together. They will differ in exactly one thing: two rules that both matched, or two orderings of the same set, or two rotations of the same ring.

Step 3 is the one people skip and the one that does the work. A canonical key converts an argument about counting into a lookup.

Fix the structure, not the number

Once the duplicate is identified there are three honest repairs, and one dishonest one.

Make the cases disjoint. Redefine the second family as matching rule B and not rule A. The sum rule then applies again as stated, with no correction term.
Count distinct canonical keys. Correct by construction and the cheapest to verify, since it is what the pipeline effectively does.
Divide out the symmetry. Legitimate only when every object has the same number of equivalent forms; if some objects have fewer, division gives a fractional or simply wrong answer.
Scale the total until it matches. This is the dishonest one. It buys agreement today and leaves the misunderstanding in place, so the next axis added reintroduces the gap in a different size.

When the cases genuinely overlap and cannot be redefined, the systematic correction — add the individual counts, take back what was shared — is the inclusion-exclusion principle, a separate tool with its own alternating-sign form for many sets. Recognising that you need it is part of this diagnosis; applying it is a different subject.

What to say in an interview

The strong answer is procedural and falsifiable: name the correspondence, name the three high-side causes, shrink and enumerate, canonicalise, and fix the structure. The weak answer asserts that the pipeline must be dropping jobs. It might be — but that is a conclusion, and you reach it only after the hand enumeration at small size agrees with your formula and still disagrees with what ran.

## A count is a claim about a correspondence When a formula and a pipeline disagree, one of them is describing a different set. The productive first move is to state the correspondence the formula assumes, in words: *every item my enumeration produces corresponds to exactly one job the pipeline schedules, and vice versa*. A count that comes out high means that map is **many-to-one**: at least one job is produced by two different routes through your enumeration. A count that comes out low means it is **not onto**: some job has no route at all. That framing turns a vague 'the number looks wrong' into a search for a specific object, which is a question you can answer. ## The three ways a count runs high - **Cases that are not disjoint.** You added the counts of two families, and some job satisfies both rules. The addition rule requires every object to fall in exactly one case; nothing warns you when it does not. - **An order imposed on an unordered object.** You counted ordered selections when the object is a set. Each underlying object is then reached once per ordering. - **A symmetry never divided out.** The object has a transformation that produces the same object — a rotation of a ring, a swap of two interchangeable slots. Each object is reached once per symmetry. And two ways it runs low, worth checking once the high causes are excluded: - **A case never written.** A whole family of jobs sits outside the enumeration — a scheduled family nobody put in the model. - **A restriction that is not real.** You assumed an axis was constrained when the pipeline permits it. | Symptom | Likely cause | Fix | |---|---|---| | Count is exactly twice reality | an unordered pair counted as ordered | divide by the number of orderings, or enumerate one representative | | Count is high by a small, irregular amount | overlapping cases in a sum | redefine the cases so no job matches two | | Count is high by a clean factor of n | a symmetry of n equivalent forms | divide out the symmetry, or anchor one position | | Count is low | a missing family, or an assumed restriction | list the families the pipeline actually defines | ## The diagnostic routine 1. **Shrink the problem.** Reduce every axis to two options. The formula should still apply, and now the full enumeration is small enough to write on a page. 2. **Enumerate by hand and compare.** If the formula and the hand list disagree at this size, the defect is in the model, not in a large-input edge case. 3. **Give every object a canonical key.** Sort the parts, name the axes explicitly, fix a starting point for anything cyclic. Two routes that produce the same object now produce the same key. 4. **Bucket by key and look for buckets of size greater than one.** The keys with two entries name the duplicate, and the two entries name the two routes that reached it. 5. **Read the two routes together.** They will differ in exactly one thing: two rules that both matched, or two orderings of the same set, or two rotations of the same ring. Step 3 is the one people skip and the one that does the work. A canonical key converts an argument about counting into a lookup. ## Fix the structure, not the number Once the duplicate is identified there are three honest repairs, and one dishonest one. - **Make the cases disjoint.** Redefine the second family as *matching rule B and not rule A*. The sum rule then applies again as stated, with no correction term. - **Count distinct canonical keys.** Correct by construction and the cheapest to verify, since it is what the pipeline effectively does. - **Divide out the symmetry.** Legitimate only when every object has the same number of equivalent forms; if some objects have fewer, division gives a fractional or simply wrong answer. - **Scale the total until it matches.** This is the dishonest one. It buys agreement today and leaves the misunderstanding in place, so the next axis added reintroduces the gap in a different size. When the cases genuinely overlap and cannot be redefined, the systematic correction — add the individual counts, take back what was shared — is the **inclusion-exclusion principle**, a separate tool with its own alternating-sign form for many sets. Recognising that you need it is part of this diagnosis; applying it is a different subject. ## What to say in an interview The strong answer is procedural and falsifiable: name the correspondence, name the three high-side causes, shrink and enumerate, canonicalise, and fix the structure. The weak answer asserts that the pipeline must be dropping jobs. It might be — but that is a conclusion, and you reach it only after the hand enumeration at small size agrees with your formula and still disagrees with what ran.

From the number alone, can you tell an over-count from an under-count?
Only against a trusted reference. Compare with a hand enumeration at a deliberately tiny size, where the true answer is listable. The gap's shape also hints: a clean factor suggests an undivided symmetry, while a small irregular excess suggests overlapping cases.
Your count is lower than what the pipeline schedules — what is the usual cause?
A case that was never written down, such as a job family defined outside the matrix, or a restriction you assumed that the pipeline does not apply. The map is no longer onto: some scheduled job has no route through your enumeration.
Why is counting distinct canonical keys preferred to dividing the total by a factor?
Division is only valid when every object has the same number of equivalent forms. Canonical keys make no such assumption: each object contributes one key whether it has many equivalent forms or one, so irregular cases cannot corrupt the total.

saying these in an interview costs you the question

Adds counts of rules that can both match the same job
Concludes the pipeline is broken before checking the model
Counts an unordered selection as though order mattered
Scales the total to match reality instead of finding the duplicate
Never enumerates at a size small enough to list by hand
Divides by a symmetry factor without checking every object has it

Your count of a build matrix's jobs exceeds what the pipeline actually schedules, so how do you locate the double count?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

A count is a claim about a correspondence

The three ways a count runs high

The diagnostic routine

Fix the structure, not the number

What to say in an interview

▾common follow-ups3 questions

▾red flags6 flags

A count is a claim about a correspondence

The three ways a count runs high

The diagnostic routine

Fix the structure, not the number

What to say in an interview

answer

go deeper