How FAANG interview prep works without LeetCode burnout

FAANG interview prep fails when it becomes a second full-time job. Grinding hundreds of LeetCode questions creates the sensation of progress, but it often trains recognition, fatigue, and a bad habit of reaching for a remembered trick before understanding the problem. A working engineer needs a smaller system: learn a bounded set of patterns, retrieve them after increasing gaps, and test the whole interview skill under realistic time pressure.

The target is not a problem count. It is reliable performance on an unfamiliar prompt while another person watches, asks questions, and changes a constraint. That includes clarifying the task, choosing a data structure, writing correct code, testing it, explaining tradeoffs, and recovering when the first idea fails. Those behaviors can fit into six focused hours a week. They do not require sacrificing every evening for three months.

Define the interview before you study for it

Start by identifying the actual loop, because a generic FAANG plan wastes time on rounds you may never face. Ask the recruiter for the number, length, and format of coding, system design, behavioral, and role-specific interviews. Ask whether code must compile, whether you can run it, which languages are accepted, and what seniority signals matter. A recruiter may not disclose question types, but the format alone changes how you should practice.

Amazon's official software development interview topics page makes a useful distinction that candidates often ignore. It says interviewers assess whether you can apply what you know to solve problems efficiently, rather than whether you memorized every detail. Its SDE II guide also expects syntactically correct code, attention to edge cases, and validation of bad input. I agree with that emphasis, but I would push it further: a solution you can reproduce only after seeing the pattern label is not knowledge you can apply.

Build a one-page loop map. For each round, write the format, expected duration, likely evaluation areas, and your current confidence from one to five. Then assign weekly time by risk, not anxiety. If you already design distributed systems at work but freeze while coding on a shared editor, another system design video is comfort study. Give the coding simulation more time. If you are interviewing for a senior role and have never practiced a design discussion, spending every hour on arrays is equally misguided.

Use a date only when the baseline supports it. Run one coding mock, outline one system design, and record two behavioral stories before committing to an interview week. Eight to twelve weeks is a sensible range for many employed candidates, but it is not a law. A candidate who can solve medium problems cleanly may need four weeks of interview practice. Someone rebuilding data structures after years of management may need sixteen. The baseline decides.

A small pattern list beats a giant problem queue

A useful pattern list contains decision rules, not just topic names. "Graphs" is too broad. "Use breadth-first search for the shortest path in an unweighted graph" tells you what evidence should trigger a technique. Your list should be small enough to revisit and broad enough to cover the recurring structures in general software interviews.

For most candidates, I start with these families:

• Arrays and strings: hash lookup, two pointers, sliding window, prefix sums, and interval merging.
• Linked structures: pointer reversal, fast and slow pointers, stacks, queues, and monotonic stacks.
• Trees and graphs: depth-first search, breadth-first search, topological ordering, union-find, and trie traversal.
• Search and optimization: binary search on values, heaps, greedy choices, backtracking, and dynamic programming.
• Implementation: parsing, state simulation, boundary handling, and data structure design.

This is not a promise that every company draws from the same catalog. It is a map for organizing practice. Add role-specific material only after the recruiter conversation. A frontend candidate may need browser behavior and UI implementation. A machine learning candidate may need probability, modeling decisions, and data questions. A mobile engineer may face concurrency or platform APIs.

Give every pattern a trigger, a default approach, a common trap, and two representative problems. For sliding windows, the trigger might be a contiguous range with a condition you can maintain incrementally. The trap is forcing the method onto a condition that does not change monotonically as the window moves. For topological sorting, the trigger is dependency ordering in a directed graph. The trap is returning a partial order without detecting a cycle.

Cap the initial list at roughly thirty representative problems. That number is a constraint, not a magic threshold. Each problem must earn its place by teaching a distinct decision or failure mode. Replace duplicates instead of expanding the queue. Once you can retrieve and implement those representatives, add variants that break your assumptions. A second nearly identical question has little value; a variant that changes an unweighted graph into a weighted one exposes whether you understood the choice of algorithm.

Spaced retrieval turns solutions into usable memory

