TCS Interview Questions and Answers

Answer

The NQT is a standardised assessment TCS uses as the entry gate for fresher hiring. Two things about it surprise candidates. First, it is a qualifier score, not just a pass mark, and the score is used to route you.

Candidates who clear the core sections are generally considered for the standard entry band, while candidates who also perform on the advanced sections are considered for the higher bands that TCS has historically marketed as Digital and Prime. Those bands differ in pay substantially, so the test is effectively a salary negotiation you conduct with a keyboard. Second, the NQT score has a shelf life and is used by other recruiters too, so a strong score is an asset beyond TCS.

What the panel is really probing when they ask you about the NQT in the interview is whether you understood the structure or just showed up. A weak answer is 'it was an aptitude test with some coding'. A strong answer names the sections you attempted, says which advanced section you took and why, and states your own assessment of where you were strong and weak.

That signals self-awareness, which the managerial round scores directly. Do not claim a score you cannot support, because your result is on their system.

Answer

The test is built around a foundation block covering numerical ability, verbal ability, and reasoning ability, with an advanced block for quantitative and coding that decides higher-band consideration. The exact section count, question count, and timings have changed across cycles, so confirm the current pattern on your admit card rather than trusting a coaching PDF from two years ago. What has stayed constant is the operating model: sections are usually individually timed, and once a section closes you cannot go back into it.

That single rule dictates your entire strategy. Budget time per question before you start, and enforce it with a hard rule, if a question has taken more than ninety seconds and you cannot see the path, mark it and move. The most common way strong candidates fail this test is not weakness, it is spending seven minutes on one number-system question and then rushing eight easy ones.

Attempt in two passes: sweep the section picking off everything you can solve confidently, then return with the remaining time for the heavy questions. In verbal, do the vocabulary and error-spotting questions first and the reading comprehension last, because comprehension is where minutes vanish. Practise on a timer at least ten full sections before test day, because pacing is a trained reflex, not a decision you can make live.

Answer

The recurring set is narrow and worth drilling to reflex: percentages, profit and loss, ratio and proportion, averages, time speed and distance, time and work, simple and compound interest, number systems including HCF, LCM and remainders, permutation and combination at a basic level, probability, mensuration, and data interpretation. The interviewer probing this later is checking whether you have quantitative comfort, because service delivery involves estimation, effort sizing, and reading client data. On the test itself, the skill being measured is not mathematics, it is arithmetic economy.

Learn the standard shortcuts: convert percentages to fractions (12.5 percent is one eighth), use the successive percentage change formula instead of computing twice, use the concept of total work as an LCM of the individual times rather than fractions, and use options to back-solve when the algebra looks long. Memorise squares to thirty, cubes to fifteen, and reciprocals to twenty. A weak preparation approach is solving a thousand random questions.

A strong one is solving two hundred and recording, for each mistake, whether it was a concept gap, a calculation slip, or a misread. Fix the category that dominates your error log, because that is where your marks actually are.

TIME AND WORK, the LCM method

A finishes a job in 12 days, B in 18 days. Together?

1. Total work = LCM(12, 18) = 36 units
2. A's rate = 36 / 12 = 3 units per day
3. B's rate = 36 / 18 = 2 units per day
4. Combined  = 5 units per day
5. Time      = 36 / 5 = 7.2 days

SUCCESSIVE PERCENTAGE CHANGE

Price up 20 percent, then down 20 percent. Net?
Net = a + b + (a * b / 100) = 20 - 20 + (20 * -20 / 100) = -4 percent

PROFIT AND LOSS shortcut
SP = CP * (100 + profit percent) / 100
Buy at 400, sell at 20 percent profit: SP = 400 * 120 / 100 = 480

Answer

Verbal ability covers reading comprehension, sentence completion, error spotting, para jumbles, synonyms and antonyms, and preposition and article usage. The losses cluster in three predictable places. First, articles and prepositions, because these are the parts of English that are learnt by exposure rather than by rule, and Indian regional English has its own settled habits that the test marks wrong.

Second, subject-verb agreement in long sentences where the subject and verb are separated by a clause. Third, reading comprehension, not because the passages are hard but because candidates read the whole passage carefully and run out of time. The fix for comprehension is to read the questions first, then scan for the answer location, and only read closely around it.

For grammar, do not study grammar in the abstract, work through error-spotting sets and write down the specific rule you broke each time, because you will find your errors repeat across only eight or ten rules. This matters beyond the test, because TCS runs a large client-facing business and communication is assessed again in the HR round. A candidate who scores well in verbal but cannot hold a two-minute spoken answer will still struggle later, so pair reading practice with speaking practice.

Answer

Reasoning is usually the most clearable section for a prepared candidate because the question types are finite. Expect seating arrangements both linear and circular, blood relations, coding and decoding, syllogisms, direction sense, series completion including number and alphabet series, statement and conclusion, and visual or figure-based pattern questions. What separates a fast solver from a slow one is diagramming discipline.

For seating arrangements, draw the frame first and fill only definite information, never a guess, and mark uncertain positions with an option list rather than committing. For blood relations, use a symbol convention you never vary, plus for male, minus for female, a horizontal line for spouse, a vertical for parent to child. For syllogisms, draw Venn diagrams and test whether a conclusion holds in every valid arrangement, not just the first one you drew, which is the single most common error.

Alphabet series questions get much faster if you have the letter positions memorised, at least the anchors, E is 5, J is 10, O is 15, T is 20, Y is 25. The interviewer is not going to ask you a syllogism later, so this section is purely a marks opportunity, and it is the cheapest section to improve in two weeks of practice.

Answer

Marking rules have differed across cycles and across sections, and TCS has historically applied negative marking to some sections and not others, so you must read the instruction screen on test day rather than assume. That said, the decision framework is the same either way. If there is no negative marking, never leave a question blank, mark something on every question before the section closes and keep the last thirty seconds free purely for that sweep.

