Two equal-priority cards change order. What should you inspect?
Margin Notes orders work cards by ascending priority. A new comparator looks short, but equal-priority cards do not keep the agreed order.
The question
Fictional exercise. The supplied code, data and outcomes are authored teaching examples, not an employer question or model output.
function compare(a, b) {
return a.priority > b.priority ? 1 : -1;
}| Priority | Input position | |
|---|---|---|
| alpha | 2 | 0 |
| beta | 2 | 1 |
| gamma | 1 | 2 |
The caller uses a stable ordering operation. Priorities are integers from 0 to 1,000.
Equal priorities compare as zero; reversing unequal inputs reverses the sign. A card compares as zero with itself. The stable caller retains input order for ties.
“Evaluate the comparator before trying a different sorting algorithm. Which contract is broken and what would you test?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Inspect the relation
What would you do here? Open the move you’d make.
Replace the sorting algorithm first
Tempting, but it misses something. The supplied comparison relation already violates its contract.
Assume equal records always return zero
Tempting, but it misses something. The else branch returns -1, including for self-comparison.
Evaluate self and equal-priority comparisons
The strong move. Those inputs directly test the required relation.
See how a strong candidate says it
“For alpha against itself, the greater-than condition is false, so the function returns -1. Equal-priority alpha and beta also return -1 in both argument orders. That contradicts equality and sign reversal.”
Why it works: A tiny counterexample can expose a broken comparator contract.
Step 2: Bound the observed claim
What would you do here? Open the move you’d make.
Show the contradictory comparison values
The strong move. They establish the defect under the supplied contract.
Claim every engine must return one specific wrong order
Tempting, but it misses something. That outcome is not established by this packet.
Ignore ties because the usual sample is sorted
Tempting, but it misses something. The accepted input includes equal priorities.
See how a strong candidate says it
“I can show a contract violation without claiming a particular final order from every sorting implementation. The faulty relation gives the caller inconsistent instructions about ties.”
Why it works: The counterexample is stronger than an unsupported claim about all sort outputs.
Step 3: Choose the minimal repair
What would you do here? Open the move you’d make.
Return 1 for every pair
Tempting, but it misses something. Self-comparison and equal priorities still fail.
Return the priority difference
The strong move. It meets equality and sign requirements in the stated domain.
Use a random sign for ties
Tempting, but it misses something. That discards the explicit tie rule.
See how a strong candidate says it
“Inside the stated integer domain, a.priority - b.priority returns zero for ties and reverses sign for unequal inputs. The caller's stable tie behavior can then preserve alpha before beta.”
Why it works: The repair aligns the comparison with the actual contract.
Step 4: Choose independent checks
What would you do here? Open the move you’d make.
Check only gamma before alpha
Tempting, but it misses something. An unequal pair does not test the broken tie branch.
Assert a screenshot looks sorted
Tempting, but it misses something. It cannot establish the comparator's equality behavior.
Check the relation and the caller's tie behavior
The strong move. These are distinct observable parts of the contract.
See how a strong candidate says it
“Check compare(x,x), both argument orders for a tie, both orders for unequal priorities, and a caller example with equal priorities. Keep the integer-domain limit explicit.”
Why it works: A single sorted happy path misses the faulty relation.
The answer, in short
- Decision
- Repair equality in the comparator before changing the sort.
- Because
- The supplied function returns -1 even for a self-comparison.
- What would change it
- Missing or nonnumeric priorities would require a separately stated input contract.
Common traps
- Treating a plausible result as proof of the full contract.
- Claiming more than the shown inputs and checks establish.
Check your answer
- Did you evaluate compare(x,x)?
- Did you check a tie in both argument orders?
- Did your repair match the stated numeric domain?
- Did you distinguish the comparator contract from one final sort output?
Last reviewed Nov 10, 2026