Swiggy Machine Coding Round: Format, Timing and What Gets Marked (2026)

Swiggy's machine coding round is where the loop is actually decided. Candidates who clear the online assessment and the data structures round on merit are regularly turned down here — the round rewards a completely different skill from the one most interview preparation builds, and almost nobody practises it under a clock.

This guide covers what the round looks like, how long you get, the rubric interviewers mark against, and the failure modes that end otherwise strong loops. If you want to practise against the design problems evidenced at Swiggy, Swiggy's interview kit holds nine low-level design problems attributed to the company, each with an editorial and an AI-evaluated practice mode.

---

Where the machine coding round sits in Swiggy's loop

Swiggy runs a multi-stage loop for software engineering roles. The exact number of rounds varies by level and team, but the reported sequence is consistent:

Stage	Format	What it screens
Online assessment	~3 medium-difficulty algorithmic problems	Baseline coding ability, filter volume
Data structures & algorithms	Live coding with an engineer	Problem solving, complexity reasoning
Machine coding	60–120 min, build a working system	Design under time pressure, code quality
Low-level design	Discussion-led class and interaction design	Abstraction, extensibility, trade-offs
Engineering manager / hiring manager	Behavioural + past project depth	Ownership, collaboration, level fit

The two middle rounds are the ones people underestimate. The algorithmic rounds are familiar territory — most candidates have spent months on that shape of problem. The machine coding round asks for something structurally different: a small but complete, working, well-factored system, written from a blank file, in one sitting.

💡 Pro Tip: Treat the machine coding round as a separate discipline from algorithmic practice, with its own preparation track. Strong algorithmic performance does not transfer to it, and candidates are routinely surprised by that.

---

What the round actually looks like

You get a short, deliberately under-specified problem statement — a parking lot, a splitwise-style ledger, a ride matcher, a food-ordering flow, an inventory or rate-limiting service. You then have roughly 60 to 120 minutes to produce running code.

The specifics that matter:

• You write real, executable code. Not pseudocode, not a diagram. It compiles and it runs.
• You choose the language. Use the one you are fastest in, not the one you think sounds impressive.
• No database, no framework, no network. In-memory state is expected and encouraged. Reaching for Spring or Django wastes the clock.
• A driver or test harness is expected. Something that demonstrates the system working end to end.
• The spec is intentionally incomplete. The gaps are part of the test.

That last point is the one candidates most often miss. An under-specified prompt is not an oversight — it is checking whether you ask, or whether you silently invent requirements and build the wrong thing.

⚠️ Important: Spend the first five minutes clarifying scope and stating your assumptions out loud. Interviewers consistently report this as a positive signal, and it costs you almost nothing on the clock.

---

The rubric: what interviewers actually mark

Machine coding rounds are marked against a rubric that is fairly consistent across companies that run them. Roughly in order of weight:

1. It works. A running system that covers the core flow beats an elegant half-finished abstraction every time. Get something end to end early, then improve it.

2. Class design and separation of concerns. Are responsibilities in sensible places? Does one class do one thing? Is there a domain model at all, or is everything in a single controller-shaped blob?

3. Extensibility against the obvious next requirement. Interviewers frequently ask, near the end, "how would you add X?" A design where the answer is "add a new class implementing this interface" scores far higher than one where the answer is "change these four methods."

4. Correct use of abstractions. Interfaces where behaviour genuinely varies. Composition over inheritance. Enums and value objects rather than loose strings and magic numbers.

5. Readability. Clear naming, small methods, consistent style. This is a proxy for what your production code will look like.

6. A working demonstration. A main method or test harness that exercises the flows.

✅ Do: Build the smallest working version of the core flow first, then layer on structure. ❌ Don't: Spend forty minutes on an elaborate class hierarchy before a single line of it runs.

---

How to structure 90 minutes

A rough allocation that consistently works:

Time	Focus
0–5 min	Clarify the spec. State assumptions and scope explicitly.
5–15 min	Sketch the domain model — the entities, and the two or three interfaces where behaviour will vary.
15–60 min	Implement the core flow end to end. Keep it running at all times.
60–75 min	Handle edge cases; extract the abstractions the design is asking for.
75–85 min	Write the driver or tests that demonstrate it working.
85–90 min	Walk through the design, and name what you would do with more time.

The final five minutes matter more than their share suggests. Explicitly naming your trade-offs — what you deliberately left out and why — converts an incomplete solution into evidence of judgement. Our guide on explaining your thought process clearly in coding interviews covers how to narrate this without losing time.

