TCS delivers IT services to client companies such as banks, insurers, airlines and retailers, and much of that work is keeping large existing systems running and changing them safely. As a campus hire, expect fundamentals placed inside that work: database transactions for money transfers, nightly jobs that process big files, queries on customer records, and how you behave when given a project you did not choose. What to show here: solid basics, careful work and willingness to learn any technology. 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 →
“In our final year project I wanted to build the machine learning part, but the team needed someone to write test cases and documentation. I was given that. At first I was disappointed. Then I decided to do it properly. I wrote test cases for every screen and found several bugs the others had missed, including one that lost data when a form was submitted twice. I also learned how the whole system fitted together, which helped me in the viva. The project got your result. I learned that the less popular work often teaches you the most.”
Weak answers show resentment, or say they would ask to be moved until they get the technology they want.
“During my internship I wrote a script to update student fee records from a spreadsheet. Before running it on the real data, I ran it on a copy and compared ten records by hand. Two were wrong, because some names in the sheet had extra spaces and matched the wrong student. If I had run it directly, some students would have shown the wrong balance. I fixed the matching to use the roll number and ran the comparison again. Since then I always test on a copy first and check a few records by hand. The result was your result.”
Weak answers say they rarely make mistakes, or rely fully on someone else to test their work.
“A transfer has two steps: reduce the balance of the first account and increase the balance of the second. If the system fails after the first step, money has left one account and reached nowhere. A transaction groups both steps so that either both happen or neither does. If anything fails in between, the database rolls back to the state before. When both succeed, it commits. Transactions also help when two transfers touch the same account together, because the database keeps them from reading a half-finished balance. I used this in my college banking project.”
Weak answers recite the four property names without being able to explain what happens when the transfer fails halfway.
“I would not let one bad record stop the whole file, unless the rules say the file must be perfect. The program should check each record first, such as missing fields or a wrong date format. A bad record is written to a reject file with the line number and the reason, and the program continues. At the end it prints how many records were read, updated and rejected, so someone can confirm the totals match. If rejects pass a limit, it should stop, because the whole file is probably wrong. I would read the file line by line, not load it all into memory.”
Weak answers let the program crash on the first error, or skip bad records silently with no record of them.
“The two tables are linked by customer id. I would start from the customers table and LEFT JOIN the policies table, with the condition that the policy status is active placed inside the join. Customers with no active policy will have empty policy columns, so I filter with WHERE the policy id IS NULL. The status condition must be in the join, not in the WHERE clause, or the left join behaves like an inner join. Another way is NOT EXISTS with a subquery. I would test with a customer who has only expired policies and one with none at all.”
Weak answers use an inner join, which can only return customers who do have policies.
“Development is where I write and try code, and it is fine if things break there. The testing environment is where testers and business users check the change against requirements, using data that looks like real data but does not expose real customers. Production is the live system that customers and staff depend on. If developers changed it directly, an untested change could stop a bank branch from working, and nobody would know what changed. So each change moves step by step with approvals, and there is a record. Access to production is limited to a few people for the same reason.”
Weak answers see the process as red tape, or think testing on their own laptop is enough.
“I would stop before doing anything with the data. I would not take screenshots, export it, or paste it into a ticket, even to show the problem. Then I would tell my team lead the same hour, in person or by a private message, describing what I saw without copying the values. Real customer data should not be in a test environment, and the client will want to know. I would ask for masked or generated data so testing can continue. If I was unsure whether the data was real, I would still raise it and let someone senior decide.”
Weak answers carry on testing because it is convenient, or share examples of the data in a group chat to ask about it.
“In my first job I want to learn how real systems are built and kept running, not only how to write code. TCS delivers IT services to client companies in banking, insurance, retail, travel and more, so I would see how technology supports an actual business. I understand that I may be placed on any technology, that there will be process to follow, and that some work is support and testing. I am fine with that, because each of those teaches discipline. Over a few years I want to become someone a client trusts with an important system.”
Weak answers mention only job security or the brand, or insist on one technology from the first day.
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.
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.