If there is negative marking, apply elimination discipline: guess only when you have ruled out at least two options, because that converts a one-in-four gamble into a favourable one, and skip cleanly when you cannot eliminate anything. The mistake that costs the most is emotional guessing on a hard question you have already invested four minutes in, because the sunk time makes you unwilling to walk away. Decide your rule before the test and follow it mechanically. Also note that many candidates lose more marks to misreading than to guessing, particularly on questions that ask for the value that is not true or that ask for the remaining quantity rather than the used quantity, so underline what is being asked before you compute.

Answer

The advanced block is the mechanism by which TCS separates candidates for its higher service bands. Attempting and performing on it is what moves a candidate from the standard entry offer toward the Digital or Prime consideration set, and the pay gap between those bands is large enough that it dwarfs anything you could negotiate later. So the answer to should you attempt it is almost always yes, with one caveat: never sacrifice the foundation sections for it, because failing the base qualification means the advanced score is irrelevant.

The advanced quantitative questions go beyond the standard set into harder number theory, probability, and combinatorics, and the advanced coding problem is a genuine algorithmic question rather than a syntax exercise, expecting you to reason about complexity and edge cases. Prepare for it the way you would prepare for any coding round: arrays, strings, hashing, two pointers, sorting, basic recursion, and simple dynamic programming. What panels are really probing when they later ask about your advanced section attempt is your ambition and your honesty about your own level. A candidate who says 'I attempted it, solved the first problem fully and got partial cases on the second, and here is what I would fix now' reads far better than one who claims a clean sweep that the score sheet does not support.

Answer

TCS has historically hired freshers into differentiated bands, marketed at various times as Ninja for the standard entry offer, Digital for a higher band, and Prime for the top band, with the routing driven by assessment performance and the interview. The practical differences are pay, the nature of the initial project allocation, and how quickly you are put on client-facing or newer technology work. As a broad and frequently reported range, the standard entry band has sat in the region of ₹3.36 to ₹3.6 LPA, the Digital band materially higher at around ₹7 LPA, and the Prime band higher still, often quoted in the ₹9 to ₹11 LPA region.

Treat all of those as ranges that vary by year, batch, degree, and location, and never quote a figure in an interview as if it were a policy. What the panel is probing when band comes up is whether you understand that you are being sorted and whether you are realistic. A weak answer is demanding a band you did not qualify for.

A strong answer is stating which band you are being considered for, saying you would take the standard offer and work toward internal movement, and asking a factual question about how internal band movement works after joining. That reads as commitment rather than entitlement.

Answer

The coding section is a small number of problems solved in an online editor against hidden test cases, typically allowing C, C plus plus, Java, Python, and often Perl. Scoring is per test case rather than all or nothing in most cycles, which changes your strategy completely: a partially correct solution that handles the common cases is worth far more than a blank editor, so always submit something that compiles and runs. The most avoidable failure in this round is not algorithmic, it is input handling.

Many candidates lose everything because they wrote a function and never read from standard input in the exact format the problem specified, or because they printed a prompt string like 'Enter the number' which the automated checker counts as wrong output. Read the sample input and output block character by character and match it exactly, including whether the output ends with a newline and whether values are space separated or on separate lines. Second most avoidable: not handling the trivial edge cases, empty input, a single element, all elements equal, negative numbers.

Write your solution, then spend one minute walking those four cases mentally before you submit. If you have time left, do not polish, use it to test.

Answer

This is a staple of the TCS style coding round because it looks trivial and quietly tests three things: string tokenisation, whitespace handling, and whether you can do it in place when asked. The naive approach of splitting on a single space and joining in reverse works on clean input and breaks on the real test cases, which will include leading spaces, trailing spaces, and multiple spaces between words. The interviewer is probing whether you validate input assumptions or trust them.

Present the simple language-provided solution first because it is correct and readable, then say out loud that the in-place variant is the follow-up they usually want: reverse the entire character array, then reverse each word individually, which gives O(n) time and O(1) extra space. That two-step trick is worth memorising because the same idea powers the array rotation question, which is the other problem from this family. A weak answer stops at the split and join and cannot explain the space complexity. A strong answer states both approaches, names the complexities, and mentions the whitespace edge cases before the interviewer has to point them out.

# Python: simple and correct, split() collapses repeated whitespace
def reverse_words(s):
    return ' '.join(reversed(s.split()))

print(reverse_words('  the sky   is blue '))  # 'blue is sky the'


// Java: the in-place idea, reverse all then reverse each word
static void reverse(char[] a, int i, int j) {
    while (i < j) { char t = a[i]; a[i++] = a[j]; a[j--] = t; }
}

static String reverseWords(String s) {
    char[] a = s.trim().replaceAll("\\s+", " ").toCharArray();
    reverse(a, 0, a.length - 1);
    int start = 0;
    for (int i = 0; i <= a.length; i++) {
        if (i == a.length || a[i] == ' ') { reverse(a, start, i - 1); start = i + 1; }
    }
    return new String(a);
}
// Time O(n), extra space O(1) beyond the array itself

Answer

Sorting is forbidden because sorting costs O(n log n) and the problem is solvable in a single O(n) pass, so the constraint is the actual question. Track two variables, the largest and the second largest, both initialised to negative infinity rather than to zero or to the first element, because initialising to zero silently breaks on an array of all negative numbers, which is exactly the test case they include. Walk the array once.

If the current value is greater than the largest, the old largest becomes the second largest and the current becomes the largest. Otherwise if the current value is greater than the second largest and strictly less than the largest, update the second largest. That strict inequality is the second trap: with input like [5, 5, 3], a candidate who uses a non-strict comparison returns 5 as the second largest, and the interviewer will ask whether duplicates should count as distinct.

Ask that clarifying question before you code, because asking it is itself scored. If no valid second largest exists, say what you would return and why, a sentinel, an exception, or a null, rather than letting the function return garbage. A weak answer sorts and slices. A strong answer states the O(n) single pass, names both traps, and asks the duplicate question first.

def second_largest(nums):
    if len(nums) < 2:
        return None                       # state your contract explicitly
    first = second = float('-inf')
    for n in nums:
        if n > first:
            second = first
            first = n
        elif n > second and n < first:    # strict: duplicates do not count
            second = n
    return None if second == float('-inf') else second

print(second_largest([5, 5, 3]))       # 3
print(second_largest([-7, -2, -9]))    # -7, works because of -inf init
print(second_largest([4, 4, 4]))       # None