---

The failure modes that end loops

Across reported experiences, the same handful of mistakes recur:

• Nothing runs at the end. The single most common failure. A beautiful design that does not execute reads as a candidate who cannot ship.
• Over-engineering the first ten minutes. Factories, builders and abstract base classes before the core flow exists.
• Building the wrong thing. The consequence of not clarifying the under-specified spec.
• Everything in one class. No domain model, all logic in a single procedural blob.
• Silence. The interviewer cannot mark reasoning they never heard.
• Ignoring the extension question. Answering "how would you add X?" with a rewrite rather than a plug-in point.

Practising against real problems under a real clock is the only reliable fix. The nine low-level design problems evidenced at Swiggy are a direct way to do that — each with a worked editorial, and an AI mock interview in LLD mode that will push back on your design the way an interviewer does.

---

Preparing for the rest of the loop

The machine coding and LLD rounds decide the outcome, but they are not the whole loop.

The algorithmic rounds — the online assessment and the data structures round — reward pattern recognition rather than volume. Working through a structured pattern set is far more efficient than grinding problem lists; the DSA Patterns Sheet is free to browse and organises the material by the pattern each problem actually tests. If you are calibrating how much of this you need, how much DSA is enough for product-based company interviews is a useful reference point.

The design rounds benefit from understanding the distinction the industry draws between class-level and architecture-level design — low-level design vs high-level design covers what each round expects. The Low Level Design Sheet is also free to browse and is the fastest way to build the vocabulary these rounds assume.

The engineering manager round is a genuine evaluation, not a formality. Prepare two or three projects you can discuss at depth: what you owned, what went wrong, and what you would change.

💡 Pro Tip: Practise machine coding by hand, on a timer, without an AI assistant. The round is timed and unassisted; practice that does not match those constraints builds false confidence.

---

A two-week preparation plan

Week 1 — build the vocabulary. Work through core object-oriented design patterns and the class-design idioms these rounds assume. Implement two design problems end to end without a time limit, focusing on getting the structure right. Read the editorials afterwards and compare against your own decisions.

Week 2 — build the speed. Switch to a 90-minute clock. One problem per session, running code by the end, no exceptions. Alternate between problems you have seen and problems you have not. Finish each session by writing down what you would have done with another thirty minutes — this is the exact muscle the final five minutes of the real round uses.

Throughout both weeks, keep a light algorithmic practice habit running so the earlier rounds stay sharp. In-browser code practice with AI feedback works well for this in short sessions.

---

Frequently asked questions

How long is Swiggy's machine coding round? Reported durations cluster between 60 and 120 minutes, with 90 minutes common. Confirm the exact length with your recruiter — it varies by level and team.

Can I use my own IDE? Usually yes, and you should. Use the editor and language you are fastest in. Confirm with your recruiter beforehand.

Do I need a database? No. In-memory state is expected. Introducing persistence usually costs time without earning marks.

Should I write tests? Write enough to demonstrate the system working — a driver exercising the main flows is typically sufficient. Comprehensive unit tests are a bonus, not a requirement, and rarely worth the clock unless you finish early.

Is the LLD round separate from machine coding? They are typically distinct. Machine coding is a build exercise producing running code; the LLD round is discussion-led, focused on class structure, relationships and trade-offs. Both examine design thinking, in different formats.

Does Swiggy ask data structures and algorithms questions too? Yes. The online assessment and a dedicated data structures round both come before the design rounds. Pattern-based preparation is the efficient route through them.

What languages can I use? Any mainstream language you are fluent in — Java, Python, C++, Go, JavaScript and C# are all commonly used. Fluency matters more than the choice.

How much does the machine coding round count? Reported experiences consistently describe the design rounds as the decisive stage of Swiggy's loop, with candidates who performed well algorithmically still being turned down at this point.

---

Start practising

The machine coding round rewards a specific, trainable skill: producing clean, working, extensible code from a blank file under time pressure. It is trainable — but only by doing it, on a clock, repeatedly.

Open Swiggy's interview kit to work through the nine low-level design problems evidenced at Swiggy, each with an editorial and AI-evaluated practice. Pair it with an LLD mock interview to rehearse the discussion round, and browse the free Low Level Design Sheet to fill the gaps as you find them.

Interview formats change. Confirm timings and round structure with your recruiter, and check Swiggy's careers site for current openings and process details.