Live Coding Under Questioning round·Engineering·Medium·20 min

TCS Digital Engineer Interview — Live Coding Under Questioning

20 min · 1 credit · scorecard at the end
Z
ZeroPitch Research Desk
Updated 2026-06-09 · Newly added · be among the first to take it
Field
Engineering
Company
Tata Consultancy Services
Role
Digital Software Engineer Trainee
Duration
20 min
Difficulty
Medium
Completions
New
Updated
2026-06-09

What this round is about

  • Topic focus. You write classic programs like reversing a string, checking a palindrome, or the Fibonacci series on a shared screen while the interviewer questions every choice.
  • Conversation dynamic. The interviewer picks the problems live and cross-questions you mid-code: explain this line, state the complexity, handle empty input, do it without extra space.
  • What gets tested. Staying correct and articulate under questioning, narrating your reasoning, and tracing your own code before you say it works.
  • Round format. Around twenty minutes, voice plus a shared canvas, with deliberately easy problems so the pressure is the scrutiny, not the difficulty.

What strong answers look like

  • Clarify before coding. You restate the problem in one line and write a sample input with its expected output, for example hello becomes olleh, before touching the logic.
  • Narrate each line. You speak your reasoning as you write, so the interviewer can follow why each statement is there, not just what it does.
  • Trace before declaring done. You run your code by hand on the sample you wrote and confirm the output, catching boundary bugs yourself.
  • Justify the complexity. When asked, you give the correct time and space complexity and say why, for example O of N time because each character is touched once.

What weak answers look like (and how to avoid them)

  • Coding in silence. Writing without speaking leaves the interviewer guessing how you think. Narrate every line, even when stuck.
  • Skipping the sample. Jumping into a loop with no sample input means you have nothing to trace against. Write the input and expected output first.
  • Declaring done without tracing. Saying it works before running it by hand hides off-by-one and boundary bugs. Always trace the sample before claiming correctness.
  • Rewriting on a follow-up. Wiping the board when asked to optimise signals you do not understand your own code. Adjust the part that uses extra memory instead.

Pre-interview checklist (2 minutes before you start)

  • Recall the two-pointer reverse. Be ready to reverse a string in place by swapping the two ends and moving inward, not by building a new string.
  • Have a sample input habit ready. Plan to write a small input and its expected output for any program before you code.
  • Think of the palindrome trace. Be ready to check a number or string by comparing ends, and to dry-run it on a value like 585.
  • Identify your edge cases. Know what your program should return on empty input, a single character, or a negative number.
  • Re-read your complexity basics. Be able to say O of N, O of one, and O of N squared and explain which loop causes which.

How the AI behaves

  • Probes every line. It asks you to explain statements you wrote and to prove correctness by tracing, not by asserting it works.
  • No mid-interview praise. It will not say great answer or tell you whether you passed. It acknowledges what you said and pushes further.
  • Forgives syntax, not muddled logic. It does not penalise a forgotten semicolon or method name, but it pushes hard when your reasoning is unclear.
  • Throws one curveball. After a clean solution it asks you to optimise it or handle an edge case, and watches whether you adapt or restart.

Common traps in this type of round

  • The silent coder. Writing a whole function with no narration so the interviewer cannot follow the reasoning.
  • The skipped dry run. Declaring the program done without tracing a sample, then being shown a boundary bug.
  • The guessed complexity. Stating O of N because it sounds right, with no link to the loop that actually drives the cost.
  • The full rewrite. Erasing a working solution and starting over when asked a small optimise-it follow-up.
  • The frozen explanation. Going quiet when asked to explain a line you just wrote, instead of describing what it is meant to do.
  • The unchecked edge case. Not saying what the program returns on empty or negative input until the interviewer forces it.

Sample problems you'll face

