Why a paragraph is a different exercise
A named machine coding problem such as a parking lot or a bill splitter arrives with a shape you have seen before. The parking lot page and the bill-splitting page both cover how to scope a familiar problem in the first few minutes. A paragraph does not come with a shape. It reads like a ticket or a message from a product owner, and the rules are buried inside ordinary sentences.
That is deliberately closer to the job. Some engineers pass algorithm screens and then struggle to turn a written requirement into working code, and this format is built to catch exactly that. The skill being tested is requirements analysis under time pressure: finding the rules, noticing where they interact, and building those first.
A paragraph to work from
We run a few gyms. Members book places in classes through our app. Each class has a capacity the instructor sets, and once it is full, members can join a waitlist. If someone with a place cancels more than twelve hours before the start, the first person on the waitlist gets the place automatically. Later cancellations free the place but nobody is promoted, since they would not see the notice in time. Premium members can book fourteen days ahead, everyone else seven. We text a reminder the evening before. Eventually we would like instructors to see attendance history.
What you write first: the rules, numbered
Requirements analysis here is short and concrete. Before any class, write the rule list in a comment or on the shared screen. Each line is a sentence you could turn into a test.
| # | Rule | Decision |
|---|
| R1 | A class has a fixed capacity | Build, a constructor argument |
| R2 | Booking a full class puts the member on a waitlist, in order of joining | Build |
| R3 | A cancellation more than 12 hours before start promotes the first waitlisted member | Build, this is the core |
| R4 | A later cancellation frees the place and promotes nobody | Build |
| R5 | Premium members book up to 14 days ahead, others 7 | Build, small |
| R6 | Reminder text the evening before | Out, a side channel no rule depends on |
| R7 | Instructors see attendance history | Out, introduced with "eventually" |
Two things in that table are worth saying aloud. First, "a few gyms", "our app" and "the instructor" do not appear as rules. They are context. Building a Gym, an App or an Instructor class would add structure with no behaviour. Second, the rule list exposes a question the prose hides: does R5 apply to promotion? If a standard member is waitlisted for a class nine days away and a place opens, are they promoted outside their seven-day window? That is a real conflict between two sentences, and an interviewer will notice whether you found it. Ask, or pick an answer and say it.
Then the first test, for the rule that interacts most
R3 touches capacity, the waitlist order, time and cancellation together, so it is where a wrong model shows up first. Write it as a test before the class it exercises exists.
@Test
void earlyCancellationPromotesFirstWaitlistedMember {
Instant.parse();
(start, );
spin.book(ana, start.minus(Duration.ofDays()));
spin.book(ben, start.minus(Duration.ofDays()));
spin.book(cara, start.minus(Duration.ofDays()));
spin.cancel(ana, start.minus(Duration.ofHours()));
assertEquals(Set.of(ben, cara), spin.attendees());
assertTrue(spin.waitlist().isEmpty());
}
A second test for R4 follows in a minute, with the cancellation at eleven hours and the waitlist left untouched. With those two passing, the hard part of the problem is done, and everything else is additive. In a ninety-minute machine coding slot, reaching this point in the first half hour leaves room for R5 and for the questions the interviewer adds during review.
The rule list is also where your requirements analysis earns its keep later. When the interviewer changes a rule, you can point at the line it replaces and the test that will fail.
What you deliberately do not build, and how you say so
Each exclusion should be spoken with its reason, because a missing feature with a reason reads as scoping and one without reads as running out of time.
The reminder text is out because no rule depends on it. If you want to show where it would attach, a promotion can return or record an event that a notifier could consume later. Do not write the notifier. Attendance history is out because the paragraph itself defers it. Persistence, authentication and the app are out because the paragraph describes behaviour, not infrastructure. Multiple gyms are out because no rule differs between them.
This is a different skill from announcing your approach before typing. That page is about explaining how you will build a class you have already chosen. This one is about deciding which classes and rules deserve to exist at all.
Modelling the nouns instead of the rules
The common failure is to read the paragraph, underline every noun, and create a class for each: Gym, Member, Instructor, Class, Waitlist, Reminder, App. Twenty minutes later there are seven files of fields and getters, and the twelve-hour promotion rule, which is the actual requirement, has no home. It ends up as a method on whichever class was open when the candidate remembered it.
Interviewers recognise this quickly, because it is requirements analysis skipped rather than done. A noun list shows the candidate can read. A rule list shows they can turn a requirement into behaviour, and that is what the paragraph format exists to grade. Start from the verbs and the conditions: book, cancel, promote, more than twelve hours, once it is full. The classes you need are the ones those rules have to live in.
Turn the paragraph into rules before you turn it into classes. The first code you write should be a test that would fail if you had misunderstood the hardest sentence.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).