Accenture Data Analyst — Interview Questions
Accenture Data Analyst Interview Questions
Accenture Data Analysts work inside client engagements where the data is rarely clean, the ask is rarely precise, and the person receiving the analysis is rarely technical. Interviews test SQL and statistics fundamentals, but just as heavily they test whether you can produce a usable, honestly-caveated answer under a deadline instead of a technically correct but unhelpful one. This guide covers the scenarios that come up most and what a strong answer sounds like.
Accenture's Interview Process for Data Analyst
Most candidates go through a telephone/recruiter screen, followed by a technical round covering SQL (beginner to intermediate), Python and its data libraries (pandas, NumPy), statistics fundamentals, Excel, and often Tableau or another BI tool — sometimes delivered as a timed assessment on a platform like HackerRank, lasting 45–90 minutes. A final HR/manager round covers behavioral fit and communication style.
Question 1: The Query That Returns the Wrong Numbers
You write a SQL query to calculate a client's monthly active users for a dashboard due this afternoon. The number comes out 30% higher than the client's internal team reports. You have two hours before the dashboard goes live. What do you do?
Why interviewers ask this
This checks whether you trust a suspicious number just because the query ran without errors, and whether you have a systematic way to find a discrepancy under time pressure instead of just re-running the same query hoping it changes.
Example strong answer
First I'd hold the dashboard rather than ship a number I don't trust, and let whoever's expecting it know there's a discrepancy I'm running down — a 30% gap is too large to be rounding or timezone noise, so shipping it risks the client immediately distrusting the whole dashboard. Then I'd check the most common causes in order of likelihood: am I counting duplicate user IDs because of a join that's fanning out rows, am I using a different definition of "active" than the client's internal report (a login versus a meaningful action), and am I missing a filter for test accounts or internal traffic that the client's report excludes.
In my experience, a join fanning out duplicate rows is the single most common cause of an inflated count like this, so I'd check for that first by counting distinct user IDs before and after each join in the query to see exactly where the number balloons. If that's not it, I'd get the client's actual definition of "active user" in writing rather than assuming, since a mismatched definition is the second most likely cause and no amount of query debugging fixes a definitional mismatch.
Once I find the cause — say it's duplicate rows from a one-to-many join with a login events table — I'd fix the query, sanity-check the corrected number against a manual spot-check of a handful of known users, and only then ship the dashboard, even if that means it goes live an hour late with a heads-up to whoever's waiting on it.
Follow-up questions
- You find the cause but fixing it properly would take longer than your two-hour window. What do you do?
- The client's own internal number turns out to be wrong, not yours. How do you raise that?
Question 2: Building the Dashboard No One Fully Specified
A client stakeholder asks for "a dashboard showing how the campaign is performing." No metrics are specified, no comparison period, no audience is named. You have a week.
Why interviewers ask this
Vague analytics requests are the norm on client engagements, and this tests whether you can convert an underspecified ask into a small number of decisions that actually get used, instead of building a large dashboard that answers questions no one asked.
Example strong answer
Before building anything, I'd ask the stakeholder one question: what decision will this dashboard help you make? "Performance" means something different if they're deciding whether to extend the campaign budget versus deciding which creative to kill versus reporting up to their own leadership. That one answer usually cuts the possible metric list from twenty down to four or five that actually matter for the decision at hand.
Say the real driver is deciding whether to extend budget — I'd build the dashboard around cost-per-acquisition and return on ad spend trended over time, compared against the campaign's original target, not a kitchen-sink view with every available metric. I'd include one comparison period (typically versus the prior campaign or a pre-defined benchmark) since a single number with no comparison rarely drives a decision on its own.
I'd also build it as a rough draft first and get five minutes of the stakeholder's reaction before polishing it, rather than spending the full week perfecting something based on my own guess at what they meant. That early check usually catches a misunderstanding — say they actually cared about regional breakdown, not overall trend — while there's still time to fix it, instead of discovering the mismatch at delivery.
Follow-up questions
- The stakeholder says "just show me everything, I'll figure out what matters." How do you push back constructively?
- Two different stakeholders on the same account want the dashboard to answer two different decisions. What do you do?
Question 3: When the Data Says Something the Client Doesn't Want to Hear
Your analysis shows the client's newest product feature, which leadership championed publicly, is actually reducing user retention for a meaningful segment. You're presenting to the team that built it tomorrow. How do you handle it?
Why interviewers ask this
Analysts who soften or bury inconvenient findings to avoid friction aren't useful to a client long-term, but analysts who deliver bad news carelessly damage the relationship. This tests whether you can do both: be accurate and be tactful.
Example strong answer
I wouldn't soften the finding into vague language like "there may be some nuance worth exploring" — that protects my comfort, not the client's ability to act on the information. I'd state the finding plainly but precisely: which segment, how large, what size effect, and how confident I am in it, including any limitations in the analysis so the finding can't be dismissed later as "the data was wrong."
I'd frame the presentation around the decision this enables rather than around blame — not "this feature was a mistake," but "here's a specific segment where it's underperforming, and here's what we could test to address it." That reframes an uncomfortable finding into something actionable, which is what the team that built the feature actually needs from the meeting, rather than a verdict on their work.
I'd also share the finding with my Accenture lead before the client meeting, not to get permission to say it, but so they're not surprised in the room and can back me up if the client pushes back defensively. Presenting a genuinely inconvenient finding cold, with no internal alignment first, is how good analysis gets dismissed as "the analyst didn't understand the feature."
Follow-up questions
- The feature's product owner disputes your methodology in the meeting, in front of the client's leadership. How do you respond in the room?
- Leadership asks you to soften the finding in the write-up that gets circulated afterward. What do you do?
Question 4: Small Sample, Big Claim
A/B test results come in after one week: the treatment group converted 18% better than control. The client wants to roll it out to everyone immediately. The sample size is small enough that you're not confident the result is statistically significant. What do you say?
Why interviewers ask this
This tests basic statistical judgment — specifically, whether you'll wave through an exciting-looking number under commercial pressure, or actually check significance and communicate the real uncertainty without killing the client's momentum unnecessarily.
Example strong answer
I'd run the actual significance test rather than eyeballing the 18% and calling it good or bad, because with a small sample, an 18% lift can easily be within noise, and the client rolling out based on noise risks reversing a decision later when the real effect turns out to be flat or negative. Say the test comes back with a p-value of 0.18 — not significant at a normal threshold, meaning the true effect could plausibly be anywhere from a loss to a much bigger win.
I wouldn't tell the client to simply wait longer with no further explanation, since that reads as unhelpful stalling on an exciting result. Instead I'd give them a specific plan: continue the test for a defined additional period with a calculated sample size needed to detect an effect of this rough magnitude reliably, and give them a firm date when we'll have a real answer — concrete enough that it doesn't feel like an indefinite delay.
If the client has a strong business reason to move faster than that — a launch deadline, a competitive pressure — I'd offer a middle path: a phased rollout to a larger but still limited segment, monitored closely, rather than either a full immediate rollout or a hard no. That gives them forward motion while limiting the downside if the 18% turns out to be noise.
Follow-up questions
- The client says "we don't have time to wait for statistical significance, just ship it." How do you respond?
- The extended test comes back and the effect actually reverses to negative. How do you deliver that news?
Question 5: Missing Data, Immovable Deadline
Two weeks into a month-long analysis, you discover a third of the transaction records for one region are missing due to a data pipeline issue that isn't your team's to fix, and won't be resolved before your deadline. What do you do?
Why interviewers ask this
Data gaps caused by systems outside your control are common on client engagements, and clients still expect a deliverable on the agreed date. This tests whether you adapt the analysis honestly around a real constraint instead of either quietly extrapolating over the gap or blowing the deadline waiting for a fix you don't control.
Example strong answer
First I'd quantify exactly what's missing — which region, what proportion of records, over what time window — rather than treating it as a vague problem, because the right response depends heavily on whether it's 5% of one region's data or a third of the total dataset. I'd also flag it immediately to my lead and, depending on severity, to the client, rather than discovering it internally and hoping it resolves itself before the deadline.
For the analysis itself, I'd decide whether that region can be reasonably excluded and called out as excluded, or whether it's important enough to the overall conclusion that I need a partial view with clearly labeled confidence — for example, presenting national trends confidently while explicitly noting that regional-level conclusions for the affected region are directional only, not final, until the pipeline issue is fixed. What I wouldn't do is fill the gap with an estimate and present it with the same confidence as real data, because that risks the client making a real decision off fabricated numbers without knowing it.
I'd deliver on the original deadline with this caveat clearly stated on the first page of the report, not buried in a footnote, and propose a specific follow-up date for a corrected version once the pipeline issue is resolved. Clients generally respond far better to "here's what we know now, clearly labeled, and here's when we'll have the rest" than to either a silently incomplete report or a missed deadline with no interim deliverable.
Follow-up questions
- The client's business decision genuinely can't wait for the follow-up — they need a number now. What do you tell them?
- It turns out the missing data isn't random — it's concentrated in exactly the segment the client cares about most. Does that change your approach?
Preparation tip
Accenture data analyst interviews reward candidates who talk about what they'd verify and how they'd caveat a finding, not just candidates who get to a clean number fastest. A confident answer that ignores a data quality problem reads worse than a slightly slower answer that catches it.