{"title":"How Coding Interviews Work","description":"","content":"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.\n\nThis chapter breaks down the main types of coding interviews, the typical timeline from application to offer, and how interviewers actually score what they see.\n\n---\n\n# The Interview Formats\n\nThere are four main interview formats in widespread use.\n\n### Phone Screen\n\nThis 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.\n\nPhone 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.\n\n### Onsite (Virtual or In-Person)\n\nIf 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.\n\nA typical onsite loop looks like this:\n\n\n| Round | Duration | Focus |\n|-------|----------|-------|\n| Round 1 | 45 min | Data structures and algorithms |\n| Round 2 | 45 min | Data structures and algorithms |\n| Round 3 | 45 min | System design (senior+) |\n| Round 4 | 45 min | Behavioral / culture fit |\n| Round 5 | 45 min | Coding or domain-specific |\n\n\nNo 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.\n\n### Live Coding / Machine Coding\n\nLive 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.\n\nMachine 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.\n\n### Take-Home Assignments\n\nTake-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.\n\nTake-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.\n\n---\n\n# The Typical Timeline: Application to Offer\n\nHere is what a typical process looks like at a large tech company.\n\n\n```mermaid\nflowchart LR\n A[Application]:::primary --> B[Recruiter
Screen]:::secondary\n B --> C[Phone
Screen]:::primary\n C --> D{Pass?}:::orange\n D -->|Yes| E[Onsite
Loop]:::primary\n D -->|No| F[Rejected]:::red\n E --> G{Pass?}:::orange\n G -->|Yes| H[Offer]:::green\n G -->|No| F\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\n\n| Stage | Timeline | What Happens |\n|-------|----------|--------------|\n| Application | Day 0 | Submit resume or get a referral |\n| Recruiter screen | Week 1-2 | 15-30 min call about background and role fit |\n| Phone screen | Week 2-4 | 1 technical coding round |\n| Onsite | Week 4-7 | 4-6 rounds in one/two days |\n| Hiring committee | Week 7-9 | Independent review of all feedback |\n| Offer | Week 8-10 | Compensation discussion and offer letter |\n\n\nStartups 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.\n\n---\n\n# What Gets Evaluated: The Rubric\n\nMost large tech companies use structured rubrics during interviews. The rubric scores candidates on several dimensions rather than a single solved-or-not verdict.\n\n### The Four Pillars\n\n\n```mermaid\nflowchart TD\n A[Interview
Evaluation]:::primary --> B[Correctness]:::green\n A --> C[Efficiency]:::orange\n A --> D[Communication]:::secondary\n A --> E[Problem
Solving]:::primary\n\n B --> B1[Code works for
all edge cases]:::green\n C --> C1[Optimal time and
space complexity]:::orange\n D --> D1[Clear explanation
of thought process]:::secondary\n E --> E1[Structured approach
to breaking down problems]:::primary\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n**Correctness** is the baseline. Your code should produce the right output for standard inputs and handle edge cases.\n\n**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.\n\n**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.\n\n**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.\n\n### How Rubrics Typically Work\n\nMost companies score each dimension on a scale. Here is a simplified version of what many FAANG-style rubrics look like:\n\n\n| Score | Meaning | What It Looks Like |\n|-------|---------|-------------------|\n| Strong Hire | Exceeded expectations | Optimal solution, clean code, excellent communication, handled follow-ups |\n| Hire | Met expectations | Working solution, good efficiency, communicated approach clearly |\n| Lean Hire | Borderline | Solution worked with hints, some inefficiency, decent communication |\n| Lean No Hire | Below bar | Needed significant hints, major bugs, unclear communication |\n| Strong No Hire | Well below bar | Could not make meaningful progress, fundamentally wrong approach |\n\n\nA \"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.\n\n---\n\n# FAANG vs Startups\n\nThe interview experience varies significantly between large tech companies and startups, both in structure and in what gets weighed.\n\n### FAANG and Large Tech\n\nCompanies 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.\n\nWhat this means for you:\n\n- Problems come from curated question banks and tend toward classic algorithmic challenges.\n- System design is weighted heavily for senior roles (L5+ at Google, E5+ at Meta).\n- Behavioral rounds use structured frameworks like Amazon's Leadership Principles, and answers are often expected in STAR format (Situation, Task, Action, Result).\n\n### Startups and Mid-Size Companies\n\nStartups optimize for speed and practical skill assessment. The process is less standardized and often closer to the day-to-day work the role involves.\n\nWhat this means for you:\n\n- You might get a take-home project instead of a whiteboard problem.\n- The coding round might involve a real codebase, not an isolated algorithm.\n- Culture fit and domain experience carry more weight.\n- The hiring manager often has final say, not a committee.\n\n\n```mermaid\nflowchart LR\n subgraph FAANG[\"FAANG / Big Tech\"]\n direction TB\n A1[Standardized
Process]:::primary\n A2[Hiring
Committee]:::primary\n A3[Algorithmic
Focus]:::primary\n A4[4-6 Rounds]:::primary\n end\n\n subgraph Startup[\"Startups\"]\n direction TB\n B1[Flexible
Process]:::orange\n B2[Manager
Decision]:::orange\n B3[Practical
Focus]:::orange\n B4[2-3 Rounds]:::orange\n end\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\n\n| Dimension | FAANG | Startups |\n|-----------|-------|----------|\n| Process length | 6-10 weeks | 1-3 weeks |\n| Number of rounds | 4-6 | 2-4 |\n| Problem style | Classic algorithmic | Practical / domain-specific |\n| Decision maker | Hiring committee | Hiring manager |\n| System design | Dedicated round | Often combined with coding |\n| Behavioral | Structured (STAR format) | Conversational |\n\n\n---\n\nThe 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.","pageType":"dsa"}

Get Premium