Eighteen days, 102 questions: a DSA sprint

On July 12, 2026, I wrote down the state of my coding preparation in two lists. The closed list was respectable: dynamic programming, intervals, two pointers, sliding windows, and the core graph algorithms (breadth-first and depth-first search, Dijkstra, topological sort, multi-source and 0-1 breadth-first search, cycle detection). The open list had twelve entries: tries, heaps and top-K, union-find, LRU caches, monotonic stacks, backtracking, binary search on the answer, linked list operations, string parsing with stacks, monotonic deques, segment trees, and data structure design questions that escalate with follow-ups.

Google’s two onsite coding rounds were about two and a half weeks away, back to back, each with a medium and a hard problem, written in a shared document with no IDE.

This post describes the sprint I built to close that gap: a bank of 102 questions drawn from public candidate reports, a plan that mapped every question to a date across three phases, a strict session protocol, and daily miss logs that turned out to be the most useful part of the whole exercise. It is part 7 of the 35 companies, 8 offers series.

Some context: I came to this as a data scientist. In March I had about 234 LeetCode problems solved over several years, almost none of them in the categories this loop leaned on, and in a self-assessment I could not start a single dynamic programming problem. By July that had changed, but the open list above shows how much was left.

The sprint in numbers:

• Open patterns: 12 on day 1 → all acquired and cold-verified by day 6, with no regressions on the verification day
• Question bank: 102 questions, every one mapped to at least one date
• Daily load: 7–10 problems a day in the integration phase
• Outcome: both onsite coding rounds came back Hire

Background: why a sprint, and why this shape#

By July the coding rounds had moved several times. Once the dates were finally fixed, I had a hard end point and a known list of gaps, which is the situation where a sprint beats open-ended practice.

Three problems shaped the design.

Open patterns were unfamiliar, not rusty. Some of the twelve I had never implemented at all. Acquiring a pattern from zero takes a different kind of session from refreshing one, and both are different from testing it under time pressure.

Known is not the same as available cold. I had “solved” many of the closed problems at some point. Whether I could solve them again with no warm-up, while talking, in a shared document, was a separate question that needed its own test.

Process failures looked like knowledge failures. In earlier mocks, problems I knew went wrong because I skipped a clarifying question, stated the wrong complexity, or jumped past the brute-force solution. Those are not algorithm gaps, and more algorithm practice does not fix them.

The sprint architecture#

The sprint had three inputs (a question bank, the open-pattern list, and the end date) and three phases, with a validation pass before day 1 to make sure the plan was complete.

graph LR
    A[("Public candidate<br/>reports")] --> B["Question bank:<br/>102 questions"]
    C["Open patterns: 12"] --> D["18-day plan"]
    B --> D
    D --> E["Phase 1:<br/>acquisition, 7 days"]
    E --> F["Phase 2:<br/>integration, 7 days"]
    F --> G["Phase 3:<br/>simulation and taper"]
    G --> H["Onsite rounds"]
    D --> V["Validation:<br/>coverage and load"]
    V --> D

    class A blue
    class B,C gray
    class D amber
    class E,F,G violet
    class V gray
    class H green

The question bank#

The bank came from public candidate reports for Google software and ML engineering interviews in India: interview write-ups on LeetCode Discuss and Glassdoor, and preparation guides. An earlier research pass had collected about 110 unique onsite problems from 2020 to 2026, weighted toward recent Bangalore and Hyderabad reports. From those I built a working set of 102 questions, each tagged with its pattern, its priority (P0 must know cold, P1 likely, P2 awareness only) and where it had been reported.

Two parts of the bank changed how I practiced.

Kill-shots. Eight problems in the reports were associated with a No Hire or Lean Hire outcome. I read them before every session, not to memorize them but to remember what a failing round actually looked like.

Disguises. Google problems rarely say “use Dijkstra.” Reports described problems framed as deleting hierarchical storage in a valid order (topological sort), finding the cheapest route through a teleporter network with broken links (Dijkstra), or counting active users in the last N minutes of a log stream (a sliding window with a monotonic deque). I kept a table mapping disguise to pattern and practiced recognizing the pattern from the framing in under 30 seconds.

Three phases, each with exit gates#

The plan was 18 days, and every question in the bank appeared on at least one date.

graph TD
    A["Phase 1: acquisition<br/>days 1–7"] --> B["Two or three new<br/>patterns per day"]
    B --> C["Day 6: cold verify<br/>all open patterns"]
    C --> D["Day 7: regression fix"]
    D --> E["Phase 2: integration<br/>days 8–14"]
    E --> F["Timed mixed sweeps,<br/>7–10 problems a day"]
    F --> G["Phase 3: simulation<br/>days 15–18"]
    G --> H["Stamina pairs:<br/>two problems back to back"]
    H --> I["Verbal sweep and<br/>template write"]
    I --> J["Taper day"]

    class A,E,G amber
    class B,F,H violet
    class C,D,I gray
    class J green

Phase 1, acquisition. Each day introduced two or three open patterns and ended with an exit gate I had to pass before moving on. Day 1 covered tries and heaps, and its gate was: can I write trie insert, search and prefix search from memory, and maintain a min-heap of size K? Day 3 covered union-find, LRU caches and binary search on the answer, and its gate was writing union-find with path compression and union by rank from memory. Day 6 was a cold verification of every open pattern, with no new material. Mine came back clean, with no regressions. Day 7 was reserved for fixing anything that had not.

