12 Algorithm Patterns: Talking Points for AI-Assisted Code
This post is the tactical pattern catalog. For the four-phase psych framework that wraps it (Internalize → Explain → Defend → Modify), see the sibling Defending an AI-Assisted Answer: A Talking Points Playbook. Together they're the candidate-side defense surface — playbook on top, pattern catalog underneath.
You're 18 minutes into a Stripe phone screen. Your AI tool just produced a clean sliding-window solution for "longest substring with at most K distinct characters." You typed it in. Tests pass. The interviewer leans into the camera.
"Walk me through your approach. Why O(n) and not O(n log n)?"
You stammer. "Uh, sliding window is faster I think... we, uh, move the right pointer and then... shrink from the left." Three seconds of silence. The interviewer types something into their notes. The follow-up is going to be worse.
That moment is where AI-assisted candidates lose the round — not because the tool got fingerprinted, but because the candidate cannot defend the code in their own voice. This post is the discipline that fixes that.
Key takeaways
- The "explain your code" question is the single most common interviewer-side detection vector in 2026, and no kernel driver fixes it. The defense is candidate-side: internalize the AI's answer before the interviewer asks.
- Study Mode turns AI from a paste-engine into a learning surface. Click any node in the system-design or algorithm graph to drill into the invariant, the complexity argument, and the failure mode. By the time you start typing, the answer is yours.
- This post is the talking-points pattern catalog: 12 of the most common AI-assisted patterns, each with the anti-pattern phrase that outs you, the strong-candidate phrase that defends like an engineer, and the common follow-up the interviewer will ask next.
Section 1 — The "explain your code" trap
Why interviewers ask "why this approach" is independent of whether they suspect an AI tool. The question is a coherence check. A senior candidate has reasons for picking sliding window over a hashmap-of-substrings, and those reasons are mathematical (amortized linear walk vs quadratic enumeration), structural (the input has a moving constraint), or empirical (the input range hits the regime where one beats the other). A junior candidate picks the algorithm by recognition without the reasoning underneath.
Strong candidates sound like this: "I noticed the constraint reduces to 'maintain a window over the input where some predicate stays valid.' That's a sliding-window pattern. The reason it's O(n) and not O(n²) is that each character enters and exits the window at most once across the entire scan, so the inner work is amortized constant. A hashmap of all substrings would be O(n²) construction with no early exit, which is strictly worse here."
Weak candidates sound like this: "I used a sliding window because that's the pattern for substring problems. It's faster — O(n) instead of O(n log n) or whatever."
The pattern is identical to what David Haney, an engineering manager who has written extensively on hiring-side detection, calls the "no one can fake understanding" check. The interviewer asks, the candidate either has a structured defense or doesn't. AI gave you the answer, but if you didn't internalize the why, the answer is a liability.
The good news: the defense is a fixed, learnable structure. Three things, every time:
- Name the pattern. Not "sliding window," but the constraint shape that signals sliding window — "maintain a window where a predicate stays valid as we scan."
- Defend the complexity with an amortization argument. Not "it's O(n)," but the loop-invariant fact that explains why it's O(n).
- Acknowledge the alternative. "I considered X, but rejected it because of Y."
If your AI tool drops a working sliding-window solution and you can produce those three sentences without panic, you read as senior. If you can't, the working code becomes a question mark in the recruiter notes.
Section 2 — Why screenshot tools make this worse
The capture pipeline matters here, and it's not a feature checklist — it's a workflow gap.
Screenshot-and-OCR tools work by snapping a frame of your screen, OCR'ing the text, feeding it to a model, and pasting the model's output back into your editor. The candidate's role in that loop is mechanical: copy the problem into the AI's input window, wait for the snapshot, paste the answer back. There is no moment when the candidate is forced to reason about the structure of the answer. The model thinks; the candidate transcribes.
That workflow trains exactly the wrong muscle. Every round, the candidate gets faster at paste latency and slower at internalization. By the time the interviewer says "walk me through it," the candidate has spent zero seconds with the answer in their own head.
FaangCoder's architecture changes the loop. The same Solve hotkey reads your code from process memory at the kernel and hands back a structured solution — but Study Mode is the surface where you actually learn it.
Study Mode renders the system-design or algorithm graph as a clickable structure. Each node is a concept (sliding window, two-pointer, monotonic stack, etc.); each edge is a tradeoff. Click a node to expand the invariant, the complexity argument, the canonical failure mode, and the language a strong candidate uses to defend it. The 60 seconds you spend in Study Mode after Solve are 60 seconds of active learning, not transcription.
The result, when the interviewer asks "why this approach": you have an answer. Not because you memorized one, but because you spent a minute reading the canonical defense and matched it to your code.
Section 3 — Study Mode walkthrough on a sliding-window problem
Concrete example. The problem is "longest substring with at most K distinct characters," classic sliding window. Walk-through:
Step 1 — Solve. Hit Alt+Enter. FaangCoder reads the problem from process memory and ships back a sliding-window solution: two pointers, a hashmap counting character frequencies in the window, a while loop that shrinks from the left when the distinct-character count exceeds K. Code lands in your editor. Tests pass.
Step 2 — Open Study Mode. Click the algorithm graph. The "two-pointer / sliding window" node lights up because that's the pattern Solve picked. Click it.
Step 3 — Read the invariant. The expanded node says: "Right pointer always moves forward. Left pointer never moves backward except when the window violates the predicate. At every loop iteration, the window represents a contiguous candidate substring satisfying the predicate." You re-read your code with that invariant in mind. The right++ line is the right-pointer advance. The while (distinct > k) left++ is the predicate-violation shrink. The invariant matches the code.
Step 4 — Click the O(n) edge. The complexity argument expands: "Each index enters the window at most once via right-pointer advance, and exits at most once via left-pointer advance. Total pointer moves across the entire scan: at most 2n. Therefore O(n) amortized — the inner while loop's total work across all iterations is bounded by n, not by n per outer iteration." That last sentence is the one a senior candidate produces under pressure. Read it twice.
Step 5 — Click the failure-mode edge. "If K equals or exceeds the number of distinct characters in the input, the window never shrinks, the answer is the full string. If K is zero, the answer is the empty string." You now know the two boundary cases by heart. The interviewer's "what about edge cases" question is pre-loaded.
Step 6 — Close Study Mode. Total elapsed: ~90 seconds. You've internalized the pattern, the invariant, the complexity argument, and the failure mode. When the interviewer asks "walk me through it," you have a structured answer in your own voice.
This is the rhythm. The point of Study Mode is not to make the AI smarter — it's to make the candidate ready to defend the AI's answer.
Section 4 — Talking points by pattern
Twelve of the most common AI-assisted patterns, with the language to use and the language to avoid. For each pattern, three things: the anti-pattern phrase that outs you as not understanding, the strong-candidate phrase that defends like an engineer, and the common follow-up the interviewer will ask next.
1. Sliding window
Anti-pattern: "I just used a sliding window because that's what works for substrings."
Strong: "The constraint was 'longest substring where some predicate stays valid,' which is the canonical sliding-window pattern. The window stays valid by shrinking from the left whenever the predicate is violated, which keeps the inner work O(1) amortized over the n-step right-pointer walk. Total complexity: O(n) time, O(distinct) space."
Follow-up + counter: "Why not enumerate all substrings with a hashmap?" → "That's O(n²) construction with no early exit. Sliding window exploits the fact that we only need the optimal valid window at each right-pointer position, not every window."
2. Two pointers (opposite ends)
Anti-pattern: "Two pointers is just a faster way to scan."
Strong: "The input is sorted, so for any pair (i, j) we can decide whether to advance the left or right pointer based on the comparison with the target. Each pointer moves monotonically, so total work is O(n) instead of the O(n²) brute-force pair enumeration. The correctness argument is that we never skip a valid pair: if arr[i] + arr[j] < target, advancing i strictly increases the sum, so no smaller i' paired with this j can match either."
Follow-up + counter: "What if the array isn't sorted?" → "Then I'd switch to the hashmap version — single pass, check target - element in the map, O(n) time but O(n) space. Two-pointer-on-sorted is the O(1)-extra-space version when sorting is allowed."
3. Two pointers (fast-slow / Floyd's)
Anti-pattern: "Tortoise and hare detects cycles, that's the pattern."
Strong: "Floyd's cycle detection works because if a cycle exists, the fast pointer (advancing two nodes per step) must eventually lap the slow pointer (one node per step) inside the cycle. The relative velocity is one node per step, so they meet within the cycle in at most cycle-length iterations. Total complexity O(n) time, O(1) space — strictly better than the hashmap-of-visited approach when memory is constrained."
Follow-up + counter: "How do you find the start of the cycle once you've detected it?" → "Reset one pointer to the head, advance both at the same speed; they meet at the cycle entry. Mathematically, the distance from the head to the cycle entry equals the distance from the meeting point to the cycle entry, going forward through the cycle."
4. Hashmap dedup / O(1) lookup
Anti-pattern: "I used a hashmap because lookup is fast."
Strong: "The lookup pattern is 'for each element, check whether the complement / partner / previous-occurrence already exists.' The hashmap gives O(1) expected lookup, so the outer scan is O(n) total. The space cost is O(n) in the worst case where every element is distinct. The tradeoff against a sorted-array binary-search approach is that we trade O(n) extra space for the ability to handle unsorted input in a single pass."
Follow-up + counter: "What about hash collisions?" → "Worst-case O(n) lookup if the hash function adversarially collides every key into one bucket, but the expected case is O(1). For interview-grade implementations I'd use the language's built-in hashmap, which uses a well-distributed hash and resizes the backing array to keep load factor under threshold."
5. Binary search on answer
Anti-pattern: "Binary search because the array is sorted."
Strong: "This is binary-search-on-the-answer-space, not on the array. The answer-space is monotonic — if k candies per child works, every smaller value also works; if k+1 doesn't, every larger doesn't either. So I'm binary-searching the answer-space [1, max_pile] and at each step running a linear feasibility check. Total complexity: O(n log max_pile), which beats the O(n × max_pile) brute force when max_pile is large."
Follow-up + counter: "How did you know the answer-space was monotonic?" → "The feasibility predicate is 'can we satisfy all m children with at most k candies each.' If k works, k-1 is harder, so monotonicity holds. The trick to spotting binary-search-on-answer is recognizing that the search space is the answer's value range, not the input."
6. Prefix sum
Anti-pattern: "Prefix sum lets you query range sums in O(1)."
Strong: "After O(n) preprocessing, any range sum [l, r] is prefix[r+1] - prefix[l] in O(1). This trades O(n) extra space for O(1) per range query, which is the right move when there are O(n) or more queries. The deeper pattern is 'cumulative state I can subtract' — works for sums, XOR, count of even/odd parity, anything where a difference of two cumulative values gives the range answer."
Follow-up + counter: "How do you handle updates?" → "Naive prefix sum is O(n) per update — you have to rebuild the suffix. For mixed update/query workloads I'd switch to a Fenwick tree (BIT) for O(log n) on both, or a segment tree if the operation is more complex than addition."
7. Monotonic stack
Anti-pattern: "Monotonic stack solves next-greater-element problems."
Strong: "The stack maintains a monotonic invariant — strictly decreasing in this case — so each element is pushed once and popped once across the entire scan. Total work is O(n) amortized, even though the inner while loop looks quadratic. The reason it works for next-greater-element: when we pop an element x because we see a larger y, we've found x's next greater element in O(1), and x is never reconsidered."
Follow-up + counter: "What if I want next-smaller-element instead?" → "Same structure, flip the invariant to strictly increasing. The pattern is identical — the stack stores the open candidates whose answer hasn't been resolved yet, and the monotonic property guarantees each element is touched at most twice."
8. BFS (level-order)
Anti-pattern: "BFS finds the shortest path."
Strong: "BFS processes nodes in layers — every node at distance d from the source is processed before any node at distance d+1. That layer-by-layer property is what guarantees shortest-path correctness on an unweighted graph. The frontier is a queue because FIFO is what produces the layered ordering. Total complexity: O(V + E)."
Follow-up + counter: "What if edges are weighted?" → "BFS no longer guarantees shortest path. Switch to Dijkstra for non-negative weights — that's O((V + E) log V) with a binary heap — or Bellman-Ford for negative weights at O(V × E). If all weights are 0 or 1, a deque-BFS variant gets you back to O(V + E)."
9. DFS (path / connected components)
Anti-pattern: "DFS explores the whole graph recursively."
Strong: "DFS uses a stack — explicit or via recursion — to do a depth-first traversal. For connected-components I'm marking visited nodes as I go, so each edge is examined twice (once from each endpoint) and total work is O(V + E). For path-finding I'd use DFS with backtracking — push the current node onto the path, recurse, pop on return — which lets me enumerate all paths or find any single path without revisiting completed branches."
Follow-up + counter: "What's the difference between iterative DFS and recursive DFS?" → "Iterative uses an explicit stack and the same O(V + E) complexity; the advantage is no risk of stack overflow on deep graphs. Recursive is cleaner to read but blows the stack at depth ~10⁴ in most languages. For production code I default to iterative; for an interview I'd ask the interviewer's preference and explain the tradeoff."
10. DP top-down (memoization)
Anti-pattern: "I memoized the recursion to make it faster."
Strong: "The recursion has overlapping subproblems — the same (i, j) state is computed multiple times across different recursion branches. Memoization caches each state, so total work is bounded by the number of distinct states times the per-state work. In this problem the state space is O(n × k) and per-state work is O(1), so total complexity is O(n × k) time and O(n × k) space."
Follow-up + counter: "Why top-down instead of bottom-up?" → "Top-down only computes the states actually reached by the recursion, which can be a strict subset of the full state space when the input is sparse. Bottom-up computes everything, which is sometimes wasted work. The tradeoff is recursion overhead versus possibly-unnecessary computation."
11. DP bottom-up (tabulation)
Anti-pattern: "I built a DP table from the bottom up."
Strong: "The recurrence is dp[i][j] = max(dp[i-1][j], dp[i-1][j-w[i]] + v[i]), which only depends on the previous row. So I'm filling the table in row-major order, and at each cell the inputs are already computed. Total time is O(n × W) where W is the capacity, and space is O(n × W) with a naive table or O(W) if I roll over the previous row in place."
Follow-up + counter: "How do you reconstruct which items were chosen?" → "Either keep the full table and trace back from dp[n][W] — at each cell, decide whether the optimal came from including or excluding item i — or store a parent pointer per cell. The first trades space for time-of-reconstruction; the second is symmetric. For large n × W where memory matters, I'd compute the table in a streaming way and store reconstruction info separately."
12. Union-Find / DSU
Anti-pattern: "Union-Find groups things into components."
Strong: "DSU maintains a forest of trees, one per equivalence class. find walks to the root with path compression — flattening the tree on the way back — and union merges two trees by attaching the smaller-rank root under the larger-rank one. With both optimizations, the amortized cost per operation is O(α(n)), the inverse Ackermann function, which is effectively constant for any input that fits in memory. Total complexity for m operations on n elements: O(m × α(n))."
Follow-up + counter: "Why both path compression and union-by-rank?" → "Either alone gives you O(log n) amortized. Both together give you the inverse-Ackermann bound. The compositional argument is that path compression alone can lead to long chains under adversarial unions, and union-by-rank alone doesn't flatten existing chains. They cover each other's failure modes."
Section 5 — The Study Mode rhythm
The full timing of an AI-assisted answer with proper defense, in seconds:
- 0–30s: AI proposes the solution. Code lands. Tests pass.
- 30–90s: You read it. Identify the pattern by name. Don't move your hands; the interviewer's read is "candidate is composing their thoughts." That's a normal thing.
- 90–150s: Open Study Mode. Click the pattern node. Read the invariant. Click the complexity edge. Read the amortization argument. Click the failure-mode edge. Read the boundary cases. Total: 60 seconds for the full canonical defense.
- 150–180s: Close Study Mode. Say out loud, in your own voice: "I'll use [pattern X] because the input has [constraint Y]. The complexity is [bound Z] because [amortization argument]. The alternative I considered was [W], rejected because [reason]."
Three minutes total, of which two are reading and one is rehearsing. When the interviewer asks "why this approach?" — at minute 18 of a 45-minute round — you have a 60-second answer pre-loaded. Not memorized. Earned.
The pattern catalog above is the cheat-sheet that lets Study Mode be a 60-second activity instead of a 10-minute one. Each pattern has three sentences ready; you match them to your code and adapt the specifics.
Section 6 — FAQ
What if I don't have time for Study Mode in a 45-min round? Three minutes of Study Mode is two questions of preparation. If the round has six questions, you're spending 18 minutes total, which is well under the time budget. Most candidates spend that time stalled and silent anyway. Better to spend it reading the canonical defense than freezing on follow-ups.
Does this work for system design too? Yes — and arguably it's where Study Mode shines hardest. The system-design graph in Study Mode is the canonical surface for "click a node, drill into the tradeoff." For a 45-minute design round, 5 minutes in Study Mode at the start of the design phase pre-loads the tradeoff vocabulary you'll need across the whole round. Sharded SQL versus a wide-column store, eventually-consistent versus linearizable, push versus pull replication — all of them have canonical defense paragraphs that Study Mode renders.
What if the interviewer asks about edge cases I didn't think about? The canonical defense for every pattern includes the failure-mode edge in Study Mode — the boundary cases where the chosen approach degrades or breaks. Reading that edge is the prevention. If you're caught flat-footed anyway, the senior move is to think out loud: "Let me work through that edge case. If the input is [empty / single element / all duplicates], my code does [trace through]. So the result would be [X], which means the edge case is [handled / breaks here]." Honest reasoning under pressure is a stronger signal than a smooth recital.
Can I use Study Mode mid-round? Yes, gated to Study Mode being open in your overlay. The hotkey works at any time. The 60-second per-pattern read is the right tool when the interviewer's follow-up forces you to switch frames — for example, you wrote a sliding-window solution but the interviewer changes the constraint and now the problem is monotonic-stack-shaped. Study Mode lets you re-anchor in 60 seconds instead of stalling.
Is this still "cheating" if I understand the answer? That's a question for you, not for the tool. What we'll say: candidates who can defend their code under questioning read as engineers. Candidates who can't, regardless of where the code came from, read as not engineers. The tool produces working code; Study Mode produces an engineer who can defend it. Whether the result is ethical is an internal decision. We just build the surface.
Try it yourself
Run the proctor simulator before any important round to verify your tool can stay invisible while you study. Then practice the Study Mode rhythm on five problems of varying difficulty before the loop. The defense pattern is fixed; the only variable is how many problems you've drilled it against.
For the broader playbook on the four phases of a defensible AI-assisted answer, see the talking-points playbook. For the algorithm-pattern foundation underneath the catalog above, see the LeetCode patterns guide. For where this fits in the post-AI hiring discourse, see the post-AI hiring perspective.
If you want a tool whose Study Mode renders the canonical defense for every pattern your Solve hotkey produces, FaangCoder is $399 lifetime — Study Mode is in both the lifetime and monthly tiers. 14-day refund. Free demos at /demo/solve, /demo/debug, and /demo/optimize. Discord at discord.gg/rApY63vyNZ for engineers running this exact prep loop.