All writing

The Interview Round Nobody Prepares For

Krisalay KumarAugust 22, 20263 min read

A candidate posts in a Discord channel at 2 a.m.: they have an interview coming up, they've found two articles about implementing a memory allocator, and they're asking whether anyone can suggest more problems like it before they go to sleep.

That message is the reason this post exists — and the reason ThyncLabs now runs low-level design mocks.

Two interviews, three rounds

Ask an engineer how they're preparing and you'll hear about two things: LeetCode grinding, and system design. Both have industries built around them — problem banks, courses, mock platforms, YouTube channels with millions of views.

Then they sit a loop and meet a third round. Someone says "design a parking lot" or "implement a thread pool" and expects working code in 45 minutes, with the design defended out loud along the way.

It isn't a coding round: there's no clever trick to find, and the algorithm is usually obvious. It isn't a system design round either: no load balancers, no sharding, nothing to draw. It's the one in between — and it grades something neither of the other two touches.

What it actually measures

An LLD round grades structure. Where responsibilities live. What the pieces promise each other. Whether the thing you built survives contact with a changed requirement.

That last part is the round's open secret. Every good LLD interviewer engineers the same moment: somewhere past the midpoint, they change the problem. Now the lot needs a new kind of spot. Now two threads call your allocator at once. A good design bends in one place. A poor one cracks everywhere — and both candidates wrote code that worked five minutes earlier.

It comes in two flavors, and companies rarely tell you which you'll get. Machine coding — parking lots, rate limiters, Splitwise — is about class modeling and extensibility, and it's a standard round at essentially every product-company loop in India. Systems programming — allocators, thread pools, ring buffers — is about memory layout, invariants, and concurrency, and it rules at infrastructure companies, trading firms, and anywhere the product is the low-level software.

Why the preparation ecosystem is thin

Static content struggles with this round in a way it doesn't struggle with DSA.

A LeetCode problem has a right answer you can publish. A system design problem has a canonical architecture you can diagram. An LLD problem has neither — the whole evaluation lives in a conversation. Did you ask what the interface guarantees before you designed to it? Can you say why this decomposition and not that one? When the requirement moved, did your design move with it, or did you spend four minutes defending the version that no longer fit?

You can read an article about the parking lot problem and still fail the parking lot round. That gap is exactly what a mock closes — and it's why the candidate at 2 a.m. was collecting articles when what they needed was reps.

What we built

ThyncLabs now runs low-level design mocks across both flavors — 21 problems at launch, from the canonical parking lot to memory allocators, thread pools, and an order matching engine.

The round runs the way a real one does. You get a deliberately thin prompt and the requirements are yours to draw out — that conversation is graded, not a preamble to the grading. You state your design in words before you write it. You implement the core on a shared page while thinking out loud. Then the interviewer changes something, on purpose, and you find out what your design is made of. The report scores you across requirements, design quality, how the extension landed, complexity honesty, and communication — and it names the principle behind each note, because "your pricing logic forced three classes to change" teaches more when it also says single responsibility.

Alongside the mocks there's a free course — 111 lessons across both flavors, every problem worked end to end: the requirements conversation, the model in words, the implementation, and the trade-off space around it.

One thing the course deliberately withholds: the twist. Every problem's mid-interview requirement change lives only in the interviewer's brief. You can read the entire course cover to cover and still meet something you haven't seen when you sit the round — which is the point, because that's what the real thing does.

Where to start

If you have a loop coming up and you've never sat an LLD round, start with the foundations chapter — it's six lessons on what the round measures and how to convert design knowledge into interview signal. Then take one mock. The report will tell you which of the four acts is leaking points, and that's a far better study plan than another article.

The interview you're least prepared for is usually the one you didn't know was on the schedule.

Practice the interview, not just the problem.

Sit a live AI mock — DSA, low-level design, or system design — and get a scored report the moment you finish. Two free every month.

Take a free mock →