Phase 2, integration. Seven days of timed, mixed practice organized as sweeps: graphs, then sliding windows and dynamic programming, then trees and string dynamic programming, then intervals, then arrays and greedy problems, then advanced dynamic programming and matrices. Within a day the problems were mixed rather than grouped by pattern. Interleaved practice, where problem types are shuffled rather than practiced in blocks, produces better retention; Rohrer and Taylor (2007) found that students who practiced shuffled problem types far outperformed students who practiced in blocks on a test a week later. It also matches the interview, where nobody tells you which pattern is coming.

Phase 3, simulation and taper. Stamina pairs of two problems back to back, to simulate the round format. Then a verbal sweep of the top-priority questions with a cold write-out of every pattern template, and a taper day with light review only.

Every question was run in one of three modes. Code meant a full implementation from scratch, timed, 30 to 45 minutes. Verbal meant stating the pattern, the approach, the complexity and the likely follow-up in 5 to 10 minutes, without code. Cold verify meant solving a previously practiced problem from scratch with no hints, to test whether the acquisition had held. Verbal mode let me cover far more of the bank than coding everything would have.

The session protocol#

Each day ran through the same planner and interviewer split I described in the post on running prep on Claude. The interviewer never named a pattern, never taught mid-problem, and pointed at bugs by asking me to trace specific inputs. My side of each problem followed a fixed protocol with time budgets:

1. Recognize the pattern from the framing before coding: about a minute.
2. Clarify constraints, edge cases and expected output with one or two questions.
3. State the brute force and its complexity, even when the optimal approach is obvious.
4. State the optimized approach and convince the interviewer before writing a line.
5. Code with clear names, thinking aloud.
6. Dry-run a small example by hand, then state time and space complexity and edge cases.

This is close to the sequence the Tech Interview Handbook’s coding interview cheatsheet recommends: clarifying questions before coding, approaches with trade-offs, stated complexity, then scanning for mistakes and testing with edge cases instead of announcing that you are done.

What the miss logs showed#

Every session ended with a log of each problem: clean, needed a nudge, wrong, or “I don’t know.” Reading those logs at the end of the integration phase was the most useful hour of the sprint, because the pattern in them was not the one I expected.

Three consecutive integration days show the shape.

The algorithm misses were real but scattered: a word-ladder search that enqueued intermediate patterns instead of words, an interval structure with comparison operators inverted at the boundaries, a trie built per octet that was wrong for IP wildcard matching. Each was a one-off.

The process misses repeated, and they were the ones that would cost a round.

Complexity wrong on the first attempt. On one day I stated the wrong complexity three times on a single problem before getting it right. I also gave 2^n for generating balanced parentheses, where the answer involves the Catalan numbers.

Skipping the brute force. On several problems I jumped straight to an optimized idea, which made it harder to explain and easier to get wrong.

No clarifying questions. Skipping them caused at least one bug that a single question about input size would have prevented.

Naming without content. Once I proposed “a balanced BST” for a problem without being able to say how its operations would work. An interviewer would ask the next question immediately.

Deflecting follow-ups. On one follow-up I answered “you tell me,” which is the one response that scores nothing.

On day 14 I scripted fixes for the process gaps rather than adding more problems, and later in the sprint I asked the interviewer persona to flag every missed complexity statement flatly, with no commentary.

The logs also caught at least one error the other way: on a task-scheduling problem I found a bug in the reference solution, which had dropped a condition about the earliest start time. Treat any reference solution, including an AI’s, as something to test.

At the end of the integration phase I ran a coverage audit. It found three high-priority problems still open (including the classic median of two sorted arrays), and four areas untouched (geometry, concurrency, iterator design, bitmask dynamic programming). I worked the open problems into the final days, starting with the median problem, and deliberately left the four areas, judging them unlikely at this level.

Results#

Both onsite coding rounds came back Hire. One of them involved an approach I later learned was wrong for the problem; the other went well, including a coded follow-up. The loop post in this series covers the rounds themselves.

Against the plan, the sprint went like this:

The taper is the honest failure. Instead of light review, I spent the last day before the rounds, and the hours right before them, in new dynamic programming coaching, and the coach leaked full solutions despite a nudges-only rule. It probably cost more in fatigue than it added in knowledge.

What I’d do differently#

Give it four weeks, not eighteen days. The plan was sound, but 7–10 problems a day for a week is close to the limit of what I could absorb. Two more weeks of integration would have made every day less compressed.

Drill process from day 1. The miss logs showed that complexity, clarifying questions and brute force mattered more than any single pattern. I scripted fixes for them on day 14; they should have been rules on day 1.

Protect the taper. Light review before a round is not laziness. The urge to cover one more topic is strongest the day before, and it is exactly the day to resist it.

Use verbal mode more. Verbal practice covered patterns at a fraction of the time and exposed the same reasoning gaps that coding did. A higher ratio of verbal to code in the integration phase would have widened coverage without more hours.

Conclusion#

A coding sprint is a scheduling problem with a known end date, and the shape that worked was simple: acquire the missing patterns with exit gates, verify them cold, then practice mixed and timed until the round format feels routine. The bank and the plan made the sprint possible. The miss logs made it effective, because they showed that the thing most likely to cost me a round was not an algorithm I did not know but a step I kept skipping.

Learn the patterns, but log the process. The process is what the interviewer is scoring while you think.

Part 7 of the 35 companies, 8 offers series. I join Google as a Software Engineer III, AI/ML, in October 2026.