The 3 problems below are the same ones you'll work through in the live session — no surprises. Read the constraints carefully; the AI persona will refer you to the on-canvas card by problem number.

  1. 1Reverse a String

    Write a function that reverses a string. Given an input string, return the same characters in the opposite order. Be ready to narrate each line, trace it on your sample, and state the time and space complexity. The interviewer may then ask you to do it without allocating any extra space.

    Example inputhello
    Example outputolleh
    • The interviewer wants the in-place approach: traverse till half the length and swap the characters from one end with the other.
    • State the time complexity as O(N) and, for the in-place version, the auxiliary space as O(1).
    • Handle the empty string and a single-character string without crashing.
    • ON THE CANVAS: write your sample input and expected output first, then write the reversal function and trace each swap by hand before you say done.
  2. 2Check a Palindrome

    Write a function that decides whether the input is a palindrome, meaning it reads the same forwards and backwards. Use the same comparing-the-two-ends idea from the reverse problem. Be ready to handle both a string and a number, and to dry-run it on the interviewer's value.

    Example input585
    Example outputYes
    • For a string, use a two pointer approach comparing characters from one end with the other in O(1) extra space.
    • For a number, reverse the digits using num % 10 to extract each digit and compare rev_num with num.
    • Say what your check does with a negative number such as minus 121 before the interviewer forces it.
    • ON THE CANVAS: trace 585 and 123 by hand through your comparison, showing each pair you check, before declaring the result.
  3. 3Print the Fibonacci Series

    Write a program that prints the first N terms of the Fibonacci series, where each term is the sum of the two before it. Narrate the loop, trace the first few terms, and be ready to state the complexity and to discuss an iterative versus a recursive version.

    Example input7
    Example output0, 1, 1, 2, 3, 5, 8
    • The iterative approach uses three variables a, b, c and runs in Time Complexity O(N) with Auxiliary Space O(1).
    • Seed the first two terms as 0 and 1 and explain why the loop starts where it does.
    • Say what the program prints for N equal to 0 or 1 before the interviewer asks.
    • ON THE CANVAS: write out the first seven terms by hand from your three variables to confirm the loop produces 0, 1, 1, 2, 3, 5, 8.

Interview framework

You will be scored on these 6 dimensions. The full rubric with definitions is below.

Sample-first Discipline
Whether you write a concrete input and expected output before coding, instead of diving straight into a loop.
20%
Think-aloud Clarity
How clearly you narrate the purpose of each line as you write, so the interviewer can follow your reasoning.
20%
Dry-run Before Done
Whether you trace your code by hand on the sample and confirm the output before you claim it works.
20%
Complexity Justification
Whether you state the correct time and space complexity and point to the loop or operation that causes it.
15%
Curveball Composure
Whether you adjust your existing code for an optimise-it or edge-case ask rather than freezing or rewriting.
15%
Edge-case Awareness
Whether you say what your program does on empty, single-character, or negative input when probed.
10%

What we evaluate

Your final scorecard breaks down across these dimensions. The full rubric and tier criteria are revealed inside the interview itself.

  • Sample-First Problem Framing18%
  • Think-Aloud Narration Quality18%
  • Dry-Run Before Completion18%
  • Complexity Reasoning Under Probe16%
  • Curveball Recalibration Response16%
  • Edge-Case Handling When Probed14%

Common questions

