Coding interview questions test whether you can turn an ambiguous problem into working, analyzed code under time pressure - not whether you've memorized a solution. The questions below are sourced from real candidate reports and onsite loops rather than generated or scraped from public repos, so what you practice matches what interviewers are actually asking right now. Use the checklist below on every question, whether it's from this bank or one you hit cold in an interview.

Step 1: Read and clarify

Restate the problem in your own words. Ask about input size, edge cases (empty input, duplicates, negative numbers), and expected output format. Confirm whether you can modify the input or need extra space.

Step 2: Walk through examples

Trace 2 - 3 examples by hand, including a small case and an edge case. Write down expected outputs before you design an algorithm.

Step 3: Start with brute force

Describe the naive solution first - nested loops, full sort, or exhaustive search. State its time and space complexity. Interviewers want to see you can solve it before you optimize.

Step 4: Spot the pattern

Look for signals: sorted input → two pointers or binary search; top-k / streaming → a heap; fast lookup → hash map; ordering + eviction → linked list + map; intervals → sort or sweep line; graph → BFS/DFS; connections arriving incrementally / grouping → Union-Find; combinatorial search → backtracking.

Step 5: Design the optimized approach

Explain your data structures and the main loop in plain English before coding. For each operation, state why it is O(1) or O(log n). Draw a quick diagram if it helps.

Step 6: Implement and test

Write clean code with meaningful names. After coding, walk through your earlier examples and one edge case out loud. Fix off-by-one errors and null checks.

Step 7: Analyze complexity

State time and space complexity and justify them. Mention trade-offs (memory vs speed, preprocessing vs query time). Be ready for follow-ups: thread safety, scale, or API changes.

Question categories you'll actually get asked

Practice questions cluster into a small number of recurring categories, and knowing which bucket a prompt falls into is half the battle. Array and string problems lean on sliding window for a shrinking or growing contiguous range, two pointers for a sorted array worked from both ends, Kadane's algorithm for a maximum subarray, and a monotonic stack for "next greater element"-style problems. Interval problems, meeting rooms, calendar conflicts, come down to sorting by start time and either merging overlaps or sweeping a line across them, covered in merge intervals. Graph problems split into BFS and DFS traversal, topological sort for dependency ordering (build systems, course prerequisites), and Union-Find for "are these two nodes connected" queries as edges arrive incrementally. Search problems are almost always binary search once you notice the answer space is monotonic, and selection problems (kth largest, median of a stream) reach for a heap or quickselect depending on whether you need one answer or a running one. Recursive problems split further into straightforward divide and conquer, backtracking when you need every valid combination rather than one answer, and dynamic programming once you notice overlapping subproblems in the recursion tree. A smaller but recurring bucket is bit manipulation: XOR tricks for finding a single non-duplicate, bitmasks for subset enumeration, and shift operations for anything phrased around powers of two.

None of these categories require memorizing which company asks what. They require recognizing the signal in the prompt fast enough that you spend your limited interview time on the solution, not on figuring out which family of problem you're looking at.

How difficulty is calibrated here

Difficulty on most question banks is a static label picked once and never revisited, which is part of why the same problem gets tagged medium on one site and hard on another. Here it tracks two things that actually move: how far past the brute force the optimized solution sits, and how often recent candidates report struggling with the follow-ups rather than the base problem. A question with a one-line optimized solution once you spot the pattern, many sliding window problems, reads as easier than one where the follow-up (thread safety, streaming input, a memory constraint that rules out your first approach) does most of the work, even when the base algorithms are comparably obscure. That distinction matters because grinding easy-tagged problems past the point of diminishing returns builds confidence, not skill, while jumping straight to hard-tagged problems on unfamiliar patterns burns time without building the recognition Step 4 depends on. Work through medium-tagged problems in a pattern until they stop taking you more than 20-25 minutes, then move to the hard-tagged versions of the same pattern before switching categories, instead of bouncing between difficulties and patterns at random.

How to structure a coding interview practice session

An hour of unstructured practice teaches less than the same hour spent deliberately. Work one pattern per session rather than jumping topics: pick a signal from Step 4 (say, sliding window), solve two or three problems in it back to back, and only move to the next pattern once the recognition step stops taking you more than a minute or two. Reserve the last 10 minutes of any session for the part most candidates skip entirely: talking through your solution out loud as if an interviewer just asked "why is this O(n)?", since silently knowing the answer and being able to defend it under a follow-up are different skills. If you're prepping solo and can't find a live partner, a text-to-speech readback of your own explanation, or narrating into a phone recording, catches gaps a silent read-through won't. Weekly, that adds up to roughly 3-5 sessions of 45-60 minutes each being more durable than one long weekend cram, because pattern recognition needs spaced repetition to actually stick rather than a single dense exposure.

Mistakes that cost the round

