I had 800-something LeetCode problems solved when I interviewed at Amazon. I figured I was ready. Two-pointer, sliding window, DP, graphs — I'd drilled all of it. I could smell a "this is a heap problem" from the second line of a prompt.
Then they handed me a repository. Not a blank editor — an actual codebase that was partly built, and the task was to implement a couple of new features and debug the existing ones that were broken. Real code I hadn't written, a test suite I had to get green, and a clock running.
I froze. Not because it was hard in an algorithmic sense. It wasn't. I froze because nothing I'd practiced had prepared me to open a codebase I didn't write, understand what it was doing, add to it without breaking it, and fix logic that was already wrong.
That gap — between what LeetCode trains and what machine coding rounds test — is the thing nobody warns you about. Especially in India, where the machine coding / LLD round has quietly become the round that actually decides SDE-1 and SDE-2 offers at most product companies.
For context on where this is coming from: I'm a senior software engineer at Atlassian now, and before that I worked at Flipkart, Coupang, and Snabbit. I've been on both sides of these rounds — sweating through them as a candidate and running them as an interviewer. I learned a lot at every one of those places, most of it the hard way, and a fair amount of it was unlearning the idea that being good at algorithms made me good at this.
What LeetCode is actually good at
I want to be fair to LeetCode, because the internet loves to dunk on it and that's lazy.
LeetCode measures one specific skill really well: can you take a clean, self-contained problem statement and produce an efficient algorithm from a blank editor. That's a real skill. It filters for people who can think about complexity, spot the right data structure, and reason about correctness on paper. It's also a decent proxy for "did you take DS&A seriously," which is why companies keep using it for the first screen.
So no, the 800 problems weren't wasted. They just measured a thing that stops being the bottleneck the moment you're past the phone screen.
What a machine coding round actually is
A machine coding round hands you something closer to your actual job. You get a working-ish codebase — a service for bookings, or payments, or inventory — and the work is to extend it, fix it, or make a suite of failing tests go green. You bring your own language and your own structure. The interviewer is watching how you build, not whether you remember Kadane's algorithm.
The flavor that caught me off guard — the Amazon one — is the one I now see most often: a repository-based round. Instead of "design and build X from a blank file," it's "here's a repo that mostly works: add these features, fix the ones that are broken, get the tests green." That's the version that maps most directly to the job, and it's brutal if the only thing you've practiced is generating code from scratch, because generating was never the hard part.
The skills it's grading are the ones you use every day as an engineer and almost never practice deliberately:
- Reading code you didn't write. Most of the round is comprehension before you type a single line. Where does this break? What's the contract this function is supposed to honor?
-
Debugging under a clock. A test says
expected 200, got 500. LeetCode never once made you sit with a stack trace. - Business logic and edge cases. A hotel booking where a guest checking out on the 10th must not block a guest checking in on the 10th. Half-open intervals. Off-by-one at a boundary is exactly the bug that ships to prod and double-books a room.
- Code someone else can read. Naming, structure, keeping a rejected request from mutating state. Nobody grades your variable names on LeetCode.
None of that shows up in a DP problem. All of it shows up on day one of the job. That's the whole point of the round.
Why the usual prep doesn't transfer
Here's the trap. When people hear "machine coding," they go read more LLD theory. They memorize the SOLID principles, watch a factory-pattern video, read about how to design a parking lot. Then they walk in and still stall, because they've been studying descriptions of building software instead of building it.
It's the difference between reading about swimming and being in the water. You can recite the strokes perfectly and still sink the first time someone throws you in.
Machine coding is a doing skill. The only prep that transfers is repetitions of the actual thing: open an unfamiliar repo, understand it, make it correct against a real test suite, on a timer. You need the muscle memory of "tests are red, where do I start" so that when it happens in the interview, your hands already know the motion.
How I actually practice for it now
After that first round went badly, I changed how I prepped, and later I ended up building a tool around it because I couldn't find one that did this well.
The practical version, tool or no tool:
- Practice in real repositories, not editors. Clone something, break it, fix it. Pull request reviews at work are secretly great practice for the comprehension half.
- Always run against tests. "It looks right" is how you fail. Green tests are the only honest signal, same as the real round.
- Time yourself. The clock is half the difficulty. An unhurried fix proves nothing about a 90-minute round.
- Rotate problem types. Concurrency, date logic, idempotency, pagination contracts — the categories that actually recur.
If you want a running start, I put a set of these problem statements up here, free to read and use however you like: github.com/sasrivas25/machine-coding-problems. And the thing I built, Gronex, lets you solve them inside a real repo against a failing test suite in the browser — which is as close to the actual round as I could make it. Use it, don't use it, either way the method above is what moved the needle for me.
The short version
LeetCode gets you the interview. It doesn't get you the offer anymore, at least not at the companies running machine coding rounds — and that's most of them now. The round after the algorithm screen is testing whether you can engineer, and the only way to get good at that is to do it, on a clock, against real tests, over and over.
If you're grinding DSA right now and haven't touched a single machine coding rep, that's the highest-leverage switch you can make this week.
What was your machine coding round like? Curious whether other people froze the same way I did.
Top comments (0)