Accenture Software Engineer Interview Questions
A software engineer at a global consulting and IT services company builds and runs technology for client companies, so the code often belongs to someone else, follows their rules and outlives the project. Prepare stories about joining unfamiliar codebases, estimating work for a client, handling changing requirements, working across time zones and leaving behind code the client's own team can run. What to show here: clear client communication and code others can maintain. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Accenture hires, in its own words, and its questions for every job →
1. Tell me about a time you joined a codebase you did not write, with little documentation, and still had to deliver a change quickly.
- Describe the codebase and why it was hard to follow.
- Explain how you found the parts that mattered: running it, tracing a request, reading tests.
- Show how you made the change safely.
- Mention what you left behind for the next person.
“On an internship project I was asked to fix a report in an old application nobody on the team had written. There was almost no documentation. I started by running it locally and following one request from the screen down to the database, writing notes as I went. I found the report logic in a large class with no tests, so I added a couple of simple tests around the current behaviour before touching anything. Then I made the fix, and the tests showed I had not broken the rest. I also added my notes to the project wiki.”
Weak answers rewrite large parts of the old code on day one or make changes without any way to check them.
2. Describe a time you worked with teammates or a client in a very different time zone. How did you keep work moving without losing a full day on every question?
- Set the situation and the time gap.
- Explain the habits you used: end-of-day notes, clear questions, shared tracker.
- Describe how you handled a blocker while the other side was offline.
- Share what improved.
“In one project, the people who reviewed our work were many hours behind us, so our questions often waited a whole day. I started writing an end-of-day note with what I finished, what was blocked, and each question written so it could be answered with a yes or no. When I was blocked, I moved to another task instead of waiting, and I noted my assumption in the ticket so the reviewer could correct it. We also agreed on a short overlap call a few times a week. After that, your result.”
Weak answers complain about the other team being slow and show no change in how they themselves communicated.
3. A client asks how long it will take to add a feature to their existing system, which you have not seen yet. How do you give an estimate you can stand behind?
- Ask to see the code, the environments and the current tests before committing.
- Break the feature into small tasks, including testing, review and deployment.
- List the unknowns and assumptions, and give a range.
- Agree when you will update the estimate after the first look.
“I would not give a single number on the spot. I would ask for a short time to look at the code and how it is deployed. Then I break the feature into small tasks, including the parts people forget, like test data, code review, security checks and release steps. For each unknown, such as an old library or a missing test environment, I write an assumption. I give the client a range with those assumptions listed, and I promise a firmer number after the first task is done, when the real code has taught us more.”
Weak answers give one confident number without seeing the system, or leave out testing and deployment time.
4. How would you plan moving a client's old on-premise application to the cloud without stopping their business while you do it?
- Understand what the application does, what it talks to and when it is busiest.
- Choose a path, like lift and shift first or changing parts as you go.
- Move in stages with data sync, testing and a rollback plan.
- Cut over at a quiet time, watch it closely and keep the old system ready until the client signs off.
“I would start by mapping the application: its users, its database, the other systems it calls, and its busy hours. Often the safest first step is to move it with few code changes, then improve it later. I would set up the cloud environment following the client's security rules, copy the data, and keep it in sync with the old system. We test with real traffic patterns in the new setup. Then we switch over during a quiet window, monitor closely, and keep the old system ready to switch back until the client is happy.”
Weak answers jump straight to a full rewrite on new services and never mention data sync, rollback or the client's busy periods.
5. The client has coding standards and security rules that differ from what you are used to. How do you make sure your code meets them from the first pull request?
- Read the client's standards and ask where they are enforced.
- Set up their linters, formatters and security scans on your machine.
- Check common rules yourself: secrets, logging of personal data, approved libraries.
- Ask a client reviewer early and keep a short checklist.
“I treat the client's rules as the rules, even if my own habits differ. Before writing code, I read their standards and set up the same linter, formatter and scanning tools they use in their pipeline, so problems show on my machine first. I pay special attention to security items: no secrets in code, no personal data in logs, and only libraries they have approved. For my first change, I ask a reviewer from the client team to look early, then I turn their comments into a small checklist I use every time.”
Weak answers argue that their own style is better or wait for reviewers to catch every rule.
6. What do you put in a handover so the client's own team can run, support and change your code after the project ends?
- A simple readme: what it does, how to run it, how to deploy it.
- Decisions and their reasons, plus known limits.
- Runbooks for common problems and where the logs are.
- Walkthrough sessions and a period where the client team makes changes with you watching.
“I start from the question: could someone new fix a bug here without calling me? So I leave a clear readme on how to set up, test and deploy the code. I write down important design decisions and why we made them, along with known limits. I add short runbooks for common issues, like a failed job, and where to find logs. Documents alone are not enough, so I run walkthroughs and then let the client's engineers make the next few changes while I review, so they learn by doing.”
Weak answers treat handover as sending a code link, or write documents nobody on the client team has tried to follow.
7. What appeals to you about building software for client companies in different industries, and why Accenture in particular?
- Say what you like about client work: variety, real business problems, learning fast.
- Accept the harder parts, like changing requirements and client rules.
- Connect it to Accenture as a global company that builds and runs technology for clients.
- Link it to how you want to grow.
“I like the idea of solving real business problems for many kinds of companies instead of one product for years. Early in my career, seeing different codebases, industries and ways of working will teach me faster. I also know client work means changing requirements, strict client rules and clear communication every day, and I am comfortable with that. Accenture builds and runs technology for client companies around the world, so I would get that variety while working with experienced people. I want to grow into an engineer clients trust with their systems.”
Weak answers could be said about any company, or show no idea that the work is done for clients.
8. Midway through a sprint, the client changes a requirement that makes work your offshore teammates already finished no longer fit. What do you do?
- Confirm the new requirement in writing and understand why it changed.
- Check what finished work can be reused and what must change.
- Share the impact on time and scope with your lead and the client.
- Update the tickets and brief the offshore team clearly before their day starts.
“First I would make sure I understand the change exactly, and get it written down in the ticket or an email, not just said on a call. Then I look at what my teammates already built and see how much can be kept. I would bring that to my lead with a simple view: what changes, what extra time it needs, and what might move out of this sprint. Once the client agrees, I update the tickets and leave a clear note for the offshore team so they start their day knowing what to do.”
Weak answers either refuse the change outright or quietly redo the work and let the deadline slip without telling anyone.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.