Accenture Technology Consultant — Interview Questions
Accenture Technology Consultant Interview Questions
Accenture Technology Consultants sit at the intersection of business strategy and technical implementation — advising clients on platform decisions (ERP, CRM, cloud), building the business case for change, and translating technical trade-offs into language a non-technical executive can act on. Interviews are conversational rather than pure Q&A, gauging the breadth of your functional expertise as much as depth in any one area. This guide covers the scenarios that come up most and what a strong answer sounds like.
Accenture's Interview Process for Technology Consultant
Most candidates go through two core rounds: a skills round covering your experience, technical breadth, and platforms you've worked with (CRM, ERP, digital/SEO, cloud), often including guesstimates and go-to-market strategy questions; and a techno-managerial round with the hiring manager that blends behavioral questions with an assessment of how you'd operate on a live client engagement. Graduate-level pipelines sometimes add a half-day assessment center with case studies, paired exercises, and a segment where you present a technology idea to an assessor.
Question 1: The Client Who Doesn't Want to Migrate
You're advising a mid-size manufacturing client on migrating from an on-premise ERP system to a cloud platform. The business case is strong, but the client's long-tenured IT director is quietly resisting — delaying data requests, questioning the timeline in every steering meeting. How do you handle it?
Why interviewers ask this
A large share of Accenture's advisory work fails or succeeds based on internal client politics, not the technical merits of the recommendation. This tests whether you can read and work with resistance rather than just escalating it or ignoring it and hoping the business case wins on logic alone.
Example strong answer
Before doing anything about the resistance itself, I'd try to understand what's actually driving it — IT directors who've run a system for a decade are rarely resisting out of simple stubbornness. It's often one of a few specific fears: that the migration exposes gaps in how the current system has been maintained, that their team's skills become less relevant on the new platform, or that they genuinely don't trust the vendor's timeline based on past experience with similar projects. I'd have a direct one-on-one conversation, framed as wanting his input rather than as managing his objections, to find out which it is.
If it's a skills or relevance concern, I'd bring a concrete plan for his team's role post-migration into the business case itself — training paths, ownership of the new platform's governance — rather than treating that as an HR afterthought once the technical plan is approved. If it's timeline distrust, I'd propose a smaller proof-of-concept migration for one module first, so he sees a real result before betting the whole system on the new timeline, which is a more persuasive move than another slide reasserting the business case.
What I wouldn't do is escalate to his boss immediately as a first move, even though that might resolve the delay faster — that tends to create a hostile relationship for the rest of the engagement with the person whose team's cooperation the migration actually depends on. I'd only escalate if a genuine, specific attempt to address the underlying concern doesn't move the delays, and even then I'd frame it around the business risk of delay, not around him personally.
Follow-up questions
- The proof-of-concept module has a rough result due to a data quality issue unrelated to the platform. How does that affect your approach?
- The IT director's concerns turn out to be legitimate — the vendor's timeline really is unrealistic. How do you handle bringing that back to the client sponsor who approved the business case?
Question 2: The Guesstimate
Roughly how much would a mid-size retail client with 200 stores save annually by consolidating five regional CRM systems into one platform? You have two minutes to think and should talk through your reasoning out loud.
Why interviewers ask this
Guesstimates aren't about the final number — they're about whether you can structure a rough business case logically under time pressure, make reasonable assumptions explicit, and land on an order-of-magnitude answer a client could actually use as a starting point.
Example strong answer
I'd break the savings into two buckets: direct cost savings from consolidating licensing and infrastructure, and productivity savings from agents and marketing teams no longer working across five disconnected systems. For licensing, if each regional CRM costs roughly $150 per user per year and there are, say, 1,000 total users across the five systems, that's $150,000 a year just in software cost — consolidating to a single platform at a similar or slightly higher per-seat cost but with volume pricing might realistically cut that by 20–30%, so call it $30,000–$45,000 in direct licensing savings, plus whatever infrastructure or support overhead five separate systems require versus one, which I'd estimate conservatively at another $50,000–$100,000 given typical maintenance and integration costs for legacy regional systems.
For productivity, if customer service or marketing staff spend even 20–30 minutes a day working around fragmented customer data across systems — checking multiple places for a customer's history — that's a meaningful chunk of a workday recovered across a large user base; at even a conservative fully-loaded cost per employee, that adds up to a larger number than the direct licensing savings, though it's a softer number to defend to a CFO.
Putting it together, I'd land on a rough range of $300,000–$500,000 in annual savings, weighted more toward the productivity side, and I'd be explicit that the productivity number is the one that needs validation through a time-and-motion study before it goes into a formal business case — the licensing and infrastructure numbers are more defensible on their own.
Follow-up questions
- The CFO says they only care about hard, contractually-verifiable savings, not productivity estimates. How does your recommendation change?
- How would you validate the productivity assumption cheaply before commissioning a full study?
Question 3: The Go-To-Market Question
A client is launching a B2B SaaS product aimed at mid-market logistics companies and asks for your view on their go-to-market approach. They're currently planning a broad digital ad campaign across all mid-market verticals simultaneously. What's your read?
Why interviewers ask this
This tests commercial judgment beyond pure technology delivery — whether you can push back constructively on a client's plan with a more focused alternative, and communicate strategy clearly without a formal case-study framework to lean on.
Example strong answer
I'd start by asking what evidence exists that logistics companies across all mid-market verticals have the same buying trigger and the same pain point, because a broad simultaneous launch usually works when the product's value proposition is genuinely universal across those verticals — and for a specialized B2B SaaS product, that's rarely true. Logistics companies in cold-chain versus general freight versus last-mile delivery have different regulatory pressures, different existing tech stacks, and different urgency levels around a new tool.
I'd recommend narrowing the initial go-to-market to one or two verticals where the pain point is sharpest and where there's an identifiable trigger event — say, a recent regulatory change affecting cold-chain logistics that makes the product newly relevant — rather than spreading a limited ad budget thin across all verticals at once. A focused launch also gives the sales and customer success teams a chance to build a repeatable playbook with early customers in one vertical before scaling the messaging and proof points to the next.
I'd frame this to the client not as "your plan is wrong" but as a sequencing question: the broad approach might be right eventually, but starting narrow gets them to product-market fit signals and referenceable customers faster, which actually strengthens the broader campaign later because they'll have real case studies instead of only feature claims. I'd back this with a rough estimate of how much further their initial budget goes when concentrated on one vertical's media channels versus spread across several.
Follow-up questions
- The client's leadership has already committed to the broad launch publicly to their board. How do you adjust your recommendation given that constraint?
- How would you measure whether the narrow-vertical approach is actually working within the first quarter?
Question 4: Legacy Platform vs. New Build
A client's core order management system is 15 years old, painful to maintain, but stable and deeply embedded in daily operations. They're deciding between a full replacement and incrementally modernizing the existing system. What do you recommend, and how do you get there?
Why interviewers ask this
This is one of the most common real advisory decisions at Accenture, and there's rarely a universally correct answer — interviewers want to see the framework you'd use to reach a recommendation, not just "replace it" or "keep it" stated with confidence.
Example strong answer
I wouldn't default to "replace it" just because the system is old, and I wouldn't default to "keep it" just because it's stable — the right answer depends on specifics I'd need to gather first: how much genuine business capability is blocked by the current system versus how much is just maintenance friction, how much of the 15-year-old logic actually encodes business rules nobody's documented elsewhere, and what the client's realistic tolerance is for risk and disruption during a transition.
If the system is blocking real growth — say, it can't support a new sales channel the business wants to launch — that tips toward replacement, because incremental fixes to an old architecture often can't unlock genuinely new capability, only reduce friction on what already exists. If the pain is mostly maintenance cost and developer frustration but the system does what the business needs today, incremental modernization — wrapping the legacy core with modern APIs, migrating specific modules over time — is usually the lower-risk path, since a full replacement of a system this embedded in daily operations carries real risk of business disruption during cutover.
I'd bring the client a structured comparison: cost and risk of full replacement versus incremental modernization, mapped against which specific business capabilities each path unlocks and by when, rather than a single recommendation with no visible reasoning. Often the honest answer is a hybrid — incrementally modernize now while building toward replacement of the highest-risk components over a longer horizon, rather than a single big-bang choice.
Follow-up questions
- The client's CEO wants a full replacement regardless, for competitive optics with their board. How do you handle a business decision that overrides your technical recommendation?
- How would you scope a first incremental modernization phase to prove the approach works before committing to the full multi-year plan?
Question 5: Translating the Trade-off
You need to explain to a client's non-technical VP of Operations why choosing a more customizable CRM platform will cost 40% more and take three months longer than a simpler, more standardized option — without losing them in technical detail or having them just default to the cheaper option because it sounds easier.
Why interviewers ask this
Accenture consultants constantly translate technical trade-offs for non-technical decision-makers, and this tests whether you can do that in business terms — cost, risk, time-to-value — rather than falling back on technical jargon that a VP of Operations has no reason to find persuasive.
Example strong answer
I'd avoid explaining the technical difference between the platforms at all in the first pass — not because it doesn't matter, but because leading with "platform A has a more flexible API architecture" doesn't help a VP of Operations make a decision. Instead I'd translate it into what each option means for the business: the standardized option gets them live three months sooner, but it can't support the custom approval workflow their sales team currently relies on, meaning that workflow either goes away or gets rebuilt manually outside the system. The customizable option costs more and takes longer, but it preserves that workflow and can flex as their process changes next year without another costly rebuild.
I'd quantify the trade-off in terms they already use to make decisions — if losing the custom approval workflow costs the sales team meaningful time per deal, or risks deals slipping through without proper sign-off, that's a concrete cost against the three months saved, not just an abstract feature loss. I'd present it as a genuine choice with a real cost either way, not as "the expensive one is objectively better," because sometimes three months and lower cost is actually the right call for that business, and my job is to make the trade-off visible, not to sell a foregone conclusion.
I'd close by giving a clear recommendation anyway, since a VP of Operations generally wants my view, not just a menu — but I'd state it as a recommendation grounded in their stated priorities, explicitly noting what would change my recommendation if their priorities were different.
Follow-up questions
- The VP says "just tell me which one to pick," impatient with the trade-off framing. How do you respond?
- Three months into the standardized option, the sales team's workaround process is causing real problems the VP didn't anticipate. How do you handle that conversation?
Preparation tip
Accenture technology consultant interviews reward candidates who translate technical decisions into business consequences without dumbing them down, and who give a real recommendation rather than hiding behind "it depends" with no follow-through. State the trade-off, then commit to a view.