Before
100 coffees
Sales $400
Variable costs $100
Contribution $300
Fixed costs $200
Harper / Recruiting practice
Practice your case opening.
Define the problem. Decide what you need to learn. Connect evidence to a possible solution.
Practice your opening · original exercise
How would you approach this case?
A café’s total revenue is steady, but profit has fallen. The owner wants to restore profit within three months without reducing service quality.
Talk through what you would investigate first, why it matters, and what evidence would change your approach.
Sign in and return to this answerDictation uses your browser’s speech service, which may process audio remotely. It starts only when you choose Dictate. You can also type or use your phone keyboard’s microphone. Review the text before submitting.
Your next improvement
See the eight reasoning checks
AI feedback evaluates the text of this attempt, not speaking delivery or interview readiness. It may be wrong. Harper does not save answers to your account; provider processing policies apply.
Compare with a worked approach
First clarify how much profit fell and which period we are comparing. Then separate changes in contribution from changes in operating costs. Steady total sales can hide a shift toward lower-margin products, so compare product mix and contribution per item as well as ingredient, waste, staffing and rent costs.
Start with a bridge from last period’s profit to this period’s profit. If ingredient costs explain most of the gap, investigate purchasing and waste before proposing staffing cuts. Test the change against the three-month target and service-quality constraint.
Decision → possible causes → evidence → first test.
Visual deep dive: sales up ≠ profit up
What customers buy changes the result.
Coffee
$4 price − $1 variable cost
$3 contribution
Sandwich
$6 price − $5 variable cost
$1 contribution
Contribution is the money left after variable costs, before fixed costs.
After
80 coffees + 40 sandwiches
Sales $560 (+40%)
Variable costs $280
Contribution $280
Fixed costs $200
Ask what changed: prices, items per transaction, product mix, or costs?
Revenue = transactions × average spend. Items sold and transactions are different measures.
New stores can hide weaker existing stores
Last year: existing stores $1,000.
Existing stores −10%; chain total $1,200, up 20%.
Separate fictional examples. The practice case has steady sales; these examples illustrate why sales alone cannot explain profit.Keep or clear this attempt
Worked example / synthetic practice
Hear the question. Set up the problem.
Practice naming the decision, separating possible causes and choosing a test.
The prompt
“Students sometimes get two room bookings after pressing Reserve again during a delay. How would you reduce duplicates without losing legitimate reservations?”
1 of 5 / Watch a worked setup
What decision is hiding in the prompt?
Decision: choose a change that reduces duplicate bookings.
Constraint: people must still be able to make legitimate reservations.
Unknown: are there two stored bookings, or does one booking appear twice?
Why not start with “disable the button”?
That assumes repeat clicks are the cause. A second click may follow a delayed confirmation, and duplicated display can happen even with one booking. First ask what “duplicate” means.
A useful first question
“Do the two bookings have different booking IDs, or is the same ID shown twice?”
Why it mattersThe answer separates a record-creation problem from a display problem. It changes what you investigate next.
See the whole worked solution
- Define a duplicate and preserve legitimate bookings.
- Compare booking IDs, repeated requests and confirmation timing.
- If a retry creates another record, make the same reservation attempt reuse its existing result.
- Test a delayed reply plus a retry: one booking, recoverable confirmation. Test a genuinely new attempt too.
- If records are already unique, revise the hypothesis and investigate the display.
This is a conceptual investigation, not a complete production system design.
2 of 5 / See the relationship
A waiting screen does not prove a failed booking.
Person / screen
Press Reserve
sends request ↓Booking service checks availability and creates or reuses a booking
returns result ↓Screen shows confirmation
During a delayed reply, the screen can still say “waiting” after the service has created the booking.
Term at this step
API
An interface and rules through which software interacts. Here, it carries a reservation request and its result.
The Reserve button is part of the user interface; it is not itself the API. APIs are not always network services.
Definition · MDN ↗Read the diagram as text
The person presses Reserve. The screen sends a request to the service. The service checks availability and creates or reuses a booking, then returns a result. A delayed result leaves the screen waiting; the stored outcome may already exist.
“Waiting” describes this example’s screen state, not an HTTP status code.
3 of 5 / Complete one missing link
Which evidence separates the explanations?
Possibility A
orA repeated request creates a second booking record.
Possibility B
One stored booking appears twice on screen.
Choose a check, or open the hint for help.
Hint: what observation would change the investigation?
Two stored IDs point toward record creation. One stored ID shown twice points toward display. Click counts and load time alone cannot distinguish those outcomes.
4 of 5 / Finish the test
Prevent a duplicate without blocking a new booking.
Suppose the evidence supports A: a retry creates a second record. The proposed change reuses the result for the same reservation-attempt identifier.
Show the worked test and reasoning
Delay the reply and repeat the identical attempt: require one active booking and recoverable confirmation. Then submit a genuinely new reservation: require it to succeed if available.
Also try conflicting parameters with the same attempt identifier; they must not silently reuse the wrong booking. Rejecting every second click would fail the legitimate-use constraint.
Term at this step
Idempotent
Repeating an identical operation has the same intended server effect as doing it once.
Here: a retry of the same booking attempt creates no additional booking.
Responses can differ. A POST request is not automatically idempotent; the service must implement the behavior.
Definition · MDN ↗5 of 5 / Try changed conditions
One booking. Two confirmation cards.
The service stores one booking, but the screen shows two confirmation cards after refresh. Set up an investigation before opening the worked response.
Compare with a worked response
Decision: show each booking once while keeping every legitimate booking visible. Duplicate records are not supported by the current observation.
Investigate: compare the returned booking IDs with the displayed cards before and after refresh. If the response contains one item but the screen renders two, investigate display state; if the response itself repeats the same ID, investigate response assembly.
Test: refresh and revisit the screen: one card per booking ID, with no legitimate booking disappearing. A second stored booking would change the investigation. Adding record-creation deduplication alone would not resolve the observed display issue.
Review your reasoning against four checks
- Names the decision and the legitimate-use constraint.
- Separates an observation from an assumed cause.
- Chooses evidence that distinguishes explanations.
- States an expected outcome and what would change the approach.
Use these checks to revise your answer. This page does not grade free text or certify mastery.
Try the same reasoning in a different setting
A refund screen says “processed,” but the money is not visible on the card. What does each system know, and which evidence distinguishes a display update, payment processing and settlement delay?
Start by defining what “processed” means in that system. Trace a single refund identifier across status records and stated settlement timing before assuming another refund is needed.
Reset this tab’s draft
Clears only this lab’s lesson answers and framework fields in this tab.
Original synthetic exercise · no account data sent. Browse case types · Framework library
01 / Define the decision
What needs to change—and why?
02 / Separate the questions
Give each bucket one job.
Use two or three buckets. Each should answer a different part of the decision. Leave the third blank if it adds no value.
03 / Connect evidence to action
Keep a copy
Your entries are saved for reloads in this tab when storage is available. They are not sent to Harper or your account. Download before closing the tab.
Your framework will appear here after you fill in the decision and select “Show my framework.”
Concepts / Problem to possible response
Choose a word. Explore the reasoning.
Warm colors mark observed problems. Cool colors mark possible responses. Selecting a word highlights its partner and reveals the evidence to check; a pairing is a hypothesis, not a prescribed answer.
Problem language
Possible responses
Start with what you observe.
Select a word to distinguish the symptom, a possible response, and the question between them.
Word size shows teaching emphasis, not measured frequency. Selected words also have an outline and underline.
Worked examples / Case cube
Turn the case. Change the structure.
Seven case types. Six faces—profit and cost share a face. Rotate, frame your answer, then reveal only what you need.
Swipe or use ← → to rotate through case types
Build your answer before you reveal
Original worked examples for practice. Switching case types hides all answers. These cards do not expose unseen casebook solutions.