The most common failure is not an incorrect algorithm, it's skipping Step 1 and coding from the first idea that comes to mind, which produces a solution to a slightly wrong problem or misses an edge case the interviewer expected you to ask about. A close second is silence: interviewers grade the reasoning as much as the final code, so narrating the brute force and the pattern you're reaching for before you type is not optional color commentary, it's the part being scored. Going straight for the optimized solution without stating the brute force first reads as memorization rather than derivation, even when the final code is correct, because it skips the part of the signal interviewers are actually trying to see. On the complexity side, the most common miss is stating Big O without justifying it, "O(n log n) because I sorted" is a claim, walking through why each operation costs what it costs is the analysis. And once the happy path works, stopping there without testing an edge case (empty input, a single element, all duplicates) out loud leaves an easy follow-up unanswered that the interviewer was almost certainly going to ask anyway.

Practice under real conditions

Solving a question alone with unlimited time teaches you the algorithm, not the interview. Once you can solve a question cleanly, redo it under conditions that match the real thing: a plain text editor or shared doc instead of an IDE with autocomplete, a hard 35-45 minute window, and the problem read aloud instead of read silently. If you can, trade problems with another candidate and interview each other - narrating your own reasoning is a different skill from having it in your head, and it's the one that actually gets graded.

Practice by company

Sites built around a raw question count sort candidates into difficulty tiers and leave the company-matching to you. Every coding question here is tagged with the companies that have actually asked it and when it was last reported, so you can go straight to a company's real question mix instead of guessing which of 500+ generic problems apply: Amazon, Meta, Google, Microsoft, Apple, and more are tracked separately from the pattern-based list below.

FAQ

What are the most common coding interview questions?

Most coding interview questions map to a small set of recurring patterns: two pointers and sliding window on arrays/strings, hash maps for fast lookup, BFS/DFS on trees and graphs, binary search on sorted or monotonic data, backtracking for combinatorial search, and dynamic programming for overlapping subproblems. Learn to recognize the signal for each pattern (see Step 4) and you can solve variations you've never seen, not just ones you've memorized. See the full pattern breakdown for worked examples of each.

How many coding interview practice questions should I do?

Depth beats volume. 40-60 questions solved properly (brute force stated, pattern named, optimized solution coded and tested out loud) prepares you better than 300 questions skimmed for the answer. Prioritize by frequency and recency: a question a company's interviewers have actually asked in the last few months is worth more reps than an old, rarely-seen one.

What's the difference between practicing here and grinding an unfiltered list?

An unfiltered question bank makes you sort signal from noise yourself. Every question in this bank is sourced from real candidate reports and onsite loops, tagged with the companies that ask it and when it was last seen, so your practice time goes toward questions with current interview relevance instead of a random walk through every problem that has ever existed.

How long should I spend on each problem?

Time-box it: 20-25 minutes to reach a working solution (brute force counts), then whatever time it takes to state and, time permitting, implement the optimized version. If you are stuck past 25 minutes with no brute force, that is the signal to check the pattern and retry from Step 4, not to keep grinding blind.

Should I practice out loud or just write code?

Out loud, every time. Interviewers grade the reasoning as much as the final code, and narrating Steps 1-3 (clarify, trace examples, brute force) before you touch the keyboard is the habit that transfers directly to the real interview.

Which question categories should I prioritize first?

Arrays and strings (sliding window, two pointers) and hash maps show up most often across every company tracked here, so they pay off fastest if you're short on time. Graphs (BFS/DFS, Union-Find) and dynamic programming take longer to get comfortable with and are worth starting early even if you practice fewer of them, since the recognition skill develops slower than it does for array patterns.

Does it matter which language I use to practice?

Not for the pattern-recognition work in Steps 1-4, but the implementation details in Steps 5-7 (off-by-one errors, mutability, standard-library search/sort behavior) are language-specific. If your interviews will be in a language other than your default, practice the last few steps in that language directly - see the binary search pattern walked through in Python, Java, Go, C++, and C.

Are free coding practice sites enough, or do I need a paid one?

For the algorithm itself, free is almost always enough: the core patterns in Step 4 are public knowledge, and a large free problem set is plenty to build recognition. What a free, unfiltered list doesn't give you is curation, so you spend real prep hours sorting which of several thousand problems are still relevant to your actual interviews versus grinding whatever a list happens to put in front of you next. That's the specific gap a curated, company-tagged bank closes, not a claim that the underlying algorithms are somehow different or better once you're paying for them. See our breakdown of the free and paid options if you're deciding where to spend a subscription.

Related reading

• Coding interview patterns cheat sheet - the recurring signals from Step 4, in one place.
• Dynamic programming patterns - recognizing and structuring overlapping-subproblem questions.
• Sorting algorithms: time complexity cheat sheet - apply these rules to compare sort implementations.
• Binary search algorithm - O(log n) search on sorted arrays, two implementation patterns.
• How to analyze time complexity - why halving the search space is O(log n).