30 Coding Interview Questions for 2026 Prep

Practice 30 coding interview questions for 2026 with pattern-by-pattern approaches, common pitfalls, and a repeatable interview process.

Interview coding example guide: 30 most asked interview questions (2026)

Coding interviews test whether you can think clearly under pressure — not whether you memorized a solution last night. This guide covers the 30 questions you're most likely to see in 2026, organized by category, with what each one actually tests and a concrete approach for every one. Whether you're prepping for a phone screen or a senior on-site loop, the goal is the same: build a repeatable process you can apply to any problem, not a library of answers you'll forget by next week.

What interviewers are actually evaluating

Most candidates fixate on getting the right answer. Interviewers care about how you get there. Four criteria show up in nearly every coding interview rubric:

• Communication — Can you explain your thinking out loud while you work? Silence is the worst signal you can send.
• Problem solving — Do you break down ambiguity before writing code? Do you ask clarifying questions, or do you start typing immediately?
• Technical competency — Is your implementation clean, correct, and appropriately structured? Variable names, edge-case handling, and code organization all count.
• Testing — Do you verify your solution with normal inputs, edge cases, and invalid inputs before declaring it done?

A deceptively simple question often reveals more signal than a hard one. One interviewer's binary-search problem — a question most candidates assume they can solve in their sleep — consistently surfaces whether a candidate thinks about test cases, handles overflow bugs, and communicates tradeoffs. The problem isn't the problem. The process is the problem.

How to use this guide

The 30 questions below are grouped into four categories: arrays and strings, linked lists and stacks, trees and graphs, and dynamic programming plus system design concepts. For each question, you'll see what it tests and a short example approach.

Recommended workflow: read the question, attempt your own solution, then compare your approach to the one listed. Don't skip the attempt step — reading answers without trying first builds false confidence.

On prep time: expect a bare minimum of about 30 hours of focused practice to be competitive. Candidates who feel well-prepared typically invest closer to 100 hours, combining topic study with timed practice.

Verve AI's mock interview tool lets you practice these questions with real-time AI feedback — useful for building the habit of thinking out loud before you're doing it in front of a real interviewer.

The 30 questions

Arrays and strings (questions 1–8)

1. Two Sum What it tests: Hash map usage, complement logic. Approach: Iterate once. For each element, check if `target - current` exists in a hash map. If yes, return both indices. If no, store the current value and index. O(n) time, O(n) space. Always clarify: can there be duplicate values? Is the array sorted?

2. Reverse a string in place What it tests: Pointer manipulation, in-place operations. Approach: Two pointers — one at the start, one at the end. Swap and move inward. O(n) time, O(1) space.

3. Find duplicates in an array What it tests: Set usage, space-time tradeoffs. Approach: Insert elements into a set. If an element already exists, it's a duplicate. Clarify whether you need to return all duplicates or just detect one.

4. Longest substring without repeating characters What it tests: Sliding window technique. Approach: Maintain a window with a set of characters. Expand right; when a duplicate enters, shrink from the left. Track the max window size. O(n).

5. Anagram check What it tests: Character frequency counting. Approach: Count character frequencies in both strings using a hash map or array. Compare. O(n) time. Ask: are inputs always lowercase ASCII?

6. Rotate array by k positions What it tests: Modular arithmetic, in-place manipulation. Approach: Reverse the entire array, then reverse the first k elements, then reverse the rest. O(n) time, O(1) space. Clarify: rotate left or right?

7. Merge two sorted arrays What it tests: Two-pointer merge logic. Approach: Start from the end of both arrays and fill backward into the target. Avoids overwriting. O(n + m).

8. Valid palindrome What it tests: String cleaning, two-pointer technique. Approach: Strip non-alphanumeric characters, lowercase everything, then compare with two pointers moving inward. Ask about Unicode handling if the interviewer doesn't specify.

Linked lists, stacks, and queues (questions 9–15)

9. Reverse a linked list What it tests: Pointer reassignment, iterative vs. recursive thinking. Approach: Iterate with three pointers — previous, current, next. Reassign `current.next` to previous at each step. O(n) time, O(1) space.

