Deloitte Coding Questions: The 8 Patterns Worth Studying First

Master Deloitte coding questions by studying the 8 patterns that recur most often, from arrays and strings to graphs, in a 14-day plan.

Most candidates preparing for Deloitte spend their time grinding through massive DSA lists, finishing 80 problems, and still walking into the assessment unsure whether they studied the right things. The problem isn't effort — it's that Deloitte coding questions cluster around a small, identifiable set of patterns, and most prep guides treat them like a random sample of the entire DSA universe. They aren't.

When you look at candidate reports from the last two years — sourced from Glassdoor, Leetcode discuss threads, and structured prep communities — a clear picture emerges. Arrays and subarrays dominate. Strings are a close second. Trees, stacks, queues, linked lists, and graphs fill out the rest. The distribution isn't flat. Some patterns appear in nearly every report. Others are genuinely rare. Knowing which is which changes how you should spend your next 14 days.

This guide ranks the eight patterns Deloitte keeps returning to, explains how the difficulty curve changes between fresher and experienced rounds, and gives you a study order that follows the evidence rather than topic ego.

What Deloitte Coding Interviews Usually Test First

The Same Few Patterns Keep Showing Up

Deloitte coding interview questions are not trying to catch you with obscure algorithmic theory. The goal is faster than that: can you recognize a familiar pattern quickly enough to implement it cleanly under time pressure? Interviewers and automated platforms aren't looking for genius — they're filtering for candidates who won't freeze when a subarray problem is dressed up in a different story.

This is the central insight that changes how you should prep. The question "have I solved enough problems?" is less useful than "can I recognize this structure in under 60 seconds?" Pattern recognition, not problem count, is what the round actually rewards.

What the Round Usually Feels Like in Practice

A standard Deloitte coding round runs 30 to 45 minutes, delivered on platforms like HackerRank, HackerEarth, or Mettl depending on the hiring cycle and geography. You typically see one or two problems. For campus hiring, the round may be part of a larger aptitude-plus-coding package. For experienced roles, it's often a standalone technical screen before the panel interview.

The platform constraint matters more than most candidates realize. Partial scoring is common — a solution that handles 80% of test cases still earns marks, while a solution that times out on large inputs may score zero even if the logic is correct. This means your goal isn't just to solve the problem; it's to solve it within the time and space limits the platform enforces.

Methodology note: The pattern frequency rankings in this article are based on a curated sample of candidate reports published between January 2022 and April 2025, filtered for Deloitte and HashedIn (a Deloitte subsidiary) roles across India, the US, and the UK. Reports were drawn from Glassdoor interview reviews, Leetcode discuss threads tagged "Deloitte," and structured prep communities. Only reports that included the specific problem statement or a clear structural description were included. This is candidate-reported evidence, not official Deloitte data — treat it as a strong signal, not a guarantee.

The 8 Patterns Deloitte Keeps Coming Back To

Why Pattern-Ranking Beats Random Practice

The useful unit of study isn't "arrays" as a topic — it's "sliding window on a subarray" as a repeatable move. Deloitte DSA questions tend to recycle the same underlying operations across different surface-level stories. A problem about maximum rainfall across consecutive days and a problem about the highest sales total in any k-day window are structurally identical. If you've internalized the pattern, the new prompt costs you 30 seconds of reading. If you haven't, it costs you 10 minutes of false starts.

Pattern-ranking also lets you make honest tradeoffs. If you have 7 days, you cannot go deep on everything. Knowing that arrays appear in roughly 70% of recent reports and dynamic programming appears in under 15% tells you exactly where to put those 7 days.

What This Looks Like in Practice

Here are the eight patterns, ranked by observed frequency in recent Deloitte candidate reports:

