Interviews

📘 Learn Interviews from zero

Think of a technical interview not as an exam with one right answer, but as a collaborative work session where the interviewer is auditioning you as a future colleague. They care less about whether you reach the perfect solution and more about how you think out loud — exactly how a senior engineer would behave at a whiteboard.

Analogy: imagine a chef interview. You're not just handed a dish to taste; you're asked to cook in front of them. They watch how you read the recipe (clarify requirements), prep ingredients (plan before coding), narrate your knife work (think aloud), taste as you go (test with examples), and adjust seasoning when something's off (handle feedback). A great cook who works in total silence still fails the audition.

Worked example (coding): "Find two numbers in an array summing to a target." A beginner immediately writes nested loops. The FAANG-bar candidate instead says: "Inputs are an integer array and a target; can values repeat? Are they sorted? Brute force is checking every pair, O(n^2) time, O(1) space. I can do better: as I scan once, I store each number in a hash map and check if target - current was already seen — that's O(n) time, O(n) space." Same answer, but the second candidate revealed a trade-off, named complexities, and validated assumptions.

Worked example (behavioral): asked about conflict, you anchor with STAR: Situation (two teams wanted incompatible APIs), Task (I owned the integration), Action (I ran a design review, proposed a versioned contract), Result ("shipped in 2 weeks, zero rollbacks").

Key insight: interviews reward a visible, structured process — clarify, baseline, optimize, verify — far more than a silent leap to the optimal answer. And the loop doesn't end when you leave the room: a crisp same-day thank-you and an honest written self-debrief compound directly into your next interview.

✨ Added by the guide to build intuition — not from the source course.

🎯 Guided practice

1. Easy — Coding (Valid Anagram). "Given two strings, return true if one is an anagram of the other." Step 1 — clarify: case-sensitive? Unicode or ASCII? Whitespace counts? Assume lowercase ASCII. Step 2 — baseline: sort both strings and compare — O(n log n) time, easy to reason about. Step 3 — optimize: anagrams have identical character frequencies, so use a frequency-count hash map (or a fixed int[26] array): add 1 for each char in string A, subtract 1 for each in B, then check all counts are zero. Step 4 — analyze: O(n) time, O(1) space (fixed 26-slot array). Pattern taught: "compare by structure, not order" maps directly to the frequency counting / hash map pattern — the same instinct solves "group anagrams" and "valid permutation."
2. Medium — Coding (Longest Substring Without Repeating Characters). "Find the length of the longest substring with all-distinct characters." Step 1 — clarify: substring (contiguous), not subsequence; return the length. Step 2 — baseline: check every substring for uniqueness — O(n^2) or worse. Step 3 — recognize the pattern: "longest contiguous window satisfying a property" is the sliding window signal from ByteByteGo's patterns. Step 4 — build it: keep a window [left, right] and a hash set of chars inside it. Expand right one char at a time; when you hit a duplicate, shrink from left (removing chars) until the window is valid again; track the max window size throughout. Step 5 — analyze: each character enters and leaves the window at most once, so it's O(n) time and O(min(n, charset)) space. Why this teaches the core: the two pointers never move backward — that monotonic invariant is what collapses an O(n^2) scan into a single linear pass, the defining trait of every sliding-window problem.
3. Behavioral — STAR drill ("Tell me about a time you disagreed with a teammate"). Step 1 — pick a real story with genuine tension and a decision you personally drove. Step 2 — Situation/Task (2 sentences max): "Our team was split on rewriting a flaky service versus patching it before a launch; I owned the call." Step 3 — Action (the bulk, all first-person "I"): "I ran a 30-minute spike to measure the failure rate, wrote a one-pager laying out patch-vs-rewrite trade-offs, and proposed patching now with a tracked rewrite ticket." Step 4 — Result (quantified): "We shipped on time, error rate dropped from 4% to 0.2%, and the rewrite landed the next quarter." Self-critique checklist: is the answer ≥70% "I" rather than "we"? Is there a real number in the Result? Does it surface a Leadership-Principle-style signal a FAANG interviewer is scoring (here: bias for action + disagree-and-commit)? Why this teaches the core: the same Situation→Task→Action→Result skeleton, drilled across conflict/failure/leadership prompts, converts a rambling anecdote into a scannable signal an interviewer can grade in 90 seconds.

✨ Added by the guide — work these before the full problem set.