All documentation

Coding, design & case rounds

A company interview is a set of rounds, each with a problem and a place to work on it. Choose the round you face next; the interviewer sets the problem, reads your code or your whiteboard as you go, and writes you up the way a hiring committee reads a packet.

Students & job seekers12 min read
Read this with the main guide
Everything in Mock interviews applies here too: the room, speaking your answers, booking a real interviewer and refunds. This page covers what is different about company interviews.

Overview

A civil services board is one long conversation. A company interview is a sequence of separate rounds — a phone screen, then a loop of coding, design and behavioural interviews — and in most of them you are given a problem and expected to work on it in front of the interviewer, thinking aloud.

So each round in the Studio has a format as well as a panel. Coding rounds give you a shared code editor. Design and case rounds open on the whiteboard. Behavioural rounds are a conversation about your own experience. In every format the AI interviewer sets the problem, pins it where you can see it, and follows your work: it reads your code line by line and looks at what you draw.

Companies and rounds

The rounds and their lengths follow each company's published process and candidate reports from 2025–26. Each company has a public page with the detail.

CompanyRounds you can sitWhat stands out
Amazon SDEPhone screen (45–60 min) · Loop: coding (55–60) · System design, SDE II and above (55–60) · Bar Raiser (55–60)A Leadership Principles question opens every round, technical ones included.
Google SWETechnical phone screen · Onsite coding · Googleyness & Leadership · System design, L5 and above (45 min each)Code in a plain editor that does not run it; you test it by hand.
Microsoft SWETechnical screen (45–60) · Loop: coding (45–60) · Design (45–60) · As appropriate (30–45)The screen opens on a project of yours before the problem.
Meta SWEPhone screen, two problems · Onsite coding, two problems · System design · Behavioural (45 min each)Two problems in 45 minutes, so pace matters as much as the idea.
Flipkart SDEMachine coding (90–120) · PSDS, two problems (60) · System design, SDE-2 and above (60) · Hiring manager (45–60)Machine coding wants working, extensible code for a small real system.
Product startup SDEDSA (45–60) · Low-level design / machine coding (60–90) · High-level design (60) · Hiring manager (45)The pattern at Swiggy, Zomato, Razorpay, CRED, PhonePe and similar.
IT services campusTechnical (20–40) · Managerial (15–30) · HR (10–15)TCS, Infosys, Wipro, Accenture, Cognizant: your project, fundamentals, then a short problem.
Consulting caseMcKinsey-style case, interviewer-led (30–40) · BCG / Bain-style case, candidate-led (30–40) · McKinsey PEI (15–20)Structure, numbers and a recommendation, on the whiteboard.
Product managerProduct sense (45) · Execution & metrics (45) · Leadership & drive (30–45)Design something for someone; diagnose a metric; tell the story.

Online assessments — the timed coding tests many companies send before any interview — are tests, not interviews, and are not part of the room.

Before you start

  • Choose the round. The setup page lists every round of that company's process, with its format and length. Sit the one you face next.
  • Choose your programming language, for coding rounds: Python, Java, C++, JavaScript or C. You can change it in the room.
  • Fill in your résumé. The role you are going for, your education and experience, your projects, skills and achievements, and why this company. The interviewer pitches the problem to the level on your résumé, and behavioural questions come from your projects and your work.
  • Full interview only, for coding, design and case rounds: a problem cannot be drilled in five questions. Behavioural rounds can be drilled one area at a time.

A coding round

A coding round runs the way a real one does:

  1. The problem. The interviewer sets it, and it is pinned above the editor (and under Problem in the side panel): a statement, a small worked example and the constraints that matter. Fold it away when you need the room.
  2. Your approach. Talk before you type: the brute force, then the better idea, with its time and space cost. The interviewer asks about the approach before it lets you code, and pushes back on a weak one.
  3. The code. Write it in the editor, saying what you are doing. Your code goes with every answer you give, so the interviewer always reads the latest version — with line numbers, so it can say “on line 12, what happens when the list is empty?”
  4. Testing. In most coding rounds the code is not run, just as in most real screens: the interviewer asks you to walk through an example and the edge cases by hand. This is where most candidates lose marks. The rounds whose real version runs code have a Run button — see Running code.
  5. The follow-up. A harder variant, a different constraint, or a question on how your solution would scale.

Meta's phone screen and onsite coding, and Flipkart's PSDS, set two problems in one round, as those interviews do. Flipkart's machine-coding and a startup's low-level design round ask instead for a small working system — classes, their responsibilities and code that could be extended — and run 60 to 120 minutes.

When the code is the answer
If you have only been typing, press Send code under the editor. It sends the code on its own, without a spoken answer, and the interviewer responds to it. It is only available when the code has changed since you last sent it.

The code editor

  • Syntax highlighting for Python, Java, C++, JavaScript and C, with line numbers, auto-indent, matching brackets and simple word completion. Tab indents.
  • Your code is kept on this device while the interview is open, so a reload does not lose it.
  • Up to 20,000 characters, far more than any interview answer needs.
  • Switch language from the editor's header. The interviewer is told which language it is reading.

Running code

Flipkart's machine coding, a startup's low-level design round and Meta's AI-enabled round run your code, because the real ones do. Press Run above the editor; the output, errors and time taken appear under it, and you can type input for your program.

  • Python and JavaScript run in your browser. Python needs a one-time download the first time you run it.
  • Java, C++ and C are compiled and run on our server.
  • A run is stopped after a few seconds, so an infinite loop can't hang the room; the next run starts fresh.
  • Your last run goes to the interviewer with your next answer, so it can say “your second test fails — why?”

Meta's AI-enabled round