10. Detect a cycle in a linked list What it tests: Floyd's cycle detection (fast/slow pointers). Approach: Move one pointer one step and another two steps. If they meet, there's a cycle. O(n) time, O(1) space.

11. Merge two sorted linked lists What it tests: Pointer manipulation, merge logic. Approach: Use a dummy head node. Compare the front of both lists, attach the smaller one, advance that pointer. Continue until one list is empty, then attach the remainder.

12. Implement a stack using two queues What it tests: Data structure internals, creative constraint handling. Approach: Push is O(n) — enqueue to queue2, then dequeue all of queue1 into queue2, then swap names. Pop is O(1). Clarify which operation should be optimized.

13. Valid parentheses What it tests: Stack usage, matching logic. Approach: Push opening brackets onto a stack. For each closing bracket, check if the top of the stack matches. If the stack is empty at the end, the string is valid.

14. Min stack What it tests: Auxiliary data structure design. Approach: Maintain a second stack that tracks the current minimum. Push to both; pop from both. getMin is O(1).

15. LRU cache (concept) What it tests: Hash map + doubly linked list design, O(1) get/put. Approach: Hash map for O(1) lookup. Doubly linked list for O(1) insertion/removal at head and tail. On access, move the node to the head. On capacity overflow, evict the tail. This one comes up often in senior loops — interviewers expect you to discuss tradeoffs between memory overhead and access speed.

Trees, graphs, and search (questions 16–22)

16. Invert a binary tree What it tests: Recursive tree traversal. Approach: Swap left and right children at each node, then recurse. Base case: null node. O(n).

17. Level-order traversal (BFS) What it tests: Queue-based traversal, level grouping. Approach: Use a queue. Process all nodes at the current level, enqueue their children, repeat. Track level boundaries by queue size at each iteration.

18. Validate a binary search tree What it tests: Recursive range checking. Approach: Pass min/max bounds down the recursion. Each node must be greater than the lower bound and less than the upper bound. A common mistake is only checking immediate children instead of propagating bounds.

19. Number of islands What it tests: Graph traversal (BFS or DFS), visited tracking. Approach: Iterate through the grid. When you find a '1', increment the count and flood-fill (DFS or BFS) to mark all connected '1's as visited.

20. Clone graph What it tests: Graph traversal with hash map for visited tracking. Approach: BFS or DFS. Use a hash map from original node to cloned node. For each neighbor, clone if not yet visited, then connect.

21. Binary search What it tests: Precision, off-by-one errors, overflow handling. Approach: Standard left/right pointer narrowing. Use `mid = left + (right - left) / 2` to avoid the integer overflow bug that caught professional programmers for decades — Jon Bentley famously noted that roughly 90% of professionals got binary search wrong on the first try. Test with a single-element array, an empty array, and a target not present.

22. Lowest common ancestor of a binary tree What it tests: Recursive tree logic, base-case handling. Approach: If the current node is null or matches either target, return it. Recurse left and right. If both sides return non-null, the current node is the LCA. If only one side returns non-null, propagate it up.

Dynamic programming and system design concepts (questions 23–30)

23. Climbing stairs What it tests: Recognizing overlapping subproblems. Approach: `dp[i] = dp[i-1] + dp[i-2]`. Start with the naive recursive solution, show why it's exponential, then add memoization, then convert to tabulation with O(1) space using two variables.

24. Coin change What it tests: DP formulation, minimization. Approach: `dp[amount] = min(dp[amount], dp[amount - coin] + 1)` for each coin. Initialize dp array with infinity, dp[0] = 0. O(amount × coins).

25. Longest common subsequence What it tests: 2D DP, string comparison. Approach: Build a 2D table. If characters match, `dp[i][j] = dp[i-1][j-1] + 1`. Otherwise, `dp[i][j] = max(dp[i-1][j], dp[i][j-1])`. O(m × n).

26. Word break What it tests: DP with string matching, set lookup. Approach: `dp[i]` is true if the substring `s[0..i]` can be segmented using the dictionary. For each position, check all possible word endings. O(n² × k) where k is average word length.

