TCS Coding Round in 2026: NQT Pattern, Common Questions and How to Prepare

“TCS coding round” usually means one of two things: the Advanced Coding section of the TCS National Qualifier Test (NQT), or the coding questions in the technical interview that follows it. This guide covers both, starting with the test, because that’s where most people are filtered out.

One warning before the details. TCS doesn’t publish a fixed pattern, and it changes things between hiring drives. The numbers below are what candidates and placement sites report for recent drives. The instructions on your test screen are the final word, so read them properly on the day.

Where the coding round fits in TCS hiring

Freshers register on the TCS NextStep portal and take the NQT, which runs on TCS iON. The test has two parts. The Foundation part checks aptitude. The Advanced part has harder aptitude questions and the coding problems:

Pattern as reported for 2026 drives. TCS can change it between drives.

Your result decides which track you’re considered for. The salaries below are the figures commonly reported for recent batches, not numbers TCS publishes, and the cut-offs are unofficial too:

After the NQT come the interviews: a technical round, a managerial round and an HR round. Some panels combine the first two. We’ll get to the coding you can expect there later on.

What the two problems usually look like

The first problem is usually direct. The statement tells you what to compute, and the work is implementing it carefully. The second needs an idea: the obvious solution is too slow, and you have to spot the pattern that makes it fast.

Problem 1: careful implementation

• Numbers and digits: the difference between the sum of digits at odd and even positions, reversing a number, Armstrong, palindrome and perfect numbers, primes in a range, GCD and LCM. Watch for numbers with 50 or 100 digits. Those don’t fit in any integer type, so read them as a string.
• Arrays: second largest without sorting, rotating by k places, moving all zeros to the end, counting pairs with a given sum, the frequency of each element.
• Strings: counting vowels and consonants, reversing each word, checking anagrams, removing duplicate characters, compressing “aaabb” into “a3b2”.
• A story around a loop: a parking lot that charges by the hour, a bus filling its seats, a shop applying discounts. The story is long, but underneath it’s usually a loop and a few conditions. Read it twice and write down the rules before you code.

Problem 2: one good idea

• Sliding window and two pointers: the longest substring without repeating characters, the smallest subarray with a sum of at least k.
• Prefix sums and hashing: counting subarrays with a given sum, answering many range-sum queries quickly.
• Sorting plus a greedy choice: the minimum number of platforms for trains, the most tasks you can finish before their deadlines.
• Simple dynamic programming: coin change, the longest increasing subsequence, ways to climb stairs, 0/1 knapsack, the best path through a grid.
• Matrices: spiral order, rotating by 90 degrees, searching a matrix whose rows and columns are sorted.
• Now and then, a small graph: counting islands in a grid, or connected components with BFS or DFS.

The constraints tell you what the setter expects. A judge does roughly 10⁷ to 10⁸ simple operations a second. So if n can be 100,000, a double loop (10¹⁰ steps) will time out on the large hidden cases, and you need something closer to n log n. If n is at most a thousand or so, the double loop is fine. Check this before you write a line of code.

How marking works: test cases, not “accepted”

Each problem runs against a couple of sample cases you can see and several hidden ones you can’t. Candidates consistently report partial marks for the cases they pass. That changes how you should play the section:

• A brute force is worth real marks. If you can’t find the fast solution, a slow correct one still passes the small hidden cases. Never leave a problem blank.
• Edge cases are where marks go missing. Check n = 0 and n = 1, all elements equal, negative numbers, very large values, empty strings and strings with spaces.

The TCS iON editor: where good coders lose easy marks

Plenty of people who solve the problem still fail every test case because of how their program reads input or prints output. Your output is compared with the expected output exactly, character by character. The usual traps:

• Read input the way the statement says. Most problems use standard input. Some older-style problems pass the values as command-line arguments instead, and then a program waiting on standard input simply hangs. The statement tells you which one it is.
• Don’t print prompts. A line like Enter a number: is extra output, and it fails the case.
• Copy the output format from the sample: spaces, line breaks, capital letters, and no trailing space where the sample has none.
• Delete your debug prints before you submit.
• Use 64-bit integers when values can grow: long long in C and C++, long in Java. Python’s integers don’t overflow.
• Know your imports and headers by heart. Don’t count on autocomplete. Practice writing import java.util.*; or your C++ includes from memory.
• Java’s Scanner trap: after nextInt(), call nextLine() once before reading a whole line. Otherwise you get an empty string.
• Be patient with the compiler. A run can take several seconds. Wait for the result instead of clicking again and again.

If you use Python, reading every token at once avoids most input problems, because it doesn’t care whether the numbers come on one line or several:

import sys

data = sys.stdin.read().split()
n = int(data[0])
arr = list(map(int, data[1:1 + n]))

print(max(arr))

In C++, cin >> x already reads token by token, and so does Scanner.nextInt() in Java. Trouble starts when you mix token reads with whole-line reads, so pick one style per problem.

