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.

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.

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.

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).