Answer

Pattern printing survives in high-volume Indian assessments because it is a cheap, unambiguous test of nested loop control, index arithmetic, and whether the candidate can produce output that matches a specification exactly. It is not a measure of talent, it is a filter for people who cannot translate a visual specification into loop bounds. The reliable method is mechanical, not intuitive.

For each row, write down three things on paper before coding: how many spaces, how many characters, and what the character is. Then express each as a function of the row index. For a pyramid of n rows with row index i starting at zero, spaces are n minus i minus 1, and stars are 2i plus 1.

Once you have those two formulas the code writes itself. The single biggest source of failure is trailing whitespace, because an automated checker compares your output byte for byte and a trailing space after the last star will fail a test that looks visually identical. Build the row into a string and print it once rather than printing character by character, and you sidestep the issue entirely. Say that reasoning aloud, because it shows you understand how the grader works.

n = 5

# Pyramid: spaces = n - i - 1, stars = 2i + 1
for i in range(n):
    print(' ' * (n - i - 1) + '*' * (2 * i + 1))

#     *
#    ***
#   *****
#  *******
# *********

# Floyd's triangle, the number variant they often pair with it
k = 1
for i in range(1, n + 1):
    row = []
    for j in range(i):
        row.append(str(k))
        k += 1
    print(' '.join(row))

Answer

Do not rewrite the algorithm. A solution passing seven of ten is almost never conceptually wrong, it is failing a category of input, and your job is to identify which category. Work through a fixed checklist in order.

Empty or single-element input. The maximum constraint size, which usually means an integer overflow in C or Java where the fix is long instead of int. Negative numbers and zero.

All elements identical. Already sorted and reverse sorted input. Input with whitespace or case variation if it is a string problem.

Time limit exceeded, which shows up as a specific verdict and means your complexity is too high, not that your logic is wrong. If the verdict is a runtime error rather than a wrong answer, look at array bounds and division by zero first. The reason this question gets asked in the interview afterwards is that TCS is a delivery business and defect triage is the actual job, so a candidate who debugs systematically is demonstrating the skill they will be paid for.

A weak answer is 'I would check my logic again', which says nothing. A strong answer names the checklist and explains that the verdict type narrows the search before you touch the code.

Answer

This is the most asked SQL question in Indian service company interviews and the panel is testing three layers. Layer one is whether you can write it at all. Layer two is whether you handle ties, because if two people both earn the highest salary, does the second highest mean the second distinct value or the second row?

Ask that before you write. Layer three is whether you handle the empty case, because a subquery approach returns NULL cleanly while a LIMIT with OFFSET approach returns no row at all, and those behave differently in application code. Give the correlated subquery version using MAX with a WHERE clause excluding the top value, because it is portable and returns NULL when there is no second salary.

Then offer the modern window function version with DENSE_RANK, and explain the difference between RANK, DENSE_RANK, and ROW_NUMBER on tied values, because that follow-up is guaranteed. DENSE_RANK gives distinct salary levels, RANK skips numbers after a tie, and ROW_NUMBER gives an arbitrary ordering among ties. A weak answer memorises one query and cannot adapt when the interviewer changes it to the Nth highest. A strong answer generalises immediately by swapping DENSE_RANK equals 2 for equals N.

-- Portable version, returns NULL when there is no second salary
SELECT MAX(salary) AS second_highest
FROM   employee
WHERE  salary < (SELECT MAX(salary) FROM employee);

-- Window function version, generalises to the Nth highest
SELECT DISTINCT salary
FROM (
  SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
  FROM   employee
) t
WHERE rnk = 2;

-- Tie behaviour on salaries 90000, 90000, 75000
-- RANK()       -> 1, 1, 3
-- DENSE_RANK() -> 1, 1, 2
-- ROW_NUMBER() -> 1, 2, 3

Answer

Name exactly one language and commit to it. This is not a modesty question, it is the panel choosing which door to open, and a candidate who says 'C, C plus plus, Java, Python, and a little JavaScript' has just invited questions in all five and will be tested on their weakest. Say one language, add one sentence on where you used it, and stop.

For example, 'Java, I have used it for the last two years including my final year project and my data structures coursework'. The follow-ups from a TCS technical panel are predictable for each language: for Java expect OOP concepts, abstract class versus interface, collections framework, string immutability, exception handling, and possibly threads at a surface level. For Python expect list versus tuple, mutable default arguments, dictionaries, list comprehensions, and OOP.

For C expect pointers, memory, structures, and string handling. Prepare depth in one language rather than shallowness in four. If you genuinely work across two, name the primary one and mention the second only as an aside.

A weak answer hedges. A strong one commits and then demonstrates by immediately grounding the language in something you built, which quietly steers the conversation toward your project where you are strongest.

Answer

The panel has heard the car and animal examples several hundred times and they signal that a candidate memorised rather than built. Ground each pillar in your project. Encapsulation is bundling state with the methods that operate on it and controlling access, so in a project you might say the payment class holds the card details as private fields and exposes only a process method, which means no other class can leave the object in a half-valid state.

Abstraction is exposing what an object does while hiding how, so a report generator interface with a generate method lets the caller work without knowing whether it writes PDF or Excel. Inheritance is reusing and specialising, a base user class with admin and student subclasses adding their own permissions, and you should immediately add the caveat that inheritance is overused and composition is usually the better default, which signals maturity. Polymorphism is one interface with many implementations, resolved either at compile time through overloading or at runtime through overriding, and you should be ready to write both.

Expect the follow-up 'give an example of runtime polymorphism from your code' straight after. A weak answer defines all four in thirty seconds and cannot produce a single line of code. A strong one gives one concrete example per pillar and volunteers the composition caveat.

Answer

Structurally, a class can implement many interfaces but extend only one abstract class, which is the constraint that usually decides the design. An abstract class can hold state, constructors, and non-public members, while an interface historically could not, though modern Java allows default and static methods and private methods inside interfaces, and Java also supports constant fields there. The real decision rule to state is about relationships.

