The sample feed looks sorted by timestamp — why still ask whether ordering is guaranteed?
answer
- one example is one draw
- an illustration is not a contract
- devices buffer and flush late
- guarantee you may exploit vs assumption you must defend
- where did that property come from?
basics
~20 sAn example is a sample, not a contract. Sensors buffer and flush late, so a feed that happened to arrive in order once can arrive scrambled tomorrow. Ask, and treat the answer as a fact that changes the plan.
solid answer
~40 sThe example shows one input the interviewer happened to pick; it says nothing about the guarantee behind it. So I ask directly: is the feed guaranteed chronological, can two readings share a timestamp, is it already deduplicated. If the answer is "no, devices buffer and flush late", my plan changes before I write a line — I either establish the ordering myself and pay for it, or pick an approach that does not depend on order at all. If the answer is "yes, guaranteed", I say out loud that I am relying on it, which turns it into a stated precondition instead of a hidden one. The distinction I want to demonstrate is between a guarantee I may exploit and an assumption I would have to defend.
go deeper
Remember that a worked example is an illustration, not a specification. Be ready to name two or three properties — ordering, duplicates, size — that you would confirm rather than infer from the sample you were shown.
Explain what actually changes on each answer: with a guarantee you exploit the property and name it aloud; without one you either establish it and account for the cost, or pick an approach that never depends on it.
Show the production instinct: an inferred property becomes a silent failure when an upstream system changes, so preconditions belong in a boundary check or an explicit validation, not in a candidate's head.
Frame it as contract discipline — which invariants a component is entitled to assume, who enforces them, and what it costs when each team defensively re-establishes the same property. That tradeoff is yours to set, not to discover in review.
## One example proves an existence, not a rule A worked example is evidence that *some* input has a property. A guarantee is a claim that *every* input has it. No number of examples closes that gap, and interview examples are typically chosen to be readable at a whiteboard, not to be representative. The moment you build on "the sample was ordered, so the input is ordered", you have promoted an existence claim into a universal one without anyone agreeing to it. The scenario makes it concrete. Temperature sensors on a fleet of devices buffer readings locally when connectivity drops and flush them when it returns. A batch that flushes late carries old timestamps and arrives after newer readings. Nothing about the sample you were shown reveals this; one sentence from the interviewer does. ## What changes when the answer is "no" If ordering is not guaranteed, everything downstream of "assume ordered" is suspect, and you have exactly two honest moves: 1. **Establish the order yourself.** This is legitimate, but it is not free — it costs time, it may cost extra space, and it may destroy the original arrival order, which can itself be meaningful. If you take this route, say what it costs. 2. **Choose an approach that never depends on order.** A single pass tracking a running best does not care what sequence the readings arrive in. Many problems have such a formulation, and noticing that it exists is worth more than the sort. The wrong move is a third one candidates reach for: assume disorder is rare and proceed. "Rare" is a probabilistic claim about production data made by someone who has not seen production data, and it silently converts a correctness property into a luck property. ## What changes when the answer is "yes" A confirmed guarantee is an asset. It licenses techniques that a scrambled feed does not, and you should use it. But state it: "I'm relying on the feed being chronological — if that stops holding upstream, this breaks and it breaks quietly." That sentence does two jobs. It tells the interviewer you know which property your solution rests on, and in real work it is the line that ends up in a comment, an assertion, or a validation step at the boundary — which is where a hidden precondition should live. ## The general class of properties worth confirming Ordering is the most common one, but it belongs to a family, and the family is what you should actually carry into interviews: - **Ordering** — sorted, or arbitrary? - **Uniqueness** — can keys repeat? Can values repeat? These are different questions. - **Completeness** — can fields be missing or unset? - **Bounds** — how many elements at most; what range can values take? - **Mutability** — may you reorder or modify the input in place, or is it shared with something else? - **Availability** — is the whole input in hand, or does it arrive incrementally with no ability to look back? Each has the same shape: a property that is either given to you (exploit it, name it) or not given (establish it, or design around it). The failure mode is identical across all six — inferring the property from a sample. ## Why this reads as a level marker Interviewers use this deliberately. Underspecifying the ordering and showing a tidy example is a cheap, reliable probe: candidates who ask are separating the contract from the illustration, which is the same reflex that makes someone read an interface's documented guarantees rather than its observed behaviour on the happy path. Candidates who do not ask usually discover the problem when the interviewer says, thirty minutes in, "what if it isn't ordered?" — at which point the honest answer is that the whole plan needs revisiting. There is also a defensive-coding trap on the other side. "I'll just establish the order regardless, so the question doesn't matter" sounds safe and is not: it pays a real cost for an unknown benefit, and it hides that you never learned which regime you are in. The cost may be trivial or may dominate your solution; you cannot tell without the answer. Ask first, then decide. ## The habit, compressed When you catch yourself about to use a property of the input, ask where the property came from. If the answer is "the interviewer said so", proceed and name it. If the answer is "the example had it", stop and ask. That single reflex catches most requirement-level failures before any code exists.
- The interviewer confirms the feed is guaranteed chronological. What do you do with that?Use it, and say I am using it. I name it as a precondition my approach rests on and note that it fails quietly if it stops holding upstream. In real work that sentence becomes a boundary check or a documented assumption; in the interview it shows I know which property carries my solution rather than just that it works.
- Why not simply establish the ordering yourself and skip the question?Because it pays a real cost for an unknown benefit. Ordering the feed takes time and possibly extra space, and it can destroy arrival order that mattered. If the input was already guaranteed ordered, that cost bought nothing; if it was not, I may still have preferred an order-independent single pass. The answer decides which.
- Besides ordering, which input properties do you confirm?Whether keys or values can repeat, whether fields can be missing, the bound on size and on value range, whether I may modify the input in place, and whether the whole input is in hand or arrives incrementally. Each is a property I either get as a guarantee or must establish myself.
saying these in an interview costs you the question
- The example was sorted, so the input is sorted
- If ordering mattered the interviewer would have mentioned it
- Out-of-order arrivals are rare enough to ignore
- I'll always reorder defensively, so the question is moot
- An unstated assumption is fine as long as the code works on the sample