Seven Days Before the Interview: Audit First, Grind Second

The calendar invite lands and your stomach drops. Seven days. You open LeetCode and start solving problems. Arrays, then trees, then a random graph problem because you remember those are on the list. Three hours later you've done six problems and have absolutely no idea if you're ready or just really good at burning time on a Sunday.

This is what most engineers do. It's also what gets them eliminated by the second round.

A solid one-week coding interview prep plan is not about volume. It's about coverage and calibration, and finishing in a state where you can actually perform. This is Part 1 of a four-part countdown series. We start where you are now: seven days out, a full week still ahead.

The Audit You've Been Avoiding

Before you solve a single problem this week, you need an honest picture of where you stand. Not how you feel about each topic. How you actually perform under a timer.

Most engineers audit by vibes. "I'm pretty good at trees" means you've done some tree problems and vaguely remember the recursive template. That is not the same as applying it to a problem you've never seen, under 35 minutes, while narrating your reasoning out loud. Wildly different skills. One feels like thinking. The other feels like being watched.

Do a cold diagnostic instead. Pick one LeetCode medium from each of these 10 patterns, set a 30-minute timer per problem, and go:

• Arrays and hashing
• Two pointers
• Sliding window
• Binary search
• Trees (one BFS, one DFS)
• Graphs (one connected-components problem, one shortest-path)
• Backtracking
• Dynamic programming
• Heaps and priority queues
• Monotonic stack

Write down three things for each: did you solve it, how long it took, and whether you could correctly explain the time and space complexity. That output is your audit. It is more honest than anything you'd tell yourself otherwise.

Don't skip the edge case check. Can you handle empty inputs, single elements, negative numbers, and duplicates? Most interview bugs aren't in the algorithm. They're in the wrapper logic around it.

This is you doing a vibes-based self-assessment. Don't be this person.

The Patterns That Actually Pay Off This Week

The distribution of questions at FAANG-level interviews is well-documented enough to plan around. Arrays and hashing cover roughly 30 percent of questions. Trees and graphs together cover about 20 percent. Two pointers and sliding window add another 15. Binary search accounts for 10 percent more.

Five pattern families cover 75 percent of what you will see. If your audit flagged any of these as weak, that is where the next five days go. Not into the comfortable patterns where you're already solid and can feel productive while accomplishing nothing.

A note on dynamic programming: if you don't already have a working mental model for DP, this is not the week to build one from scratch. DP takes longer to internalize than any other pattern, and one week is not enough to go from shaky to reliable under pressure. Review the framework if you have it. If you don't, skip new DP problems entirely and spend that time somewhere with better return. (If you need the DP framework itself, we covered it in Dynamic Programming Is Just Recursion With a Memory.)

Monotonic stacks are underrated on yield per hour. If you haven't done them, two hours on the pattern covers next-greater-element variants, daily temperatures, and stock span problems. They show up more often than people expect, and the pattern is fast to internalize. It's the kind of thing you can go from zero to dangerous in an afternoon, which is exactly the energy you want this week.

A Schedule That Doesn't Break You in Three Days

Eight hours on Saturday sounds like dedication. In practice it means you wake up late, feel slow, spend four hours stuck on one problem, and destroy your confidence right when you need it most. Classic self-own.

Spreading the same total hours across a week retains more. That's just how memory works.

Two focused hours per day. Every day. Split like this:

Morning block (45 minutes): One timed problem. Set a 35-minute timer and solve. Spend the remaining 10 minutes reviewing the solution, even if you got it right. Look at edge cases you missed. Look at whether your complexity analysis was correct. If you didn't finish, read the editorial and trace through it.

Evening block (75 minutes): Thirty minutes reviewing your two weakest patterns from the audit, not by solving problems but by reading solutions and asking why each decision was made. Then 45 minutes on your mistake list, which we'll get to below.

The weekly rhythm: days 1 and 2 are the audit and a hard focus on your bottom two patterns. Days 3 through 5 put 70 percent of your practice on those same weak patterns and 30 percent on keeping your strong ones warm. Day 6 is mock interviews only, no new material. Day 7 is company research, logistics, and one short review session of your strongest topics to finish confident.

Start the Mock Interviews Before You Feel Ready

Everyone knows they should do mock interviews. Almost nobody starts early enough. The mental model is "I'll do mocks once I feel ready," which means you run your first one two days before the interview, it goes badly, and there's no time to act on the feedback. Extremely normal. Also a disaster.

A single timed mock gives you more signal than three hours of passive problem review. It surfaces things you can't measure any other way: whether you narrate your thinking without prompting, whether you ask clarifying questions before you code, whether you handle being stuck without freezing, and how your pacing looks against a real clock.

Start on day 3 or 4. Use platforms like interviewing.io or Pramp, or recruit a friend who'll stay quiet and just read you a problem. SpaceComplexity runs voice-based mock interviews with rubric-scored feedback across communication, problem-solving, and code quality, which is useful if you want structured feedback on all three dimensions at once.