Re-solving a problem after a gap is more useful than reading its solution three times in one evening. Henry Roediger and Jeffrey Karpicke's work on retrieval practice found that testing memory improves later retention compared with additional study. Nicholas Cepeda and colleagues reviewed distributed practice across many learning settings and found a consistent spacing benefit. Coding interviews are not vocabulary tests, so the research does not dictate a perfect calendar. It does support the mechanism: recall the approach without cues, get feedback, and return after some forgetting has occurred.

Use four passes for each representative problem. On day zero, solve or study it until you can explain the invariant and produce correct code. On day two, start from a blank editor and write the approach before coding. Around day seven, solve it under a moderate time limit. Around day twenty-one, retrieve it in a mixed set without seeing the pattern label. Adjust the gap based on performance rather than worshipping the schedule.

Record the attempt in a compact form you can search. This YAML fragment is enough:

problem: longest-substring-without-repeats
pattern: sliding-window
last_attempt: 2026-08-09
result: shaky
failure: moved-left-pointer-backward
next_review: 2026-08-11
proof: each-character-index-keeps-left-bound-monotonic

The failure and proof fields matter more than a difficulty label. "Shaky" means you reached a correct result but needed a hint, exceeded the time box, could not justify complexity, or missed a test that would expose a bug. The proof is one sentence stating why the approach works. If you cannot write it plainly, you probably copied a sequence of steps without learning the invariant.

Do not save full polished solutions as your main notes. They encourage recognition. Save the prompt reference, trigger, invariant, failure, and next review date. When review day arrives, retrieve before reading. If you fail, inspect only enough material to repair the missing idea, close it, and implement again. That sequence feels slower than scrolling through explanations because it does actual learning.

Six deliberate hours fit around a full-time job

A sustainable week separates learning, retrieval, and simulation. Trying to do all three in every session adds setup cost and makes a tired Tuesday feel like a failed interview. Use short weekday sessions for one cognitive job and reserve one weekend block for integration.

A realistic six-hour schedule looks like this:

1. Monday, 45 minutes: retrieve two due problems from a blank editor.
2. Tuesday, 60 minutes: learn one new pattern or repair one weak family.
3. Thursday, 45 minutes: solve one unfamiliar problem and review the decision, not just the code.
4. Saturday, 120 minutes: run a coding mock and review it while the memory is fresh.
5. Sunday, 90 minutes: practice system design or behavioral material, then plan due reviews.

The remaining hour is buffer. Spend it on a second short mock, role-specific work, or rest if your job consumed the week. A schedule without buffer breaks the first time production fails late on Thursday. Moving unfinished sessions into Sunday creates a punishment pile and teaches you to resent the plan.

Protect the start and stop conditions. Decide the problem before the session, open the editor, put your phone elsewhere, and stop when the block ends. Do not browse for a more perfect list during practice time. If you miss a day, move the highest priority retrieval to the next available block and drop the least important new material. Never double the next session to repay a fictional debt.

Your energy is part of the schedule. Put unfamiliar problems at the time of day when you can still reason. Use lower-energy periods for reviewing a mock transcript, tightening a behavioral story, or reading an official format guide. Candidates with children, on-call work, or long commutes may need four 35-minute blocks instead of two long weekdays. Keep the functions of the sessions even when the calendar changes.

Track completed focused minutes, retrieval results, and mock evidence. Do not track the size of the queue as an achievement. The weekly question is whether a weak behavior improved. Examples include stating an invariant before coding, testing empty input without prompting, or comparing two approaches before choosing one. Those are observable and trainable.

Solve for explanation before speed

The best practice rule is to time-box struggle without turning every problem into a race. For an unfamiliar medium problem, spend the first few minutes clarifying inputs, constraints, and examples. Then state a simple correct approach, even if it is slow. Search for the bottleneck and improve it. Interviewers can follow that progression; they cannot grade thoughts you never say.

Give yourself roughly twenty to thirty minutes for a serious solo attempt, depending on the expected interview format. If you have no plausible direction after ten focused minutes, take a small hint such as the relevant data structure, then continue. If the hint gives away the whole method, mark the attempt as failed. Failure is useful scheduling data. Pretending a hinted solution was independent poisons the review queue.