Meta's newer coding round gives you a small codebase with a bug in it and an AI assistant beside the editor. The room sets it up the same way: the starter file loads into the editor, the AI assistant tab opens beside it, and you can run the code. Ask the assistant anything you would ask a colleague — it answers briefly and never writes the whole solution. Up to 15 questions a round. The interviewer sees what you asked and how you used the answers, and that is part of what it assesses.

A system-design round

Design rounds open with the whiteboard in focus and the prompt pinned above it: design a URL shortener, a feed, a ride-matching service. The interviewer expects the shape a real design round has:

  1. Requirements. Ask what is in scope, who the users are and what scale matters, before drawing anything.
  2. A high-level design. Draw the main components and how requests move between them.
  3. A deep dive. The interviewer picks one part — the data model, the cache, the queue — and goes into it.
  4. Scale and failure. What breaks at ten times the load, what happens when a component dies, and what you would trade off.

The interviewer sees the whiteboard. About a second after you stop drawing, the room takes a picture of the board. The next time you answer, the picture goes with your answer, but only if the board has changed since the last one it saw. The picture is small, so label boxes in a few large words and keep arrows clear; a crowded corner will not be read.

Draw and talk
A real interviewer watches you draw and hears you explain it. Say what each box is as you add it. The interviewer reads the picture, but your spoken reasoning is what it scores.

A case round

Case rounds work like design rounds with a business problem: a client's profits are falling, should they enter a market, how big is the market. The case is pinned, the whiteboard is open for your structure and your arithmetic, and the round moves through structure, analysis, the numbers and a recommendation.

  • McKinsey-style, interviewer-led. The interviewer takes you through a set sequence of questions, one part of the case at a time.
  • BCG / Bain-style, candidate-led. You drive: you decide what to look at next and ask for the data you need.
  • McKinsey PEI. The Personal Experience Interview, one story explored in depth: what you did, why, and what happened.

Product manager rounds are cases too: Product sense asks you to design something for someone, Execution & metrics gives you a metric that moved and asks why.

Behavioural rounds

Amazon's Bar Raiser, Google's Googleyness & Leadership, Microsoft's As appropriate, Meta's behavioural interview, a hiring manager, a campus managerial or HR round: these are conversations about what you have done. Each asks for specific stories — a conflict, a failure, a decision with too little data — and follows up until it finds your own part in them.

  • Answer with one real situation, what you did yourself, and the result, with a number where you have one. A general account of how you usually work scores low.
  • At Amazon, questions map to the Leadership Principles, and each is scored as one.
  • Behavioural rounds can be drilled: pick one area and take five questions on it.

The write-up

A company round is written up as the interviewer's feedback to a hiring committee, not as a board's marks. Each of the round's criteria — problem solving, coding, verification, communication; or requirements, depth, trade-offs — is scored out of 10 on a hiring bar:

ScoreMeans
9–10Strong hire — would stand out at this level
7–8Hire — solid, with at most minor gaps
5–6Borderline — got there with help, or uneven
3–4No hire — significant gaps
0–2Absent, or damaging

Hiring bars are high, and an average performance is a 5 or a 6. Code that does not solve the problem cannot score above 5 on problem solving or coding, however clean it looks. The overall verdict uses the same words, from Strong hire down to No hire yet.

Alongside the scores, the report shows:

  • The problem (or problems, or the case) exactly as it was set.
  • Your final code with review notes: your code as you left it, with up to five notes pinned to the lines they are about — a missed edge case on line 14, an unnecessary copy on line 9.
  • The whiteboard as you left it, for design and case rounds.
  • Three fixes and Before the real interview, prepare these.
  • The full transcript, marking each answer that carried your code or a new drawing, each run, and what you asked the assistant.
  • Replay your code. A slider through your code as it grew, from the first line to the last, so you can see where the time went.

With a real interviewer

Real interviewers can take company rounds too: engineers, hiring managers, consultants. When you book, choose the round, and their session and scorecard follow it.

  • Code. In a coding round the code tile opens in focus, and it is shared: you both see every keystroke, and either of you can type. The interviewer may paste the problem in as a comment. Type one at a time; if you both type at once, the last change wins.
  • Whiteboard. Shared, with one pen. Ask for it when you want to draw, and the interviewer hands it over.
  • Run is there when the round allows it, and both of you see the output.
  • The scorecard uses the same criteria as the AI write-up, so the two can be compared, and adds the interviewer's own call — strong hire, hire, no hire or strong no hire — as they would give it in a debrief.
  • Moments. During the interview they can mark a moment (“asked a sharp clarifying question”); each appears in your report at the time it happened.
  • Afterwards the report replays the shared code as it grew and, if the call was recorded with your agreement, includes its transcript and summary.

What it does not do

  • It does not judge your code by test cases. There is no “accepted”. Most rounds don't run code at all, as most real ones don't: the skill being tested is reasoning about code you cannot execute. Where running is allowed, you run your own tests.
  • It does not replay leaked questions. Problems are original, of the kind and difficulty the round asks, rather than copied from a list you could memorise.
  • Online assessments are not part of the room. Group discussions are, as their own round where a selection has one: see Group discussions.

Common questions

Can I write the code in my own editor?
You can paste it in, but practise in the room's editor at least once. Real screens use a plain shared editor, often with no way to run the code, and that feels different from your own setup.

What if the interviewer misreads my code?
Say so, as you would to a person: “line 8 handles that case.” It reads your answer and your code together.

Which round should I start with?
The one you face next. If you have no interview booked yet, the phone screen: it is the round most candidates are cut at.

I am a fresher. Which interview fits?
IT services campus for the mass recruiters, Product startup SDE or a big company's coding rounds for product roles. Put your projects in the résumé form: campus interviews start from them.


Header Logo