Chapter Goal: Technical skill gets you in the room. How you perform in the room gets you the offer. This final chapter covers everything between arriving at the interview and signing the offer — company-by-company formats, the UMPIRE coding framework, how to think out loud, how to handle being stuck, behavioral questions, Amazon's Leadership Principles, the most common failure modes, and a reflection template to improve after every round.
ROUNDS (typically 5-6):
• 2-4 Coding rounds (LC Medium to Hard, algorithms & data structures)
• 1 System Design round (L4+ — grow more important with seniority)
• 1 "Googleyness & Leadership" behavioral round
WHAT THEY TEST:
• Problem decomposition: can you break complex problems cleanly?
• Code quality: readable, correct, handles edge cases
• Communication: do you explain your thought process?
• Adaptation: follow-ups are common ("now do it without extra space")
• At L5+: leadership examples, cross-functional impact
CODING ENVIRONMENT: CoderPad or Google Docs (yes, sometimes no IDE)
TIPS:
✅ Write clean, readable code — variable names matter
✅ State your approach before coding — Google values structure
✅ Expect at least one follow-up per problem (optimized variant)
✅ For behavioral: quantify impact ("reduced latency by 40%")
✅ Interviewers submit independent reviews — perform consistently across rounds
❌ Don't rush to code without a plan
❌ Don't assume your first solution is what they want — discuss trade-offs
ROUNDS (typically 4-5):
• 2 Coding rounds ("Product Sense Coding" — real-world framing)
• 1-2 System Design rounds (L4+)
• 1 Behavioral round ("Meta values")
WHAT THEY TEST:
• Speed: Meta moves fast — a clean 30-minute solution scores well
• Product thinking: problems often have real-world framing
• Impact orientation: behavioral rounds focus on measurable outcomes
• Collaboration: "How did you work with others to achieve X?"
CODING ENVIRONMENT: CoderPad, sometimes their internal tool
TIPS:
✅ Write working code fast, then optimize
✅ Behavioral: frame everything around impact and scale
✅ System design: discuss Facebook-scale problems (billions of users)
✅ Values: "Move Fast", "Be Bold", "Build Social Value"
❌ Don't over-engineer the design ("good enough" with speed > perfect)
❌ Don't skip edge cases — they care about correctness
ROUNDS (typically 5-7, same day "loop"):
• 1-2 Coding rounds (LC Medium, practical problems)
• 1-2 System Design rounds (for SDE II+)
• 3-4 Behavioral rounds (each linked to Leadership Principles)
• 1 "Bar Raiser" round (independent, can veto the hire)
WHAT THEY TEST:
• Leadership Principles (LPs): EVERY behavioral answer must map to an LP
• Customer-first thinking: always tie solutions back to customer impact
• Ownership: "tell me about a time you owned a problem end-to-end"
• Dive Deep: technical depth in both coding and system design
THE BAR RAISER:
An Amazon employee from a different team who holds the hiring bar.
Their vote carries extra weight and can block a hire even if the rest vote yes.
They look for "will this person raise the bar of Amazon?"
TIPS:
✅ Prepare 2-3 STAR stories for EACH of the 16 LPs
✅ Use "I" not "we" — they want YOUR individual contribution
✅ Quantify everything: "I reduced build time from 45min to 8min"
✅ For coding: write practical, readable code (not competitive-style)
✅ Know AWS services — it's OK to reference them in system design
❌ Never say "we did X" without explaining YOUR specific role
❌ Don't skip the LP connection in behavioral answers
ROUNDS (typically 5-8, often same-day on-site):
• 5-6 Technical coding rounds (variety of interviewers)
• 1 System/architecture round (senior+)
• 1 Hiring Manager round
WHAT THEY TEST:
• Fundamentals: data structures, algorithms, sometimes OS concepts
• Clean code: Apple values craftsmanship — messy code is a red flag
• Domain depth: often interviewer-specific (iOS, ML, security)
• Product quality mindset: "how would a user experience this?"
TIPS:
✅ Write exceptionally clean code — Apple culture prizes polish
✅ Know your chosen language deeply (they notice when you misuse APIs)
✅ Privacy: discuss data minimization if the problem involves user data
✅ Battery/performance: mention efficiency for mobile contexts
✅ Be genuine — Apple values passion for the product
❌ Don't use language features you're not fully comfortable with
❌ Don't rush — Apple prefers a thorough, correct solution over a fast sloppy one
ROUNDS (typically 4-6):
• 2-4 Coding/system design rounds (senior-focused)
• 1-2 Culture fit rounds ("Freedom and Responsibility")
• Hiring Manager round
WHAT THEY TEST:
• Senior-level judgment: Netflix hires "fully-formed" senior engineers
• Culture: "Keeper Test" — would your manager fight to keep you?
• Systems thinking: streaming, reliability, distributed systems
• Autonomy: can you operate independently with minimal guidance?
NETFLIX CULTURE TENETS:
"Act in Netflix's best interest"
"Freedom comes with responsibility"
"Context, not control"
TIPS:
✅ Demonstrate senior judgment — don't wait to be told what to do next
✅ Discuss resilience: circuit breakers, fallbacks, chaos engineering
✅ Show breadth: Netflix values engineers who can own a full problem
✅ Be direct and candid — Netflix culture rewards honesty
❌ Don't show junior behaviors: waiting for hints, asking obvious questions
❌ Don't shy away from challenging the interviewer's framing
ROUNDS (typically 4-5):
• 3-4 Technical coding rounds (LC Easy-Medium to Medium-Hard)
• 1 System Design round (senior+)
• 1 "As Appropriate" (hiring manager or as-appropriate final round)
WHAT THEY TEST:
• Problem solving: strong emphasis on thinking process
• Collaboration: "growth mindset" culture
• Communication: Microsoft values clear verbal reasoning
• Domain fit: often team-specific (Azure, Office, Xbox, Bing)
TIPS:
✅ Test your code thoroughly — Microsoft interviewers often run your code
✅ Think about multiple approaches before coding
✅ Show enthusiasm for the specific team/product
✅ Discuss Azure services in system design where relevant
✅ Growth mindset: show you learn from mistakes and feedback
❌ Don't use overly competitive programming tricks — prefer readable
❌ Don't ignore the behavioral component — culture fit matters
UMPIRE gives you a repeatable process for every coding problem. It prevents the most common failure mode: jumping to code without understanding.
U — UNDERSTAND Read carefully. Ask clarifying questions.
M — MATCH Identify the pattern. What algorithm applies?
P — PLAN Sketch the approach. Pseudocode or spoken outline.
I — IMPLEMENT Write clean, working code.
R — REVIEW Trace through with an example. Find bugs.
E — EVALUATE State complexity. Discuss optimizations.
Problem: "Given an array of integers and a target sum, find two indices whose values sum to the target."
U — UNDERSTAND
Questions to ask:
• "Are there duplicate values in the array?" (affects approach)
• "Can I use the same element twice?" (usually no)
• "Is the array sorted?" (enables two-pointer)
• "What should I return if no solution?" (clarify before coding)
• "Will there always be exactly one answer, or possibly none/multiple?"
Confirmed: Unsorted array, one unique solution, can't reuse same element.
M — MATCH
"Two numbers summing to a target in an unsorted array..."
→ Hash map (complement lookup): for each element, check if target-element is in map
→ Two pointers would work if sorted (but problem says unsorted)
Pattern: Hash Map + Complement lookup → O(n) time, O(n) space
P — PLAN (say this aloud before coding)
"I'll iterate through the array keeping a hash map of value → index.
For each element x, I check if (target - x) is already in the map.
If yes, return {map[target-x], current_index}.
If no, add x → current_index to the map and continue."
I — IMPLEMENT
vector<int> twoSum(vector<int>& nums, int target) {
unordered_map<int,int> seen;
for (int i = 0; i < nums.size(); i++) {
int complement = target - nums[i];
if (seen.count(complement))
return {seen[complement], i};
seen[nums[i]] = i;
}
return {};
}
R — REVIEW (trace through aloud)
"Let me trace: nums=[2,7,11,15], target=9
i=0: complement=7, seen={} → miss, add seen[2]=0
i=1: complement=2, seen={2:0} → hit! return {0,1} ✓"
Edge cases: nums=[], nums=[3,3] target=6 → returns {0,1} (not same index) ✓
E — EVALUATE
"Time: O(n) — single pass. Space: O(n) for the hash map.
If the array were sorted, I could use two pointers for O(1) space.
If we needed all pairs (not just one), I'd collect all hits instead of returning early."
The interviewer cannot evaluate what they cannot see. Silence is the enemy. Speaking your thoughts allows the interviewer to guide you, correct misconceptions early, and assess your reasoning — even when your code isn't perfect.
READING THE PROBLEM:
"So the input is a sorted array of integers and a target. The output is
the index pair. Let me ask a few things before I start..."
PATTERN MATCHING:
"This looks like a two-sum variant. Since the array is sorted, I'm thinking
two pointers instead of a hash map — that gets me O(1) space."
CODING:
"I'm initializing two pointers, l at 0 and r at the end. The loop
condition is l < r because I don't want them to point to the same element..."
HITTING AN OBSTACLE:
"I'm noticing that my current approach doesn't handle duplicates correctly.
If there's a duplicate, both pointers might advance past the answer.
Let me think about how to handle that..."
AFTER CODING:
"Let me trace through with an example to verify. I'll use [1,3,5,7] with
target=8. l=0, r=3: 1+7=8, found! Returns {0,3}. Looks correct."
GOOD PHRASES:
"Before I start, let me ask a few clarifying questions..."
"I see two approaches. The naive O(n²) solution would be... but we can do
better with a hash map in O(n)."
"I'm going to write a working solution first, then we can optimize."
"Let me trace through this with [simple example] to make sure it's correct."
"This has time complexity O(n log n) because of the sort step, and O(n)
space. Could we do better on space? I think we could use..."
"I'm not sure about this part — let me think through it..."
AVOID:
❌ "I don't know." (say what you DO know, and reason from there)
❌ Long stretches of silence while staring at the screen
❌ "I'll just try this and see..." (without explaining why)
❌ "Sorry, I messed up." (just fix the bug calmly, no excessive apology)
Jumping to code without clarifying is the most common junior mistake. Interviewers expect and welcome questions — it signals you think like an engineer, not a coder.
INPUT & CONSTRAINTS:
"What's the range of values? Could there be negatives? Duplicates?"
"What's the size of the input? (affects whether O(n²) is OK)"
"Can I assume the input is non-empty? Or should I handle empty input?"
"Is the array sorted? Can I sort it?"
"Are there integer overflow concerns? Should I use long long?"
OUTPUT:
"Should I return indices or values?"
"If there are multiple valid answers, should I return all or just one?"
"What should I return if there's no solution?"
EDGE CASES (ask or state):
"I'll assume n ≥ 1 — should I handle n=0?"
"For a circular linked list problem: should I handle the null head case?"
SCALE & PERFORMANCE:
"Is there a specific time or space complexity you're targeting?"
"Is this called once or many times? (preprocessing may help if many calls)"
✅ Ask 2-4 targeted questions that will meaningfully affect your approach
✅ State assumptions for minor edge cases ("I'll assume n ≥ 1")
❌ Don't ask every possible question — it signals indecisiveness
❌ Don't ask for the solution ("what algorithm should I use?")
❌ Don't ask questions you should know from the problem statement
Direct hint: "Have you considered using a stack here?"
Subtle hint: "What if you thought about it from the other direction?"
Question hint: "What's the time complexity of what you have so far?"
→ This is often saying "that's too slow, optimize it"
Direction hint: "Let's focus on the merge step — how would that work?"
→ They're steering you toward a specific component
DO:
✅ Acknowledge the hint: "Ah, that's a good point. Let me think about
what a stack would give me here..."
✅ Incorporate it quickly: Don't fight the hint, run with it
✅ Show you understand WHY it helps: "If I use a stack, I can maintain
the monotonic order which solves the issue I was stuck on."
DON'T:
❌ Ignore the hint and keep going down the wrong path
❌ Accept it blankly without reasoning about why
❌ Ask "why?" repeatedly — experiment and show your thinking
If you've been stuck for 5 minutes and made no progress, change strategy. Don't silently spiral — the interviewer is watching and can help.
1. SOLVE A SIMPLER VERSION
"Can I solve this for n=1? n=2? What's the pattern?"
"What if all values were distinct? What changes with duplicates?"
"What if it were sorted? How does unsorted affect this?"
2. BRUTE FORCE FIRST, OPTIMIZE AFTER
"Let me write the O(n²) solution first to make sure I understand the
problem, then we can optimize."
(A working slow solution beats a broken fast solution.)
3. THINK ABOUT WHAT YOU KNOW
"I know the answer involves... I know the output needs to be..."
Start from what you're certain about and work outward.
4. DRAW AN EXAMPLE
Draw the problem on paper/whiteboard. Trace by hand.
"Let me work through [small example] manually and see if the pattern
becomes clearer."
5. THINK ABOUT RELATED PROBLEMS
"This reminds me of the two-sum problem. Can I reduce this to that?"
"I've seen something like this with merge intervals..."
6. ASK FOR A HINT (last resort, after genuine effort)
"I've been thinking about approaches A and B. I'm not sure how to
handle [specific obstacle]. Could you point me in the right direction?"
→ Frame as asking for direction, not the answer
FIRST: Get a working brute-force solution
→ Even O(n³) working code is better than O(n log n) broken code
THEN: Analyze complexity and discuss trade-offs
"My current solution is O(n²) time and O(1) space.
I think we can improve the time to O(n log n) by sorting first,
or O(n) using a hash map at the cost of O(n) space."
THEN: Ask if optimization is wanted
"Should I optimize further, or is this level of performance acceptable?"
→ Some interviewers want you to optimize; others care about correctness
THEN: Implement the optimization if asked
Start from scratch or explain clearly what changes
COMMON OPTIMIZATION SIGNALS:
Interviewer asks "can we do better?" → yes, optimize
"What's the time complexity?" with a pause → probably too slow
Follow-up with larger n → hint that O(n²) is too slow
No comment on complexity → may be fine, but ask to be safe
"We can reduce time from O(n²) to O(n) by using an additional O(n) hash map."
"We can save O(n) space by sorting in-place, at the cost of modifying input."
"We can precompute [X] in O(n) preprocessing to answer each query in O(1)."
"For k calls to this function, the O(n log n) preprocessing pays off if k > log n."
Testing your code live shows you write production-quality code, not just algorithmic code. It's one of the clearest senior signals.
STEP 1: Walk through a simple, normal example
Choose a small input (3-5 elements) that exercises the main logic.
Trace your code line by line — not "in your head," but out loud.
"When i=0, complement=7. seen is empty, so we skip to adding nums[0]=2.
seen={2:0}. When i=1, complement=2. 2 is in seen! Return {seen[2], 1}={0,1}."
STEP 2: Test edge cases
• Empty input: nums=[]
• Single element: nums=[5]
• Two elements: nums=[3,7] (minimum for a pair problem)
• All same values: nums=[2,2,2]
• No solution: nums=[1,2,3] target=10
• Negative values: nums=[-3,0,3] target=0
• Integer limits: INT_MAX, INT_MIN (overflow risk)
• Already sorted: [1,2,3,4,5]
• Reverse sorted: [5,4,3,2,1]
STEP 3: Run through your code, not just the concept
Don't say "yeah, it handles empty arrays" — actually trace what happens
when nums=[] is passed. Does the for-loop simply not execute? Does it
return {}? Confirm each path.
STEP 4: Fix bugs calmly
If you find a bug, don't panic. Say:
"Ah, here's an issue — when the array is empty, my code tries to access
nums[0] which is undefined. Let me add a guard at the top:
if (nums.empty()) return {};"
Finding and fixing bugs is a positive signal, not a negative one.
S — SITUATION: The context. Where? When? What was the stakes?
T — TASK: What was YOUR specific responsibility?
A — ACTION: What did YOU do? (Use "I", not "we")
R — RESULT: The measurable outcome. Quantify when possible.
1. "Tell me about yourself."
→ 2-minute narrative: education → experience → current → why this company
2. "Tell me about a challenging technical problem you solved."
→ STAR. Focus on YOUR decision-making and technical depth.
3. "Tell me about a time you failed."
→ Be honest. S: what failed. A: what you did after. R: what you learned.
→ They want self-awareness, not perfection.
4. "Tell me about a conflict with a teammate."
→ Show maturity, empathy, and resolution. Avoid placing blame.
5. "Tell me about a time you had to meet a tight deadline."
→ Show prioritization, communication, and delivery.
6. "Why do you want to work here?"
→ Specific to the company, team, and mission. Research before the interview.
7. "Where do you see yourself in 5 years?"
→ Ambitious but realistic. Show alignment with the role's growth path.
8. "Tell me about a time you influenced someone without authority."
→ Data-driven persuasion, stakeholder management, cross-team collaboration.
GOOD STAR EXAMPLE (leadership):
S: "In my previous role, our team of 4 was tasked with migrating a legacy
monolith to microservices before a company-wide launch deadline in 8 weeks."
T: "I was the technical lead responsible for the architecture design and
ensuring the team stayed unblocked."
A: "I broke the migration into 12 independent services with clear interfaces.
I held daily 15-minute syncs to surface blockers early. When the auth
service fell 2 weeks behind, I pair-programmed with the engineer for 3
days to get it back on track."
R: "We delivered 11 of 12 services on time. The remaining service was
gracefully delayed by 1 week with minimal business impact. The migration
reduced deployment time from 4 hours to 12 minutes."
WHAT MAKES IT STRONG:
✅ Specific context (8 weeks, 4 engineers, 12 services)
✅ Clear individual contribution ("I" throughout)
✅ Shows technical depth AND leadership
✅ Quantified result (4 hours → 12 minutes)
✅ Honest about imperfection (one service was late)
Amazon evaluates EVERY behavioral answer against its 16 Leadership Principles. Prepare 2-3 STAR stories for each. The stories can overlap but each should have a distinct primary lesson.
1. CUSTOMER OBSESSION
"Leaders start with the customer and work backwards."
Question: "Tell me about a time you went above and beyond for a customer."
Story angle: Delayed a feature to do user research; changed direction based on feedback.
2. OWNERSHIP
"Leaders act on behalf of the entire company, never saying 'that's not my job.'"
Question: "Tell me about a time you took on something outside your scope."
Story angle: Found a critical bug in another team's code, fixed and informed them.
3. INVENT AND SIMPLIFY
"Leaders expect and require innovation. They look for new solutions."
Question: "Tell me about a time you invented a new process or simplified a complex one."
Story angle: Replaced a 6-step manual deployment with a 1-click script.
4. ARE RIGHT, A LOT
"Leaders have strong judgment and good instincts."
Question: "Tell me about a time you had to make a decision with incomplete information."
Story angle: Chose a technology despite pushback; outcome validated the decision.
5. LEARN AND BE CURIOUS
"Leaders are never done learning."
Question: "Tell me about a time you learned something new to solve a problem."
Story angle: Taught yourself a new framework/language for a critical project.
6. HIRE AND DEVELOP THE BEST
"Leaders raise the performance bar with every hire and promotion."
Question: "Tell me about a time you mentored someone."
Story angle: Paired with a junior engineer weekly; they shipped their first
major feature independently within 3 months.
7. INSIST ON THE HIGHEST STANDARDS
"Leaders have relentlessly high standards — constantly raising the bar."
Question: "Tell me about a time you refused to ship something that didn't meet your standards."
Story angle: Pushed back on a release because of flaky tests; found a real bug.
8. THINK BIG
"Leaders create and communicate a bold direction."
Question: "Tell me about a time you thought bigger than the immediate problem."
Story angle: Solved for 10x scale when teammates designed for 2x.
9. BIAS FOR ACTION
"Speed matters. Many decisions are reversible. Don't wait for perfect info."
Question: "Tell me about a time you took a calculated risk."
Story angle: Shipped a minimal prototype in 2 days to validate assumptions,
avoiding 3 weeks of wrong engineering.
10. FRUGALITY
"Accomplish more with less. Constraints breed resourcefulness."
Question: "Tell me about a time you achieved something with limited resources."
Story angle: Reduced AWS bill by 60% through rightsizing without feature impact.
11. EARN TRUST
"Leaders listen attentively, speak candidly, and treat others respectfully."
Question: "Tell me about a time you had to earn the trust of a stakeholder."
Story angle: Won over a skeptical PM by over-communicating progress and
delivering on every commitment for 4 weeks straight.
12. DIVE DEEP
"Leaders operate at all levels and stay connected to the details."
Question: "Tell me about a time you dug into data to find the root cause."
Story angle: Traced a production bug through 6 microservices to a
misconfigured timeout that had been wrong for 8 months.
13. HAVE BACKBONE; DISAGREE AND COMMIT
"Leaders are obligated to respectfully challenge decisions they disagree with.
Once a decision is made, they commit to it wholly."
Question: "Tell me about a time you disagreed with your manager or team."
Story angle: Argued against a technical approach in a design review with data;
was overruled; committed to the decision and made it succeed.
14. DELIVER RESULTS
"Leaders focus on the key inputs and deliver them with the right quality."
Question: "Tell me about a time you delivered despite obstacles."
Story angle: Lost a team member mid-sprint; reorganized the work and
delivered all critical features on time.
15. STRIVE TO BE EARTH'S BEST EMPLOYER
"Leaders work to create a safer, more productive environment."
Question: "Tell me about a time you improved team culture or wellbeing."
Story angle: Started a weekly "failure forum" where team shared what they
learned from mistakes — psychological safety improved.
16. SUCCESS AND SCALE BRING BROAD RESPONSIBILITY
"We are big; we have an outsized impact. We are humble and thoughtful."
Question: "Tell me about a time you considered the broader impact of your work."
Story angle: Noticed a feature could inadvertently expose user location data;
flagged it and led privacy review before launch.
Prepare a 3×5 matrix: 3 stories × 5 dimensions each
For each of your 3 best STAR stories, identify which LPs it serves:
Story 1: "The Migration"
→ Ownership (took on scope), Deliver Results (shipped on time), Think Big
Story 2: "The Production Bug"
→ Dive Deep, Customer Obsession (prevented user impact), Earn Trust
Story 3: "The Architecture Decision"
→ Are Right A Lot, Have Backbone, Bias for Action
Now you can map ANY LP question to one of your prepared stories.
❌ Coding without understanding the problem
Fix: Always spend 2-3 minutes asking questions and restating the problem.
❌ Not handling edge cases
Fix: Before coding, list 3-4 edge cases. Handle them explicitly.
❌ Naming variables a, b, c, x, y, z
Fix: Use descriptive names. "leftPointer" beats "l" in an interview.
❌ Getting the time complexity wrong
Fix: For every nested loop, state the complexity of each. Multiply.
❌ Assuming input is valid without asking
Fix: "I'll assume n ≥ 1 and all integers fit in a 32-bit int."
❌ Testing only the happy path
Fix: After happy path, run through empty input, single element, duplicates.
❌ Not knowing the STL/standard library
Fix: Know sort, binary_search, lower_bound, unordered_map, priority_queue.
❌ Writing code that's impossible to debug
Fix: Write one logical unit at a time. Don't write 50 lines at once.
❌ Coding in total silence
Fix: Narrate what you're doing and why. The interviewer is your rubber duck.
❌ Saying "I don't know" and stopping
Fix: Say what you DO know. Reason toward the answer from there.
❌ Abandoning your approach at the first obstacle
Fix: Say "I see a problem with this approach — let me think about how to
resolve it" and work through it. Commitment shows maturity.
❌ Accepting hints without understanding them
Fix: "Interesting — why would a stack help here? Ah, because it maintains
the last-seen element... I see."
❌ Not asking for a hint when you need one
Fix: After genuine effort, "I've tried approaches A and B. Could you give
me a nudge in the right direction?"
❌ Talking too much before coding (over-planning)
Fix: After 5 minutes of discussion, say "Let me start coding and refine
as I go" — balance planning with execution.
❌ Saying "we" without "I"
Fix: Always explain YOUR individual contribution within the team effort.
❌ Choosing stories with no measurable outcome
Fix: Every result should have a number: time saved, users affected, % improvement.
❌ Choosing stories where you were perfect
Fix: Include stories where you made a mistake and recovered (shows growth mindset).
❌ Using the same story for every LP question
Fix: Prepare 5-7 stories from diverse projects, with different lesson angles.
❌ Criticizing former employers
Fix: Be diplomatic. "There were constraints that limited our options" > "management was bad."
❌ Not researching the company
Fix: Know the company's mission, recent products, and the specific team you're joining.
WEEKS 1-2: Foundations
Daily: 2 LeetCode Easy + 1 Medium (Arrays, Strings, Hashing)
Read: Chapters 1-6 of this guide
Goal: Fluent with two pointers, sliding window, hashing
WEEKS 3-4: Core Data Structures
Daily: 1 Medium + 1 Hard warmup (Linked Lists, Trees, Heaps, Tries)
Read: Chapters 7-14
Goal: Can implement BFS, DFS, binary tree traversals from memory
WEEKS 5-6: Algorithms
Daily: 1 Medium + 1 Hard (Sorting, Binary Search, Backtracking, Graphs)
Read: Chapters 15-22
Goal: Implement Dijkstra, topological sort, merge sort from memory
WEEKS 7-8: Advanced Topics + Mock Interviews
Daily: 2 Hard problems, 1 system design practice
Read: Chapters 23-27
Mock: 2-3 mock interviews per week (Pramp, interviewing.io, friends)
Goal: Can identify pattern within 5 min of reading any problem
DAILY ROUTINE (2 hours):
20 min: Review yesterday's problems (spaced repetition)
60 min: Solve today's problems (timed: 25 min per Medium)
20 min: Read patterns/chapter material
20 min: Behavioral story practice (write one STAR story)
✅ Review your pattern recognition cheat sheet (Chapter 25)
✅ Re-read your STAR stories for the company's key values
✅ Light practice: 1-2 Easy problems to stay sharp without fatigue
✅ Set up your interview environment: stable internet, quiet room, IDE ready
✅ Sleep 8 hours — tired candidates make careless mistakes
❌ Don't try to learn new algorithms the night before
❌ Don't do Hard problems under pressure — increases anxiety, not skill
30 min before: Stretch, eat something light, review signal words (Chapter 25)
5 min before: Open your coding environment, test the video call
During: Follow UMPIRE. Stay calm. Ask questions. Think out loud.
After each round: Don't dwell — the next round starts fresh.
Use this after every practice session and real interview. Improvement is multiplicative — candidates who reflect after every session improve 3-4x faster than those who don't.
DATE: _______________ COMPANY/ROUND: _______________ OUTCOME: _______________
─── PROBLEMS ENCOUNTERED ─────────────────────────────────────────────────────
Problem 1: _______________________________
Pattern I identified: _______________________________
Was I correct? Yes / No / Partial
Time to working solution: _______ min
Did I test edge cases? Yes / No
Time complexity stated: _______
Problem 2 (if applicable): _______________________________
[Same fields]
─── COMMUNICATION ────────────────────────────────────────────────────────────
Did I clarify requirements before coding? Yes / No
Did I think out loud throughout? Yes / No
Did I handle being stuck well? Yes / No / N/A
Did I incorporate interviewer hints quickly? Yes / No / N/A
─── BEHAVIORAL (if applicable) ───────────────────────────────────────────────
Questions asked:
1. _______________________________ LP targeted: _______
2. _______________________________ LP targeted: _______
Did I use STAR structure? Yes / No / Partial
Did I quantify results? Yes / No
─── WHAT WENT WELL ───────────────────────────────────────────────────────────
1. _______________________________
2. _______________________________
─── WHAT TO IMPROVE ──────────────────────────────────────────────────────────
1. _______________________________ Action: _______________________________
2. _______________________________ Action: _______________________________
─── PATTERNS TO REVIEW ───────────────────────────────────────────────────────
Struggled with: _______________________________
Study plan: ___________________________________________
─── OVERALL ENERGY & CONFIDENCE (1-10) ──────────────────────────────────────
Score: ___ Notes: _______________________________
Keep a spreadsheet with one row per problem practiced:
Date | Problem | Difficulty | Time | Pattern | Correct? | Review Needed?
Review "Review Needed" problems every 3 days (spaced repetition).
After 200+ problems, you should see:
• Time to first approach < 5 minutes for most Mediums
• Pattern identification accuracy > 80%
• Edge case coverage: habitual, not forced