Use the same completion test every time:

• You explained the brute-force option and why it misses the constraint.
• You named the invariant or state that makes the better approach correct.
• You wrote executable code in your interview language without completion tools.
• You tested normal, boundary, and adversarial cases by tracing actual values.
• You stated time and space complexity and defended the expensive operation.

Consider a common sliding-window failure. The candidate stores the latest index of each character and moves the left boundary to last_seen[c] + 1. When a repeated character lies before the current window, that assignment moves the boundary backward and admits invalid characters. The fix is left = max(left, last_seen[c] + 1). The lesson is not that one line. The invariant says left never decreases and the current window contains no duplicate. Record that invariant, then schedule a variant.

Reading the editorial solution immediately after getting stuck is popular because it removes discomfort and produces a neat notebook. It is also weak practice when repeated. Try, take a bounded hint, finish, close the reference, and reconstruct. The reconstruction reveals whether the explanation entered memory or merely looked familiar.

Classify misses by cause, because a wrong answer does not always call for another algorithm lesson. If you chose the right approach but produced an off-by-one error, schedule a short implementation drill with boundary cases. If you could not select an approach, revisit the pattern trigger and compare it with a neighboring pattern. If you solved correctly but went silent for fifteen minutes, repeat the same problem while narrating decisions. If you ignored a clarified constraint, practice restating constraints before proposing code. One score cannot prescribe all four repairs.

Keep your interview language boring. Use the language you know well enough to create a queue, sort with a comparator, handle strings, and write small helper functions without searching for syntax. Switching to a language because its solution appears shorter adds a second learning problem. Prepare a one-page syntax sheet for constructs you genuinely forget, review it before practice, then remove it during simulation. The goal is recall, not proving that you never consult documentation at work.

After a successful solution, ask one follow-up that changes the constraint. What if input arrives as a stream? What if memory cannot grow with the input? What if edges carry weights? What if duplicate values are allowed? You do not need to implement every extension. Spend five minutes explaining which assumption broke and what must change. This is more productive than rushing to another unrelated easy problem, and it prepares you for the moment when an interviewer modifies the prompt after your first solution.

Mock interviews need a rising cadence

Mocks should begin early enough to change your habits and become more frequent near the real loop. Waiting until you have "finished LeetCode" avoids the part that exposes communication gaps. There is no finished state anyway. Run the first diagnostic mock in week one, while the result can still shape the plan.

During the middle weeks, schedule one mock every seven to ten days. In the final two or three weeks, use two per week if recovery and work permit. Make at least half of them live with another person. Solo recordings help with verbal discipline, but they do not reproduce interruptions, ambiguous replies, or the pressure of someone watching you debug.

A coding mock should match the target medium: shared editor, no autocomplete if that is expected, visible timer, and the same language you will use. Give the interviewer permission to stay quiet. Helpful friends often rescue too early because silence feels awkward. Afterward, score evidence in four categories: problem framing, algorithm choice, implementation, and verification. A single overall rating hides what to train.

Review the recording or notes within a day. Pick no more than two corrections for the next mock. If you tried to fix seven behaviors at once, you would remember none under pressure. A useful correction is specific: "state the loop invariant before writing the loop" or "trace one failing example before editing code." "Communicate better" cannot guide a session.

Do not use mocks to collect predictions about passing. Different interviewers and question mixes create too much noise. Use them to find recurring failures. Three mocks that expose rushed testing tell you more than a stranger's percentage estimate. When two consecutive mocks show clean performance at the target format, the evidence supports booking. One lucky run does not.

Coding cannot consume the whole preparation budget

Senior candidates often overprepare algorithms because the feedback is immediate and neglect system design and behavioral rounds where level decisions happen. Split time according to the loop map. For a senior generalist with coding, design, and behavioral interviews, a starting allocation might be half coding, a quarter design, and a quarter behavioral. Change it when mock evidence says otherwise.

