The coding round is the one part of every loop that hasn't changed in fifteen years: two LeetCode-medium problems in 60–70 minutes, graded live. It is also strictly pass/fail — nobody asks about your RAG architecture after you've fumbled a linked list. The single most important sentence in this track: you are not preparing 500 problems, you are preparing 17 patterns — a pattern recognized is a problem half-solved, and one month of daily, deliberate, out-loud practice on the curated 83-problem list below is enough to make LeetCode-medium routine. The failure mode isn't lack of knowledge; it's grinding random problems silently, memorizing solutions instead of re-deriving them, and never rehearsing the performance itself: naming the pattern, stating the complexity, testing the edge cases, talking the whole time.
This track pairs with the Qualcomm Datacenter AI track — its daily DSA blocks are this plan; the company-reported problems below are starred there too.
- It's the filter. DSA rounds exist to cheaply eliminate, so they come first and they're non-negotiable. Passing buys you the right to show applied depth later.
- It's a code-quality sample. Interviewers (Qualcomm's are explicitly reported to do this) grade naming, decomposition, and edge-case discipline — a correct-but-messy solution reads junior. The round samples how you write code under mild stress, which is the job.
- It's a communication test. The strongest pass signal is a candidate who narrates: restates the problem, proposes brute force with its complexity, names the pattern that improves it, codes while talking, then tests aloud. Silence fails people who would have passed.
Seventeen patterns cover essentially every screen and onsite coding question. The trigger cue is what the problem statement sounds like; recognize the cue, and you know the shape of the solution before you write a line. Problems marked ★ are reported from real Qualcomm India loops. Every problem named in this lesson — all 83 — lives in the practice room with its pattern, model approach, and complexity behind a reveal, so the drill loop is built in.
Language call: Python is fastest to write and fine almost everywhere; if the company is systems-flavored (Qualcomm is), be ready to discuss what your Python hides — how a dict is a hash table, what a list resize costs — or just interview in C++ if it's your daily driver. Pick one language on day 1 and never switch mid-month.
The plan below fails without the protocol; the protocol works even if you fall a week behind the plan. (The practice room runs the pattern-drill and timed-mock-set parts of it in-app, with misses resurfacing automatically.)
- Two to three new problems + one review, every day (~90 minutes — the 83-problem curriculum needs ~3/day; stretch problems count as half, since sketching suffices). The review problem comes from your miss log — anything you couldn't solve cold, re-attempted at +3 days, then +7, then +14 (spaced repetition, the same trick that makes flashcards work).
- 25-minute cap per new problem. Stuck at 25 → read the solution, close it, re-derive from memory, and log it as a miss. Staring for an hour teaches stamina, not patterns.
- Narrate everything, every time — restate, brute force + complexity, pattern, code, then test aloud on: empty input, single element, duplicates, extremes. This is rehearsal for the actual graded behavior, and it feels ridiculous alone precisely because nobody practices it.
- Log every miss with one line: problem, pattern, the insight you were missing. The log, not the problem list, is your personal curriculum by Week 4.
The full 83-problem curriculum, week by week. Problems marked (stretch) are hards you should recognize and sketch even if you don't finish them cold; everything else is a must-solve. If a week overflows, cut stretch problems, never the protocol.
The highest-frequency patterns and the complexity-analysis muscle.
- Patterns: arrays & hashing, two pointers, sliding window, prefix sums, binary search (incl. on-the-answer).
- Arrays & hashing: Two Sum, Group Anagrams, Product of Array Except Self, Longest Consecutive Sequence, Majority Element (learn Boyer–Moore), Subarray Sum Equals K.
- Two pointers: 3Sum, Container With Most Water, Sort Colors, String Compression ★, Trapping Rain Water (stretch).
- Sliding window: Best Time to Buy and Sell Stock, Longest Substring Without Repeating, Longest Repeating Character Replacement, Minimum Window Substring, Sliding Window Maximum (stretch — the monotonic-deque bridge to Week 2).
- Binary search: Koko Eating Bananas, Search in Rotated Sorted Array, Find Minimum in Rotated Sorted Array, Search a 2D Matrix, Median of Two Sorted Arrays (stretch — recognize the partition idea).
- Milestone: given any Week-1 problem, you name the pattern within 60 seconds of reading it, and stating time/space is reflex.
The Qualcomm-reported cluster lives here — treat ★ problems as mandatory.
- Patterns: fast/slow pointers, list surgery, stack & monotonic stack, tree DFS/BFS, BST, heap/top-k, design.
- Linked lists: Reverse Linked List, Merge Two Sorted Lists, Linked List Cycle, Remove Nth From End ★, Reorder List, Copy List with Random Pointer, Reverse Nodes in k-Group ★, LRU Cache ★ (design).
- Stacks: Valid Parentheses, Min Stack, Daily Temperatures, Asteroid Collision ★, Largest Rectangle in Histogram (stretch).
- Trees: Invert Binary Tree, Diameter of Binary Tree, Level Order Traversal, Right Side View ★ (Qualcomm asked the left-view mirror), Lowest Common Ancestor (BT and BST versions — different insights), Validate BST, Kth Smallest in BST, Binary Tree Maximum Path Sum ★, Serialize/Deserialize (stretch).
- Heaps: Merge k Sorted Lists ★, Top K Frequent Elements, Kth Largest in a Stream, Task Scheduler, Find Median from Data Stream (stretch — two heaps).
- Milestone: LRU Cache and Reverse Nodes in k-Group, cold, bug-free, in under 20 minutes each — both are pure "code quality under pressure" tests.
- Patterns: graph BFS/DFS on grids and adjacency lists, topological sort, union-find, backtracking, tries, bit manipulation.
- Graphs: Number of Islands ★, Rotting Oranges (multi-source BFS), Clone Graph, Pacific Atlantic (reverse from the borders), Course Schedule I & II, Redundant Connection (union-find), Accounts Merge (union-find), Word Ladder (stretch — BFS on an implicit graph).
- Backtracking: Subsets, Permutations, Combination Sum, Word Search, N-Queens (stretch).
- Tries: Implement Trie, Word Search II (stretch — trie + backtracking composed).
- Bits: Single Number ★, Power of Two ★, Reverse Bits ★, Counting Bits; plus Find the Duplicate Number (Floyd's cycle on an array — file it under fast/slow).
- Milestone: you can write BFS and DFS on a grid from muscle memory and articulate when union-find beats both (incremental connectivity, no full traversal needed).
- 1-D DP (the ladder): Climbing Stairs → House Robber → Maximum Subarray (Kadane) → Coin Change → Word Break → Longest Increasing Subsequence (know the O(n log n) tails upgrade).
- 2-D DP: Unique Paths → Longest Common Subsequence → Edit Distance (stretch — recognize and set up the table even if slow).
- Intervals & greedy: Merge Intervals, Insert Interval, Non-overlapping Intervals (sort by END — know why), Jump Game.
- Second half — mocks: three timed sets of 2 problems / 70 minutes, full protocol, ideally with a peer or recorded and reviewed. Then burn the remaining days on your miss log exclusively — it is now a precise map of your weaknesses.
- Milestone: two consecutive timed sets at 2/2 with narration you'd be happy for an interviewer to hear. Rest the day before the real one.
[IC3] Design an LRU cache with O(1) get and put. Which data structures combine, and why does neither alone suffice?
A hash map alone gives O(1) lookup but has no notion of order, so you can't find the least-recently-used entry without a scan. A doubly-linked list alone maintains perfect recency order — move a node to the front on every access, evict from the tail — but finding a key in it is O(n). The design is the combination: map from key → list node, list holds (key, value) in recency order. get = map lookup + unlink node + relink at head; put = same, plus on overflow evict the tail node and use the key stored in that node to delete its map entry — forgetting that back-pointer from list to map is the classic bug. Both ops are a constant number of pointer operations. Follow-ups to expect: thread safety (one lock is fine; sharding the map if contended) and "what does Python's OrderedDict/Java's LinkedHashMap give you for free?"
[IC3] You need the k largest elements from a stream. Heap, full sort, or BST — walk me through the tradeoffs.
Full sort is O(n log n) time and O(n) memory and needs all data up front — wrong for a stream by definition. The stream answer is a min-heap of size k: each arriving element is compared to the heap's minimum (the weakest of the current top-k); if larger, pop-push. That's O(log k) per element, O(k) memory, and the answer is always current — the two properties a stream demands. A balanced BST of size k does the same asymptotically but with worse constants and more code; its real justification appears only when you also need order statistics or range queries over the retained set. The senior touch: say why min-heap and not max-heap ("I need cheap access to the worst of my best, not the best") — that one sentence shows the structure was chosen, not memorized.
[IC4] Number of Islands: BFS, DFS, or union-find? When does the right answer change?
On a static grid all three are O(rows × cols) and any is acceptable — say that first, then differentiate. DFS is the least code but recurses; on a pathological 250k-cell single island you risk stack overflow, which is exactly the edge case interviewers fish for — offer iterative DFS or BFS with an explicit queue/stack. BFS also generalizes directly to shortest-path variants (Rotting Oranges, Walls and Gates), so it's the better habit on grids. The answer changes when the problem becomes dynamic: "islands appear one cell at a time, report the count after each" (Number of Islands II) makes re-traversal O(n) per update — union-find with path compression gives near-O(1) amortized merges. Rule worth saying aloud: traversal for static connectivity, union-find for incremental connectivity.
[IC4] How do you recognize that a problem wants a sliding window — and when does the window technique break down?
The cue is a contiguous subarray/substring optimizing some property: "longest substring with at most k distinct", "minimum window containing…". The window works when the property is monotone under growth/shrink: extending the right edge can only move you toward violating (or satisfying) the constraint in one direction, so each pointer advances at most n times — O(n) with a hash-map of window contents. It breaks down when monotonicity fails: negative numbers in a "subarray sum ≤ target" problem mean growing the window can decrease the sum, so shrinking is no longer a correct response — you switch to prefix sums (+ hash map or sorted structure). It also doesn't apply to non-contiguous subsequences — that's DP territory. Stating the monotonicity condition, not just the trigger phrase, is what separates pattern-matching from understanding.
[IC4] Take coin change from brute-force recursion to memoization to tabulation. What exactly changes at each step, and what stays the same?
What never changes is the recurrence: minCoins(amount) = 1 + min over coins of minCoins(amount − coin). Brute force evaluates that recurrence as a tree — exponential, because the same subamount is recomputed astronomically many times. Memoization changes only the bookkeeping: cache each computed subamount, and the tree collapses to O(amount × coins) time — same code plus a dictionary, still top-down, still recursion-depth-limited. Tabulation changes the direction: build an array from 0 up to amount, each cell filled from already-final smaller cells — same complexity, no recursion, and the state layout becomes explicit (which is what lets you spot space optimizations like keeping one row of a 2-D table). Interviewers ask this to check you see the invariant: DP isn't a trick, it's the same recurrence with the redundancy removed. Base cases and the unreachable-amount sentinel (∞ → −1) stay identical throughout.
[IC5] Find the top-k most frequent items in a stream too large for one machine's memory. Evolve your whiteboard heap answer into a system.
The whiteboard answer — hash-map counts + size-k min-heap — dies at "too large for memory": the count map is the thing that doesn't fit (the heap was never the problem; it's O(k)). First move: shard by hash(item) across workers, each holding exact counts for its shard, each maintaining a local top-k; a coordinator merges local top-k's — exact and correct because every occurrence of an item lands on the same shard. If even per-shard counts blow memory, trade exactness for sketches: a Count-Min Sketch bounds memory at the cost of overestimates, paired with a heap of candidate heavy hitters (or use Space-Saving/Misra-Gries for deterministic error bounds). Then say the systems words that levels this answer: windowing (top-k over the last hour ≠ all time — decay or ring of sketches), skew (one hot key overwhelming a shard → split hot keys with local pre-aggregation), and where the merge is approximate (a globally-frequent item that's never locally top-k — bound it or widen local k). This is the question where a DSA round quietly becomes a design round; walking that gradient calmly is the IC5 signal.
- Random grinding is the #1 failure mode. 300 shuffled problems teach less than 70 organized by pattern with spaced review of your misses.
- Reading solutions isn't the sin — skipping the re-derive is. Solution → close it → rebuild from memory → log the missing insight. Otherwise you've stored trivia, not a pattern.
- Silence fails passable candidates. Every practice rep is narrated: pattern, complexity, edge cases. The interviewer grades the monologue as much as the code.
- State complexity before coding, not after being asked. "Brute force is O(n²); the sorted input suggests two pointers for O(n)" — that sentence, early, is worth more than a faster finish.
- Test aloud before declaring done: empty, single element, duplicates, extremes, and the input that breaks your loop bounds. Declaring done and being wrong costs double.
- Don't switch languages mid-month. Fluency compounds; novelty resets it.
- The 25-minute cap is load-bearing. Long struggles feel virtuous and teach almost nothing per minute.
- Patterns beat encyclopedias in the room too. If a problem resists its apparent pattern for 5+ minutes, say so and re-classify out loud — interviewers reward visible course-correction.
Flashcard. One month = 17 patterns × 83 problems × the daily protocol (2–3 new + 1 spaced review, 25-min cap, narrate always, log every miss). W1 arrays/windows/binary-search (21), W2 lists/trees/heaps (25, the ★ Qualcomm cluster), W3 graphs/backtracking/tries/bits (21), W4 DP/greedy (13) + timed mocks + miss-log only. Stretch hards are recognize-and-sketch, not must-finish. The round grades three things: pattern recognition, code quality, and the narration — train all three every single day.
NeetCode 150 (the base list, pattern-organized, with videos), Blind 75 via the Tech Interview Handbook (the minimal classic), Sean Prashad's LeetCode Patterns (pattern → problem index), Striver's A2Z sheet (the exhaustive India-standard syllabus — use as reference, not as the plan), and the Tech Interview Handbook's coding-interview cheatsheet for the round's etiquette: exactly the narrate-test-communicate behaviors the protocol drills.