TCS Software Engineer Interview Questions
Software engineers at TCS often look after systems that a client has run for many years, then maintain and modernise them without a break in service. Prepare to talk about proving that old code is wrong, refusing shortcuts that would rot a system, working out the impact of a small change across a large codebase, replacing old modules while proving the results still match, and following a client's change process under pressure. What to show here: careful ownership of long-running client systems. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How TCS hires, in its own words, and its questions for every job →
1. Tell me about a time you found a bug in code that had run unchanged for years on a client's system. How did you convince people it was a bug and not intended behaviour?
- Describe what you noticed and why it looked wrong.
- Explain how you checked the rule with documents and business people.
- Share the evidence you gathered and how you presented it.
- Give the result and how the fix was handled.
“While tracing a customer complaint, I found that a fee calculation rounded down before adding a charge, which was against the written rule. It had run that way for years, and the client's team assumed it was intended. I did not argue from opinion. I pulled the rule document, worked through several real cases by hand, and showed the difference between the code and the rule for each. I also estimated how many accounts were affected. The client agreed it was a defect, and we fixed it through a change request with a correction for past cases. The result was your result.”
Weak answers change the old behaviour quietly, or drop the issue because nobody had complained before.
2. Describe a time a client's business user asked you for a shortcut in the code, such as a special case for one branch or one customer. What did you do?
- Describe the request and the need behind it.
- Explain the cost of a hard-coded exception over time.
- Share the alternative you offered.
- Give the result.
“A client's operations manager asked me to make one branch skip a validation step, because that branch handled a special type of customer. The quick way was an if statement with the branch code in it. I explained that such exceptions pile up, nobody remembers why they exist, and they break when branches merge. Instead I proposed a setting on the branch record that switched the validation, so the rule was visible and could be changed by their admin team without code. It took a little longer, and the manager agreed. The result was your result.”
Weak answers add the special case to keep the user happy, or refuse without offering a proper way to meet the need.
3. A bank client wants to make the account number field longer. That field is used in hundreds of programs, files and screens. How do you work out the impact before changing anything?
- Search code, database definitions, file layouts and screens for the field.
- Trace where the value flows to other systems and reports.
- Group findings by type of change needed.
- Plan the order of change and the testing.
“I would begin with a wide search for the field name and its copies across programs, database columns, file layouts, screens and reports. Names differ in old systems, so I would also trace the data flow from known places to find fields that hold the same value under another name. Interfaces to other systems matter most, because they cannot change on our date alone. I would list each item with the kind of change it needs, such as a wider column or a new file layout. Then I would propose an order where the system accepts both lengths for a while, and plan full regression tests.”
Weak answers search for one field name and stop, or forget the files exchanged with other systems.
4. You are rewriting an old program that calculates insurance premiums into a modern language. How do you prove the new one gives the same answers as the old one?
- Treat the old program's output as the specification.
- Run both on the same real inputs and compare results.
- Investigate every difference and decide with the business which is right.
- Run side by side for a period before switching.
“Documents for old programs are often out of date, so I treat the old program's behaviour as the real rule book. I would collect a large set of real inputs with personal details masked, run both programs on them, and compare outputs field by field. Every difference is looked into. Sometimes the old program has a bug the business has come to depend on, so the client decides which answer is correct. I would pay attention to rounding and date handling, where languages differ. Before switching, both run side by side for some cycles with automatic comparison.”
Weak answers rewrite from the specification alone and test with a few hand-made cases.
5. An airport check-in system depends on a central reservation system. Design it so staff can still check passengers in when the link to the central system is lost.
- Decide which functions must work offline.
- Keep a local copy of the data needed for upcoming flights.
- Record actions locally and sync when the link returns.
- Handle conflicts, such as one seat given twice.
“I would decide first what must work offline: finding a passenger, confirming a seat and printing a boarding pass. Changing a ticket can wait. Each airport keeps a local copy of passenger lists and seat maps for flights in the next several hours, refreshed often while the link is up. When the link fails, the system moves to local mode and shows staff a clear notice. Every action is written to a local log with a unique id. When the link returns, the log is replayed to the central system. Conflicts, like a seat given twice, are flagged for staff to settle before boarding.”
Weak answers simply show an error when the link is down, or sync afterwards with no plan for conflicts.
6. Ten defects are open on a client's system and the team can fix four this week. How do you decide which ones, and how do you explain the difference between severity and priority?
- Define severity as technical impact and priority as business urgency.
- Gather facts: who is affected, how often, is there a workaround.
- Rank with the client's input and the service agreement.
- Communicate the plan for what is not fixed now.
“Severity is how badly the defect breaks the system. Priority is how soon the business needs it fixed. They can differ: a spelling error on the login page is low severity but may be high priority if customers see it. For each defect I would ask how many users are affected, how often, whether money or compliance is involved, and whether a workaround exists. I would also check what the service agreement promises for each level. Then I propose a ranking to the client and agree on it. The remaining six get a planned date and a workaround.”
Weak answers fix the easiest defects first, or decide alone without asking the business.
7. A senior manager at the client calls you directly and asks you to apply a quick fix to the live system today, skipping the usual change approval. What do you do?
- Understand the urgency and the real business impact.
- Explain the risk of skipping the process in plain words.
- Offer the emergency route that the process itself provides.
- Involve your lead and keep everything on record.
“I would listen first and understand what is hurting the business and how urgent it is. I would not say yes on the call, and I would not flatly refuse either. I would explain that an untracked change to the live system is a risk for them, and that their own process usually has an emergency path with faster approval. I would offer to prepare the fix and the emergency request straight away, and inform my lead and the client's change manager. If it is truly urgent, the fix can go out the same day, tested and recorded.”
Weak answers apply the fix quietly to please the manager, or hide behind process without offering a fast route.
8. Why do you want to work as a software engineer at TCS, looking after systems that clients have run for years?
- Say what you value in engineering work.
- Connect it to running and modernising systems for clients.
- Link to your experience.
- Say how you want to grow.
“I value being trusted with systems that matter. TCS delivers IT services to client companies and often looks after their important applications for years, so an engineer gets to understand a system and a business deeply, not only pass through. I have enjoyed maintenance and modernisation work, where success means nothing breaks and the system gets a little better each release. I know that means process, documentation and patience, and I am comfortable with that. I want to grow into someone who can lead the modernisation of a large system safely.”
Weak answers want only new projects and see maintenance as something to escape from.
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.