Deloitte Interview Questions (2026): Most Asked, With Answers

Most candidates go through an online application and resume screen, an online assessment (numerical, verbal, and situational judgment questions), a recorded video interview, and then one or two live interview rounds before a final decision. Graduate and campus roles often add a group exercise or a case study day; experienced hires more often skip straight from the video interview to a live case and behavioral round with a manager, then a partner or senior manager interview to close.

The full cycle, from applying to getting an offer, typically runs three to six weeks depending on the practice and how fast the local office needs to fill the role.

The online assessment stage usually combines numerical reasoning (interpreting charts and tables under time pressure), verbal reasoning (reading a passage and judging whether a statement is true, false, or can't say), and a situational judgment test that presents workplace scenarios and asks you to rank possible responses. It's timed and adaptive in places, meaning it can get harder if you're doing well.

You can study for it, mostly by getting fast and accurate at reading a data table under a clock, which is a specific skill separate from raw intelligence. Practicing fifteen or twenty timed numerical reasoning sets in the week before matters more than most people expect going in.

Profit is revenue minus cost, so a flat top line with falling profit means the drop lives on the cost side or in the mix of what's being sold, not in total sales volume. I'd split costs into fixed and variable, then ask whether cost of goods sold, labor, or overhead has moved disproportionately, and separately check whether the sales mix shifted toward lower-margin products even with total revenue unchanged.

I'd want one number before going further: gross margin by product category over the same period. If margin held steady across categories, the problem is almost certainly a specific cost line that spiked. If margin fell somewhere specific, the mix shift is the more likely story.

I'd anchor on population, roughly 500,000 for a mid-sized city, then estimate cars per household (say 1.5) and households per station's realistic drive-time catchment, working from an assumption like one station per 8,000 to 10,000 cars based on typical fill-up frequency and station capacity. That lands somewhere in the range of 40 to 60 stations, and I'd sanity check it against what a city that size actually looks like if I've lived somewhere comparable.

The number itself barely matters. What's being tested is whether you state your assumptions out loud instead of doing silent math, and whether you sanity-check the final number against something real instead of just presenting whatever the arithmetic spits out.

The income statement shows revenue and expenses over a period, ending in net income. The balance sheet shows assets, liabilities, and equity at a single point in time. The cash flow statement bridges the two, showing how cash actually moved during the period across operating, investing, and financing activities. Net income from the income statement flows into retained earnings on the balance sheet, and depreciation, a non-cash expense on the income statement, gets added back on the cash flow statement because it reduced net income without actually using cash.

Materiality is the threshold above which a misstatement in the financial statements would be likely to influence a reasonable investor's or stakeholder's decisions. Auditors set it quantitatively, often as a percentage of a benchmark like revenue, pre-tax income, or total assets depending on the entity, and adjust it based on qualitative factors, whether a small dollar amount could still matter if it affects debt covenants, executive compensation triggers, or reveals fraud regardless of size.

First, what's actually driving the move, cost reduction, scalability for growth, or an end-of-life data center forcing the decision, because the answer changes the priority order. Second, what's the application's current architecture, a monolith is a very different migration than something already loosely coupled. Third, what are the compliance and data residency constraints, since some industries and geographies restrict where data can physically live regardless of technical feasibility.

Structured data fits neatly into rows and columns, like a spreadsheet of sales transactions, where every record has the same fields. Unstructured data doesn't, emails, contracts, call transcripts, images, where the useful information exists but isn't organized into predictable fields you can query directly. Most clients already have far more unstructured data than they realize, sitting in shared drives and inboxes, and a lot of Deloitte's data and AI engagements exist specifically to extract structure and value out of that unorganized pile.

Pick a real disagreement with a genuine outcome, not a manufactured one where you were obviously right the whole time. What Deloitte interviewers are actually listening for is whether you raised the disagreement directly and professionally instead of either staying silent or escalating it emotionally, and whether you could still work productively with that person afterward regardless of who turned out to be right. An answer where you were wrong and said so is often stronger than one where you were vindicated.

Consulting and audit work both put you on teams you didn't choose, often with people rotating on and off an engagement every few months. A good answer names the specific friction (someone who wanted every decision documented in writing when you preferred a quick conversation, say) and describes a concrete adjustment you made, not a vague claim that you're "adaptable." Vague adjectives without a specific behavior attached to them are the most common way this answer falls flat.

The weak version of this answer talks about Deloitte's size, reputation, or the fact that it's the largest professional services network by revenue. Those are true but they're true of PwC, EY, and KPMG too, so they don't actually explain why you're sitting in that specific room. A stronger answer names something specific to the practice you're applying to, a project type, an industry vertical Deloitte is known for in your target sector, a person you spoke to who described a specific piece of work, and connects it to something concrete about your own background.

It means understanding what the client actually needs, which isn't always the same as what they initially asked for, and being proactive about surfacing risks or opportunities before they're asked about. A client who asks for a report on Q3 numbers might really need help understanding why a specific metric moved, and good client service means noticing that gap and addressing it rather than delivering exactly and only the literal request.

Document every change request in writing as it comes in and be direct, early, about how each change affects timeline, cost, or both, rather than silently absorbing scope creep until the project is behind and over budget with no clear record of why. Being firm about scope doesn't mean being inflexible about the client relationship. It means every change is a visible, agreed trade-off instead of an invisible one.

Consulting and audit engagements constantly put junior and mid-level staff in charge of coordinating people who don't report to them, other team members, sometimes client staff. A strong answer describes specifically how you got buy-in, through clear communication of the stakes, through making the ask small and specific rather than vague, rather than through a title you didn't actually have.

HireVue is the recorded video interview platform Deloitte uses at the screening stage in many markets. A question appears on screen, you get roughly thirty seconds to think, and then you record a two-to-three-minute answer with no interviewer present and no chance to ask a clarifying question. Most rounds run four to six prompts, usually behavioral or situational, sometimes with one asking you to explain your interest in the specific service line.

The lack of a human on the other end is the part people underestimate. There's no nodding along, no follow-up question to react to, and no way to tell if your answer landed. Practicing out loud to a phone camera beforehand, not just rehearsing in your head, closes most of that gap.

No. Case interviews are standard for Strategy and Consulting roles and common for Financial Advisory. Audit and Assurance, Tax, and most Risk Advisory roles instead focus on technical and situational questions, sometimes with a short written exercise (a memo, a small data set to interpret) rather than a live business case. Technology and Digital consulting roles often get a hybrid: a lighter business case plus a technical or coding-adjacent conversation depending on the specific role.

Candidates sometimes prep the wrong thing entirely because "Deloitte interview questions" gets treated as one bucket online when the actual content depends heavily on which practice you applied to.

Final rounds usually involve conversations with a partner or senior manager, sometimes three to five separate interviews in a single day for campus and assessment-center hiring. The questions shift from "can you do the job" toward "do we want to sit across a client table with you." Expect more open-ended discussion, less structured framework-checking, and a genuine two-way conversation where the partner is also selling you on the practice.

It's also the stage where a strong answer to "why Deloitte specifically, not just consulting in general" carries real weight, because partners have sat through enough generic answers to notice one that's actually specific.

Group exercises show up mostly in graduate and campus assessment centers, less often for experienced hires. A small group gets a business problem or a set of options to prioritize and has to reach a group recommendation in a fixed time, often twenty to thirty minutes, with an assessor watching but not participating.

The content of the recommendation matters less than most candidates assume. Assessors are mostly watching whether you build on other people's points instead of just waiting for your turn to talk, whether you bring in a quiet participant, and whether you can disagree with someone's idea without making it personal. Dominating the conversation to "prove leadership" is one of the more common ways candidates talk themselves out of an offer here.

First, what's the actual goal, revenue growth, diversifying away from a concentrated existing market, or defending against a competitor already moving into that region, because the right analysis changes depending on the motive. Second, what does demand and competitive intensity look like in that specific market for this specific product category, not the country's GDP in general. Third, does the client have or need a local manufacturing or distribution presence, since that decision alone can determine whether the economics work at all.

I'd resist jumping straight into a market-sizing exercise before those three are answered. A well-sized market that doesn't match the client's actual goal is a wasted hour.

Say so directly and update. Something like, that changes my earlier assumption that margin was stable, let me revise. Interviewers running Deloitte cases are usually testing whether you can absorb new information mid-analysis without getting defensive about the framework you already built, not whether your first assumption was correct.

Candidates who quietly try to make the new number fit their old structure, instead of rebuilding around it, are one of the more common ways a strong-looking case falls apart in the second half.

A good answer reaches a defensible recommendation with sound logic. A great one also states the recommendation's biggest weakness unprompted, the assumption most likely to be wrong, the risk that could flip the conclusion, before the interviewer has to ask "but what if X." That single move signals you'd catch your own blind spot on a real client engagement instead of needing a manager to catch it for you.

A test of controls checks whether a company's internal process, an approval workflow, a reconciliation step, actually operated the way it's documented to, without directly verifying the underlying transaction amounts. A substantive test directly verifies the accuracy of an account balance or transaction, confirming a receivable balance with a customer, recalculating depreciation. Auditors often rely more heavily on substantive testing when controls testing reveals weaknesses, since a broken control means you can't lean on the process and have to verify the numbers directly instead.

That mismatch is exactly the kind of ratio-level red flag analytical procedures exist to catch. I'd want to know whether the inventory growth reflects a deliberate stock-up ahead of expected demand, a new product line that hasn't started selling yet, or a sign that older inventory isn't moving and may need a write-down for obsolescence. I'd pull inventory aging data and compare turnover ratios against the prior year and, ideally, against a comparable competitor, rather than accepting a verbal explanation from management without corroborating it against the numbers.

ASC 606 requires recognizing revenue when control of a good or service transfers to the customer, following a five-step model: identify the contract, identify the separate performance obligations within it, determine the transaction price, allocate that price across the obligations, and recognize revenue as each obligation is satisfied. It replaced a more industry-specific patchwork of rules with one consistent framework, which matters most for companies with bundled contracts, software with multiple deliverables, or long-term service agreements, where the old rules gave more room to recognize revenue earlier than the transfer of control would actually justify.

Stay factual and let the evidence carry the conversation rather than the tone. I'd walk back through the specific support for the adjustment, ask what documentation or context they have that I might be missing, and be genuinely open to revising if they surface something I hadn't seen. What I wouldn't do is soften a correct adjustment just because the client is unhappy about it. That's the actual line auditors have to hold, and interviewers ask this exact scenario because it's the situation that separates people who can maintain independence under social pressure from people who fold.

Rehosting, often called lift-and-shift, moves an application to the cloud with minimal changes, fastest to execute but capturing the least long-term benefit since you're still running the old architecture, just on new infrastructure. Replatforming makes targeted changes, swapping a self-managed database for a managed cloud database service, without touching the application's core architecture. Refactoring rebuilds the application to be cloud-native, breaking a monolith into services, adopting containers, which takes the longest and costs the most upfront but delivers the scalability and cost efficiency that's usually the actual reason a client wanted to move in the first place.

SELECT customer_id
FROM orders
WHERE order_date >= DATEADD(month, -3, CURRENT_DATE)
GROUP BY customer_id
HAVING COUNT(DISTINCT DATE_TRUNC('month', order_date)) = 3;

The key detail is counting distinct months, not distinct orders. A customer with five orders in one month and none in the other two would fail the actual requirement even though their raw order count looks healthy, and that's usually the exact edge case an interviewer is checking for when they ask you to walk through your own query out loud.

I'd separate the delay into categories rather than treating it as one undifferentiated problem: scope creep (requirements added mid-project that weren't in the original plan), data migration issues (legacy data that's messier or less complete than assumed), change management resistance (business users not adopting the new process, forcing rework), and vendor or integration delays outside the client's direct control.

Most ERP delays I've seen described in postmortems trace back to data migration and change management more than to the software itself. The system usually works. Getting the organization's data clean enough to load it, and getting people to actually use the new workflow instead of working around it, is where the real schedule risk hides.

A data warehouse stores structured data that's already been cleaned and organized into a defined schema, optimized for fast business intelligence queries and reporting. A data lake stores raw data in its native format, structured or not, and applies structure later at the point of analysis rather than upfront. I'd recommend a warehouse when the use case is known reporting needs with stable schemas, and a lake when a client wants to preserve flexibility for future use cases, including machine learning workloads, that haven't been fully defined yet.

The specific thing to demonstrate here is that you delivered the news directly and early rather than softening it into vagueness or delaying it until it became unavoidable. In audit specifically, this maps almost exactly onto real scenarios, telling a client their books need an adjustment they weren't expecting. In consulting, it's telling a client their preferred option isn't actually the recommendation your analysis supports. Either way, the interviewer wants to hear that you said the uncomfortable thing clearly, backed it with evidence, and stayed in the conversation afterward instead of just delivering it and retreating.

Own the mistake plainly, describe how you caught it (ideally you caught it yourself, not that someone else found it and confronted you), and be specific about what you did to fix it and what changed afterward so it wouldn't repeat. The instinct to pick a fake-humble mistake, "I work too hard" or "I care too much about quality," is one of the most transparent tells in this interview and experienced interviewers have heard it hundreds of times.

Ask clarifying questions upfront rather than guessing silently and hoping it works out, but also show that you can make reasonable progress with the information you have while waiting on an answer, instead of stalling entirely until every ambiguity is resolved. Client engagements rarely arrive fully scoped, and a genuinely useful answer here describes a specific instance where you did both: asked the right question at the right moment, and kept moving on the parts that were already clear.

The generic version of this answer describes appreciating diversity in the abstract without a real example attached. The specific version names an actual instance where a colleague from a different background, functional discipline, or client-facing role saw an angle you'd missed, and describes exactly how that changed your recommendation or approach, not just how it made you "feel more open-minded." Interviewers can tell the difference within about one sentence.

Name a real industry and back it with something specific and current, a regulatory change, a competitive shift, a technology adoption trend, not a generic statement like "healthcare is important and growing." Interviewers ask this to check whether you've done homework beyond the job posting, and a candidate who can name one concrete, dated development in the sector, not just the sector's general size or importance, stands out immediately against everyone reciting the same three sentences from the industry's Wikipedia page.

Understand why they're pushing back first. Sometimes clients have context you don't, an internal political constraint, a prior failed attempt at something similar, that legitimately should change the recommendation. If, after hearing that context, your analysis still supports the original recommendation, I'd hold the position and explain the reasoning again more concretely, tied to their specific numbers rather than repeating the same general argument. What I wouldn't do is quietly change the recommendation just to avoid friction, since that erodes the actual value of the advice being paid for.

The honest answer usually involves a specific, ongoing habit, a particular publication read regularly, a specific newsletter, following named analysts or executives, not a vague claim of "reading the news." Interviewers can tell the difference between someone who genuinely tracks a beat and someone reaching for a socially acceptable answer on the spot, and naming something concrete costs nothing to prepare in advance.

Get explicit about relative urgency rather than guessing, ask each person directly what happens if their deadline slips versus the others, and use that information to sequence the work instead of trying to make silent judgment calls about whose request matters more. In a real engagement, one of those three deadlines usually has real external consequences, a client deliverable date, a regulatory filing, while another has more flexibility than it initially sounded like. Finding out which is which takes one honest conversation, not guesswork.

Specific and behavioral beats general and personal. "Your slides had three factual errors in the client numbers, here's what I'd check next time" lands better and gets remembered longer than "you need to be more careful." A good answer also describes the follow-up, whether the feedback actually changed the person's work afterward, since giving feedback that gets ignored isn't much different from not giving it at all.

A lot of the lower-value first-draft work, summarizing a document, drafting a standard email, building a first-pass slide outline, is increasingly assisted or automated, which shifts junior time toward reviewing, judging, and refining rather than producing from a blank page. That's a real shift in what "junior" work looks like day to day, but it raises the bar rather than removing the need for junior staff entirely, since someone still has to catch what the tool gets wrong, and catching a subtle error requires the same underlying technical understanding a junior would have needed to produce the work manually.

The weak version names a title, senior manager, partner track, with no reasoning behind it. The stronger version connects a specific interest, a client type you want to keep working with, a skill you want to keep building, a technical depth you're chasing, to why this particular role and practice is actually a reasonable next step toward that, not just a generic ambition statement that would apply equally at any firm in the industry.

I'd split it into three buckets: market demand (is there unmet patient volume in the target area, what do nearby competing facilities look like), financial feasibility (build cost, expected utilization, payer mix and reimbursement rates, payback period), and operational risk (staffing availability, regulatory approval timelines, cannibalization of volume from the system's existing facilities).

