When I review an ICPC practice, the damaging disagreement is rarely the one teammates remember. It is the doubt that never became a sentence.
During a contest, teammates will disagree about problem difficulty, an interpretation, the safety of a proof, and whether an implementation deserves more time. This is expected. Three people were placed together because they see different things.
One teammate codes an approach that another has not accepted. A concern arrives as tone instead of a claim. The team debates who sounds more certain while the clock keeps the only complete record.
Teams rehearse algorithms and typing. They should also rehearse how to disagree.
State the claim before defending it
“I do not think this works” gives the team little to inspect. The useful version names the failing claim: this greedy choice may block a better suffix; this state loses information about parity; this complexity assumes a bound the statement does not give.
The teammate proposing the approach should do the same. “It feels right” becomes an exchange argument, an invariant, or a bound. Once both beliefs are explicit, the disagreement belongs to the team instead of to the loudest person.
Search for a witness
Most contest disagreements should become small experiments. If the proof may fail, search for the smallest counterexample. If two interpretations compete, derive an input whose output differs. If the issue is complexity, estimate the operations at the maximum constraint instead of arguing from intuition.
A witness is better than another minute of persuasion. It can reject a claim, narrow the dispute, or expose the exact lemma that still needs proof.
The test must match the uncertainty. Random cases help with implementation bugs. They are weak evidence for a structural claim unless an oracle exists. A hand-built adversarial case may answer the question faster.
Put a clock on unresolved belief
Not every disagreement can be settled. The team still needs a decision rule. Give the uncertain claim a short time box and name what would justify continuing.
For example: spend seven minutes looking for a counterexample and writing the missing proof step. If neither appears, ask the third teammate to review the claim. If confidence remains low, park the problem and preserve the current notes.
This prevents two common failures. The team does not abandon every idea at the first objection, and it does not spend forty minutes defending work because time has already been invested.
Make confidence legible
Teams often use the same words for different levels of certainty. “I have a solution” may mean a complete proof, a promising pattern, or code that passed samples.
Agree on language before the contest. I like distinctions such as idea, proof, implementation, and tested submission. A teammate can say, “I have the idea, but the transition is unproved,” or, “The proof is complete; I need a second reader on the index boundary.”
This language changes allocation. Another teammate knows whether to check the mathematics, take the keyboard, build tests, or keep reading.
Review disagreements, not personalities
After practice, choose one disagreement that changed the contest. Reconstruct what each person believed at the time. Identify the claim that could have been stated earlier and the test that would have resolved it sooner.
Do not reduce the lesson to “listen to Alex next time.” The correct teammate will change. The reusable asset is a better protocol for exposing and testing belief.
During practice, I ask teams to use four steps:
- Name the claim. State exactly what one approach assumes or guarantees.
- Name the doubt. Identify the smallest part of the claim that may fail.
- Choose evidence. Find a proof step, counterexample, bound, or differential test that can decide.
- Set the next decision. Give the test an owner and a time box, then continue, switch, or park the problem.
This protocol is short enough to use under pressure. It also gives a coach something observable to review.
A team that never disagrees is probably hiding information. A team that only debates is failing to convert information into action. The useful middle is practiced disagreement: precise enough to test and bounded enough to end.