System design practice should produce decisions, not architecture drawings copied from videos. Take one prompt, clarify scale and reliability needs, define the main data model and interfaces, sketch the critical path, find a bottleneck, and discuss failure behavior. Practice defending why a queue, cache, database, or partitioning scheme belongs there. If every design includes fashionable components without a workload that requires them, an interviewer will notice.

Behavioral preparation needs an evidence bank rather than memorized speeches. Build six to eight stories that cover conflict, failure, influence, ambiguous ownership, technical judgment, and measurable delivery. For each story, keep the context short, name your decision, state what you personally did, and separate the result from the lesson. Practice answers at two lengths, about ninety seconds and four minutes, so the interviewer can control depth.

Resume depth also deserves rehearsal. Any technology, metric, or leadership claim on the page is fair territory. Ask a peer to choose a bullet and keep asking why. If the answer becomes vague after the second question, repair the claim or refresh the details. Inflated scope creates far more damage than admitting that another engineer owned part of a system.

Company-specific preparation belongs near the end, after the core behaviors work. Read the current official candidate material, confirm the loop with recruiting, and map your stories to the company's stated evaluation areas without forcing every story to cover everything. Official guidance can change, so use the material provided for your process rather than an old forum post.

Burnout is a scheduling signal, not a character test

LeetCode burnout usually appears as declining attention, irritability before sessions, compulsive problem counting, poor sleep, and repeated mistakes on material you previously knew. Treat those signs as evidence that training load exceeds recovery. More volume at that point rehearses careless work.

Use a simple intervention. Take two full days away from interview material. Resume at half volume for one week, keep only due retrieval and one mock, and remove new problems. If performance returns, increase slowly. If exhaustion affects work, sleep, or ordinary life after the preparation load drops, talk with a qualified health professional rather than diagnosing it as weak discipline.

Separate discomfort from depletion. Retrieval should feel effortful, and a live mock may create nerves. You can still focus and recover after those sessions. Depletion persists, reduces the quality of normal work, and makes starting feel physically heavy. A plan needs challenging sessions, but it should not produce a worsening trend across weeks.

Sleep is part of recall and judgment, so do not trade it for one more late problem. Keep at least one evening and one substantial weekend period completely free of preparation. If on-call duty destroys a planned mock, reschedule it after recovery. Running it exhausted creates a score that mostly measures the incident response shift.

A full-time job also supplies useful preparation. Explaining a production tradeoff, reviewing a colleague's code aloud, writing a short design note, or leading a post-incident discussion exercises many interview behaviors. Do not turn every work interaction into a test, but notice where the job already provides deliberate practice. That reduces the amount you must manufacture after hours.

Readiness is evidence, not a streak

Book the interview when your recent evidence matches the loop, not when an arbitrary problem counter reaches three digits. You should be able to solve representative medium questions in your chosen language, explain the invariant, test deliberately, and recover from a bug without going silent. For senior roles, you also need repeated design and behavioral practice at the expected depth.

Use a readiness gate with four conditions. First, two recent coding mocks meet your target format without major help. Second, no core pattern family remains completely unfamiliar. Third, you can deliver and deepen your main behavioral stories without reciting them. Fourth, you can take a full day off without panicking that knowledge will disappear. The last condition tests whether the system created durable recall or dependence on daily grinding.

If the date is fixed and the gate is not met, narrow intelligently. Prioritize common pattern families, clean implementation, and communication. Do not attempt a frantic tour of obscure hard problems. For a weak design round, practice two complete discussions and compare them against the evaluation criteria. For behavioral gaps, repair the thinnest evidence stories. Triage can improve performance; cramming everything cannot.

Founders sometimes copy FAANG interviews when hiring a small product team, then lose weeks testing puzzle fluency they do not need. I address that mismatch during a Team & AI Audit at oleg.is by examining the team, work, and where AI changes the staffing plan. Candidates cannot control a company's loop, but hiring leaders can stop importing a process that does not predict their actual job.

Stop adding material during the final forty-eight hours. Run light retrieval, check logistics, prepare questions for the interviewer, and sleep. The interview will still contain uncertainty. Your preparation has worked if uncertainty prompts a method: clarify, model, choose, implement, test, and correct. That is a much more durable skill than remembering which numbered problem looked similar last Tuesday.