Companies run multiple rounds of coding interviews to predict how a candidate will perform on the job. Each company structures this differently, and the format you walk into directly shapes what to prepare for and how to spend your time during the interview.

This chapter breaks down the main types of coding interviews, the typical timeline from application to offer, and how interviewers actually score what they see.

There are four main interview formats in widespread use.

Phone Screen

This is usually your first live interaction. A phone screen lasts 30 to 60 minutes, typically conducted over a shared online editor like CoderPad, HackerRank, or a Google Doc.

Phone screens act as a filter before the company commits to a full onsite. The problems tend to be in the LeetCode easy to medium range, but the window to solve and explain them is tight.

Onsite (Virtual or In-Person)

If you pass the phone screen, you move to the onsite. This is a block of 4 to 6 interviews spread across a single day (or two half-days for virtual onsites). Each round lasts 45 to 60 minutes and covers a different area.

A typical onsite loop looks like this:

No single round determines the outcome of an onsite. Each interviewer submits independent feedback, and a hiring committee (or hiring manager) reviews the full set of rounds together. A strong performance across most rounds can outweigh a mediocre one.

Live Coding / Machine Coding

Live coding is a variation where you share your screen and write code in a real IDE. Some companies use this instead of (or alongside) a shared editor round. The difference matters because in a real IDE, your code needs to compile and run, not just look correct on a whiteboard. This round checks whether a candidate can write code that compiles, passes test cases, and gets debugged on the spot.

Machine coding is a related but separate round, common at Indian product companies. Instead of a single algorithm, you build a small working component from a loose specification, like an in-memory cache, a parking lot, or a splitwise-style expense tracker. These rounds run longer, often 90 to 120 minutes, and the focus shifts to clean, modular, well-structured code with sensible class design rather than squeezing out the optimal time complexity.

Take-Home Assignments

Take-home assignments give you a project (usually 2 to 6 hours of work) to complete on your own time. You might build a small API, implement a feature, or solve a more complex algorithmic challenge. You typically get 3 to 7 days to submit.

Take-homes test depth over speed. Without time pressure, companies expect cleaner code, better test coverage, and thoughtful architecture. Many take-homes are followed by a review session where you walk through your solution and answer questions about your design choices.

Here is what a typical process looks like at a large tech company.

Startups move faster. You might go from application to offer in two weeks. Larger companies, especially those with hiring committees (Google is the classic example), can take two to three months.

Most large tech companies use structured rubrics during interviews. The rubric scores candidates on several dimensions rather than a single solved-or-not verdict.

The Four Pillars

Correctness is the baseline. Your code should produce the right output for standard inputs and handle edge cases.

Efficiency measures algorithmic awareness: picking O(n log n) over O(n^2) when constraints demand it, and reasoning about the time-space trade-off behind that choice.

Communication measures how clearly the thought process comes through. The approach should be explained before code is written, and decisions should be voiced as they are made.

Problem-solving measures how a candidate handles ambiguity: switching approaches after hitting a dead end, breaking a complex problem into smaller subproblems, and recognizing patterns from problems solved before.

How Rubrics Typically Work

Most companies score each dimension on a scale. Here is a simplified version of what many FAANG-style rubrics look like:

A "Hire" rating does not require perfection. A small bug, a missed edge case, or a single hint can still earn a Hire when the underlying communication and problem-solving were sound.

The interview experience varies significantly between large tech companies and startups, both in structure and in what gets weighed.

FAANG and Large Tech

Companies like Google, Meta, Amazon, Apple, and Microsoft run highly standardized processes. Interviewers receive training, use calibrated rubrics, and submit feedback independently. A hiring committee (not the interviewer) makes the final decision.

What this means for you:

Startups and Mid-Size Companies

Startups optimize for speed and practical skill assessment. The process is less standardized and often closer to the day-to-day work the role involves.

What this means for you:

The format and the rubric tell you what is being measured. The next chapter is about how to communicate during the interview so those signals actually come through in the time you have.