Use an abstract class when the subtypes are genuinely the same kind of thing and share implementation, an is-a relationship with shared state, for example an abstract Vehicle holding a registration number and a common start sequence. Use an interface when you are describing a capability that unrelated types can have, a can-do relationship, for example Printable or Comparable, which a report and an invoice and a badge might all implement without being related. The trap follow-up is 'since Java 8 added default methods, why do we still need abstract classes'.

The answer is state and constructors: interfaces still cannot hold instance fields or run a constructor, so shared mutable state belongs in an abstract class. A weak answer lists syntax differences only. A strong one gives the is-a versus can-do rule and then handles the default methods follow-up without being led there.

// Abstract class: shared state plus a constructor, is-a relationship
abstract class Vehicle {
    protected final String regNumber;   // state lives here
    Vehicle(String regNumber) { this.regNumber = regNumber; }
    void start() { System.out.println(regNumber + " starting"); }
    abstract int wheels();              // subclasses must supply
}

// Interface: a capability, unrelated types can implement it
interface Printable {
    String render();
    default String header() { return "=== report ==="; }  // Java 8+
}

class Truck extends Vehicle implements Printable {
    Truck(String r) { super(r); }
    int wheels() { return 6; }
    public String render() { return "Truck " + regNumber; }
}

Answer

Panels ask this because normalisation is the one database topic where a candidate either understands the mechanism or is reciting definitions, and the difference is visible in thirty seconds. Work through an actual table rather than defining the forms. First normal form requires atomic values and no repeating groups, so a column holding 'maths, physics, chemistry' in one cell violates it and you split those into rows.

Second normal form applies only when you have a composite primary key and requires that every non-key attribute depend on the whole key, so in a table keyed on student ID plus course ID, the student name depends only on student ID and must move to a student table. Third normal form removes transitive dependency, where a non-key attribute depends on another non-key attribute, so if the table stores department ID and department head name, the head depends on the department and belongs in a department table. Then say the thing that separates a good candidate: normalisation is not free, it adds joins, and in reporting or analytics workloads you deliberately denormalise for read speed.

Naming that tradeoff shows you have thought about production rather than exams. A weak answer recites 1NF, 2NF, 3NF definitions with no example and cannot answer 'when would you not normalise'.

-- Violates 1NF: repeating group in one column
-- student_id | name  | subjects
-- 101        | Asha  | maths, physics, chemistry

-- 1NF: atomic values
CREATE TABLE enrolment (student_id INT, course_id INT, PRIMARY KEY (student_id, course_id));

-- Violates 2NF: student_name depends only on part of the composite key
-- enrolment(student_id, course_id, student_name, course_fee)

-- 2NF: split partial dependencies out
CREATE TABLE student (student_id INT PRIMARY KEY, student_name VARCHAR(80), dept_id INT);
CREATE TABLE course  (course_id  INT PRIMARY KEY, course_fee DECIMAL(10,2));

-- Violates 3NF: dept_head depends on dept_id, not on student_id
-- student(student_id, student_name, dept_id, dept_head)

-- 3NF: remove the transitive dependency
CREATE TABLE department (dept_id INT PRIMARY KEY, dept_head VARCHAR(80));

Answer

Definitions alone will not clear this. The panel usually draws two small tables and asks how many rows each join returns, which is where memorised answers collapse. INNER JOIN returns only matching pairs.

LEFT JOIN returns all left rows plus matches, with NULLs where there is no match. RIGHT JOIN is the mirror. FULL OUTER JOIN returns everything from both with NULLs on both sides, and note that MySQL does not support it directly so you emulate it with a UNION of the left and right joins, which is a good detail to volunteer.

CROSS JOIN returns the Cartesian product. SELF JOIN is a table joined to itself, typically for hierarchies such as employee and manager, and that is a common follow-up question in its own right. Two things trip people up.

First, duplicates: if the right table has three matching rows for one left row, an inner join returns three rows, not one, and this fan-out is what silently doubles totals in reports. Second, a filter on the right table placed in WHERE rather than in ON converts a LEFT JOIN into an effective INNER JOIN, because the NULL rows fail the predicate. Volunteer both of those and you have answered the follow-up before it arrives.

-- emp: 3 rows (ids 1,2,3), dept ids 10, 10, NULL
-- dept: 2 rows (ids 10, 20)

SELECT * FROM emp e INNER JOIN dept d ON e.dept_id = d.id;   -- 2 rows
SELECT * FROM emp e LEFT  JOIN dept d ON e.dept_id = d.id;   -- 3 rows (one all-NULL dept)
SELECT * FROM emp e RIGHT JOIN dept d ON e.dept_id = d.id;   -- 3 rows (dept 20 unmatched)
SELECT * FROM emp e CROSS JOIN dept d;                       -- 6 rows

-- SELF JOIN: employee to manager
SELECT e.name AS employee, m.name AS manager
FROM   emp e LEFT JOIN emp m ON e.manager_id = m.id;

-- The trap: this LEFT JOIN behaves like an INNER JOIN
SELECT * FROM emp e LEFT JOIN dept d ON e.dept_id = d.id
WHERE d.name = 'Sales';        -- unmatched rows are dropped by the WHERE

Answer

This is the highest-weight question in the technical round because it is the only part of the interview where you control the material, and panels use it to test whether the project is yours. Structure the answer in four beats and keep it under ninety seconds before pausing for questions. What problem it solved and for whom.

What you personally built, using I rather than we for your parts and being honest about the team split. The technical stack and one design decision you made along with the alternative you rejected and why. One thing that went wrong and how you fixed it.

That fourth beat is what separates candidates, because a project with no problems in it was not built. Expect the panel to drill into any technology you name, so never list a framework you cannot answer three questions about. If you used a database, expect to be asked for your schema and to justify a table design.

If you used an API, expect to be asked how you handled failures. If you claim machine learning, expect to be asked about your dataset size and your accuracy metric, and be ready to say why accuracy was or was not the right metric. A weak answer is a feature tour with no decisions in it. A strong one is a decision narrative where you can defend every choice.

Answer

The technical round is generally moderate on data structures rather than competitive-programming hard. Expect arrays, strings, linked lists, stacks, queues, hash tables, binary trees at a conceptual level, and sorting and searching algorithms with their complexities. You are far more likely to be asked to explain a structure and give a use case than to implement a red black tree.

