Coding Interview Problems
Algorithm puzzles used in hiring, and how they relate to real work.
Also known as: leetcode, algorithm interviews, whiteboard interview
Many companies screen engineers with algorithm puzzles: given an array or a string, write a function that does X, within time and space limits, while talking through your thinking. Practice sites (LeetCode, HackerRank and others) are full of them.
What they actually test
- Whether you can break down a problem and reason about it aloud.
- Familiarity with common data structures and their costs (data structures, Big O).
- Basic algorithm patterns.
- Clean, correct code under mild pressure, with edge cases handled.
- Communication: do you ask clarifying questions, and take hints well?
How well they predict real job performance is debated. Day-to-day work is mostly reading code, design, debugging and collaboration. But the format is common, so it’s worth preparing.
Patterns that cover most problems
| Pattern | Typical hint |
|---|---|
| Hash map or set for lookups | “have I seen this?”, counting, duplicates |
| Two pointers | sorted arrays, pairs, palindromes |
| Sliding window | longest or shortest subarray with a property |
| Binary search | sorted data, or a monotonic answer |
| Stack | matching brackets, “next greater element” |
| Breadth-first and depth-first search | trees, grids, graphs |
| Recursion and backtracking | combinations, permutations |
| Dynamic programming | overlapping subproblems, optimal choices |
| Sorting first | intervals, grouping |
How to approach one
- Restate the problem and ask questions: input sizes, duplicates, empty input, negative numbers.
- Work an example by hand.
- State the brute-force solution and its cost (brute force).
- Improve it with a better structure or pattern, and explain why.
- Write the code carefully, naming things clearly.
- Test with edge cases, out loud.
- State the time and space complexity.
Preparing
Practice regularly in your own language, learn the patterns instead of memorizing solutions, practice speaking while solving, and review what you got wrong. See technical interviews.