Six Questions the Working Cart Cannot Answer for You
A cart that runs proves the code works. Whether you understood it is a different question, and the concept carries six that only understanding can answer: why this state, why this structure, what happens on a repeat add, what does it cost, what breaks without persistence, what changes under a new rule.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
Your cart passes every test. Which six questions would show whether you understood it or received it — and what does a blank on any one of them tell you to go back to?
You finished the cart. Every example passes, the reference matches yours closely enough, and you feel done. A colleague asks "why is it an array?" and you say "because that is what the reference uses", and then hear yourself.
Take the green tests as the check. Working code is understood code — what else would understanding mean? If a question comes up, look the answer up in the reference and repeat it; that is what references are for.
The tests check the code against the examples; they do not check you against anything. A pasted cart passes the same suite as a derived one, and the suite cannot tell the difference — it was never asked to.
- The tests check the code against the examples; they do not check you against anything. A pasted cart passes the same suite as a derived one, and the suite cannot tell the difference — it was never asked to.
- Repeating the reference's answer proves the reference was read, not that the question was understood. "Because a cart holds a handful of items" is the concept's
because; said back without knowing what would change it, it is a slogan. - The moment the check fails for real — a new rule, a question in review — there is no place to go back to, because "done" was declared at the code and the earlier stages were never yours.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Ask the six questions the concept record already holds. Why does the cart store a product id and not the product name? Why an array and not a map — and at what size, or for which requirement, would you switch? What happens when the same product is added twice, and which line makes that happen? What is the complexity of adding an item, and does it matter for a cart? What breaks if persistence disappears — and what breaks if it appears? A new requirement says quantity may not exceed 10: which invariant, example, line and test change?
- Notice that each question belongs to a stage of the loop. The first is state, the second representation, the third rules and execution, the fourth complexity, the fifth engineering, the sixth modification. A blank is not a verdict on you; it is a pointer to the stage that was skipped or received rather than derived (The Implementation Loop).
- Answer with a consequence, not a definition. "Because the catalog owns names" is a definition; "because a renamed product would show its old name in every cart that stored it" is what the state decision was protecting against, and only the second answer says when you would change your mind.
- Treat a blank as the next thing to do, not a fail. Cannot say why an array? Go to the representation stage with the concept's two representations side by side and their complexity rows, and come back when you can name the size at which you would switch (Why This Data Structure?).
The six, and the stage each one points at
The matrix quotes the concept's understandingCheck and pairs each question with the stage of the loop that answers it and the shape a real answer has. The last column is the one to read twice: it is what separates understanding from recall.
| Question (from the concept) | Stage | A real answer contains |
|---|---|---|
| Why does the cart store a product id and not the product name? | state | the stale-name failure, and the case (an order) where you would snapshot instead |
| Why an array and not a map — and at what size, or for which requirement, would you switch? | representation | O(n) vs O(1) average, what n is, why it is small, and the requirement that flips it |
| What happens when the same product is added twice, and which line makes that happen? | rules + execution | the example add-again, the find before the append, the rule it encodes |
| What is the complexity of adding an item, and does it matter for a cart? | complexity | an annotation with n named, and a reason it does not matter here |
| What breaks if persistence disappears — and what breaks if it appears? | engineering | a reload emptying the cart; then stale products from storage and two tabs racing |
| A new requirement says quantity may not exceed 10. Which invariant, example, line and test change? | modification | four named artefacts — not "add an if" |
A definition versus a consequence
The same question answered twice. Both are true. Only one of them says when the decision would change, and that clause is the whole difference between having read the concept and having understood the store.
"An array is simpler and a cart is small. The reference uses one."
"The only lookup is the find in addItem, which is a scan over the distinct products in one cart — a handful, so O(n) is invisible and the array keeps insertion order for the view. I would switch to a map when the collection is large or when one-entry-per-product must be structural rather than a line of code — a wishlist, or carts keyed by owner on a server."
The second answer names n, names the cost, names the benefit the array gives for free, and names two requirements that would flip it. A reviewer can disagree with a specific clause. The first answer can only be agreed with.
What a blank tells you to do
A blank on any question is a location, and the decision below maps it. The cost column is honest: going back to a stage is slower than looking up the answer, and it is the only thing that makes the next question answerable without looking.
Which question was blank, and where does it send you?
when You can list the fields but not say what each one protects against.
cost Back to the state canvas: every field challenged with keep / derive / drop / depends and the failure each verdict prevents. One sitting.
when You know the array works and cannot name the size or requirement at which it stops being right.
cost Back to representation: the two structures side by side, the complexity per operation, and the DSA lesson on hash maps for the O(1) average claim.
when You cannot point at the line, or you answered the modification with "add an if".
cost Back to rules and examples: rule → validation → code for the invariant, the example that discovered it, the test it became. Then the flowchart to place the new diamond.
when You can say "it would not survive a reload" and nothing about what appears when it does.
cost Forward, not back: the engineering track — persistence levels and the failure modes each one introduces.
The implementation ladder
Concept, examples, pseudocode, code, tests, production — for the concept this lesson is about. Code is the fourth tab, not the first.
Shopping Cart = A temporary collection of products the user intends to purchase, held between browsing and checkout.
- Does a cart have identity? Yes, weakly. Two carts with the same items are still two carts, because each belongs to someone and will become a different order. It needs an id once it leaves memory; in memory the variable is the identity.
- Who owns it? A shopper — a logged-in user or an anonymous session. The owner is part of the state because "my cart" has to be findable again.
- How long does it exist? From the first add until checkout or abandonment. Whether it survives a reload, a closed browser or a login is not a property of the concept; it is a persistence decision made later, and each answer changes where the cart lives.
- Should it survive reload? Usually yes for a store, usually no for a demo. V1 in memory says no; V2 browser storage says yes on one device; V3 server storage says yes everywhere the user is logged in.
- Should it survive login? Only if an anonymous cart and a logged-in cart are merged — a rule that does not exist in V1 and appears as a modification later.
- itemscollection of CartItemkeepThe cart is its items; without them nothing else means anything.
- items[].productIdidkeepThe reference to what is being bought. The catalog owns the product; the cart only points at it.
- items[].quantityinteger > 0keepTwo laptops is one entry with quantity 2, not two entries — the rule "one entry per product" needs a quantity to hold.
- owneruser id or session iddependsSo the cart can be found again by the person it belongs to.
- items[].productNamestringderiveIt would be convenient to render the cart without a catalog lookup.
- items[].pricemoneydependsThe total needs a price per item.
- totalmoneydropEvery screen shows the total.
- currencycodedependsPrices need a currency to be added.
- createdAttimestampdropAbandoned carts might be expired or emailed about.
- update Add item — the updated cart
- delete Remove item — the updated cart
- update Change quantity — the updated cart
- read View items — the list of entries — product id and quantity — for rendering
- domain Calculate total — the sum of price × quantity over the entries
- delete Clear cart — the empty cart
- • Every quantity is greater than zero.
- • One logical entry per product.
- • The total is never negative.
- • An unknown product cannot be added.
- • Quantity cannot exceed available stock — if inventory is enforced here.
How to do it
Most important first.
- Answer the six in writing before looking at the concept's own answers; then compare. A match in wording is worth less than a match in consequence.
- For each answer, add the sentence "and I would change this if…". An answer with no such sentence was memorised.
- For the third question, point at the line — literally, the find — and say which example proves it: add-again (Input → Lookup → Branch → Mutation → Output).
- For the fourth, annotate rather than assert: O(n) for the array scan, O(1) average for a map, with n being the number of distinct products in one cart — and then say why n is small (Complexity, Annotated Not Asserted).
- Run the check again after a modification. The answers to two, five and six change when the cart moves to a database; if yours did not, the modification was pasted (Understanding Is Demonstrated by Modification).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Product id, not name: a name stored in the cart is a copy of the catalog's name, and the concept's field verdict says derive — a rename would leave stale carts. Would change if: the cart became an order, where the name and price at purchase time must be snapshotted. That last clause is the understanding; the concept's own price field carries the same tradeoff.
- Array, not map: the find is an O(n) scan and n is the number of distinct products a shopper has in one cart — a handful — so the scan is invisible and the array renders in insertion order for free. Would switch at: a wishlist with thousands of entries, or when uniqueness must be structural rather than enforced in code. Both are in the concept's map representation; the size is the answer the reference does not say out loud.
- Quantity may not exceed 10: a new rule ("quantity ≤ 10"), two new examples (at 10, edge; at 11, invalid), the check placed after the find in addItem — because it needs the existing quantity — and in changeQuantity, and two tests from the two examples. Four artefacts, all named. A learner who answers "add an if" has named one of them.
How you know it worked
What now exists that did not before, and what question you can now ask.
- All six questions have written answers, and each answer ends with the condition under which it would flip.
- A blank was found and it turned into a trip to one stage — not a re-read of the whole reference.
- The answer to the complexity question names n and says why it is small, rather than reciting O(n).
- The answers changed when the cart changed, and you noticed which ones.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?Which of the six questions can I answer with a consequence and a condition, and which only with a definition?
- ?Which stage of the loop does my blank point at — state, representation, rules, complexity, engineering, or modification?
- ?What would have to be true about the store for my answer to the representation question to flip?
- ?Did my answers change the last time the cart changed — and should they have?
What can go wrong
- Grading yourself on the reference's wording. The concept's answers are one good form; an answer with a different route to the same consequence is understanding, and the same words with no consequence is not.
- Treating a blank as failure and restarting the whole loop. The blank points at one stage; the other five are fine, and redoing them is motion.
- Asking the six once. They are cheap and they are the check that a modification was derived; the third time through is where the persistence answer stops being the concept's and becomes yours.
- Answering the sixth question with code. "Which invariant, example, line and test change" has four parts, and a diff shows one of them.
- Six written answers after a finished cart feels like homework after the exam; it takes a short sitting and replaces the review question you could not answer.
- A check that admits "I derived it differently" is harder to grade than a checklist; that is the price of testing understanding rather than recall.
- Rerunning the check after every modification is overhead a team would not carry for every change; the habit is for the changes that touch a rule or a representation.
- "If I can answer the six, I am done learning the cart." The six are the floor; the rebuild and the modifications in the next two lessons are where the answers get used. A check that ends in answers and not in a change is a quiz.
- "These are interview questions." They are the questions the code raises, asked of its author. An interviewer who asks "why an array?" wants the same consequence-and-condition; the difference is that here the cart is yours and the answer changes what you do next.
- "The reference's answers are the answers." They are the answers for the reference's store. A store with a wishlist of thousands has a different answer to question two, and the check is meant to make you say so.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALEvery concept in the catalog carries an understanding check; the six questions here are the cart's, and every other concept's six map to the same stages of the loop.
- STAGE-SPECIFICThe check is for the moment a concept is called done, and again after each modification; asking it before the code exists tests the wrong thing, because several answers are about lines.
- ILLUSTRATIVEThe maximum of 10, the handful of items and the wishlist with thousands of entries are the concept's own figures and are for the shape of the argument, not measurements.
Where the depth lives
This domain asks the question and hands the answer off by name.