On arrays versus linked lists, the answer the panel wants goes past the textbook line. Arrays give O(1) indexed access and are contiguous in memory, which means they benefit from cache locality and are genuinely faster to traverse even when big O says both are O(n). Linked lists give O(1) insertion and deletion once you hold the node, but finding that node is O(n), and every node carries pointer overhead.

So the real rule is that arrays win for read-heavy and index-heavy work while linked lists win when you are constantly inserting and removing in the middle and already hold a reference. The good follow-up to volunteer is that in practice most production code uses dynamic arrays such as Java ArrayList or Python lists, because amortised resizing is cheap and cache behaviour dominates. Naming cache locality is the detail that separates a memorised answer from an understood one.

Answer

Lists are mutable and tuples are immutable, which is the surface answer, and it is not enough. The consequences the panel is testing are that tuples can be dictionary keys and set members while lists cannot, that tuples are marginally lighter, and that immutability communicates intent to the reader. The mutable default argument trap is the question that actually separates candidates: a default value in a Python function signature is evaluated exactly once at definition time, not on each call, so a function defined with a list default accumulates state across calls, which produces one of the most confusing bug reports a beginner will ever file.

The fix is to default to None and create the list inside the function body. Expect the neighbouring questions too: shallow versus deep copy and why copying a nested list with slicing still shares the inner lists, the difference between is and double equals where is compares identity, and why small integers and short strings appear to break that rule because of interning. Also expect list comprehensions, dictionary methods, and generators versus lists where the answer is memory.

A weak answer gives the one-line mutable versus immutable definition. A strong answer demonstrates the default argument bug in three lines of code.

# The classic trap: default evaluated once at definition time
def add_item(item, bucket=[]):
    bucket.append(item)
    return bucket

print(add_item('a'))   # ['a']
print(add_item('b'))   # ['a', 'b']   <- the bug

def add_item_fixed(item, bucket=None):
    if bucket is None:
        bucket = []
    bucket.append(item)
    return bucket

# Tuples are hashable, lists are not
d = {(1, 2): 'ok'}          # fine
# d = {[1, 2]: 'no'}        # TypeError: unhashable type: 'list'

# Shallow copy still shares the inner lists
outer = [[1, 2], [3, 4]]
shallow = outer[:]
shallow[0].append(99)
print(outer)                # [[1, 2, 99], [3, 4]]

Answer

The depth is conceptual rather than kernel level, and the questions repeat. On operating systems: process versus thread, where the useful answer is that threads share the address space while processes do not, which is exactly why threads are cheaper and exactly why they need synchronisation. Deadlock and its four necessary conditions, mutual exclusion, hold and wait, no preemption, and circular wait, plus how you break one of them.

Paging and virtual memory at a conceptual level, and thrashing. Scheduling algorithms, at least round robin and first come first served with the idea of starvation. On networking: the OSI layers with one protocol named per layer, TCP versus UDP with the honest answer being reliability and ordering versus latency and overhead, and a real example each, file transfer against live video.

What happens when you type a URL and press enter, which is the single most asked networking question and should be answered as a chain, DNS resolution, TCP handshake, TLS handshake, HTTP request, server response, rendering. IP addressing basics, DNS, and the common HTTP status code families. Prepare one clear sentence per topic rather than paragraphs, because the panel is sampling breadth.

A weak answer is a definition with no example. A strong one attaches a concrete situation to every concept.

Answer

A primary key uniquely identifies a row, cannot be NULL, and there is exactly one per table, although it may span several columns as a composite key. A unique key also enforces uniqueness but permits NULLs, and you can have several per table, which is why the email column on a users table is typically a unique key rather than the primary key. A foreign key is a column referencing a key in another table and enforces referential integrity, meaning the database refuses to create an orphan row.

Where candidates go wrong is stopping there. The follow-ups are what matter: how many NULLs does a unique column allow, and the answer differs by engine, most permit multiple NULLs because NULL is not equal to NULL, while SQL Server permits only one. What happens on delete of a referenced parent row, and here you should name the options, RESTRICT, CASCADE, SET NULL, and NO ACTION, and say that CASCADE is convenient and dangerous because a single delete can silently remove thousands of child rows.

Whether a foreign key is automatically indexed, which it is not in every engine, and a missing index on a foreign key column is one of the most common causes of slow joins in production. Volunteering that last point puts you ahead of most candidates.

Answer

Use a bank transfer, because it makes all four visible at once. Atomicity means the debit and the credit either both happen or neither does, so if the system crashes between them the transaction rolls back and no money vanishes. Consistency means the database moves from one valid state to another and all constraints hold at commit, so a negative balance that violates a check constraint aborts the whole transaction.

Isolation means concurrent transfers do not see each other's half-finished work, and this is where the depth is, because isolation is not binary, it is a set of levels. Read uncommitted allows dirty reads, read committed prevents them but allows non-repeatable reads, repeatable read prevents those but classically allows phantom rows, and serialisable prevents all of it at a throughput cost. Name at least one anomaly per level, because that is the question the panel will actually push on.

Durability means once the commit returns, the data survives a power failure, achieved through write-ahead logging to disk. Then add the practical point: production systems rarely run at serialisable because of the concurrency cost, and most default to read committed or repeatable read, so real applications handle some anomalies in application logic. Saying that shows you have thought past the textbook.

Answer

DELETE is a DML statement that removes rows one at a time, can carry a WHERE clause, fires row-level triggers, logs each row, and can be rolled back inside a transaction. TRUNCATE is a DDL statement that removes all rows by deallocating the data pages, takes no WHERE clause, generally does not fire row triggers, is far faster on large tables, and typically resets identity or auto-increment counters. DROP is DDL that removes the table structure itself along with its data, indexes, and constraints.