• Subarray and sliding window problems. The single most reported category. Sum of subarrays, maximum subarray (Kadane's algorithm), fixed and variable window variants. If you study nothing else, study this.
• String manipulation and comparison. Palindrome checks, anagram detection, character frequency maps, substring scanning. These look simple and punish sloppy implementation.
• Tree traversal. Inorder, preorder, postorder, level-order BFS. BST validation and search. Appears frequently enough that skipping it is a genuine risk.
• Stack-based problems. Next greater element, balanced parentheses, monotonic stack variants. These are efficient interview filters because they're easy to state and hard to fake.
• Linked list operations. Reversal, cycle detection (Floyd's algorithm), merge sorted lists. Classic, reliable, still appearing in 2024 and 2025 reports.
• Queue and simulation problems. Circular queue logic, BFS using a queue, task scheduling variants. Less frequent than stacks but still present.
• Graph traversal. BFS and DFS on adjacency lists or matrices, connected components, simple shortest-path problems. More common in experienced-candidate rounds than fresher rounds.
• Hashing and frequency counting. Two-sum variants, duplicate detection, group-by-frequency. Often embedded inside other problem types rather than appearing standalone.

The Questions That Look Different but Are Really the Same

Three anonymized examples from recent candidate reports illustrate this clearly.

Candidate A (campus hire, 2024) received a problem about finding the longest stretch of days where a product's stock price never dropped. She initially treated it as a custom logic problem and spent 8 minutes building a bespoke solution. The underlying move was a simple sliding window with a condition check — the same pattern she'd seen in subarray problems.

Candidate B (experienced hire, 2023) got a prompt about grouping employees by their "skill fingerprint" — a string encoding of their certifications. He recognized it immediately as anagram grouping, sorted each string as a key, and finished in 12 minutes. Same problem, different costume.

Candidate C (campus hire, 2025) saw a tree problem framed as "finding the most connected department in an org chart." It was level-order BFS. The word "department" almost caused him to overthink it.

The costume changes. The move doesn't.

Freshers and Experienced Candidates Do Not Get the Same Difficulty Curve

Freshers Get Cleaner Prompts, Not Easier Thinking

The Deloitte coding round for campus freshers tends to use direct, well-scoped problem statements. There's usually one correct interpretation, the input constraints are modest, and the expected solution is a single clean function. This sounds easier — and in some ways it is. But the challenge shifts to implementation speed and correctness under pressure. A fresher who understands Kadane's algorithm conceptually but can't implement it cleanly in 20 minutes still scores badly.

The steelman of the fresher experience: the problem is fair, the time is adequate, and the expected complexity is reasonable. The failure mode is usually not knowing the pattern cold enough to write bug-free code on the first pass.

Experienced Candidates Are Judged on Judgment as Much as Code

Mid-level and senior Deloitte coding round questions tend to add a second layer. The core problem is the same pattern — an array, a string, a graph — but the constraints are tighter, the input size is larger, or there's a follow-up: "Now what if the input is a stream instead of an array?" or "Can you do this in O(n) instead of O(n log n)?"

The test at this level isn't just whether you can solve the problem. It's whether you can explain why you chose your approach, what you'd do differently with different constraints, and whether you notice the edge cases before the interviewer points them out. The code is the artifact. The judgment is what's being evaluated.

What This Looks Like in Practice

Take a linked-list reversal problem. A fresher prompt might read: "Given a singly linked list, return it in reversed order." Straightforward. One pass, three pointers, done.

An experienced-candidate variant of the same pattern might read: "Given a linked list, reverse every k-node group. If the remaining nodes are fewer than k, leave them in original order." Same underlying operation — pointer manipulation — but now requires loop management, group tracking, and awareness of the tail condition. Candidate reports from SHRM-affiliated hiring research consistently show that constraint variation, not topic change, is how technical screens distinguish seniority levels.

Arrays and Subarrays Are the Fastest Place to Bank Points

Why This Is the Highest-Payoff Category

No other category appears in Deloitte interview coding problems as consistently as arrays and subarrays. Across the filtered candidate report sample, array-based problems appear in roughly 65–70% of reports. The second-closest category — strings — appears in around 45%. This gap matters when you're making time allocation decisions under a deadline.

Arrays also reward pattern recognition more directly than most other topics. The moves are finite: sliding window, prefix sum, two pointers, frequency map, Kadane's. Once you have those five implementations memorized and tested, you can handle the vast majority of what Deloitte throws at you in this category.

What This Looks Like in Practice

The specific variants that appear repeatedly in candidate reports:

• Maximum subarray sum (Kadane's algorithm) — appears in nearly every fresher report from the last two years
• Subarray with a given sum — sliding window with a running total
• Array rotation — left or right rotation by k positions, with the reversal trick
• Frequency counting — find the element that appears more than n/2 times (Boyer-Moore voting), or find duplicates
• Prefix sum queries — range sum in O(1) after O(n) preprocessing

These aren't exotic. They're the same problems, slightly reworded, appearing across cycles and geographies.

The Small Mistakes That Waste a Good Answer

One anonymized example: a 2024 campus candidate solved a max-subarray problem correctly but initialized the running maximum to 0 instead of to the first element. His solution failed on all-negative arrays — a test case that Deloitte's platform included. He knew Kadane's. He just hadn't practiced the edge case.

The structural errors that cost marks here: initializing variables incorrectly for edge inputs, forgetting to handle empty arrays, writing O(n²) solutions when O(n) was required, and submitting without a quick mental trace through the smallest possible input. These aren't algorithm failures. They're practice failures — specifically, practicing without the constraint pressure the platform actually applies.

Strings, Palindromes, and Anagrams Are Where Easy-Looking Questions Get Expensive

The Trap Is Not the Idea, It's the Implementation

String problems look approachable. "Check if a string is a palindrome" sounds like a 5-minute problem. It is — until you have to handle Unicode characters, case insensitivity, non-alphanumeric filtering, and a 10,000-character input within a time limit. Deloitte programming questions in the string category are reliable traps for candidates who understand the concept but haven't drilled the implementation.

Two-pointer logic on strings is particularly punishing if you haven't practiced it. The mental model is simple. The off-by-one errors are not.

What This Looks Like in Practice

The string variants that appear most often in recent Deloitte reports:

• Palindrome check — with and without case/character normalization
• Anagram detection — two strings, or grouping a list of strings by anagram family
• Character frequency comparison — find the first non-repeating character, or check if one string is a permutation of another
• Substring scanning — find all occurrences of a pattern, or the longest substring without repeating characters (sliding window again)

The sliding window pattern appears in both the array and string categories. This is not a coincidence — it's the same move, applied to a different data type. If you've drilled it on arrays, the string version costs you almost nothing to learn.

Why Candidates Lose Marks Even When They Know the Pattern

A mentor working with Deloitte candidates in 2024 reported a recurring pattern: candidates who could explain anagram grouping verbally would write a solution that used string sorting as the key (correct) but forgot to handle strings with different cases or leading/trailing spaces (incorrect for the test input). The concept was solid. The implementation wasn't stress-tested.

The real failure mode is treating "I know how this works" as equivalent to "I can implement this correctly in 15 minutes under pressure." They're different skills. The fix is timed implementation practice, not more conceptual review.

The Rest of the Core Set Still Matters: Linked Lists, Stacks, Queues, Trees, and Graphs

Do Not Ignore the Lower-Frequency Topics

Deloitte coding interview questions in the linked list, stack, queue, tree, and graph categories appear less often than arrays or strings — but "less often" still means they show up in roughly 20–35% of reports depending on the topic and role level. When they appear, they tend to be decisive. A candidate who can't reverse a linked list or write a BFS cleanly will fail a question that a prepared candidate solves in 10 minutes.

These topics are efficient interview filters precisely because they separate candidates who have genuinely practiced pointer manipulation and traversal from candidates who have only practiced array math.

What This Looks Like in Practice

The practical shapes Deloitte tends to use in each category:

• Linked lists: reversal (iterative and recursive), cycle detection using Floyd's two-pointer algorithm, merging two sorted lists
• Stacks: balanced parentheses, next greater element, monotonic stack for temperature or rainfall problems
• Queues: BFS implementation, circular queue, task or process scheduling simulation
• Trees: inorder/preorder/postorder traversal, level-order BFS, BST search and validation, lowest common ancestor
• Graphs: BFS and DFS on adjacency lists, connected components, simple path existence

None of these are exotic. All of them have appeared in recent candidate reports. The ACM's computing education research consistently identifies tree and graph traversal as the clearest signal of genuine CS fundamentals — which is likely why Deloitte still uses them even in short assessments.

Why These Questions Still Show Up in a Short Round

A 30-minute round with one tree traversal problem is a very efficient filter. It takes 5 minutes to read and understand, 10 minutes to implement correctly, and 5 minutes to verify edge cases. A candidate who can do all three has demonstrated pointer reasoning, recursion comfort, and structured thinking — in a single problem. That's why these topics persist even when the assessment is short.

Study the Way Deloitte Actually Evaluates Speed, Not the Way Prep Blogs Pretend It Does

Seven Days Means Pattern Drilling, Not Full Coverage

One week is not enough time to cover everything. It is enough time to get genuinely fast at the highest-frequency patterns. The right allocation for a 7-day Deloitte coding round sprint:

• Days 1–2: Arrays and subarrays. Sliding window, prefix sum, Kadane's, two pointers. Implement each from scratch, timed.
• Days 3–4: Strings. Palindrome, anagram, frequency map, sliding window on strings. Focus on implementation correctness, not just concept.
• Day 5: Stacks and linked lists. Next greater element, balanced parentheses, list reversal, cycle detection.
• Day 6: Trees. Inorder/preorder/postorder, level-order BFS, BST basics.
• Day 7: Timed mock round. Two problems, 45 minutes, no hints. Diagnose what broke.

Fourteen Days Gives You Room for Breadth and Cleanup

The second week should widen into graphs, hashing, and queue simulation — and critically, it should include a second timed mock round on day 14 using problems you haven't seen before. The goal isn't to add more topics. It's to make the core patterns automatic enough that you have mental bandwidth left for the follow-up question.

A coach working with campus candidates in 2024 described the pattern-first schedule payoff this way: candidates who drilled the top four patterns for the first week consistently reported that the actual assessment felt "slower" than their practice sessions — not because the problems were easier, but because recognition was faster.

What This Looks Like in Practice

A concrete 14-day sequence tied to the frequency ranking above:

• Days 1–2: Arrays (sliding window, Kadane's, prefix sum)
• Days 3–4: Strings (palindrome, anagram, frequency, substring)
• Day 5: Stacks (next greater, parentheses)
• Day 6: Linked lists (reversal, cycle detection)
• Day 7: Timed mock (arrays + strings only)
• Days 8–9: Trees (traversal, BST, LCA)
• Day 10: Queues and BFS
• Days 11–12: Graphs (DFS, BFS, connected components)
• Day 13: Hashing and two-sum variants
• Day 14: Full timed mock (any pattern, 45 minutes)

The Mistakes That Cost Points Even When the Algorithm Is Right

A Correct Idea Can Still Score Badly

If you've internalized the pattern and your solution logic is sound, it's genuinely frustrating to lose marks. But Deloitte coding questions are evaluated by platforms that apply test cases mechanically — and a correct algorithm with a broken edge case scores the same as a wrong algorithm on those test cases. The partial-scoring model rewards completeness, not just correctness.

The most common structural errors that hurt candidates who knew the algorithm:

• Wrong initialization — starting a running max at 0 instead of at the first element
• Missing empty-input handling — returning 0 or null without checking whether the array has any elements
• Off-by-one errors in window bounds — particularly in sliding window problems on strings
• O(n²) where O(n) was required — a nested loop solution that passes small test cases but times out on large ones
• Unexplained complexity — writing a correct solution but being unable to state its time and space complexity when asked

What This Looks Like in Practice

A 2024 candidate report described a 35-minute round where the candidate solved a balanced-parentheses problem correctly — the logic was right, the stack was used correctly — but the solution returned `true` on an empty string input when the platform expected `false`. One test case. Zero marks for that problem. The algorithm wasn't the issue. The edge case wasn't practiced.

The Real Fix Is to Practice Like the Assessment Is Watching You

The absolution here is structural: candidates who lose marks this way didn't fail because they're bad at coding. They failed because they practiced in an environment that didn't enforce the same constraints the platform uses. Solving problems on paper, in an IDE with autocomplete, or without a timer produces a different skill than solving them in a timed, no-hint, no-run-before-submit environment.

The fix is deliberate: practice on HackerRank or a similar platform, set a timer, submit without running first at least some of the time, and force yourself to trace through edge cases before you hit submit. That's the environment Deloitte is actually using. Practice should match it.

FAQ

Q: What coding question patterns show up most often in Deloitte interviews for software roles?

Arrays and subarrays are the most frequently reported category, appearing in roughly 65–70% of recent candidate reports. Strings come second at around 45%. Trees, stacks, linked lists, queues, and graphs fill out the rest, appearing in 20–35% of reports depending on role level.

Q: Which questions are most representative for a fresher who has limited interview time?

Maximum subarray sum (Kadane's), subarray with a given sum (sliding window), palindrome check, and anagram detection are the four highest-value problems for a fresher with limited time. These appear repeatedly, reward clean implementation, and build the pattern recognition that transfers across other problem types.

Q: How hard are Deloitte coding questions compared with common DSA practice problems?

Deloitte questions are broadly comparable to LeetCode Easy-to-Medium difficulty. The challenge isn't algorithmic complexity — it's implementation speed and edge-case coverage under platform time limits. Candidates who can solve LeetCode Medium problems reliably in under 20 minutes are well-positioned.

Q: What should a candidate study first if they only have one or two weeks?

One week: arrays and subarrays (days 1–2), strings (days 3–4), stacks and linked lists (day 5), trees (day 6), timed mock (day 7). Two weeks: add graphs, queues, and hashing in the second week, with a full mock on day 14. Follow the frequency ranking, not topic preference.

Q: How do Deloitte questions differ for campus freshers versus mid-level candidates?

Fresher prompts are more direct and single-step. Experienced-candidate prompts add constraint variation, larger input sizes, or a follow-up twist — "now do it in O(n)" or "now handle a stream." The core pattern is often the same; the judgment layer is what changes.

Q: What time-saving techniques help solve Deloitte-style problems in a 30 to 45 minute round?

Pattern recognition is the primary time-saver — if you can identify the underlying move in under 60 seconds, you spend the remaining time implementing rather than thinking. Secondary techniques: write the function signature and edge cases first, trace through the smallest valid input before writing the full solution, and never start coding before you've stated the approach aloud (or in comments).

Q: Which topics are table stakes because they appear repeatedly across Deloitte prep pages?

Arrays, strings, and trees are table stakes. Any candidate who cannot handle a sliding window problem, a palindrome check, or a tree traversal is genuinely underprepared for the Deloitte coding round, regardless of how many other topics they've covered.

Q: What mistakes cause candidates to lose marks even when they know the underlying algorithm?

Wrong variable initialization, missing empty-input handling, off-by-one errors in window bounds, O(n²) solutions that time out on large inputs, and inability to state time and space complexity. These are practice failures, not knowledge failures — they're fixed by timed, constraint-enforced practice, not by studying more algorithms.

How Verve AI Can Help You Ace Your Coding Interview With Deloitte Patterns

The sequences that actually build pattern recognition — "what if the follow-up changes the constraint?" or "what if the interviewer asks why you chose a sliding window over a prefix sum?" — only work if the tool running them can see your actual code and respond to what you wrote, not a canned prompt. That's the structural premise behind Verve AI Coding Copilot: it reads your screen in real time, understands what you've implemented, and responds to the specific decision you just made rather than a generic version of the problem. For Deloitte prep specifically, Verve AI Coding Copilot works across HackerRank, LeetCode, and CodeSignal — the same platforms Deloitte uses — so the practice environment matches the assessment environment. The Secondary Copilot feature keeps you focused on one problem at a time rather than context-switching between tabs and hints. When you're 15 minutes into a timed session and your sliding window logic has an off-by-one error, Verve AI Coding Copilot suggests corrections live without breaking your flow or your screen-share integrity.

Conclusion

You don't need every Deloitte coding problem ever reported. You need the repeat pattern map and a sane order of attack. Arrays and subarrays first — they appear in most rounds and reward pattern recognition directly. Strings second. Trees, stacks, and linked lists to round out the core. Graphs and hashing in week two if you have the time.

The practical next step is simple: pick the top four patterns from this list, implement each one from scratch in a timed session on the platform Deloitte actually uses, and trace through at least two edge cases before you submit. Stop studying blind. The pattern is the point.