Coding Interview Vocabulary: A Cheat Sheet
Coding Interview Vocabulary: A Cheat Sheet
Most technical interviews fail not because the candidate can't code, but because they freeze on a vocabulary mismatch. The interviewer asks about the time complexity of your solution and the candidate panics, even though they were about to say "it's a loop inside a loop, so n squared." Same concept, different word.
This post is a quick cheat sheet for the terms that come up over and over in software engineering interviews, with the kind of plain-English summary you'd want to skim on the train ride over.
Complexity and analysis
Big O notation — how the runtime or memory of an algorithm grows as the input gets bigger. "O of n" means: double the input, double the work. "O of n squared" means: double the input, four times the work. You will be asked about this in approximately every interview.
Time complexity — how long an algorithm takes, measured in number of operations as a function of input size. Almost always expressed in Big O.
Space complexity — how much additional memory an algorithm uses, also in Big O. The thing interviewers ask about second, after time.
Amortized complexity — the average cost per operation across a sequence of operations. A dynamic array's append is O(1) amortized even though some appends trigger an expensive resize, because those expensive ones are rare.
Common data structures (the ones you'll be asked about)
Hash map — key-value lookups in O(1) average time. The single most common data structure in real interviews. If you're stuck on a problem, ask yourself "would a hash map help?" first.
Linked list — chain of nodes where each points to the next. Less common in real code than interviews would suggest. Worth practicing reverse-a-list and find-middle-node anyway.
Binary tree — each node has at most two children. The substrate for binary search trees, heaps, expression trees, and many of the trickier interview questions.
Heap — a tree-shaped structure that always gives you the min (or max) element in O(log n). When the question involves "top K" of something, a heap is usually the answer.
Graph — nodes connected by edges. Comes up whenever the problem is about "find a path," "find connected components," or "find the shortest route."
Algorithms you should know cold
Binary search — repeatedly halving a sorted range to find a target. Sounds simple, has more off-by-one bugs than you'd believe. Practice it on paper.
BFS (breadth-first search) — explore all neighbors at distance 1, then all at distance 2, etc. Uses a queue. Good for shortest-path problems on unweighted graphs.
DFS (depth-first search) — go as deep as you can before backtracking. Uses a stack (or recursion). Good for tree/graph traversal and "find all" problems.
Dynamic programming — break a problem into overlapping subproblems and cache the answer to each. The technique that powers Fibonacci, longest common subsequence, and most "minimize/maximize" interview problems.
Two pointers — walk through a sequence with two indices. The trick to many array problems (two-sum on sorted array, partition, reverse).
Sliding window — a moving range over a sequence. The trick for "longest substring with no repeats," "max sum of k consecutive elements," and similar.
Patterns and design terms
Memoization — caching the result of expensive function calls so you don't redo work. The cornerstone of dynamic programming.
Greedy algorithm — make the locally optimal choice at each step, hoping it leads to a globally optimal answer. Works for some problems (interval scheduling, Dijkstra). Fails for others (most knapsack variants).
Divide and conquer — split a problem in half, solve each half, combine. The shape behind merge sort, quicksort, and many tree algorithms.
Recursion — a function calling itself. Often presented in interviews next to iteration as "can you write this both ways?"
Backtracking — try a choice, recurse, undo the choice if it didn't work. The shape behind solving sudoku, N-queens, and most "generate all valid X" problems.
System design vocabulary
Latency — how long one request takes. Often measured as a percentile (p50, p99). When someone says "what's the p99 latency," they're asking "how slow is the experience for the slowest 1% of users."
Throughput — how many requests per second the system can handle.
Sharding — splitting data across multiple databases. The trick when one database can't hold everything.
Replication — keeping copies of data on multiple machines for redundancy and read scaling.
Idempotency — an operation that produces the same result if you run it multiple times. Critical for retryable APIs.
Eventual consistency — different copies of the data might disagree briefly, but will agree eventually. The trade-off most distributed systems make.
How to use this list
Don't memorize. Browse. The point of this list isn't to cram for an exam; it's to make sure that when an interviewer drops one of these words, you immediately think "oh, that's a thing I know about." From there you can ask follow-up questions and reason out loud.
If a particular term feels fuzzy, write a tiny implementation. Five lines of code that demonstrate binary search beats five paragraphs of explanation. And for the words themselves, Dev Puzzle's glossary has plain-English definitions of about fifty more programming terms — useful both for interviews and for the daily puzzle.