A plan is a set of commitments, not a route
The instinct of a candidate who has built optimisers is to reoptimise, and it is the wrong first move. Before anything is recomputed you need to know what the existing plan has already turned into: bookings accepted by carriers, containers loaded and sealed, vessels sailed, customs declarations lodged against a specific arrival, hauliers scheduled at destination, delivery dates given to customers, production plans built on inbound material arriving on a date.
Each of those is a commitment with a different degree of reversibility, and the cost of changing them ranges from a phone call to impossible. A network model that only holds the intended route has no way to express any of it, which is why the honest first step is triage against reality rather than a solver run.
The triage produces three buckets and they are handled by different people. Consignments already past the affected node continue and need only their downstream dates revised. Consignments in flight and not yet past it are the difficult ones: they can potentially be diverted, discharged elsewhere, or left to wait, and each option has a cost and a lead time to arrange. Consignments not yet shipped are the easy ones, because they can be rebooked, deferred or sourced differently, and they are also the largest group, which makes them the place where most of the value is recovered.
Model the lane as a constraint that can be withdrawn
The structural lesson the interviewer is probing for is whether your data model treats the port as a fact or as a choice.
A route baked in as an attribute of a shipment, with an origin, a destination and a transit time, cannot be replanned because the alternatives were never represented. What replans is a model built from legs: a movement between two nodes, by a mode, with a carrier, a capacity, a cost, a transit time and a service window, where a shipment's journey is a sequence of legs and the sequence chosen is one of several feasible sequences. Then a node becoming unavailable is a constraint change, and the alternatives are already in the graph.
Two things have to sit alongside that to make it useful. The first is capacity as a modelled quantity rather than an assumption, because the alternative port has finite berth, yard and inland haulage capacity, and so does everyone else's alternative port. A replan that routes your whole flow through the neighbouring terminal is arithmetic, not a plan, if that terminal is simultaneously receiving everybody else's diverted volume. The second is allocation: on ocean freight you typically hold contracted space with carriers, and what you can actually book at short notice is bounded by that contract plus whatever spot capacity exists at whatever price it has just risen to. A model that treats capacity as available at a fixed rate will produce plans that cannot be bought.
Cost also has to include the consequences, not just the freight. A cheaper diversion that misses a production start is more expensive than an air freight charge, and a plan optimised on transport cost alone will choose it every time. Getting penalty and stockout costs into the objective, even crudely, is what makes an optimiser's answer resemble the answer a good planner would give.
The first hours are triage, and speed beats optimality
There is a strong temptation to hold the response until a proper reoptimisation is available. In a disruption of this kind that is the wrong trade, because the scarce alternatives are being consumed by everyone else in the market simultaneously. Space on the alternative service, the inland haulage, the warehouse capacity near the substitute port, and the air freight are all being bought while you compute.
So the operating model is a fast, coarse response followed by a considered one. In the first hours, freeze new bookings on the affected lane, secure options on alternative capacity before you know precisely which consignments will use them, and get the list of affected consignments in front of the people who own the customer relationships. Optionality has a price and it is usually much less than the cost of being late to the market.
The second wave is where the optimisation earns its keep, and it should be constrained rather than free. A solver told to minimise cost across the whole network will move things that did not need moving, because a globally better plan is available if you also change forty consignments that were fine. That plan cannot be executed: each change is a phone call, a rebooking, a customer conversation.
So the objective has to include a penalty for changing an existing commitment, or the model has to be run with committed legs pinned, and the output has to be a diff against the current plan rather than a new plan. Presenting a planner with a list of twelve changes to approve is usable; presenting them with a wholly different network is not.
Scarce capacity is a prioritisation decision, not a cost minimisation
The hardest part of this scenario is not routing, it is that you cannot serve everything and something has to be decided by a person.
If one air freight allocation exists and three customers need it, the choice is commercial: contractual penalties, the relative value of the relationships, whether one customer's line stops without it, whether another has inventory to absorb the delay. None of that is in a transport cost model, and a system that quietly resolves it by choosing the cheapest option has made a business decision without authority.
What a good design does is surface the trade-off with the information needed to decide, and record who decided. That means a prioritisation view listing affected consignments with their customer, their contractual exposure, the downstream consequence of lateness, and the cost of each available mitigation, ordered by whatever the business has agreed matters. Where the business has a standing rule, such as safety stock for a critical line taking precedence, it can be encoded, and where it does not, the answer is an escalation path rather than a default.
Revised arrival estimates have to travel
An arrival date is not a display field, it is an input to other plans. A container's revised arrival changes the customs declaration's timing, the destination haulage booking, the warehouse's inbound labour plan, the production schedule that consumed the material, the promise given to the end customer, and the inventory projection the planning team is using to decide what to buy next.
So the estimate needs to propagate rather than merely update. Each consumer of an arrival date should be receiving it as an event, with a version and a confidence, and the ones that cannot absorb a change automatically need a work item raised. The failure mode when this is missing is quietly expensive: the transport team knows the vessel is a fortnight late, the planning team is still calculating requirements against the original date, and the discrepancy surfaces as an unexplained stockout a month later.
Confidence deserves separate treatment. During a disruption, arrival estimates are genuinely uncertain, and publishing a precise date that changes daily trains everybody downstream to ignore the feed. Publishing a range, or a date with an explicit statement that it is provisional pending the port reopening, preserves the credibility of the channel. That is a communication decision with a systems consequence, since a data model that only holds one date cannot express it.
Knowing which nodes you cannot lose
The question worth answering before the disruption is which single points your network cannot survive, and it is answerable with data you already hold. Volume by port, by terminal, by lane, by carrier and by inland corridor, over a period, tells you where your concentration is. For each concentration, the useful analysis is not a probability, which nobody can estimate honestly, but a consequence: if this node were unavailable for a week, a fortnight, a month, what would it cost and what is the alternative.
That exercise usually produces two findings. Some concentrations are cheap to hedge, by qualifying a second port or a second haulier so that the arrangement exists before it is needed, and qualifying takes months, which is precisely why it has to be done in advance. Others are genuinely unavoidable, because there is only one deep-water port serving a region, and for those the answer is inventory positioning rather than routing: holding stock on the far side of the chokepoint is the only mitigation available for a constraint that has no alternative path.
When a fixed piece of the network simply becomes unavailable
In March 2021 the container ship Ever Given grounded across the Suez Canal and blocked it for six days, forcing hundreds of vessels either to wait or to reroute around the Cape of Good Hope, which added roughly a fortnight to those voyages. No system failed. A node that every plan treated as permanently available was withdrawn, and the plans built on it had no alternative encoded.
The instructive detail for a routing question is the shape of the choice it forced. Waiting and diverting were both bad, the right answer differed by cargo and by how much time each shipper had already consumed, and the decision had to be made before anybody knew how long the blockage would last. That is the general form of disruption response: you commit to a mitigation under uncertainty about the duration, which is why the plan needs to be revisable rather than right, and why the interviewer is listening for whether you treat a lane as a hard assumption or as a constraint that can be withdrawn.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).