TCS NQT coding practice and submission strategy

You usually face one or two problems in a language of your choice, with a fixed window per problem. Difficulty spans easy to lower-medium, weighted towards logic and correct input/output rather than advanced algorithms.

• String manipulation palindromes, reversals, character counts, anagram checks.
• Array and number logic second largest, frequency counts, sorting-based questions.
• Pattern and series printing patterns, generating sequences.
• Basic maths prime checks, factorials, GCD, digit operations.

Crucially, TCS problems often specify exact input and output formats. A logically correct program that reads input wrongly or prints an extra space can fail every test case, so format discipline is half the battle.

Submissions are graded on hidden test cases, and partial credit for passing some cases usually exists. This shapes the optimal approach: get a correct brute-force solution passing the visible and easy cases first, then optimise only if the constraints demand it and time remains.

A half-finished elegant solution that compiles but handles no edge cases scores worse than a plain loop that passes most cases. Always test your code against the sample input before submitting, and handle the obvious edges, empty input, single element, negative numbers, that graders love to hide in the final test cases.

Because the coding weight is high, clearing this section strongly often matters more than squeezing a few extra aptitude marks.

Second largest in an array: a single pass tracking the largest and second-largest beats sorting and is easy to reason about. Watch the edge case of duplicate maximums, decide whether the second largest must be strictly smaller.

Palindrome check: compare characters from both ends inward. Read the constraints, do you ignore case and spaces? Getting that wrong fails the hidden cases even with perfect logic.

Prime check: loop only up to the square root of n, not to n, so large inputs finish inside the time limit. This is the kind of small optimisation that turns a timeout into full marks.

Frequency count: use a map or fixed-size array; print in the exact order the problem specifies.

Solve one full problem end to end every day for two weeks, writing the input parsing and output formatting yourself rather than copying boilerplate. Rotate through strings, arrays, patterns and basic maths so no category feels unfamiliar. Time each solve; your target is a clean easy problem in well under the section limit so a harder one has room.

Rehearse the submission workflow, not just the algorithm: compile, run against sample, check output character-for-character, then submit. This muscle memory prevents the format slips that quietly cost full sections.

After the online test, TCS interviews probe how you explain your code and projects. InterviewPrep's free AI voice mock interview builds a technical session from your CV and a TCS job description and scores your spoken answers, pace and filler words, so you can talk through your logic confidently in the human round.

More TCS coding submissions fail on input/output handling than on flawed logic, so treat parsing as a first-class part of every solve. Read the problem's format specification twice before writing a line: how many inputs, on how many lines, separated by spaces or newlines, and exactly what the output should look like, including whether a trailing newline or specific spacing is expected.

A frequent trap is reading input in the wrong order or type, treating a string as an integer, or missing that the first line gives the array size. Write your input-reading code deliberately and test it against the sample before touching the core logic. If the sample output does not match yours character-for-character, fix the format before assuming your algorithm is wrong.

Edge cases are the second silent killer. Graders routinely hide empty inputs, single elements, negative numbers, zeros, and duplicate values in the final test cases. Before submitting, mentally run your code on these: does a palindrome check handle an empty string, does second-largest handle duplicate maximums, does a prime check reject 0 and 1 correctly?

Finally, submit early and often if the platform allows. Getting a correct brute-force solution in that passes the visible cases banks partial or full credit and takes the pressure off. Only then refine for efficiency. This disciplined loop, parse, test on sample, handle edges, submit, optimise, converts sound logic into the passing test cases that actually earn marks, which is what the coding section rewards.

A cleared coding section on the NQT is often the decisive lift for Freshers Jobs Off Campus Drive rounds in Indian IT, since a strong percentile keeps every subsequent recruiter door open.