I'd flag cannibalization early rather than letting it surface later, because a new facility that mostly pulls patients away from an existing one in the same network isn't growth, it's a cost with extra steps. That's the kind of framing an interviewer is listening for, not just a checklist of the three buckets.

Deliver something small and correct quickly rather than promising something large and impressive later. A short, accurate first deliverable, even a simple status summary done well, builds more trust in week one than an ambitious analysis that isn't ready until week four. I'd also spend real time in early conversations just listening to what the client's day-to-day frustrations actually are, since those informal conversations often surface the real problem faster than the formal kickoff materials do.

Almost never, and saying so directly is usually the right move. An across-the-board cut treats every cost line as equally cuttable and equally low-value, which is rarely true. Some costs are growth-driving (sales headcount in a region that's still ramping), some are fixed and contractual in the short term (a five-year facilities lease), and some are genuinely discretionary and safe to trim (travel, some vendor spend).

I'd reframe the goal as reaching 15 percent in aggregate, then push for a cost-by-cost review that cuts more aggressively where there's low strategic value and protects the lines that are actually driving revenue or that carry contractual exit costs if cut abruptly. The client asked for a number. The right answer to the case is proving that the number, applied uniformly, would do real damage.

Ask directly rather than guessing and hoping it doesn't come up again. Something like, I don't have a strong sense of typical margins in this specific sub-industry, can you give me a benchmark to work from, is a completely normal thing to say and interviewers expect it. What actually hurts a candidate is inventing a plausible-sounding number and building fifteen minutes of analysis on top of it, because when the interviewer eventually corrects it, the whole structure has to be rebuilt live, and that costs far more time and credibility than asking up front would have.

A going concern issue exists when there's substantial doubt about whether a company can continue operating for at least twelve months from the financial statement date, triggered by things like recurring losses, negative working capital, loan covenant violations, or an inability to refinance near-term debt. The auditor has to evaluate management's own assessment and any mitigating plans, additional financing lined up, asset sales, cost restructuring, and decide whether those plans are actually probable of being achieved, not just proposed.

If substantial doubt remains after considering management's plans, the auditor includes an explanatory paragraph in the report. That paragraph alone can affect a company's stock price, its ability to raise capital, and its lender relationships, which is why the judgment behind it gets scrutinized so heavily during quality review.

I'd start by checking whether the underlying problem is a process problem or a genuine capability gap. A lot of client requests that arrive framed as "we need AI for this" turn out, on closer look, to be a broken handoff between two teams or a manual step that could be automated with basic rules-based logic, no machine learning required. Recommending the complex solution because the client asked for it by name, when a simpler fix would solve the actual problem faster and cheaper, is a way to win a project and lose the client's trust once they realize it.

Where AI genuinely is the right call, usually pattern recognition across large unstructured data sets or prediction tasks with a lot of historical data to train on, I'd still push for a scoped pilot before a full rollout, since the failure mode for these projects is almost always underestimating how messy the client's underlying data actually is once you're inside it.

Pick a real example with real stakes, not a mildly annoyed coworker. Describe specifically what made the relationship hard, unrealistic timeline expectations, a stakeholder who kept changing requirements after sign-off, someone actively skeptical of the recommendation, and what you did differently to manage it: adjusting your communication cadence, bringing in a senior colleague at the right moment, documenting agreements in writing to prevent scope drift. The weakest version of this answer blames the other person entirely with no reflection on what you adjusted on your end.

Raise it directly with the colleague first, if the situation allows for that, rather than escalating immediately to a manager without giving them a chance to correct it. But if it's a genuine integrity issue, misrepresenting completed work, skipping a required control, rather than a quality shortcut on something non-critical, escalating promptly matters more than preserving the relationship. Deloitte's audit and advisory work runs on the credibility of its output, so an answer that treats "just don't rock the boat" as an acceptable response to a real integrity concern is the one answer here that's actually disqualifying.

Acknowledge the previous mistake directly rather than avoiding it or acting as if a fresh team erases it, since the client remembers regardless of who's now sitting across the table. I'd ask what specifically damaged the trust, not just that trust is damaged in the abstract, because "we missed a deadline" and "we gave inaccurate advice" require completely different recovery approaches. Then I'd propose something concrete and verifiable early in the new engagement, a smaller deliverable with a tight, honored deadline, rather than a broad promise that things will be different this time.

This one rewards genuine reflection over a polished non-answer. Pick something real, a choice to skip a step under time pressure that turned out to matter, a call to not escalate a concern early enough, and describe specifically what you'd change, not just that you learned "communication is important." A candidate who can articulate exactly what they'd do differently, with the reasoning for why, comes across as someone who actually reviews their own decisions rather than someone reciting a lesson they were told to have.