27. Design a rate limiter What it tests: System design thinking, tradeoff discussion. Approach: Discuss token bucket vs. sliding window. Clarify requirements: per-user or global? Distributed or single-node? Talk about Redis-based implementations for distributed cases. Senior candidates should discuss failure modes and consistency tradeoffs.

28. Design a URL shortener What it tests: Hashing, storage design, scale estimation. Approach: Base62 encoding of an auto-incrementing ID or a hash of the URL. Discuss read-heavy vs. write-heavy traffic, caching with TTL, and database choice. Clarify expected QPS before choosing architecture.

29. Design a cache What it tests: Eviction policies, consistency, distributed systems basics. Approach: Start with LRU eviction (connects back to question 15). Discuss write-through vs. write-back. For distributed caches, discuss consistent hashing and replication. Interviewers want to hear you reason about tradeoffs — memory vs. latency, consistency vs. availability.

30. Petabyte-scale log processing (concept) What it tests: Scale thinking, ambiguity handling, data pipeline design. Approach: Clarify what "processing" means — aggregation? Search? Real-time or batch? Discuss MapReduce or streaming frameworks. Talk about partitioning strategy, storage format (columnar vs. row), and how you'd handle late-arriving data. Senior candidates are expected to go deeper on tradeoffs here, not just produce a working diagram.

The process that works in every coding interview

Regardless of the question, the same five steps apply:

• Clarify before you code. Restate the problem in your own words. Ask about input constraints, expected output format, and edge cases. This is where most candidates skip ahead and lose points.
• State a naive solution first. Say it out loud. "The brute-force approach would be O(n²) because…" Interviewers want to see that you can identify the baseline before optimizing.
• Optimize with data structures. Walk through the complexity improvement. Explain the tradeoff — a hash map gives you O(1) lookup but costs O(n) memory. Name the tradeoff explicitly.
• Write clean, readable code. Meaningful variable names. Consistent structure. Don't abbreviate everything into single letters unless the scope is tiny.
• Test your solution. Walk through one normal case, one edge case (empty input, single element, maximum size), and one invalid input. Do this before saying "I'm done."

This process works for arrays, trees, DP, and system design. The content changes. The structure doesn't.

How to practice effectively

Structured practice beats random grinding. Pick one category, study the underlying patterns, then work through 5–8 questions in that category before moving on. Mixing topics too early builds breadth without depth.

Use AI as a prep partner, not an answer generator. The most effective use is checking your articulation of the problem — explain your approach to an LLM and see if it can follow your reasoning. If the AI can't follow your explanation, an interviewer won't either.

Mock interviews close the gap between knowing an answer and delivering it under pressure. Practicing alone in a text editor doesn't simulate the experience of thinking out loud while someone watches.

Verve AI's Interview Copilot lets you run AI mock interviews that simulate real coding rounds — complete with follow-up questions and structured feedback on your communication, not just your code. Practice the 30 questions above until the five-step process feels automatic. Try it free.

What to do when you're stuck

• Restate the problem out loud. Sometimes hearing it surfaces the approach.
• Try a simpler version — smaller input, fewer constraints.
• Think about which data structure fits the access pattern. Random access? Array. Fast lookup? Hash map. Ordered traversal? Tree.
• Ask a clarifying question rather than going silent. Interviewers reward engagement over silence.
• State what you know and what you're unsure of. "I think this is a sliding-window problem because of X, but I'm not sure how to handle Y" is a better signal than staring at the screen.

Transparency under pressure is a skill. Practice it the same way you practice algorithms.

Wrapping up

Thirty questions. Four categories. One repeatable process. The goal isn't memorization — it's building a framework you can apply to any problem an interviewer puts in front of you. Clarify, state the naive approach, optimize, code cleanly, test. That sequence works whether the question is Two Sum or a petabyte-scale system design.

Practice with Verve AI's mock interview tool to get real-time feedback before the real thing — so the first time you think out loud under pressure isn't the interview that matters.