That exact moment when you realize mock interviews and real interviews are completely different activities.

If your mock goes badly, that's not a sign to delay the next one. That's the whole point. Getting a failure out of the way early shrinks the real interview in your head.

One calibration point worth having: a 35-minute solve with clean code, clear narration, and correct complexity analysis is a pass. A 45-minute solve with one bug you caught yourself and a complexity misstep you corrected when pushed is also a pass. You don't need to be flawless. You need to be functional, communicative, and self-correcting.

The bar is higher than most people think for the first quality and lower than most people fear for the last two. For a full breakdown of what costs people offers even when they solve the problem, read Technical Interview Communication: You Solved the Problem. So Why No Offer?

Your Mistake List Is Lying to You

Most engineers track which problems they got wrong. That list is almost useless. What matters is why you got them wrong, because five different failure modes live inside "got it wrong" and each one has a different fix.

A graph problem you missed could mean:

1. Pattern recognition failure: you didn't see it was a graph problem at all
2. Algorithm gap: you knew the pattern, forgot the mechanics (which DFS variant, how to track visited)
3. Implementation bug: the algorithm was right but the code had an off-by-one or a wrong base case
4. Time failure: correct approach, ran out of time getting it clean
5. Communication failure: got a working solution but couldn't explain the complexity

Go back through your list and tag every problem with one of those five. Then count. The two failure modes with the highest frequency are where your next three practice sessions go. Treating every mistake as "I need to do more graph problems" when the real issue is pattern recognition spreads your effort across the wrong axis. Fix the mode, not the individual problem.

This changes what a review session looks like:

• Pattern recognition failure: Read problem statements and name the pattern before you look at any solution. Classification practice, not solving.
• Algorithm gap: Drill the mechanics until they're automatic. Write the template from memory.
• Implementation bug: Trace your code line by line on paper. Find the exact line, not just "something was off."
• Time failure: Repetition on problems you already know, building speed through familiarity.
• Communication failure: Next mock, narrate out loud the entire time, not just when you're stuck.

Company Research That Changes Which Problems You Solve

Company research is not about memorizing their mission statement or reading their about page. It's about adjusting which 20 percent of your remaining prep time you spend on specifics.

LeetCode's company tags are the starting point, with caveats. Filter to problems tagged in the last six months, and only trust high-frequency items. Meta and Amazon have enough data volume that their tags are reliable. Google actively rotates its question pool, so tags are more directional than predictive. Startups rarely have enough submissions to be useful. Never try to grind all 300-plus tagged problems for a company. Pick 20 to 30 high-frequency ones and cross-check them against your audit gaps.

Glassdoor and Blind are underused for structural intelligence. Search "[company name] interview experience 2025" and read 10 to 15 recent posts. You're not hunting for leaked questions. You're looking for format signals: how many rounds, what difficulty level, whether system design is included, whether they run your code or evaluate pseudocode. That changes how you structure your final days more than knowing a specific problem does.

The job description is the most underused prep tool in existence. If the posting mentions high-scale distributed systems, your interviewer builds them and will probably probe for optimization intuition. If it says ML infrastructure, expect dependency-graph or scheduling problems. The description names the domain. The domain shapes the angle. Read it carefully and ask which patterns apply.

Finally, ask the recruiter directly. Not what will be on the interview. Ask what format to expect and whether there is anything specific you should prepare. A good recruiter will tell you the round count, time limits, whether you'll write runnable code or pseudocode, and sometimes which team you're interviewing for. That is signal you cannot reverse-engineer from LeetCode tags.

Recap

• Audit by performance, not confidence. Solve one problem per pattern cold with a timer. Write down your results.
• Five pattern families cover 75 percent of interview questions: arrays/hashing, trees/graphs, two pointers, sliding window, binary search.
• Skip new DP problems if you don't have the framework. Use that time on monotonic stacks or heap problems instead.
• Two focused hours per day beats eight on Saturday. Morning: timed problem. Evening: weak pattern review plus mistake review.
• Start mock interviews on day 3 or 4. One mock is worth three hours of passive review.
• Tag past mistakes by failure mode, not by problem. Fix the top two modes.
• LeetCode company tags: filter to last 6 months, high frequency only. Trust Meta and Amazon more than Google or startups.
• Read the job description for domain signals. Ask the recruiter for format signals.

Part 2 covers the 72-hour window, when the strategy shifts from coverage to calibration.

Further Reading

• Tech Interview Handbook: Coding Interview Study Plan
• Tech Interview Handbook: Algorithm Cheatsheets by Topic
• NeetCode: Blind 75 Practice Problems
• GeeksforGeeks: DSA Interview Crash Course
• LeetCode Discuss: Company Interview Experiences