How to spend the 90 minutes

1. Read both problems first, including the constraints and the sample input. It takes five to ten minutes. Then start with the easier one.
2. Get the plumbing right. Read the sample input, print it straight back and run it. Now you know the input handling works before any logic depends on it.
3. Finish the easier problem completely: samples, your own edge cases, submit. Aim to be done within about 35 minutes.
4. On the harder one, write the brute force first and make sure it’s correct. That’s your safety net. Then look for the faster idea.
5. Stop adding ideas in the last ten minutes. Check edge cases, remove debug output, and make sure your best working version is the one that’s submitted.

A three-week plan for the coding section

Week 1: one language and the easy problems

Choose C++, Java or Python and stay with it. Switching languages in the middle of preparation costs more than any language advantage. Spend the week on input and output, strings, arrays and digit problems like the Problem 1 list above. Do three or four a day and give yourself 20 minutes for each.

Week 2: the patterns behind Problem 2

Work through two pointers, sliding window, prefix sums, hashing, sorting with greedy choices and basic dynamic programming. Two problems a day is plenty. When you get stuck for half an hour, read the solution, close it, and solve the same problem again the next day from an empty editor. The second attempt is where it sticks.

Week 3: full mock tests

Take timed 90-minute sessions with two problems, in a plain editor without autocomplete, reading from standard input, just like the real thing. Previous NQT questions on practice sites are good material, as long as you treat them as examples of the style, not a list to memorize. Questions repeat in flavour far more often than word for word.

Keep doing timed aptitude sets alongside all of this. The Foundation section is a gate: strong coding doesn’t help if you don’t clear it.

Coding in the TCS technical interview

If you clear the NQT, the technical round usually includes some coding. For Ninja it tends to be light. For Digital and Prime it goes deeper. What candidates commonly report:

• A short program written on paper, in a shared editor or just explained out loud: reverse a string, check a palindrome or a prime, Fibonacci with and without recursion, sort an array without the built-in sort, find duplicates.
• Your NQT solutions: what approach you took and what its time complexity is.
• Your chosen language: the pillars of OOP, static and final, overloading versus overriding, pointers in C, == versus .equals() in Java, lists versus tuples in Python.
• DBMS and SQL: keys, joins and normalization, plus a query or two. Finding the second-highest salary is a classic.
• Basics of operating systems and networks, on some panels.
• Your final-year project, in detail: what you built, what you personally did and why you chose your stack.
• For Digital and Prime: medium data-structure problems such as reversing a linked list, detecting a cycle or BFS on a grid, with a proper complexity analysis.

When you get a coding question in the interview, don’t go quiet and start typing. Restate the problem, give a simple approach and its complexity, improve it if you can, write the code, then walk through a small example out loud. Interviewers mark the thinking as much as the code. Our four-week tech interview plan has a routine for practicing exactly that.

The managerial round is mostly situations: teamwork, a deadline, a disagreement. The HR round covers relocation, shifts, the service agreement and your documents. Have honest answers ready for all of them. A hesitant answer on relocation is noticed.

The mistakes that cost the most

• Spending an hour on the hard problem before finishing the easy one.
• Ignoring the constraints and submitting a double loop when n can be 100,000.
• Reading the input wrongly, or printing extra text, and failing every case of a correct solution.
• Memorizing previous-year solutions instead of learning the patterns behind them.
• Skipping aptitude practice, then missing the Foundation cut-off.
• Practicing only with autocomplete and an IDE, then freezing in a plain editor.

Practicing the interview rounds with Keeter

First, the rule that matters: the NQT is a proctored test. Don’t use outside help of any kind during it, AI tools included. TCS can disqualify you, and no offer is worth that. Use AI help only where it’s allowed, and follow whatever rules TCS sets for each round.

Where an AI tool does help is practice for the interviews that follow. Keeter’s mock interview mode plays the interviewer and asks questions out loud based on your resume and the role, including technical and short coding questions. You can add notes such as your coding language and the topics to focus on. After each spoken answer you get feedback and a stronger sample answer, and at the end a report on your weak areas. The first 5 minutes are free, then it’s ₹4 a minute with no subscription.

Quick answers

How many coding questions are there in the TCS NQT?

Recent drives report two problems in about 90 minutes. Some older papers had three. Go by the instructions on your own test day.

Which language should I use?

The one you know best. C, C++, Java and Python are allowed. Python is the quickest to write and never overflows, but it runs slower, so watch your loops on large inputs. C++ and Java are faster and need more typing.

Do I get marks if I don’t solve a problem fully?

Candidates report partial marks for every test case passed. A correct but slow solution usually beats a fast one that’s wrong.

How hard is the TCS coding round?

The first problem is easy to medium. The second is medium, sometimes hard. If you can solve most easy and medium problems on a practice site within 30 to 40 minutes, you’re in good shape.