Three things, in this order. The complexity of the five structures you will actually say out loud, the off-by-one rules for binary search bounds, and the base case pattern for tree recursion. Then stop. Everything else available to you at this hour, especially the topic you are worried about, has a lower expected return than reading your own three recurring mistakes twice, and quite a lot of it has a negative one.
The order, and where it stops
Time boxes, because the failure mode at this hour is not choosing badly. It is choosing five things and finishing none of them.
Minutes 0 to 15: your own three recurring mistakes
Not a topic list. Open your last ten solved problems and write down the reason you were stuck or wrong each time, in process terms. These go at the top of the page because they are the only revision item nobody else could have written for you.
Minutes 15 to 35: five complexity lines
Write them from memory first, then check. You will be asked for a complexity on every single question regardless of topic, which makes this the highest frequency item on the page.
Minutes 35 to 60: binary search bounds
Two templates written out by hand, then the three bound questions, then the six case hand test. Binary search is the most common place where a candidate who had the right idea still ships a wrong answer.
Minutes 60 to 80: the tree recursion base case
One five line skeleton and a table of identity values. Trees show up constantly and the whole family collapses into one shape once the base case is automatic.
Minutes 80 to 90: stop
Read your three mistakes twice, close every tab, test your microphone and your editor, drink water. Opening one more problem here is the single most common way people lose a round they were ready for.
Block one: the five complexity lines you will say out loud
Not every structure. Only the five whose names come out of your mouth in a real 45 minute round. Say the numbers as full sentences while you check them, because saying them is the actual skill being graded.
| Structure | What you say out loud | The numbers | The line that catches people |
|---|---|---|---|
| Hash map and hash set | "I will keep a map from value to index" | Insert, lookup and delete average O(1). Worst case O(n). Full iteration O(n). | Say "average O(1)". Dropping the word average invites the collision follow up, and answering that cold goes badly. |
| Dynamic array (list, vector) | "I will append to a list and index into it" | Index O(1). Append amortised O(1). Insert or delete at the front O(n). Membership test O(n). Sort O(n log n). | A pop(0) or a shift inside a loop turns an O(n) algorithm into O(n²). Slicing copies, so a sliding window built from slices is quadratic. |
| Heap (priority queue) | "I will hold a min heap of size k" | Push O(log n). Pop O(log n). Peek O(1). Heapify an existing array O(n). | Heapify is linear, not n log n. Top k with a size k heap is O(n log k), not O(n log n). Both are free marks if you volunteer them. |
| Deque | "I will use a deque as the BFS queue" | Append and pop at both ends O(1). Index into the middle O(n). | A monotonic deque is amortised O(1) per element because each element is pushed once and popped once. Say amortised, and say why. |
| Sorted structure (balanced BST, TreeMap) | "I need the smallest key above x, so I want a sorted structure" | Insert, delete, search, predecessor and successor all O(log n). In order traversal O(n). | Python has no built in one. Say that, then offer the fallback you would actually write, two heaps or a sorted list with binary insertion, instead of bluffing. |
One extra line worth memorising: recursion costs stack space equal to the depth, so a tree recursion is O(h) space, where h is log n on a balanced tree and n on a skewed one. Interviewers ask for space more often than candidates expect, and "constant extra space" is wrong the moment you recurse.
Block two: the binary search bounds rules
The rule that fixes most off-by-one bugs is to own exactly two templates and never blend them mid problem.
Template A, exact match, closed interval. Use it when you want the index of a specific value.
lo = 0andhi = n - 1- Loop while
lo <= hi mid = lo + (hi - lo) // 2- Too small,
lo = mid + 1. Too big,hi = mid - 1. Equal, returnmid - Falling out of the loop means not found
Template B, first index where a predicate is true, half open interval. Use it for leftmost, rightmost, insertion point, and every minimum feasible value question.
lo = 0andhi = n- Loop while
lo < hi mid = lo + (hi - lo) // 2- If
ok(mid)thenhi = mid, elselo = mid + 1 - Exit with
lo == hi, the first true index, ornif the predicate is never true
Then three questions, asked in order, every time you write one:
- Does the upper bound match the loop condition?
hi = n - 1pairs with<=.hi = npairs with<. Pairingn - 1with<silently drops the last element. Pairingnwith<=reads off the end of the array. - Does every branch shrink the range? Writing
lo = midwith a rounded down mid loops forever the momenthiequalslo + 1. If your logic genuinely needslo = mid, switch to the upper mid,mid = lo + (hi - lo + 1) // 2. - What does
lomean when the loop ends? In template B it is the count of elements that fail the predicate, which is also the insertion point. If you cannot say that sentence, you cannot trust the return value.
Two more, both cheap. Write lo + (hi - lo) // 2 rather than (lo + hi) // 2 and say "avoids overflow in a fixed width language" as you type it. And when you binary search on the answer rather than on an array, the search space is the answer range, not the input, so state explicitly that the predicate is monotone before you commit to it. If feasibility can flip back and forth, binary search is simply the wrong tool, and noticing that has just saved you twenty minutes.
The six case hand test. Run your template on paper against an empty array, a one element array with the target below, equal to and above that element, and a two element array with the target sitting between the two values. Those six cases catch essentially every bounds bug you are capable of writing, and the exercise takes four minutes.
Block three: the tree recursion base case
Almost every tree question is the same five lines. Check for null, recurse left, recurse right, combine, return.
if node is None: return IDENTITYleft = f(node.left)right = f(node.right)return combine(left, right, node.val)
Two habits carry the whole family. Recurse into both children unconditionally and let the null base case absorb them, rather than null checking children before you call. Checking in both places is where duplicated logic and wrong depths come from. And decide before you type whether the answer travels up as a return value or down as a parameter, because mixing the two directions inside one function is the other reliable bug.
The only thing to actually memorise is which identity value keeps the parent correct:
| Question | Return on null | Combine |
|---|---|---|
| Maximum depth | 0 | 1 + max(left, right) |
| Count of nodes | 0 | 1 + left + right |
| Sum of values | 0 | node.val + left + right |
| Valid BST, balanced, same tree | True | left and right and the local check |
| Lowest common ancestor | None | Both sides non null, return this node. Otherwise return whichever side is non null |
| Diameter, max path sum | 0 | Return the height upward, update a separate best variable inside the call |
Now the worked exception, because it is the one that gets written wrong under pressure. Minimum depth is not the mirror of maximum depth. Take a root whose left child is a leaf and whose right child is null. With if node is None: return 0 and return 1 + min(left, right), the recursion computes 1 + min(1, 0) and returns 1. The correct answer is 2, because minimum depth is measured to a leaf and a node with one child is not a leaf. The fix is either an identity of infinity for null, or an explicit branch: when one child is missing, recurse only into the other. Say that difference out loud if the question comes up. Noticing it is worth more than solving the problem quickly and wrongly.
The skip list, stated explicitly
Everything below is a legitimate use of study time on a normal Tuesday and a bad use of it now.
- Any topic you have never implemented unaided. Segment trees, Fenwick trees, tries, Dijkstra, string matching, dynamic programming on trees, union find with path compression. If today is the first meeting, today is not the day.
- New problems. Do not open an unseen question. A fail here has no time left to be converted into a fix, and it walks into the round with you.
- The company tagged question list. At this hour it is a fear generator with no study value attached to it.
- Editorials for problems you failed last week. Reading a solution you could not produce feels like progress and leaves nothing retrievable behind.
- Obscure standard library corners. You will not recall them, and reaching for a half remembered API mid round costs a minute plus your composure.
- System design, if this round is coding. Different memory, different day.
- Video content of any kind. Passive input at the highest arousal moment of the week.
Sleep, food and water are not on the skip list. They outrank every item in this guide.
Why revising a weak topic in the last hour lowers your score
This is the part people resist, so here is the mechanism rather than the slogan.
A topic is weak precisely because the hours you already gave it were not enough. One more hour moves you from cannot do it to cannot do it, and it does so while producing a strong feeling of having learned something, because reading generates recognition and recognition feels like knowledge. The interview does not test recognition. It tests retrieval, out loud, on a clock, while a stranger watches.
Worse, the hour changes what you attempt. Having just read about a technique, you are primed to reach for it, and priming steers the first five minutes of the round, which is the part that decides the rest. Candidates who cram dynamic programming at noon try dynamic programming at two, on a problem a hash map would have closed in eight lines. Then there is load. Coding while narrating is a genuine dual task, and material loaded in the last hour sits in exactly the working memory that narration needs.
The asymmetry is the whole argument. A weak topic shows up in maybe one question in six, and an hour will not fix it. The complexity line, the bounds check and the base case are graded on every question you are asked, whatever the topic turns out to be. Revise what is graded every time, not what is graded once.
The one page you fill in
One side of one sheet. If it does not fit, cut something rather than shrinking the font. Copy this structure out by hand, because writing it is part of the revision.
- My three recurring mistakes, at the very top, each with a one sentence fix. Derive them from your own last ten problems. Good entries look like "I start coding before I have stated the approach", "I forget the empty input", "I say O(n) when the sort makes it O(n log n)", "I go silent for two minutes when I am stuck". Bad entries look like "graphs" or "DP". A topic is not a mistake.
- Five complexity rows, structure and numbers only, no prose.
- Two binary search templates, five lines each, plus the three bound questions.
- The tree skeleton and six identity values.
- Three sentences written out verbatim. The restate sentence: "Input is X, output is Y, can I assume Z?" The approach sentence: "My plan is A, that is O(b) time and O(c) space, does that sound reasonable to start with?" The stuck sentence: "Let me state a brute force first so we have something correct, then optimise."
- Nothing else. The blank space is doing work.
Those three verbatim sentences are the highest leverage lines on the page. They fire in the first ninety seconds and again when you freeze, and both are moments when improvisation is least available to you.
Where OfferPilot AI is the wrong tool right now
A vendor publishes this page, so here is the honest version. At T minus 90 minutes, installing and learning any new tool breaks the same rule as revising a weak topic, so today the answer is the paper page and nothing else. OfferPilot AI is Windows 10 and 11 only, with no macOS, Linux, mobile or browser extension, which settles it for a fair number of readers regardless. Code Copilot earns its place in the weeks before, where a captured problem comes back with the intuition, a dry run and the Big-O rather than a bare accepted solution, and that is the shape of thing you can still re-derive a fortnight later. Its overlay is excluded from screen capture at the operating system level, so it does not appear in Zoom, Teams, Meet or a screen recording. That claim covers screen sharing and screen recording only. It does nothing about a webcam, a lockdown browser, a proctor in the room or a second device camera, and where an assessment forbids outside help the honest window is the preparation, not the hour of it. The free tier is five minutes a day with no card, and the paid tiers sit on the pricing page.
The short version
Fifteen minutes on your own three recurring mistakes. Twenty on the five complexity lines. Twenty five on the two binary search templates and the six case hand test. Twenty on the tree base case table. Ten to read the page back and shut everything down. Nothing new, nothing weak, nothing unseen. A candidate who says average O(1) correctly, gets the bounds right first time, and names the null identity before typing it reads as strong, and not one of those three things needed the topic you were worried about.