Interview Simulation
Interview Simulation — Overview
Mark when done:
Phase 6 -- Interview Simulation (Days 57-60)
Deep Dive: The Interview is a Performance, Not Just Code
Beginner tip: Technical interviews test communication as much as coding. The biggest mistake is jumping straight to code. Instead: clarify the problem (2 min), state your approach out loud (2 min), code while talking (18 min), then test with examples (5 min). Interviewers WANT to help you -- but they can only help if you think out loud.
The 35-Minute Breakdown
Minutes 0-3: CLARIFY
"Can nums be empty?" "Are values always positive?" "Is it sorted?"
-> Shows you don't jump to code blindly.
Minutes 3-5: IDENTIFY PATTERN
"This looks like a sliding window problem because we need the
longest contiguous subarray with a constraint."
-> Shows pattern recognition.
Minutes 5-7: PROPOSE + COMPLEXITY
"I'll use a variable-size sliding window. O(n) time, O(k) space.
The brute force would be O(n^2)."
-> Shows you considered alternatives.
Minutes 7-25: CODE (the actual implementation)
Write CLEAN code. Use meaningful names. Talk while coding.
"I'm initializing left pointer... now expanding right..."
Minutes 25-30: TEST
Trace through your code with the example: "At i=0, window is..."
Try an edge case: empty input, single element, all same values.
Minutes 30-35: OPTIMIZE (if asked)
"We could optimize space by using X instead of Y."Common Mistakes That Cost Offers
1. Jumping to code without clarifying -> miss constraints
2. Not stating brute force first -> miss opportunity to show thinking
3. Silent coding -> interviewer cannot give hints if they don't know your process
4. Not testing -> bugs in untested code lose more points than slow solutions
5. Panicking on stuck -> say "Let me think about this differently" and try a new angleThe Stuck Protocol
Stuck for 2 min? -> Re-read the problem. Look for missed constraints.
Stuck for 5 min? -> Try a different pattern. Say it out loud.
Stuck for 8 min? -> Simplify. Solve a smaller version first.
Stuck for 10 min? -> Ask: "Could you give me a hint on the approach?"
(Asking for a hint is better than sitting in silence.)Mock Interview Log
| # | Date | Problems | Time | Result | What Went Well | What to Improve |
|---|---|---|---|---|---|---|
| 1 | 45 min | |||||
| 2 | 45 min | |||||
| 3 | 45 min | |||||
| 4 | 45 min | |||||
| 5 | 45 min | |||||
| 6 | 45 min |
Interview Execution Framework
MINUTE 0-3: CLARIFY (constraints, edge cases, input size)
MINUTE 3-5: THINK ALOUD (identify pattern, discuss approach)
MINUTE 5-7: PROPOSE (state approach, time/space complexity)
MINUTE 7-25: CODE (clean, modular, well-named)
MINUTE 25-30: TEST (trace through examples, edge cases)
MINUTE 30-35: OPTIMIZE (can we do better?)Behavioral STAR Stories
Two examples filled in below cover the two most common FAANG behavioral themes. Use them as a template — replace the Situation, Task, Action, Result with your own real stories. Keep each ≤ 90 seconds out loud (≤ 200 words written).
| # | Theme | Situation | Task | Action | Result | Maps to (LP/Value) |
|---|---|---|---|---|---|---|
| 1 | Disagreed with a teammate on technical approach | Our team was building a new search index. The senior dev wanted to use Elasticsearch; I felt our scale didn't justify the operational cost and proposed Postgres full-text search instead. | Reach a decision the team would commit to before the next sprint planning. | I built two prototypes over a weekend — one in Postgres FTS, one in Elasticsearch — measured indexing time, query latency at our 10k-doc scale, and operational footprint. Wrote a 1-page comparison and walked the team through the trade-offs. | Team chose Postgres for v1 (saved ~$400/mo + a week of ops setup). Agreed to revisit if we hit 1M docs — which we did 14 months later, and the migration was clean because we'd documented the trigger criteria. | Amazon: Have Backbone, Disagree and Commit · Google: Strong Opinions, Loosely Held |
| 2 | Delivered under a tight deadline | Two days before a customer demo, our auth integration broke after an upstream API deprecation. | Restore login flow without rolling back unrelated features that were also in the release. | I scoped the failure (only the OAuth refresh path), wrote a 30-minute hotfix wrapping the deprecated call with the new signature, added a 5-minute regression test, paired with QA to validate the demo path, and documented the rollback procedure in case it failed. Shipped 18 hours before demo. | Demo went off without users noticing. Spent the following sprint replacing the wrapper with a proper migration to the new auth API. | Amazon: Bias for Action, Ownership · Meta: Move Fast |
| 3 | ||||||
| 4 | ||||||
| 5 | ||||||
| 6 | ||||||
| 7 | ||||||
| 8 |
Tip: map each story to multiple LPs — most stories naturally cover 2-3. Practise the same story in 60 seconds and 90 seconds; interviewers gauge time-management.
Target Companies
| Company | Applied? | Status | Coding | System Design | Behavioral | Notes |
|---|---|---|---|---|---|---|
| [ ] | ||||||
| [ ] | ||||||
| [ ] |
Notes
External Resources (Hand-Picked Supplements)
- interviewing.io — anonymous mock interviews with real engineers. The replays of past interviews (free) are the closest thing to watching a senior candidate's actual thought process.
- Pramp — peer-to-peer mock interviews; trade slots with other candidates. Use 2-3 sessions during Days 57-59.
- Tech Interview Handbook — Behavioral Questions — STAR-formatted templates and the most-asked behavioral prompts at FAANG companies. Use to fill in the (currently blank) STAR table in this README.
- Amazon Leadership Principles — official — required reading if Amazon is on your target list. Map at least one STAR story per principle.
- System Design Primer — for the Day 59 system-design overview. Read the "Latency comparison numbers" and "Common solutions" sections at minimum.