Machine-Coding-Round: a catalogue of low-level design problems with worked answers

What the repository is

Machine-Coding-Round is described as all low-level design and machine coding rounds questions and answers, and the README is a catalogue rather than a project. Each entry is a problem with a link to its problem statement, a link to the code, and a link to a video tutorial, which is a structure designed for someone preparing for an interview rather than someone shipping a service. The entry point is a YouTube channel link, so the video work is treated as part of the deliverable rather than as an afterthought. The primary language is Java, the repository listing records the licence as unknown, and the last push was on 2026-04-13. There are no GitHub releases, which is consistent with a repository whose artefacts are directories of exercise code. The README ends with a line saying more will come, so the catalogue is explicitly incomplete, and that is worth knowing before you plan a study schedule around it. The distinction that makes the repository useful is that the answers are code, not prose. A low-level design answer in an interview is judged on the class structure and the reasoning at the whiteboard, and a repository of finished Java code lets you compare your sketch against a working version.

The ride-hailing and elevator problems

The first entries are the ones with the most complete content, and they show what a finished entry in this catalogue looks like. The Uber rider flow has a problem statement, a code directory and a video tutorial, all three present. The Uber driver flow entry adds two more subjects to the same shape, naming OTP and surge pricing alongside the driver flow, and it points at a separate code directory. The elevator entry follows the same pattern. That the two Uber entries link to the same problem statement path is a small inconsistency in the catalogue, and it is the kind of thing that appears in a personal repository that is edited over time rather than maintained like a product. The set of three together is a good sampler for the format, because a rider flow asks about state machine and notification design, a driver flow with OTP asks about one-time passcodes and matching, and surge pricing asks about a rule engine with time and demand inputs, so between them they cover three quite different shapes of interview question.

Games and the two variants of snake and ladder

Snake and Ladder appears twice, which is the most interesting editorial decision in the catalogue. The first entry is the plain version, with a problem statement on an external practice site, a code directory named for the game and a video tutorial. The second is the optimal variant, with the same problem statement link, a different code directory named with the optimal suffix, and its own video. Presenting the same problem twice with different solutions is a deliberate teaching structure, since the naive solution and the better solution are two different pieces of code for one specification, and comparing them is how you see what the improvement actually buys. The Tic-Tac-Toe entry is a smaller one, with the code noted simply as being in this repository rather than linked to a directory, which suggests the solution is smaller or less separated out than the others. The Bowling Alley entry returns to the standard shape with a problem statement, a code directory and a video, and the name of the problem itself points at the state machine that a bowling game needs, with frames, rolls and scoring.

The product-flavoured problems

Several entries are recognisable product designs, and these tend to be the ones where the README records a specific external practice problem rather than a link to a file in the repository. Split Wise has a problem statement, a code directory and two videos, and the pair of videos is labelled as an old one and a new one with a better structure, which tells you the earlier solution was superseded and that the author was explicit about it. Parking Lot has the same three-part structure. Trello has a problem statement and a code directory, with its video marked as yet to be updated, so the entry is half finished. Token Bucket is the emptiest, with both the problem statement and the video marked as yet to be updated while the code directory is present, so what exists is the implementation without the framing. That contrast is instructive in itself, since it shows what a reader gets from a completed entry and what they get from an incomplete one. The README's own framing for these is a low-level design question, and the external practice site links suggest they are drawn from a shared pool of machine coding prompts rather than invented by the author.

The systems problems, which are the hardest entries

The final group is the systems design set, and it is the part of the catalogue that goes beyond a single class. The Rate Limiter entry states its problem as design and develop a rate limiter, with a code directory and a video. The Key Value Store Like Redis entry states its problem as designing an in-memory key value store, again with a code directory and a video, and the title names Redis as the model to imitate, which tells you the expected features are the ones Redis users rely on. The FLIPMED entry is the odd one out, because its problem statement, its code and its video all live in a separate repository rather than in this one, so it is an index entry pointing elsewhere. There is also a section for all design patterns problems and solutions, and it points to a different repository entirely, this one written in Go rather than Java, with a playlist rather than a single video. Two separate links to a Go repository is a useful signal about how the author organises the work, since the design patterns work is clearly considered distinct from the Java machine coding work.

The repository layout and what it reveals

The top level of the tree is broader than the README's list of entries suggests, and that is where the interesting information is. Alongside the src/ directory, which holds the Java packages named for the problems, there are a set of directories that read like system design exercises rather than machine coding rounds. There is chess-game/, design-cache/, doctor-appointment-booking-system/, kafka-system/, message-queue-system/, order-management-system/, social-media-network-system/, splitwise-system/, stock-broker-application/, task-schedule-system/, uber-low-level-design/, uber-pool-booking-system/ and virtual-bank-designs-for-payouts/. So the repository contains a second layer of larger exercises that the README index does not fully describe. The names are worth reading individually, because they show what the author thinks of as a system design problem, and the list covers a cache, a message queue, Kafka, a stock broker with orders, a doctor booking system, a task scheduler, a social network and a payment payout flow. The Java package layout follows the com.lavakumar convention with one package per problem, so uber_rider_flow, uber_with_driver_flow, elevator, snakeandladder, snakeandladderoptimal, splitwise, parkinglot, tokenbucket, trello, bowlingalley, ratelimiter and inmemorykvstore are each a directory under src/com/lavakumar. The IntelliJ project file and the .idea/ directory are checked in, which is a sign the repository was worked on in IntelliJ rather than built from a command line.

Where Machine-Coding-Round is the wrong resource

The first limit is that it is a personal answer key rather than a curated one, so there is no signal about whether a given solution is the one an interviewer would accept. Two people can both pass an interview with different class structures, and the repository does not say which style it is aiming at beyond the naming conventions and the occasional comment about a better structure. The second is that it is incomplete in a way that is visible from the README, with problem statements and videos marked as yet to be updated for Token Bucket and Trello and the video for the Uber driver flow and for other entries being the older one, so a reader cannot tell what is finished and what is a placeholder except by looking. The third is the framing itself. These are interview exercises, and interview exercises optimise for the discussion they provoke rather than for correctness under concurrency, failure and scale, so a solution that handles the happy path in a few classes may be exactly what an interviewer wants and exactly what you would not ship. The fourth is that the videos are the explanation and they live on YouTube, so the written record in the repository is thin by design and a reader without video access gets problem statements and code with little of the reasoning that made the design decisions. The fifth is the language and platform concentration. The primary language is Java and the design patterns work is in a separate Go repository, so a reader working in another language gets the problem framing and has to translate the solutions themselves, which is the harder half of the exercise.

Editorial conclusion

Adopt Machine-Coding-Round as a study list if you are preparing for machine coding rounds and want worked Java answers rather than only problem statements. Skip it if you want production libraries, since nothing here is packaged for use. Verify first which problems are fully written up, since the README marks several of them as yet to be updated, and check whether the linked videos and problem statements still match the code in the repository.

Frequently asked questions

Official sources

1. Issues
2. lavakumarThatisetti/Machine-Coding-Round on GitHub
3. README