Format playbooks

The first filter for most campus and off-campus hiring. In India these tests commonly run on platforms like HackerRank, HackerEarth, Codility, Mercer | Mettl and TCS iON (commonly reported). No human is watching your thinking: only the test cases decide.

• timed, auto-scored

  What it looks like

  facts from the platforms

  • HackerRank: some test cases are hidden, and your score depends on how many test cases pass.
  • Codility: your score is the share of test cases you pass. Algorithm tasks also have performance tests that check speed on big inputs (Big-O).
  • HackerEarth: once you start a test, you can't pause it.
  • Proctored tests may need your webcam (HackerRank, HackerEarth, Mettl) and forbid switching tabs (HackerRank, Mettl).
  • Java is available: HackerRank lists Java 8, 15, 17 and 21; HackerEarth lists Java 8 and 17.

• official pages

  Examples in India

  what they say

  • Amazon's university OA: a coding assessment of about 70 minutes on average.
  • TCS NQT (2025 pattern): one test decides Ninja, Digital or Prime interviews. The advanced section, with 90 minutes of coding, is needed for Digital or Prime.
  • Off-campus challenges can lead to pre-placement interviews: the winning teams of the 2021 Amazon ML Challenge got them.

  train itIndia hiring overview

• our advice

  The OA playbook

  do

  1. Take the platform's practice or mock test first (HackerEarth and Mettl offer one).
  2. Read the input format and limits twice. Limits tell you the Big-O you need.
  3. Submit a correct brute force early: passing some test cases is better than none.
  4. Then optimise for the large hidden cases.
  5. Test the edges yourself: hidden cases love empty input and big numbers.

  avoid

  • Extra debug prints left in the output.
  • Switching tabs in a proctored test.
  • Spending 40 minutes on one question while others sit empty.

  train itedge casesdrills

A live round on video with one engineer and a shared editor. The interviewer can't see your paper, so your words carry everything.

• live, shared editor

  What it looks like

  what they say

  • Meta: the first technical screen is 45 minutes, with two coding problems in about 35 of them, in a shared editor such as CoderPad.
  • Google: for interviews over Meet, you write code in real time in an interview coding document.
  • Microsoft: you use a coding tool where you can run and compile your code.
  • AI tools: Google says they are not permitted. Meta says select roles now include an authorised AI assistant inside CoderPad, and no outside AI tools are allowed. Rules differ, so ask.

• our advice

  The screen playbook

  do

  1. Ask the recruiter: which editor, can the code run, is any AI tool allowed?
  2. Practise in a plain editor with no autocomplete, at least a few times.
  3. Type your examples as comments in the editor, so the interviewer sees them.
  4. Talk more than you would in person. Say what you are looking at.

  avoid

  • Long silences while you think on paper off-camera.
  • Using any tool the interviewer did not allow.

  train itwhat to sayonline round setup

Several rounds in one day (or over a few days), each with a different interviewer. Code may be on a whiteboard, a laptop or a shared doc.

• a loop of rounds

  What it looks like

  what they say

  • Meta's full loop: 4 to 6 interviews of 45 minutes — coding, design and behavioural.
  • Meta: expect about two problems in about 40 minutes. The interviewer won't compile your code.
  • Amazon SDE II: four 55-minute interviews, with at least one system design question.

• our advice + CtCI

  The onsite playbook

  do

  1. Follow the CtCI steps: listen, example, brute force, optimise, walk through, implement, test.
  2. On a whiteboard: draw the example big, start the code top-left, leave space between lines.
  3. Use helper methods. You can say "I will write this helper later".
  4. Treat every round as a fresh start.

  avoid

  • Erasing your example: you need it for the dry run.
  • Carrying a bad round into the next one.

  train itthe 45-minute plan

Commonly reported at Indian product companies, by experienced candidates and by people with only a year or so of experience. Everything here is community-reported: candidates' write-ups, not official pages.

• community-reported

  What it looks like

  what candidates report

  • One design problem, about 90 minutes to a couple of hours. Reported examples: a snake and ladder game, an interview-slot booking system.
  • The code must work and be demoable, not just be on paper.
  • Judged on clean, modular, extensible code with good OOP.
  • Often followed by a code review: "what would you change to add one more type?"
  • Named by candidates at Flipkart, Uber, Swiggy, Ola, Cred and PhonePe.

• our advice

  The machine-coding playbook

  do

  1. Spend the first 10 minutes on requirements. Write them as a short list.
  2. Name the classes and their jobs before writing code.
  3. Get the core flow working first, in memory, with a main that demos it.
  4. Use interfaces where a new type is likely to be added.
  5. Keep 10 minutes at the end to run the demo and tidy names.

  avoid

  • A database or UI nobody asked for.
  • Beautiful design with no working demo.

  train itmachine coding practiceJava OOPdesign data structures