What does the TCS live-coding technical round actually test?
It tests whether you can stay correct and articulate while being questioned mid-code, not whether you can solve hard problems. You write a classic program like reverse a string or check a palindrome on a shared screen, and the interviewer asks you to explain the logic line by line, state the time complexity, handle empty or negative input, and sometimes do it without extra space. The programs are easy on purpose. What is graded is your composure, your habit of tracing through a sample before declaring done, and whether you understand the code you wrote or memorised a template.
How should I structure my answer when asked to write a program?
Restate the problem in one line, then write a sample input and the output you expect before you touch the logic. Write the code while narrating each line out loud so the interviewer can follow your reasoning. Before you say done, run your code by hand on the sample you wrote and confirm it produces the expected output. Then state the time and space complexity and why. This order signals discipline: clarify, narrate, trace, then claim correctness. It also catches your own boundary bugs before the interviewer points them out.
What are the most common mistakes in this round?
Staying silent while coding, so the interviewer cannot see how you think. Jumping into a loop without writing a sample input first. Declaring the solution done without tracing it on the sample, then missing an off-by-one or boundary bug. Freezing when asked to explain a line you just wrote. Guessing a complexity answer because it sounds right. And the big one: rewriting the whole program from scratch when asked to optimise it or do it without extra space, instead of adjusting what you already have. These are composure failures, not knowledge gaps.
How is the AI interviewer different from a real TCS interviewer?
It behaves like a real technical panellist and never breaks character. It asks one question at a time, waits for your full answer, and probes at least once before moving on, even on a good answer. It will not praise you mid-interview or hint at whether you passed. It does not penalise a forgotten semicolon or library name, the same way a fair human interviewer would not. The difference is that it is consistent and patient: it gives every candidate the same probing depth and produces a transcript-backed scorecard at the end naming the exact moment your explanation or dry run fell apart.
How is the round scored?
You are scored on observable behaviours from the transcript, not delivery style or accent. The dimensions include whether you take a sample input before coding, whether you narrate your logic clearly, whether you trace your code by hand before declaring done, whether you state the correct time complexity and justify it, and whether you adjust your existing approach when given an optimise-it or edge-case curveball. Each dimension has a weight and a threshold. The post-session report quotes the specific moments that earned or lost points so you know exactly what to fix.
What should I do in the first two minutes?
Listen for the exact problem and restate it in one sentence to confirm you understood it. Write a small sample input and the expected output on the canvas before you write any logic. For reverse a string, that might be the word hello mapping to olleh. This is the single highest-signal thing you can do early: it shows the interviewer you clarify before you code, and it gives you the trace target you will use later to prove correctness. Do not start typing a loop in the first thirty seconds.
How do I handle the interviewer asking me to do it without extra space?
Do not wipe the board and start over. Look at what you already wrote and ask which part allocates extra memory, like a second string or an array. For reversing a string, the move is to swap characters from the two ends moving inward on the same buffer instead of building a new reversed string. Say out loud what you are changing and why, then re-trace the same sample to confirm the in-place version still produces the expected output. Adjusting the existing approach, not rewriting, is exactly what the interviewer is testing for here.
What does a strong answer sound like in this round?
A strong candidate says something like: let me restate that, I need to reverse the characters of a string, so for hello I expect olleh. They write that sample down, then narrate: I will use two pointers, one at the start and one at the end, swap them, and move inward until they meet. After writing, they say: let me trace hello, swap h and o, then e and l, the middle l stays, that gives olleh. When asked the complexity they say O of N time because each character is touched once, and O of one extra space because the swap is in place. Calm, narrated, traced, justified.
Why are the programs so easy if this round is hard?
Because the round is not measuring algorithm difficulty. TCS uses classic must-do programs like reverse a string, palindrome, Fibonacci, factorial, prime and swap because almost every fresher has seen them. That removes the excuse of an unfamiliar problem and isolates the real signal: can you reason out loud, trace your own code, state complexity, and stay composed while being cross-questioned. A candidate who freezes on reverse a string under questioning would freeze worse on a hard problem. Easy problems make the composure signal clean.
What happens if I cannot recall exact syntax during the interview?
Say so plainly and explain the logic anyway. Interviewers in this round value conceptual clarity and honesty over memorised syntax, and a fair interviewer will acknowledge a correct explanation and move on even if you forget the exact method name or a semicolon. What hurts you is pretending, or going silent. Describe what the line is meant to do, for example I want to take the remainder of the number divided by ten to get the last digit, and keep your reasoning visible. The logic is what is being graded, not whether you remembered the library call.
Should I think aloud even when I am stuck?
Yes, especially when stuck. Silence is the most common reason candidates lose this round, because the interviewer cannot tell the difference between thinking and freezing. If you are stuck, narrate the stuck point: I know I need to compare the first and last characters, I am deciding whether to move both pointers at once. That gives the interviewer something to engage with and often earns a clarifying nudge. A visible, reasoned struggle scores far better than a long silence followed by a half-correct answer with no explanation.

Sources this interview is built on

Real candidate-report URLs (Glassdoor / AmbitionBox / PrepInsta / GeeksforGeeks / Medium) reviewed when authoring the questions, persona, and rubric. Verify the realism yourself.