Infosys Backend Developer Interview Questions
Backend developers at Infosys often sit inside a client's platform team, shipping changes every week to systems such as a retailer's online store, a telecom operator's recharge and billing services, or a manufacturer's dealer and partner APIs. Prepare to discuss festival-season peaks, duplicate requests from partner apps, product catalogues that change all day, API versions used by slow-moving partners, and silent failures. What to show here: steady weekly delivery on platforms with real customers and peaks. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Infosys hires, in its own words, and its questions for every job →
1. Tell me about how you prepared a client's online store for its biggest sale of the year. What did you do in the weeks before, and what happened on the day?
- Describe the platform and the expected peak.
- Explain the load testing and the weak points found.
- Share the protections you added.
- Describe the day and what you learned.
“For a retail client's festival sale, I owned the order service. Weeks before, we ran load tests at several times normal traffic and found that the order confirmation step called the stock service one item at a time. I changed it to one batch call and added a queue for confirmation emails so they could not slow checkout. We also agreed a code freeze for the last week and set up a shared channel with the client's team for the day. On the day I watched queue depth and error rates and had one small config change ready. The result was your result.”
Weak answers describe hoping for the best, or a load test that used data nothing like the real sale.
2. Describe a time you worked in a squad made up of client engineers, your colleagues and people from another supplier, and ownership of a piece of work was unclear. How did you sort it out?
- Describe the mix of people and the unclear area.
- Explain what went wrong or nearly went wrong because of it.
- Share how you raised it and what agreement came out.
- Give the result.
“On a telecom client's platform, my team built the recharge API and another supplier's team built the app that called it. When a recharge failed for some customers, each side assumed the other was investigating. I noticed a day had passed with no owner. I set up a short call with both teams and the client's lead, and we traced the failure together from the app log to my service. It turned out to be a timeout on our side. We then agreed a simple rule: whoever gets the report owns it until a named person accepts it. The result was your result.”
Weak answers blame the other supplier, or wait for the client to assign the problem.
3. Design the service that applies a prepaid mobile recharge and updates the customer's balance, when partner apps sometimes send the same recharge request twice.
- Require a unique request id from every partner.
- Store the request id with its result before changing the balance.
- Update the balance in one transaction with a row lock or a version check.
- Return the same result for a repeated id.
“Every recharge request must carry a unique id chosen by the partner. When a request arrives, the service first tries to insert that id into a table of processed requests. If the insert fails because the id exists, the service returns the stored result of the earlier request without touching the balance. If it succeeds, the service applies the recharge and updates the balance inside the same transaction, with a row lock on the account so two recharges at once cannot lose an update. The result is saved against the request id. Old ids can be cleaned up after an agreed period.”
Weak answers rely on the partner not to retry, or check for a duplicate and then update in two separate steps.
4. A retailer's catalogue has a huge number of products, and prices, stock and descriptions change all day from several source systems. Design how the store reads product data quickly and stays reasonably fresh.
- Build a read model that combines data from the sources.
- Update it from change events rather than full reloads.
- Give each field its own freshness rule: price and stock fast, descriptions slower.
- Cache at the edge and clear entries on change.
“I would not have the store query several source systems on each page view. Instead, a read model holds one document per product with everything the page needs. Source systems publish change events, and a worker updates the read model, so a price change reaches the store in seconds without reloading everything. Not all fields are equal. Price and stock must be fresh, so they update at once and the cache entry is cleared. Descriptions and images can lag minutes. A full rebuild runs nightly to repair any missed events. The search index is fed from the same read model.”
Weak answers reload the whole catalogue on a schedule, or treat a description update with the same urgency as a price.
5. A manufacturer's API is used by hundreds of dealers, many of whom update their software only once a year. You need to change a response format. How do you manage versions?
- Prefer additive changes that old clients ignore.
- When a breaking change is needed, add a new version and keep the old one running.
- Track which dealers use which version from request logs.
- Set a retirement date, tell dealers early and help them move.
“First I would ask whether the change can be additive, such as a new field beside the old one, because old dealer software simply ignores fields it does not know. If the change must break the old shape, I would publish a new version of the endpoint and keep the old one working. Request logs tell me which dealers still call the old version, so I can contact them directly rather than sending a general notice. I would set a retirement date far enough away for their yearly update cycle and offer a test environment for the new version. Both versions share the same service code underneath.”
Weak answers change the response in place and expect dealers to notice, or keep every old version alive for ever.
6. The client's marketing team sends a push notification to every customer at once, and thousands open the app within a minute and hit checkout together. How do you protect the checkout service?
- Put limits in front of the service so it degrades rather than falls over.
- Queue work that does not need an instant answer.
- Cache what the burst reads repeatedly.
- Coordinate with marketing on timing and staggered sends.
“I would put rate limiting and a queue in front of the checkout service, so when the burst arrives, requests beyond capacity wait briefly or get a friendly retry message instead of a timeout. Steps that do not need an instant answer, such as sending the confirmation email or updating loyalty points, go to a background queue. The product and price data those customers read is served from cache. I would also work with the marketing team, because the simplest fix is sending the notification in waves over several minutes. Autoscaling helps, but it is too slow for a burst that starts in seconds.”
Weak answers rely on autoscaling alone, or never think of talking to the team that causes the burst.
7. After a release, orders using the store pickup option fall to zero, but there are no errors in the logs and monitoring is green. How do you investigate?
- Confirm the drop is real and tied to the release time.
- Walk the pickup flow as a customer in production.
- Compare the release diff for anything touching that option.
- Fix or roll back, then add an alert on business volume.
“Green monitoring only means nothing threw an error. I would first confirm from order data that pickup orders stopped exactly at the release, while delivery orders continued. Then I would go through the pickup flow as a customer on the live store. My guess would be that the option is no longer shown, perhaps because a store list call now returns an empty result that the code treats as normal. I would read the release diff for anything touching stores or pickup, fix or roll back, and then add an alert that fires when orders for any option fall far below the usual level for the hour.”
Weak answers trust the green dashboard and wait, or roll back without confirming the drop matches the release.
8. Why do you want to do backend work at Infosys, on platforms that belong to client companies?
- Say what you enjoy in backend work.
- Tie it to live client platforms with real customers and peaks.
- Link to your experience.
- Say what you want to learn.
“I like backend work on systems that are alive, where a change I ship on Tuesday is used by customers on Wednesday and the numbers tell me whether it helped. Infosys delivers that kind of work for client companies, on online stores, telecom services and partner APIs, so I would see several such platforms over time rather than one. I have worked on a checkout service through two peak seasons and enjoyed the preparation as much as the day itself. I want to learn how different industries shape the same backend problems, and how to work well inside a client's team.”
Weak answers speak only of technology names, and show no interest in the client's customers or business.
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.