If you have ever wondered why companies put candidates through multiple rounds of coding interviews, the answer is surprisingly simple: they are trying to predict how you will perform on the job. The tricky part is that every company does this differently, and knowing the format you are walking into changes how you prepare.

This chapter breaks down the most popular types of coding interview you will encounter.

The Interview Formats

Not all coding interviews are created equal. Here are the four main types you will face.

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 are gatekeepers. They exist to filter out candidates before investing a full day of onsite/virtual interviews. The problems tend to be easier (think LeetCode easy to medium), but the time pressure is real.

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:

Round	Duration	Focus
Round 1	45 min	Data structures and algorithms
Round 2	45 min	Data structures and algorithms
Round 3	45 min	System design (senior+)
Round 4	45 min	Behavioral / culture fit
Round 5	45 min	Coding or domain-specific

The key thing to understand about onsites is that no single round makes or breaks you. Interviewers submit independent feedback, and a hiring committee reviews the full picture. A strong performance in three rounds can outweigh a mediocre fourth.

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.

Companies that use live coding are testing something specific: can you write production-quality code under pressure? They want to see you use an IDE naturally, run test cases, and debug issues in real time.

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.

The Typical Timeline: Application to Offer

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

Stage	Timeline	What Happens
Application	Day 0	Submit resume or get a referral
Recruiter screen	Week 1-2	15-30 min call about background and role fit
Phone screen	Week 2-4	1 technical coding round
Onsite	Week 4-7	4-6 rounds in one/two days
Hiring committee	Week 7-9	Independent review of all feedback
Offer	Week 8-10	Compensation discussion and offer letter

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.

What Gets Evaluated: The Rubric

Interviewers at top companies use structured rubrics to evaluate candidates. They are not just deciding "did this person solve it or not." They are scoring you across multiple dimensions.

The Four Pillars

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

Efficiency is where you demonstrate algorithmic knowledge. Can you identify that a problem needs O(n log n) instead of O(n^2)? Do you understand the time-space trade-offs?

Communication tests your ability to clearly explain your thought process. Can you explain your approach before writing code? Do you talk through your decisions as you make them?

Problem-solving measures how you handle ambiguity. When you hit a wall, do you try a different approach or sit in silence? Can you break a complex problem into smaller subproblems? Do you recognize patterns from problems you have seen 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:

Score	Meaning	What It Looks Like
Strong Hire	Exceeded expectations	Optimal solution, clean code, excellent communication, handled follow-ups
Hire	Met expectations	Working solution, good efficiency, communicated approach clearly
Lean Hire	Borderline	Solution worked with hints, some inefficiency, decent communication
Lean No Hire	Below bar	Needed significant hints, major bugs, unclear communication
Strong No Hire	Well below bar	Could not make meaningful progress, fundamentally wrong approach

The critical insight is that a "Hire" rating does not require perfection. You can have a small bug, miss one edge case, or need a minor hint and still get a strong score if your communication and problem-solving approach were solid.

FAANG vs Startups

The interview experience varies dramatically depending on the company size and culture.

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:

Problems come from curated question banks and tend toward classic algorithmic challenges.
System design is weighted heavily for senior roles (L5+ at Google, E5+ at Meta).
Behavioral rounds use structured frameworks like Amazon's Leadership Principles.

Startups and Mid-Size Companies

Startups optimize for speed and practical skill assessment. Their interviews are less standardized but often more realistic.