Infosys Software Engineer Interview Questions
Software engineers at Infosys often work as part of a client's product squad, delivering small changes every week to a living platform: a retailer's loyalty system, a telecom operator's customer messaging, or a manufacturer's connected machines sending data from the field. Prepare to discuss steady delivery, growing teams, data that arrives late, consent rules, points that must never be counted twice, and pressure to skip tests. What to show here: small safe releases, tested code and good habits shared with the team. 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 a small change you shipped to a client's live platform that had a much bigger effect than you expected, good or bad. What did you learn about releasing often?
- Describe the change and why it seemed small.
- Explain the effect and how you noticed it.
- Share what you did in the moment.
- Say what you changed about how you release.
“I changed the default sort order on a retail client's category page from newest to most popular. It was a one-line change. Within a day, the client's merchandising team noticed that new products got far fewer views, which affected their launches. I had not asked who depended on the old order. We made the sort a setting per category so they could choose. Since then, I treat any change that customers see as a release with a flag and a note to the client's business teams, however small the code. The result was your result.”
Weak answers judge a change by its line count, or show no change in habits after the surprise.
2. Describe a time your squad on a client platform grew quickly and new engineers needed to be productive within days. What did you do?
- Describe the growth and the risk.
- Explain what you prepared: setup, first tasks, pairing.
- Share how you kept standards while people learned.
- Give the result.
“Our team on a telecom client's platform doubled in a month ahead of a big release. Setup alone used to take days, so I wrote a script that built the local environment and a one-page guide to the codebase. Each new engineer got a small real ticket on their first day and a pairing partner for the first week. We kept code review strict, but reviewers explained the reason for each comment rather than just requesting changes. I also added automated checks for the style rules, so reviews focused on design. Within two weeks new people were shipping alone. The result was your result.”
Weak answers leave new people to find their way, or lower review standards to move faster.
3. A manufacturer's machines in the field send readings every few minutes, but connections are poor and readings often arrive hours late or in batches. How do you store and process them so reports are correct?
- Keep the time the reading was taken separate from the time it arrived.
- Store raw readings before any processing.
- Compute summaries by event time and allow late data to update them.
- Show in reports how complete each period is.
“Each reading should carry the time it was measured on the machine, and I would store the time it arrived separately. Raw readings go into an append-only store first, so nothing is lost and processing can be rerun. Hourly summaries are computed by measurement time, not arrival time, and are recomputed when late readings arrive for an old hour. Reports should show how many machines have reported for each period, so a low number is understood as missing data rather than a real drop. Machine clocks drift, so I would check readings against arrival time and flag readings from the future.”
Weak answers summarize by arrival time, or treat a late batch as a sudden spike.
4. A telecom operator sends customers messages by text, email and app notification. Design the part that decides which channel to use and respects each customer's consent.
- Store consent per customer, per channel and per message type.
- Put the decision in one service every sender must use.
- Apply rules: mandatory service messages versus marketing, quiet hours, fallbacks.
- Log every decision for audits and complaints.
“Consent should be stored per customer, per channel and per kind of message, because someone may accept service alerts by text but refuse marketing everywhere. Every team that sends messages must go through one decision service instead of choosing channels themselves. That service checks the message type, the customer's consent and preferences, quiet hours for the customer's region, and falls back to another allowed channel if the first fails. Service messages such as an outage notice have their own rules and cannot be switched off. Every decision, including a refusal, is logged, so a complaint can be traced.”
Weak answers let each sender check consent in its own way, or treat marketing and service messages alike.
5. Design a loyalty points system for a retailer with stores and an online shop, where points are earned on purchases, expire after a period, and are spent at checkout.
- Model points as a ledger of earn and spend entries, not a single balance.
- Make each earn entry idempotent on the purchase id.
- Expire points by entry, oldest first.
- Reserve points at checkout and confirm or release them.
“I would keep a ledger, where every earn, spend and expiry is a separate entry, and the balance is the sum. A single balance field is easy to corrupt. Each earn entry is keyed by the purchase id, so a purchase sent twice from a store terminal cannot earn twice. Expiry is applied per earn entry, and spending uses the oldest points first. At online checkout, points are reserved with an entry that is confirmed when the order completes or released if it fails, so two carts cannot spend the same points. A refund reverses the matching earn. The balance is cached for display but rebuilt from the ledger.”
Weak answers keep one balance number and add or subtract from it, with no way to handle duplicates or refunds.
6. Your service depends on three other services owned by other teams on the client's platform. How do you test your code without needing all of them running, and still catch a broken contract?
- Unit test your logic with fakes for the other services.
- Write contract tests that check the shape of each dependency's responses.
- Run a small set of integration tests against real test instances.
- Verify the contracts on both sides in the pipeline.
“Most tests should not need the other services. I would test my logic with simple fakes that return known responses, which keeps the tests fast. The risk is that a fake drifts from reality, so I would add contract tests: recorded examples of each dependency's requests and responses that both my team and the owning team check in their pipelines. If they change a field, their build tells them my contract broke before release. A small number of integration tests run against real test instances nightly, not on every commit. This way the pipeline stays fast and still catches a changed contract.”
Weak answers mock everything and never verify the mocks, or need every service running for every test.
7. The client's product owner asks you to skip the automated tests for a change so it can be released before a sale starts tonight. What do you do?
- Find out what the change is and what tests would actually take.
- Explain the risk plainly, tied to the sale.
- Offer options: run the relevant tests only, release behind a flag, or ship a smaller change.
- Record the decision if the client still overrides.
“I would first look at the change and the tests. Often the suite takes less time than the argument, and the relevant tests can run in minutes. I would explain that a broken checkout during the sale costs far more than a short delay. Then I would offer options: run the tests that cover the changed area now and the rest afterwards, release the change behind a flag so it can be turned off in seconds, or ship a smaller version tonight. If the product owner still insists, I would ask my lead to join and record the decision, so the risk is owned openly.”
Weak answers skip the tests to please the product owner, or refuse flatly with no alternative.
8. Why do you want to work as a software engineer at Infosys?
- Say what you value in engineering work.
- Connect it to working inside client squads on live platforms.
- Link to your experience.
- Say how you want to grow.
“I value steady, careful delivery: small changes, good tests, and a platform that gets a little better every week. Infosys delivers IT services to client companies, and much of that is exactly this kind of work, inside squads that mix client engineers with our own. I like that setting because good habits have to be shared, not assumed. I have worked on a live loyalty platform where a mistake showed up in a customer's account the same day, and that taught me discipline. I want to grow into an engineer who raises the standard of whichever team I join.”
Weak answers want only greenfield projects, or say nothing about working with a client's own engineers.
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.