Strategy & Reasoning Study Portal

How it works

Why any of this transfers

The material transfers because all five were working on the same shape of problem: acting under uncertainty, with adversaries or constraints you do not control, where the cost of being wrong is asymmetric. That is the shape of a system-design round, an incident review, a prioritisation argument, and a reorg. It is not the shape of a coding exercise, which is why this module belongs in the Management track and not next to algorithms.

Be honest about the limits too. None of these give you domain facts, none of them settle a technical question, and reaching for them when a measurement would answer the question is a way of sounding thoughtful while avoiding the work. The rule from the rest of this hub applies here without modification: if the repository, the data, or a cheap experiment can answer it, that is not a judgement call and no framework is needed.

Sun Tzu — position beats confrontation

The core claim of The Art of War is not about fighting well. It is that the outcome is largely determined before the engagement, by position, information and terrain, and that the best result is the objective achieved without the fight happening at all.

Three moves that show up constantly in senior interviews:

• Winning without fighting. The strongest answer to "how did you handle the disagreement with the other team" is often that you removed the reason for the disagreement — changed the interface, split the deliverable, made both things possible — rather than that you won the argument. Interviewers read "I convinced them I was right" as junior; they read "the conflict stopped being necessary" as senior.
• Terrain. Knowing where you are strong and where you are not, and refusing engagements on ground that suits you badly. In practice: not litigating a decision in a forum where you have no context, and moving it to one where evidence decides.
• The battles you decline. Prioritisation is mostly declining, and candidates systematically under-report this. "What did you choose not to do, and what happened as a result" is a question about whether you understand that capacity is finite.

The trap is treating this as ruthlessness. It is the opposite: nearly every move is about reducing the number of confrontations, because a confrontation is expensive even when you win it.

Aristotle — why a correct argument still loses

Aristotle's contribution is the separation of demonstration from persuasion. A demonstration establishes that something is true. Persuasion moves a specific audience to act. These are different activities, and engineers routinely do the first and then feel cheated that the second did not follow.

The three appeals are the useful part, and they are not a rhetorical trick — they are three genuinely different questions an audience is asking:

• Ethos — should I trust this person's judgement? Built by accurate prior calls, acknowledged uncertainty, and above all by having been visibly wrong once and having said so.
• Logos — does the argument hold? The evidence, the mechanism, the numbers.
• Pathos — why should I care now? Not manipulation: consequence and urgency. A correct proposal with no stated cost of delay loses to a worse one with a deadline attached.

The other durable idea is the enthymeme: a real argument leaves its shared premise unstated, because stating it is tedious. That is exactly why arguments fail without either side noticing — the unstated premise is not actually shared. "We should migrate to X" often rests on an unspoken "and our current pain is caused by the platform", which the other person simply does not believe. Surfacing the hidden premise ends more disagreements than adding evidence does, because more evidence for a conclusion whose premise you reject is not persuasive at all.

Plato — attack the premise, not the conclusion

The Socratic elenchus is a specific procedure: take the claim, derive its consequences, find the one the speaker will not accept, and let the contradiction do the work. Its point is not to humiliate anyone. It is that you cannot argue someone out of a conclusion, but a person will readily abandon a premise they did not realise they held.

This is the structure of a good design review. A weak review disputes conclusions — "I don't think Kafka is right here" — and becomes preference against preference. A strong review goes after the premises: what throughput are we assuming, what does "we need ordering" mean exactly, which of these requirements did a customer actually state. Very often the design is fine and a premise is wrong, and only the premise-level question finds that.

It maps onto an engineering habit worth naming: verify against the contract, not against the intent. Asking "what did you assume, and how do you know it" is the elenchus with the philosophy removed.

The failure mode is doing it to people rather than to claims. Questioning premises in front of an audience feels like an attack unless you have made it explicit that you are testing the argument, not the person — which is itself an ethos problem, and why the two ideas need each other.

The Stoics — separate what you control from what you are judged on

The control dichotomy is the practical core: some things are up to you and some are not, and suffering comes from treating the second category as the first. For interviews this is not a coping strategy, it is a narrative structure for failure questions, which are the questions candidates handle worst.

The bad answer to "tell me about a project that failed" blames circumstances, which reads as no ownership. The other bad answer takes total responsibility for things nobody could have controlled, which reads as poor judgement — and interviewers notice, because if you cannot tell the difference between a bad decision and a bad outcome, your future estimates are unreliable.

The strong answer separates them explicitly: here is what was outside my control, here is what was inside it, here is the decision I would make differently, and here is what I changed so the same class of thing is caught earlier. That is the control dichotomy applied, and it is also just an accurate postmortem. The connection is not accidental — blameless postmortems are built on exactly this separation, which is why a good one distinguishes a bad decision from a bad outcome. A well-made decision can still lose; a lucky one is still badly made.

Archimedes — how you found it is not how you prove it

Archimedes belongs here for one specific reason. In The Method he described how he actually discovered his results — a mechanical, physical, heuristic process of balancing shapes against each other — and then noted that this procedure did not constitute a proof, so he proved the same results again rigorously by exhaustion. He kept the two apart and said which was which.

That distinction is the single most transferable idea in this module, because the modern version of losing it is expensive. An estimate is a method of discovery: it tells you where to look. A measurement is a method of proof. When an estimate is copied twice without its label, it becomes indistinguishable from a measurement, and a decision ends up resting on a number nobody ever took.

Worse, a derived estimate is not merely less precise than a measurement — it can be wrong in direction, because it is generated by a model of the data rather than by the data. A real case: a proposed retrieval key was estimated to reduce a candidate set "to about a hundred"; measured on the real corpus it produced a mean of 596 against an existing baseline of 244 — nearly two and a half times larger than the thing it was meant to replace. The arithmetic had assumed an even distribution; the actual distribution was skewed, and the heavy region was exactly what the estimate could not see.

The discipline: label every quantity measured, derived, or assumed, and keep the label attached as the number moves between documents. Archimedes did this by hand, in the third century BC, on results he was certain were correct.