Not the sanitized version you read on LinkedIn. The real system, I am sharing the exact schedule, the anxiety in between, the sequence I follow from zero to offer.
Most interview prep advice is written by people who either never failed or have conveniently forgotten what it felt like to fail badly. As I have shared multiple times in my previous blogs that I failed 23 times before I cracked the process. What I built out of those failures is not a list of resources. It is a repeatable system with specific phases, daily time budgets, decision rules for when to move on, and a clear protocol for the final 72 hours before a loop. It works for me and It has worked for a number of people I have coached through it. But none of it resembles the advice that gets posted to the top of engineering subreddits, because that advice is optimized for upvotes, not for outcomes.
Why most prep advice fails you before you even start
The internet is full of interview prep advice. There are curated lists of the 75 must-solve LeetCode problems. There are YouTube channels dedicated to mock system design sessions. There are courses promising to turn you into a senior engineer in eight weeks. If information alone were enough, nobody would be failing technical loops.
The problem is not access to information. The problem is that most people approach interview prep the same way they approach a research project: they accumulate knowledge passively and assume that understanding something conceptually is equivalent to being able to produce it under pressure. But it is not as the cognitive demand of a live technical interview is fundamentally different from the cognitive demand of reading a blog post about the same topic. In a live interview, you are generating instead of consuming like basically you are talking and typing at the same time. You have a stranger watching you work. You have a timer running in the background of your head even when there is no visible timer on the screen. None of your accumulated knowledge is useful unless you have trained your brain to access it reliably under those conditions.
The second failure mode is treating prep as a binary: either you are preparing or you are not. People tend to go from zero preparation to intense cramming the week before an interview, which is exactly backwards. The skills that matter in a technical interview are clean problem decomposition, fast pattern recognition, confident architectural narration and those things can not be absorbed in 4–5 days. They are built over months of low-intensity consistent practice, the same way you build cardiovascular fitness. A week of intense running before a 10K does not substitute for months of regular training. The week before an interview should be light review for you.
The third failure mode, and the one I see most often, is practicing in the wrong format. Solving LeetCode problems silently on your laptop is not interview practice. It is homework. An interview requires you to simultaneously think, communicate your thinking out loud, write code, field clarifying questions, handle follow-up constraints the interviewer introduces mid-problem, and maintain composure when your first approach hits a dead end. If you have never practiced all of those things at the same time, you will struggle to do them under pressure even if you technically know the material.
What follows is the actual system I use. It is organized into phases. Each phase has a specific goal, a recommended time allocation, and clear signals for when you have done enough and should move forward.
Phase 0: The Inventory (Day 1, before anything else)
Before I touch a single LeetCode problem or open a system design resource, I spend half a day doing a complete honest inventory of where I actually am.
I open a blank document and work through four categories.
Technical depth. I list every major topic area that appears in technical interviews: arrays and strings, linked lists, trees and graphs, dynamic programming, system design fundamentals, concurrency and parallelism, database design, distributed systems, API design, object-oriented design.
For each one, I write a single word: Strong, Shaky, or Blank. Strong means I could solve a medium-difficulty problem in this area right now without looking anything up and explain my solution clearly. Shaky means I have seen this material before and would recognize patterns but would struggle to produce clean working code under time pressure. Blank means I would need to start from the beginning. I am honest about this even when the honest answer is embarrassing, because a false inventory leads to wasted prep time.
Behavioral story bank. I list every major project I have worked on in the past four years and for each one I write down: the specific technical challenge I personally owned, the specific decision I made and why, the measurable outcome, and any cross-functional conflict or ambiguity I had to navigate. I do not try to construct polished STAR answers at this stage. I am just surfacing raw material. If I have worked on ten major projects and cannot identify a specific personal technical decision from at least six of them, my behavioral prep is starting from close to zero regardless of how long I have been in the industry.
Target company research. I look up everything publicly available about the interview process at my target companies. I check Glassdoor, Blind, and Levels.fyi for recent interview reports. I look at what PracHub surfaces as the company-specific question patterns. I am trying to answer 3 questions: what is the difficulty distribution of their coding rounds, what is the scope and depth of their system design sessions, and how much weight does the behavioral round carry relative to the technical rounds. The answers vary dramatically across companies and dramatically change what I prioritize in my prep.
Time budget. I look at my calendar and figure out how many weeks I have before my target interview, and how many hours per week I can realistically commit. I divide the available hours across the phases I will describe below. If I discover I have 2 weeks and 4 hours per week, I adjust the plan accordingly rather than pretending I will somehow find twenty hours a week I do not actually have.
The output of Phase 0 is my behavioral material, my target company intelligence, and my weekly time budget. This document is what I return to every few days throughout prep to check whether I am actually moving in the right direction.
Phase 1: Foundation Repair (Weeks 1–2)
Phase 1 is about clearing the Blank and shoring up the Shaky items from my inventory before I touch anything else.
The specific sequence matters. I start with the topic areas that are foundational dependencies for everything else: arrays and strings, hash maps and sets, linked lists, trees, and basic graph traversal. These topics appear in roughly 70% of coding questions and underpin the more complex patterns in later phases. If these are weak, working on dynamic programming or advanced graph algorithms is premature and inefficient, because those problems build on pattern recognition that requires the fundamentals to be automatic.
Within each topic area, my practice loop is not simply to solve problems. It is to solve, explain, and diagnose.
After solving any problem, I narrate the full solution out loud as if I am explaining it to an interviewer who cannot see my screen. I describe the data structure I chose and why it was appropriate for this specific problem. I describe the time and space complexity and explain what constraint is driving each. I describe the edge cases I tested and why they are the ones that matter. If I cannot narrate the solution cleanly after solving it, I go back and solve it again the next day without looking at my previous work.
When I get a problem wrong or need more than thirty minutes to solve it, I do a specific diagnosis rather than just reviewing the answer. I write down one of three failure modes: I did not recognize the pattern, I recognized the pattern but made an implementation error, or I recognized the pattern and implemented it correctly but could not explain it clearly. Each failure mode has a different remedy. Pattern recognition failures mean I need more exposure to that category. Implementation errors usually mean I am thinking correctly but have a specific syntax or indexing habit that is producing bugs. Explanation failures mean my conceptual understanding is actually shallower than my solve rate suggests.
I keep a daily log in a simple spreadsheet. Columns are: date, problem name and difficulty, time taken, result (solved independently, solved with hint, did not solve), failure mode if applicable, and a one-sentence note of the key insight. This log is not for anyone else. It is for me, so I can look at it after two weeks and see whether I am improving, plateauing, or going in circles.
Phase 2: Pattern Saturation (Weeks 3–4)
Once the foundational topics are solid, I shift to pattern saturation. The goal is to develop the ability to look at a problem and immediately identify the category of approach it belongs to, without needing to work through the full brute force first.
The patterns I specifically focus on are the ones that appear most frequently in the difficulty range that matters: medium to hard. These include the two-pointer approach and its many variants, the sliding window technique, binary search on the answer space (not just on sorted arrays), BFS and DFS with state tracking, prefix sums, monotonic stack and queue applications, and topological sort for dependency problems. Within dynamic programming, I focus on the subset of problems that appear in actual interviews rather than the full academic taxonomy: 1D linear DP, grid DP, interval DP, and knapsack variants.
For each pattern, I do not just practice problems instead I try to write a pattern card. A pattern card is a half-page document that describes the trigger conditions for the pattern (what properties of the problem indicate this approach is worth trying), the standard template implementation, the common variations and how they modify the template, and the typical time and space complexity. Writing these cards from scratch rather than copying them from the internet forces active encoding. I have a folder of about twenty-five pattern cards that I review every three days during this phase.
The target for Phase 2 is that when I see a new medium-difficulty problem from any of these categories, I can identify the applicable pattern within the first two minutes of reading the prompt. I test myself on this explicitly: I read the problem, set a two-minute timer, and write down just the pattern name and the key data structure before looking at anything else. Over the course of two weeks, the time it takes me to pattern-match should compress noticeably.
Phase 3: System Design Depth (Weeks 3–5, overlapping with Phase 2)
I run system design prep in parallel with pattern saturation because they draw on different cognitive resources and the overlap prevents burnout from doing the same type of practice for too many consecutive hours.
My system design prep has 3 layers.
Write on Medium
The first layer is building blocks. I spend the first week making sure I have a deep, not superficial, understanding of the core components that appear in almost every system design interview: load balancers (Layer 4 vs. Layer 7, consistent hashing for session affinity), caching (cache-aside vs. write-through vs. write-back, eviction policies and when each breaks down), SQL vs. NoSQL databases (what ACID actually means and when you trade it away, horizontal sharding strategies and their specific failure modes), message queues (Kafka vs. RabbitMQ vs. SQS and what properties of the workload determine which you choose), and CDNs (pull vs. push origins, cache invalidation tradeoffs). For each building block, I want to be able to describe not just what it does but where it fails and what the operational cost of running it is.
The second layer is framework practice. I use a consistent structure for working through any design problem: establish the scale and constraints before drawing anything, identify the core read and write paths separately, design the data model before designing the API, identify the bottleneck in each path and address it explicitly, and handle failure modes and operational concerns in a dedicated section at the end. Practicing this framework on a wide variety of prompts builds the muscle memory to structure a design session confidently even when the specific prompt is unfamiliar.
The third layer is company-specific calibration. Different companies test system design very differently. What a Google L5 system design session looks for is genuinely not the same as what a Stripe E4 session looks for. Google tends to go broad and then probe the trade-offs at scale. Stripe tends to focus intensely on reliability, correctness, and what happens when the system is actively failing. Amazon layers in operational concerns and cost frugality in a way that other companies do not. Try to talk to folks at Amazon or specific companies or check on subreddits or blind or prachub specifically for this layer because it will help you with the actual question patterns with each company rather than generic architecture prompts. The difference between knowing general system design and knowing how a specific company tests it is the difference between a decent session and a hire decision.
Phase 4: Mock Loops (Week 5 onward, and every week until the interview)
Mock interviews are where most candidates underinvest, and it is the single most expensive mistake in the entire prep process.
Practicing alone is useful. It is not sufficient. The specific stressor that makes technical interviews hard is not the material. It is the performance pressure of producing in front of another person who is evaluating you. That pressure affects your working memory, your pattern recognition speed, and your ability to hold a thought while simultaneously typing and narrating. The only way to reduce the impact of that pressure is to practice under that pressure repeatedly until it becomes familiar.
I schedule at least 2 mock coding sessions and one mock system design session per week during Phase 4. My preference is to do these with peers who are also actively interviewing, because they are calibrated to the current difficulty bar and have genuine motivation to give useful feedback. When peer mocks are not available, I use structured solo simulation: I set a hard timer, open a problem I have not seen, narrate everything I am doing out loud into a voice memo, and do not pause the timer if I get stuck. Reviewing the voice memo afterward is uncomfortable in the same useful way that watching yourself on video is uncomfortable. You hear the filler words, the moments of silence that reveal where you lost the thread, the times you jumped to code before establishing the approach.
The feedback protocol for mock sessions matters as much as the sessions themselves. I do not ask my mock partner for a general impression. I ask for 4 specific pieces of information:
where my communication dropped (times when I was thinking silently instead of narrating),
whether my approach to each problem was reasonable before I started coding,
whether my code was readable without explanation, and
whether my complexity analysis was accurate.
These four dimensions are roughly what a real interviewer is scoring.
Phase 5: The Final 72 Hours
The 72 hours before an interview loop are not for learning new material. If something is not already in my head by this point, it will not be reliably accessible under pressure. Trying to cram new concepts in the final 72 hours degrades the retrieval of existing knowledge by introducing interference.
What I do in the final 72 hours is calibration and logistics.
On the 3rd day before the interview, I do a light review pass through my pattern cards and my behavioral story document. I am not testing myself, just refreshing. I solve one or two easy problems in the language I will use in the interview, purely to warm up the syntax recall.
On the 2nd day before, I do a single full simulation of a complete interview loop: one coding problem, one system design problem, behavioral narration for three stories. I treat this simulation as close to real as I can make it: same time limits, same format (whiteboard for design, IDE for coding), same narration discipline. After the simulation, I sleep. Deliberately. The research on sleep and memory consolidation is not subtle. Sleeping after a comprehensive review session is significantly better for retention than doing another review session.
On the day before, I do nothing technical. I confirm the logistics: the Zoom link, the time zone, whether there is a specific coding environment they want me to use and whether I have tested it. I eat well. I go for a long walk. The single biggest performance variable in the final 24 hours is physiological, not intellectual.
On the morning of the interview, I have a short warm-up. I solve one easy problem in the language I will be using, just to activate the pattern-matching circuits. I read through one behavioral story. I do not try to review system design components or refresh algorithm patterns. The window is too narrow and the activation cost is too high.
The harder part nobody writes about
Everything above is the mechanical system. The harder part is managing the emotional arc of a multi-week prep process.
Interview prep is psychologically bruising in a way that regular work is not. Regular work gives you constant feedback through shipped features, merged pull requests, and team responses. Interview prep gives you minimal feedback and a lot of silence. You solve problems in isolation. You do not know whether your approach would satisfy a real interviewer. You have no idea whether the company you are targeting has already filled the role internally. The uncertainty is constant, and the only antidote to it is trusting the process enough to keep going.
The specific thing I do to manage this is to measure effort rather than outcomes during the prep phase. I do not try to evaluate how ready I am by asking myself whether I feel ready, because that feeling is almost completely uncorrelated with actual performance. Instead I track concrete process metrics: how many problems I solved this week, whether I completed my scheduled mock sessions, whether I updated my behavioral document. These are the things I control. The outcome of the interview is not something I control, so I do not spend cognitive energy there during prep.
After the interview, I do a structured retrospective regardless of outcome. I write down every question I was asked, my initial reaction to each, where I felt confident and where I struggled, and what I would do differently. If I get an offer, this retrospective is still valuable because it shows me what actually worked, not what I thought was working. If I do not get an offer, the retrospective is the material that makes the next attempt better.
What I actually use
Throughout all five phases, the platform I return to most consistently for company-specific preparation is
For the first three phases, the core tools are free and widely available: LeetCode for coding practice, the NeetCode roadmap as a structured topic guide, Designing Data-Intensive Applications for foundational system design reading, and Glassdoor or Blind for surfacing recent interview reports from real candidates at specific companies.
The one paid tool I use, specifically for the company calibration layer in Phase 3, is prachub. I landed on it not because I was looking for a platform to recommend but because the specific problem it solves mapping real interview questions to specific companies and levels is tedious and time-consuming to do manually from forum posts and Glassdoor reports. Whether that particular problem is worth solving with a tool is a personal call that depends on how much prep time you have and how targeted your company list is. For me, with two or three target companies and a finite prep window, it saved meaningful time during Phase 3. It is not a substitute for knowing the material. It is closer to a study guide that tells you which chapters to prioritize before a specific exam.
If your budget is literally, the manual version works. You compile recent interview reports from Blind and Glassdoor, sort them by recency, look for patterns in the follow-up questions interviewers asked, and use that to weight your study time toward the failure modes that company actually probes. It is slower, but the information is largely there if you are willing to dig.
The system works when you follow all of it, including the parts that feel unnecessary. The inventory matters because it forces honesty. The pattern cards matter because writing them is different from reading them. The mocks matter because solo practice is not representative of the actual task. The final 72 hour protocol matters because most people spend those hours doing the wrong things.
You do not need to be the most technically gifted engineer in the room. You need to be consistently prepared, consistently communicative, and consistent enough in your process that a bad morning or a confusing prompt does not unravel everything you have built. That level of consistency is achievable. It just requires treating preparation as a craft rather than an event.