On rollback, the honest answer is engine dependent and that nuance is exactly what the panel is testing: in Oracle and MySQL, DDL statements including TRUNCATE cause an implicit commit and cannot be rolled back, while in PostgreSQL and SQL Server, TRUNCATE is transactional and can be rolled back inside an explicit transaction. Saying 'it depends on the database' and then naming which is which is the answer that wins the point, because most candidates give a flat and wrong universal rule. Add the practical safety note: TRUNCATE is faster because it does not log individual rows, and that same property is why an accidental TRUNCATE on Oracle is unrecoverable without a backup. Also mention that a foreign key referencing the table will block TRUNCATE in most engines while DELETE would fail row by row instead.

Answer

This question is not conversational, it is a filter, and a hesitant answer is frequently the reason a candidate who cleared every technical round does not get the offer. TCS allocates from a pool of delivery centres across Chennai, Bengaluru, Hyderabad, Pune, Mumbai, Kolkata, Kochi, Bhubaneswar, Ahmedabad, Nagpur, Indore, and more, and the business cannot guarantee your preferred city. The strong answer is an unqualified yes followed by one sentence of substance: yes, you are willing to relocate anywhere in India, you have thought about it practically, and you would prefer a particular location if there is a choice but it is not a condition.

Never say 'yes but not the south' or 'only if it is close to home', because the panel writes that down. If you have a genuine constraint, such as caring for a parent with a medical condition, state it once, calmly, factually, and immediately follow with what you can do rather than what you cannot. Do not manufacture a fake constraint to look serious, and do not say yes while your face says no, because managerial panels are specifically trained to read that. What they are probing is whether you will accept an allocation without escalating three weeks in, which is a real and costly operational problem for them.

SAMPLE ANSWER

"Yes, I am completely open to relocating anywhere in India. I have already
discussed it at home and there is no constraint from my side. If there is a
choice I would find Chennai or Hyderabad easiest for family reasons, but that
is a preference and not a condition. Wherever I am allocated, I will move."

WHY THIS WORKS
- Unqualified yes comes first, before any nuance
- Shows you have actually discussed it, not just said yes in the room
- Names a preference without turning it into a condition
- Closes with a commitment sentence, which is what gets written down

Answer

This is the second great filter of the managerial round and the honest context is worth understanding. A large services business runs on long-lived client systems, and a meaningful share of fresher allocation goes to production support, maintenance, testing, and older technology stacks including mainframe, COBOL, and legacy ERP. Those projects fund the business and are genuinely skilled work.

The panel is checking whether you will be a retention risk in month four. The strong answer accepts the allocation without pretending to be indifferent: say yes, you will work on whatever you are allocated, and add a real reason rather than a compliant one, for example that in a support role you learn how a production system actually behaves under load and how a business uses it, which is knowledge you cannot get from a greenfield project. Then, and only then, name your interest area once as a longer-term aspiration and ask how internal movement works.

Asking that question is legitimate and reads as planning rather than resistance. A weak answer says 'I want to work only in AI and full stack', which is the single fastest way to lose an offer at this stage. Another weak answer is a flat 'anything is fine' with no reasoning, which reads as compliance rather than commitment.

Answer

Global delivery means some projects run to US or European business hours, and support projects run rosters that include nights and weekends. The panel needs to know now, not after you have been staffed. Answer yes if it is true, and answer with specifics so it does not sound like a reflex: say you understand shifts may rotate, that you are comfortable with it, and that you have thought about the practical side, commute, transport arrangements, and sleep.

If you have a genuine constraint, be straight about it and offer what you can do, for example that you can do evening overlap hours covering a European client comfortably. Do not lie here, because the cost of discovering a false yes lands on your team within weeks and it damages you more than a truthful no would have. What a strong candidate adds is the client-facing angle: overlap hours exist so that handovers with the client team happen live rather than over email, so you are not just accepting an inconvenience, you understand why it exists.

A weak answer is 'I can adjust', which is vague and reads as reluctance. Another weak one is asking about night-shift allowance in the same breath, save compensation questions for the HR round.

Answer

This is a stress question and the content of your answer matters less than your composure. The panel is deliberately applying pressure to see whether you become defensive, deflate, or hold your position calmly, because client-facing work involves being challenged by people with more authority than you. Do not argue with the score, do not blame the test, the internet connection, or your college, and do not collapse into apology.

Acknowledge it in one clean sentence, then redirect to evidence they can verify. Something like: yes, the quantitative section did not go the way I wanted and I know where I lost the marks, and then immediately give two concrete pieces of counter-evidence, the project you built and can demonstrate, the coding section you did clear, an internship, a certification you completed, or your performance in this technical round. Close by asking them to test you on something, which converts the exchange from defence into an offer.

Three things to avoid: over-explaining, which reads as anxiety, comparing yourself to other candidates, and going silent. If you genuinely do not have counter-evidence, say what you have done since and what you are doing now, because effort in progress still beats an excuse. What is being scored here is temperament under challenge, and you can lose it even with a good answer if you deliver it defensively.

SAMPLE ANSWER

"That is fair, my quantitative section was weaker than I wanted and I know
exactly which topics cost me. What I would ask you to weigh against it is the
project I built, which is running and which I can walk you through in detail,
and the coding section, which I cleared. Since the test I have been working
through a topic-wise plan for the areas I was weak in. If it is useful, please
test me on anything from the technical side and judge me on that."

WHY THIS WORKS
- Acknowledges once, no excuse, no argument with the score
- Redirects to verifiable evidence within two sentences
- Shows action taken after the fact, not just regret
- Ends by inviting a test, which converts defence into confidence

Answer

The panel is testing whether you can disagree without escalating, because service delivery is full of people who disagree and still have to ship. Use a real, small, specific conflict, not a dramatic one, and structure it as situation, what the disagreement actually was, what you did, and the outcome including what you learnt. The most common failure is choosing a conflict where you were entirely right and the other person was entirely wrong, because that answer tells the panel nothing except that you keep score.

Pick one where the other person had a legitimate point. A good shape: two of you disagreed on whether to spend the last week adding a feature or stabilising what existed, you asked what the evaluation criteria actually weighted, you both looked at it, and the answer settled the argument without either of you having to concede on ego. That shows you resolve disagreements with evidence rather than volume or hierarchy.

Avoid three things: saying you have never had a conflict, which is not believable, describing a conflict you resolved by simply doing all the work yourself, which signals you cannot delegate, and naming a teammate in a way that sounds like blame. Close with the specific thing you now do differently, because the learning line is what gets written on the scorecard.

