Accenture Software Engineer — Interview Questions
Accenture Software Engineer Interview Questions
Accenture hires software engineers into client delivery teams, which means the day-to-day is less "build your own product" and more "build and maintain someone else's system, inside someone else's constraints, on someone else's timeline." The interview reflects that: alongside coding ability, interviewers are checking whether you can reason about trade-offs in an existing codebase, work inside Agile sprints where client priorities shift, and communicate technical decisions to people who aren't engineers. This guide covers the scenarios that come up most and what a strong answer looks like.
Accenture's Interview Process for Software Engineer
The pipeline typically runs three to four stages: an online assessment covering quantitative aptitude, logical reasoning, and verbal ability (this is an elimination round); a coding round with one to two problems — often string manipulation, sorting, or basic algorithms in Java, C, C++, .NET, or Python — solved in about 45 minutes; a technical interview that digs into your past projects, system design basics, Agile process, databases, and cloud fundamentals; and an HR or manager round covering career goals and teamwork.
Question 1: Debugging Under an SLA Clock
You're on-call for a client's order-processing service. At 2am, a monitoring alert fires: order confirmations are delayed by 40 minutes against a 5-minute SLA. You don't recognize the error pattern in the logs. What do you do in the first 15 minutes, and how do you communicate it?
Why interviewers ask this
Accenture engineers often support production systems with contractual SLAs, so this checks whether you have a calm, methodical incident process rather than randomly poking at the system, and whether you know to communicate status before you have a root cause — not after.
Example strong answer
First, I'd post a short status update in the incident channel — "investigating delayed order confirmations, SLA breach, will update in 15 minutes" — before I dig into logs, because the client and my lead need to know something's being worked on immediately, not after I've found the answer. Then I'd check the obvious high-leverage things first: recent deploys in the last few hours, queue depth on the message broker, and downstream dependency health (payment gateway, inventory service), since a 40-minute delay pattern usually points to a backlog building somewhere rather than a single failed request.
If nothing obvious jumps out, I'd look at whether the delay is uniform across all orders or concentrated on a subset — a specific region, order type, or payment method — because that narrows the search dramatically versus reading logs linearly. Say I find it's concentrated on orders using a specific payment provider, and that provider's API is timing out intermittently. I'd check if there's a retry loop with no backoff hammering that dependency, which is a common cause of this exact symptom — delays instead of hard failures.
Once I have a working theory, I'd apply the smallest safe mitigation first — circuit-breaking that payment provider temporarily to fail fast rather than fixing the root cause live at 2am — then post an update with what I found, what I did, and the current SLA status. Root-causing the retry logic properly and writing it up happens after the immediate bleeding stops, not instead of stopping it.
Follow-up questions
- The circuit breaker fix works, but now 5% of orders are failing outright instead of being delayed. Is that better or worse, and what do you do?
- The client asks for a written incident report by 9am. What goes in it?
Question 2: Designing for Scale You Don't Have Yet
A client's internal tool currently handles 500 requests a day and works fine on a single server with a single database. They've just signed a deal that will bring that to 50,000 requests a day within two months. How do you approach redesigning it?
Why interviewers ask this
This isn't a trick question about theoretical distributed systems — it's testing whether you over-engineer for scale that doesn't exist yet or under-engineer for scale that's coming fast. Accenture client budgets and timelines rarely support a full rewrite, so pragmatism matters as much as technical correctness.
Example strong answer
Before redesigning anything, I'd find out where the current system actually breaks first under load — usually not everywhere at once. I'd run a basic load test against the existing single-server setup to see whether it fails at the database layer, the application layer, or somewhere unexpected like a synchronous third-party call, because that tells me where to spend the two months of effort instead of guessing.
If the bottleneck is the database, as it usually is at this scale jump, I'd prioritize adding read replicas and caching for the heaviest read queries before touching the application architecture — that alone often buys an order of magnitude of headroom with much less risk than a rewrite. If the application layer itself can't handle concurrent load, I'd look at whether it's stateless enough to run multiple instances behind a load balancer, which is usually a smaller change than it sounds if the app wasn't storing session state locally.
I'd explicitly avoid jumping straight to a microservices rewrite or a message-queue-everything architecture unless the load test shows the monolith genuinely can't be scaled horizontally — that's a much bigger, riskier change for a two-month timeline, and "it worked at 50,000 requests a day" doesn't require it. I'd present the client with a phased plan: immediate caching and read-replica work in weeks one and two, horizontal scaling of the app tier in weeks three and four, and load testing checkpoints before go-live, rather than a single big-bang redesign.
Follow-up questions
- The load test reveals the bottleneck is a synchronous call to a legacy mainframe system the client won't let you touch. Now what?
- How would your answer change if the client only gave you two weeks instead of two months?
Question 3: Code Quality vs. the Deadline
It's the day before a client demo. You find a bug in a teammate's recently merged code that causes incorrect data in an edge case — not one likely to come up in the demo, but one that will hit real users within a few weeks of go-live. Fixing it properly means delaying the demo prep. What do you do?
Why interviewers ask this
This tests judgment about risk and communication, not just technical fix-it skills. Accenture wants engineers who flag real problems honestly to the team and client rather than either hiding a known issue to protect the demo, or blocking everything over something that could be handled with a fast-follow.
Example strong answer
I wouldn't silently fix it myself right before the demo without telling anyone — that risks introducing a new bug under time pressure with no review, and it hides the decision from people who should weigh in. Instead I'd flag it to my teammate and lead immediately with the specific detail: what triggers the bug, how likely it is in production versus in the demo, and roughly how long a proper fix takes.
Given it's unlikely to surface in the demo itself, I'd recommend we proceed with the demo as planned rather than scrambling a same-day fix, but I'd push for the fix to be prioritized as the first item after the demo, with a ticket written now — while the context is fresh — rather than "we'll get to it." I'd also ask whether the client needs to know before go-live, since that's a business and risk decision, not just an engineering one; if it's the kind of bug that could cause a compliance or billing issue, that changes the calculus even if the demo itself is unaffected.
What I want to avoid is the two failure modes: quietly shipping a known data-integrity bug to protect a demo's optics, or turning a fixable edge case into a full demo-blocking crisis the night before. The right move is naming the risk clearly, letting the team make an informed call, and making sure the fix doesn't quietly fall off the backlog once the demo excitement passes.
Follow-up questions
- Your teammate who wrote the buggy code gets defensive when you raise it. How do you handle that conversation?
- The client finds the bug themselves two weeks after go-live before you've fixed it. How does that change your next steps?
Question 4: Agile Priorities Shifting Mid-Sprint
You're three days into a two-week sprint, deep into a feature the client explicitly prioritized last planning session. The client's product owner emails asking for a completely different, smaller feature to be swapped in — "urgently" — without going through a formal re-planning conversation. How do you respond?
Why interviewers ask this
Client-driven priority shifts are constant on Accenture delivery engagements, and this checks whether you protect sprint commitments and process without being rigid or unhelpful when the client legitimately does have something urgent.
Example strong answer
I wouldn't just drop what I'm doing and start the new feature based on one email, and I also wouldn't refuse outright and hide behind "that's not how Agile works." I'd reply quickly acknowledging the request and ask one clarifying question: what specifically makes this urgent — a hard external deadline, a blocked downstream team, or a preference that surfaced today. That answer determines whether this is genuinely sprint-breaking or can wait eight days for the next planning session.
If it turns out to be genuinely urgent — say, tied to a regulatory deadline the business side just found out about — I'd loop in the scrum master or delivery lead immediately rather than deciding solo to swap scope, since that's a call that affects the whole team's commitment, not just my task. We'd have a short, real conversation about what gets descoped or delayed to make room, and I'd make sure that trade-off is visible to the client too — not free, even if it's the right call.
If it's not truly urgent, I'd say so directly but constructively: "this sounds important, let's make sure it's the top item for next sprint rather than pulling it in now, since we're partway through committed work." Most client stakeholders respect that framing because it shows their request was heard and will be acted on, just not by breaking a commitment made a few days ago without discussion.
Follow-up questions
- The product owner escalates over your scrum master's head directly to the client partner on the account. What do you do?
- How would you prevent this pattern of "urgent" mid-sprint asks from recurring every sprint?
Question 5: The Legacy System Nobody Wants to Touch
You're asked to add a new feature that requires modifying a 10-year-old module with no tests, written by someone who left the company years ago, and the client is nervous about anyone touching it. How do you approach the work?
Why interviewers ask this
A large share of Accenture's engineering work is on systems that predate the current team, often for clients who are risk-averse about their legacy stack. This tests whether you can make progress carefully without either refusing to touch it or barreling in and breaking something.
Example strong answer
Before writing any new code, I'd spend time understanding the module's actual behavior rather than just its code — tracing a few real inputs through it manually, checking any logs or monitoring that show how it's used in production today, and writing a small set of characterization tests that capture its current behavior even without understanding every line, so I have a safety net before I change anything.
I'd scope the change to touch as little of the existing module as possible — often that means wrapping the new logic around the old module rather than editing its internals directly, even if that's slightly less elegant, because the risk of an unintended side effect in code nobody fully understands outweighs the benefit of a cleaner internal change. If the feature genuinely can't be added without modifying the core logic, I'd make that change in the smallest possible increment and get it reviewed by the most senior person available on that codebase, even if that means a short delay.
I'd also communicate the risk honestly to the client rather than presenting it as routine: "this module has no test coverage and no clear owner historically, so we're adding characterization tests first and keeping our change minimal — that adds a few days but significantly reduces the risk of breaking something in production." Clients who are nervous about legacy code generally respond well to seeing that caution taken seriously rather than glossed over.
Follow-up questions
- Your characterization tests reveal the module has a bug that's been silently producing slightly wrong output for years. Do you fix it as part of this work?
- The client says there's no time for characterization tests — they need the feature in three days. What do you do?
Preparation tip
Accenture interviewers for engineering roles are usually less interested in whether you get the "optimal" algorithmic answer and more interested in how you handle constraints you didn't choose — legacy code, shifting client asks, incomplete test coverage. Narrate your reasoning about risk and trade-offs out loud; a slightly slower but well-reasoned approach beats a fast answer that ignores the constraint the question was built around.