swadhin / faang-playbook public
/ faang-playbook / 00-Hiring-Pipeline / 03-Online-Assessments.md
swadhinbiswas feat: add Netflix L5 interview playbook · 2/2/2026
41c1cbb
111 lines · 3.7 KB
Raw Download

Online Assessments (OA) / Quizzes

Some companies run an OA as a cheap first filter; others skip it.

Treat an OA like a production incident: be systematic, reduce mistakes, and keep your head.

What an OA is testing

In practice, OAs mostly test:

  • Correctness under constraints: choosing an algorithm that fits time/memory.
  • Implementation hygiene: clean code, fewer bugs, edge-case handling.
  • Reasoning speed: can you convert a prompt into a plan quickly?
  • Composure: do you spiral when stuck?

Many candidates fail for process reasons (I/O mistakes, no tests, misread constraints), not because they don’t “know DSA.”

The OA protocol (repeatable)

Phase 1: Understand (3–5 minutes)

  1. Read the statement twice.
  2. Rewrite the task in your own words.
  3. Extract constraints (e.g., $n \le 10^5$, values up to $10^9$, time limit 1–2s).
  4. Identify required outputs and edge behaviors.

Phase 2: Design (5–8 minutes)

  1. Write 2–3 examples.
  2. Add 1–2 edge cases (empty, duplicates, negatives, overflow, extreme sizes).
  3. Choose a baseline approach.
  4. Sanity-check complexity.

Phase 3: Implement (rest of time)

  1. Code the simplest correct solution.
  2. Keep functions small.
  3. Avoid cleverness unless required.

Phase 4: Verify (last 10–20%)

  1. Run your examples.
  2. Run edge cases.
  3. Do a quick “invariants pass” (what must always be true?).
  4. Only then micro-optimize.

Time management heuristics

  • If you are stuck for 5 minutes: step back and ask, “What’s the simplest representation that makes this easy?” (sorting? hashmap? prefix sums? two pointers?)
  • If you are 50% through time with no working code: ship the simplest working baseline.
  • If you have a baseline working early: spend the remaining time on tests + clarity.

Common failure modes (and how to avoid them)

  • Ignoring constraints: $n$ up to $10^5$ but writing $O(n^2)$.
    Fix: complexity check before coding.
  • Misreading the prompt: wrong interpretation of inclusive/exclusive boundaries.
    Fix: rewrite the prompt and test with examples.
  • Edge-case bugs: empty input, duplicates, overflow, off-by-one.
    Fix: explicit edge-case tests.
  • I/O mistakes: parsing errors, forgetting to flush/print formatting.
    Fix: keep I/O minimal and test sample.
  • Over-engineering early: starting with a fancy structure.
    Fix: baseline first, optimize after.

OA setup checklist (do this before the test)

  • Choose your default language and have a template ready (fast input, output formatting).
  • Know how to do:
    • sort + custom comparator,
    • binary search,
    • heap/priority queue,
    • BFS/DFS,
    • hashmap/multiset equivalents,
    • modular arithmetic basics.
  • Practice at least 2 timed sets in the same environment you’ll use.

Archetype differences

  • FAANG / Big Tech: OAs are common at junior/mid, less common at senior; they’re often standardized and strict on correctness.
  • Unicorns / startups: may skip OA or use take-home-ish screens; expect practical coding/debugging.
  • Enterprise / automotive: may include language/platform/domain checks (C++/embedded, safety, data constraints) more often than pure DSA.

After the OA

  • If you can, write down what you struggled with while it’s fresh.
  • Regardless of outcome, keep prepping for phone screens; many companies pipeline quickly.

Cross-links

Grounding sources