SAMPLE ANSWER

"In our final year project two of us disagreed in the last week. I wanted to
add a dashboard feature, my teammate wanted to fix the bugs we already knew
about. Both were reasonable. Instead of arguing, I pulled up the evaluation
rubric and we saw that stability and demo reliability carried more weight than
feature count. We spent the week fixing bugs, the demo ran without a crash,
and I have used that approach since, when two people disagree, go and find the
criteria rather than debating opinions."

WHY THIS WORKS
- The other person had a legitimate point, so it is a real conflict
- Resolved with evidence, not seniority or volume
- Concrete outcome, the demo did not crash
- Ends with a transferable habit, which is what gets scored

Answer

Ninety seconds, four beats, and no life story. The panel is not gathering information, they already have your resume, they are assessing spoken fluency, structure, and confidence, and they are deciding which thread to pull next, so this answer is your chance to choose the topic of the next five minutes. Beat one: who you are academically in one line, degree, branch, college, year.

Beat two: your strongest technical grounding, named specifically, one language and one area. Beat three: one project or internship with a result, quantified if you can, and this is the thread you want them to pull. Beat four: why you are here, connecting what you have done to the role.

Common failures: starting with 'I was born in', listing every family member, listing every subject you studied, running four minutes, or reciting something obviously memorised in a flat monotone. Practise it aloud until it is fluent but not word-perfect, because a word-perfect delivery sounds rehearsed and a panel that senses recitation will interrupt you. Do not say anything you cannot defend, because every noun in this answer is a potential question. End cleanly with a full stop rather than trailing off, because a confident close is disproportionately memorable.

SAMPLE ANSWER, 90 seconds

"I am Rahul Verma, a final year Information Technology student at Pune
Institute of Technology, graduating in 2026 with 8.1 CGPA.

My strongest area is Java, along with SQL and database design, which I picked
up across coursework and two projects.

The project I am proudest of is a college transport tracking system I built
with three teammates. I owned the backend and the database. We had a problem
where the location updates were flooding the server, and I fixed it by
batching the writes, which brought the response time down noticeably and let
the app handle all forty buses instead of failing after about ten.

I am interested in TCS because I want to work on systems that real users
depend on every day, and the scale here means I would see problems I cannot
see anywhere else."

WHY THIS WORKS
- Four clean beats, under 90 seconds, no family history
- Every claim is defensible under follow-up questioning
- The project beat has a specific problem and a specific fix
- Closes with a reason that is about the work, not about the brand

Answer

The panel knows you applied broadly and is not offended by it, so do not pretend TCS is your only application. What they are testing is whether you know anything specific about the company or whether you are reciting a template that would work for any employer. The failure mode is generic praise, largest IT services company, great brand, good learning opportunities, which is what the majority of candidates say and which the panel has stopped hearing.

Build your answer from three specifics. One about the work: the scale and the range of domains, banking, retail, insurance, healthcare, telecom, which means the systems you touch are used by millions and the problem types vary across your career. One about your own path: what you want your first two years to look like and why a structured training and delivery environment fits that better than a small team where you would be alone.

One about something you actually researched, a business area, a client industry, a technology unit, or the training programme. Be honest if asked directly whether you applied elsewhere, say yes and name what would make you choose this offer. Honesty scores better than a transparently false exclusivity claim, and panels are very good at spotting the latter.

SAMPLE ANSWER

"I did apply to several companies, and I will be honest about that. The reason
TCS is where I want to start is the range. In one organisation there is
banking, retail, healthcare, and telecom work going on, so over the first few
years I get exposure to problem types I would not see in a single-product
company.

The second reason is the structured start. I know I am not going to be
productive on day one, and a company with a real training pipeline and
experienced people on the delivery floor is a better place to build my
foundation than a small team where I would mostly be guessing."

WHY THIS WORKS
- Honest about applying elsewhere, which the panel already assumed
- Two specific reasons, neither of which is generic brand praise
- Self-aware about being a fresher without being self-deprecating
- Nothing in it that a follow-up question could catch out

Answer

State it plainly in one sentence, give the true reason without a long defence, say what you did during that period, and confirm the current status. That is the whole structure, and the length of your answer is itself part of the assessment. A candidate who takes two minutes to explain a one-year gap sounds like they are hiding something even when they are not.

Eligibility rules on gaps and backlogs vary by hiring cycle and are typically stated in the job posting, and companies commonly ask that all backlogs be cleared before joining, so know your own status precisely and never misstate it, because background verification checks your academic record directly and a discrepancy found later is treated far more seriously than the gap itself. For a preparation gap, say what you were preparing for and what you learnt from it, including if it did not work out, because a candidate who can talk about a failure without shame reads as resilient. For a health or family reason, one sentence is enough and you are not obliged to give medical detail.

For backlogs, give the number, the reason, and the current cleared or pending status with a date. What the panel is scoring is not the gap, it is whether you handle an uncomfortable fact with composure.

SAMPLE ANSWER, one year gap after graduation

"I graduated in 2024 and took a year to prepare for government examinations.
I wrote two of them and did not clear either. During that year I also finished
a SQL and Java certification and built two small projects, so it was not an
empty year, but I decided in early 2025 that software delivery was where I
wanted to build my career and I have been preparing for it since. I have no
pending backlogs, all cleared in my final semester."

WHY THIS WORKS
- Plain statement of fact in the first sentence, no build-up
- Honest about not clearing the exams, no invented success
- Evidence that the time was used, which is what the panel wants
- Ends with the backlog status stated proactively

Answer

The panel is not asking for a prediction and does not believe you have one. They are checking three things: that you intend to stay long enough for the investment in you to pay off, that your ambition is compatible with how careers actually progress here, and that you have thought about your own development at all. So answer in terms of capability rather than job titles.

Say what you want to be good at, name a direction, and connect it to a path that exists inside the organisation, such as growing from a developer into someone who owns a module and mentors newer joiners, or moving toward a specialisation like data engineering, cloud, or a business domain like banking. Three answers to avoid. 'I want to be a manager in five years', which is unrealistic from a fresher start and reads as impatience with the work itself.

'I want to do an MBA' or 'I plan to prepare for higher studies', which directly signals you will leave, and while honesty matters, this is a genuine offer risk. And 'I have not thought about it', which is the worst because it says you drift. If you truly do not know your specialisation, say so and describe how you plan to find out, which is a legitimate and mature answer.

Answer

Indian IT services employers commonly attach a service agreement to fresher offers, which is a contractual commitment to remain with the employer for a stated period after joining, usually counted from your date of joining or from the completion of initial training. If you leave earlier you may be liable for a stated amount, and some agreements also involve original document retention, although that practice has been criticised and policies differ. Terms vary by year, band, and role, so never rely on what a senior told you about their batch, read your own document.

Before you sign, check these specifically: the exact duration and whether it starts from joining or from training completion, the exact payable amount and whether it reduces on a pro rata basis as you serve, what triggers the liability, whether resignation during training is treated differently, what happens if you are terminated rather than resigning, whether any original certificates are to be submitted, and the notice period stated separately from the service agreement. Ask the HR contact in writing over email rather than verbally, so you have the answer on record. In an interview, if you are asked whether you are comfortable with a service agreement, answer yes if you are, and it is entirely legitimate to add that you would like to read the terms, which is a normal and professional thing to say.

Answer

Campus and off-campus fresher offers are made against a demand forecast, and actual onboarding happens when project demand and training capacity align, which is why candidates frequently wait months between an offer letter and a joining date, sometimes considerably longer in slow demand cycles. This is normal in Indian IT services and is not by itself a sign that your offer is at risk, but it does create real decisions for you. Practically: stay reachable, keep the email address on your offer active and check it including spam, respond to every communication quickly because non-response is one of the few things that genuinely puts an offer at risk, and complete any pre-onboarding learning the company assigns, since completion is often tracked and in some cases linked to onboarding priority.

TCS has run pre-joining learning under the Xplore banner, and completing assigned modules is a low-cost way to stay in the queue in good standing. Keep preparing technically rather than going idle, because you will face internal training assessments after joining. It is also legitimate to keep interviewing elsewhere while you wait, since an unstarted offer is not employment, but be straight with yourself about the service agreement and the reputational cost of accepting and then not joining. If the wait is causing genuine financial hardship, contact HR politely and factually and ask for an indicative timeline.

Answer

New joiners typically go through a structured initial learning programme covering programming fundamentals, a technology stack, database work, and professional and communication skills, delivered over several weeks with periodic assessments. This is not a formality. Performance in training commonly influences your project allocation, and repeated failure in assessments has consequences that can include extended training, reallocation, or in serious cases termination of employment, with specifics varying by policy and year.

The practical advice for someone who has just joined is straightforward: treat training as your job rather than as an extension of college, because the failure pattern is almost always the same, candidates who have already cleared a hard selection process relax for three weeks and then find the assessment is genuinely demanding. Attend every session, complete the assignments on the day they are set rather than in a weekend catch-up, and use the trainers, because they are accessible in a way that senior people on a project later will not be. If you struggle with a topic, raise it early with your trainer rather than at the assessment, since support given proactively is normal and support requested after a failure looks different on your record. Ask what the retake policy is at the start rather than after you need it.

Answer

Background verification is usually run through a third-party agency and checks identity, address, education, prior employment, and in many cases a criminal record check. Candidates worry about the wrong things. The checks almost never fail because of a modest CGPA or a gap year that you declared honestly.

They fail because of discrepancies between what you stated and what the record says. The recurring causes are: dates of employment that do not match what your previous employer confirms, a job title inflated on your resume, a salary figure stated in the application that your payslips do not support, an employment period you left off your resume entirely, a degree year or percentage that does not match the university record, and an experience letter from a company that cannot be contacted or that does not confirm you. For freshers, the common problem is an internship claimed as employment or a certificate from an institute that cannot verify it.

Two practical rules follow. Declare everything, including short stints you would rather forget, because an omission discovered later is treated as concealment. And keep your documents ready in a single folder: mark sheets and degree certificate, offer letters, relieving letters, payslips, PAN and Aadhaar, and address proof. If you know of a genuine discrepancy, disclose it proactively to HR, because a disclosed issue is manageable and a discovered one usually is not.

Answer

Lateral hiring is demand driven rather than pool driven, which changes almost everything. There is usually no aptitude test. You are interviewed against a specific open requirement on a specific project, so the technical round goes deep on the exact stack in the job description rather than on general fundamentals, and your last two years of work matter far more than your degree.

Expect a technical round, sometimes two, a managerial round with the delivery manager who owns the position, and an HR round covering compensation and notice period. Preparation differs accordingly: rehearse a five-minute walkthrough of your current project, know your own architecture including why decisions were made, be ready to explain what you personally owned as opposed to what your team delivered, and have concrete numbers, team size, ticket volume, release cadence, or performance improvements you contributed to. On the commercial side, notice period is a live negotiating point, and if you are on a ninety day notice you should raise buyout early rather than at the offer stage, since whether buyout is supported varies by requirement and urgency.

Be precise and honest about your current fixed CTC, because verification will check payslips. A weak lateral candidate talks about their team's work in the plural. A strong one has numbers and can defend individual ownership.

Answer

Saying no is a wasted opportunity and is often noted, because it suggests either low interest or that you have not thought about the job as something you will actually do. Ask two questions, not five, and make them about the work rather than about benefits. Good options: what does the first six months look like for someone joining in this role, how are freshers allocated to projects and how much say does a candidate have, what does the initial training cover and how is it assessed, what does the team consider a strong performance in the first year, and how does internal movement between technologies work after the first project.

Each of those signals that you are planning to be there and to do well. Avoid asking about salary in the technical or managerial round, since HR owns that conversation and raising it early reads as transactional. Avoid asking anything you could have found on the company website in thirty seconds, because it demonstrates you did not look.

Avoid leave policy, work from home policy, and appraisal timing as your first question, not because they are illegitimate concerns, but because as an opening question they signal what you are optimising for. Listen properly to the answer and respond to it, since a candidate who asks a question and then does not engage with the reply looks like they were performing.