Architecture Defence Under Why round·Engineering·Hard·20 min

TCS Prime Software Engineer — Architecture Defence Under Why

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
Prime Software Engineer
Duration
20 min
Difficulty
Hard
Completions
New
Updated
2026-06-09

What this round is about

  • Topic focus. You pick one project you built and defend its architecture: why this database, why this caching choice, why microservices or a monolith, and what changes at ten times the load.
  • Conversation dynamic. The interviewer is a senior delivery lead who pushes on every why, follows up before moving on, and rewards reasoning from fundamentals over framework names.
  • What gets tested. Ownership of your own contribution, the evidence behind your claims, research aptitude on an open problem, and whether you can explain one decision to a non-technical stakeholder.
  • Round format. A 20-minute managerial round with a shared whiteboard for your architecture sketch and a live tracker of the decisions you have defended.

What strong answers look like

  • Property-driven choices. You name the specific property of your data or load that drove a decision, such as the read pattern being single-key lookups, not that a tool is popular.
  • Numbers with a baseline. You quote a measured figure against what it was before, for example response time dropped from a starting point you actually observed.
  • Point at the diagram. You say which box on your sketch saturates first under load and what you would do to that box, instead of speaking in abstractions.
  • Owns the trade-off. You end a defence by naming the cost you accepted, such as slower writes for cheaper reads on a read-heavy workload.

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

  • Hiding behind we. Describing the whole project as a team effort without your own part. Say which module or layer you personally wrote.
  • Popularity as a reason. Defending a database or framework with everyone uses it or it was in the tutorial. Tie the choice to a property of your problem instead.
  • Scale with no evidence. Claiming the system handles huge load with nothing behind it. State the highest load you actually tested and how you measured it.
  • Invented numbers. Quoting an impressive figure out of nowhere. Only cite numbers you can attach a baseline and a measurement method to.

Pre-interview checklist (2 minutes before you start)

  • Pick your strongest project. Choose the one whose design you can defend deepest, and have its problem statement ready in one sentence.
  • Recall your own modules. Identify exactly which parts you personally built versus the team, so you can draw the boundary fast.
  • Have one number ready. Pull up one real measurement from your project and the baseline you compared it against.
  • Think of your weak point. Identify the one component you would not want a client to stress-test on day one, and why.
  • Prepare a plain-language line. Have a two-sentence, jargon-free way to explain one technical decision to a non-technical manager.

How the AI behaves

  • Probes every claim. It asks for the property, the baseline, or the measurement behind a statement, not the headline.
  • No mid-interview praise. It will not say great answer or validate you, because it is still evaluating, just like a real panel.
  • Redirects on abstraction. If you describe a design verbally without sketching, it pushes you to the whiteboard within the first couple of turns.
  • One fair second chance. If you stall, it simplifies the question once rather than handing you the answer.

Common traps in this type of round

  • Buzzword defence. Saying scalable, cloud-native, or microservices without the reasoning underneath.
  • The we shield. Talking about team outcomes while never naming the line you personally owned.
  • Unmeasured performance. Asserting the system is fast or handles load with no figure and no baseline.
  • No rejected alternative. Defending a choice without being able to say what you considered and why you dropped it.
  • Perfect-design claim. Insisting nothing would be redesigned, which reads as not understanding the trade-offs you made.
  • Jargon at the stakeholder. Explaining a decision to a non-technical listener in implementation detail they cannot use.

Interview framework

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

Design Trade-off Reasoning
Whether you justify choices by a property of your own data or load and name what you rejected, not by popularity.
25%
Project Ownership Clarity
How clearly you isolate the module or layer you personally built versus what the team did.
20%
Architecture Diagram Quality
Whether your whiteboard sketch shows distinct components, labeled data flow, and the bottleneck under load.
20%
Evidence And Measurement Honesty
Whether your numbers come with a baseline and a measurement method instead of bare impressive figures.
15%
Stakeholder Plain-language Explanation
Whether you can explain one decision to a non-technical sponsor in business terms without distorting it.
10%
Intellectual Honesty Under Pressure
Whether you admit gaps and reason a path to the answer rather than bluffing a confident wrong one.
10%

What we evaluate

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

  • Design Trade-off Reasoning22%
  • Project Ownership Clarity18%
  • Architecture Diagram Quality18%
  • Scale and Bottleneck Reasoning14%
  • Evidence and Measurement Honesty10%
  • Stakeholder Plain-Language Explanation10%
  • Intellectual Honesty Under Pressure8%

Common questions

What does the TCS Prime managerial round actually test?
It tests whether you can defend the architecture of your own project under repeated why questioning, rather than recite buzzwords. The panel pushes on why you chose a particular database, why a caching approach, why microservices or a monolith, and what would break at ten times the load. It also checks research aptitude, how you approach an open problem with no known answer, and whether you can explain one technical decision to a non-technical stakeholder. Honesty about what you do not know, paired with how you would find out, scores higher than confident bluffing.
How should I structure my answers in this round?
Pick one project you know cold and lead with the problem it solves and for whom, in two sentences. When you defend a decision, name the specific property of your data or load that made the choice right, not its popularity. State numbers with the baseline you measured them against. When you sketch, put boxes for components and arrows for data flow, then point at the box that fails first under load and say what you would do to it. Close each answer by naming the trade-off you accepted, so the panel sees you understood the cost of your choice.
What are the most common mistakes candidates make here?
The biggest one is describing the whole project as we and never isolating what you personally built. The second is justifying a framework or database with everyone uses it or it was in the tutorial. The third is claiming the system scales or is fast with no measurement behind it, then quoting an impressive number with no baseline. The fourth is insisting the design has no weak point. Each of these invites a harder follow-up that exposes shallow ownership, so name your contribution, your evidence, and your limits up front.
How is this AI interviewer different from a real TCS panel?
The dynamics are the same: it pushes every why, follows up before moving on, and rewards reasoning over recall. The difference is that it never gets tired, never gets personal, and gives you one fair redirect to a simpler version of a question if you stall. It will not praise you mid-interview or hint at your result, exactly like a real panel that is still evaluating. After the session you get a written scorecard, which a real interviewer would not hand you. Use it to find the one decision you could not defend with a number.
How is my performance scored in this practice round?
You are scored on the reasoning behind your design choices, the ownership of your own contribution, the evidence and numbers behind your claims, the clarity of your explanation to a non-technical listener, and your honesty about gaps with a path to the answer. The whiteboard is graded too: a vision pass checks whether your diagram shows distinct components with labeled data flow and at least one failure point with a recovery path. Applied reasoning is weighted above textbook recall, so a confident wrong answer scores below an honest, well-reasoned uncertain one.
What should I do in the first two minutes?
Decide immediately which single project you can defend most deeply and open with the problem it solves and for whom, in plain language. Do not list every project on your resume. Have your tech stack and your personal modules clear in your head. If the interviewer asks you to sketch, pull up the whiteboard within the first couple of turns rather than narrating without it. Set the frame that you own this project, because the entire round will revolve around it and your individual contribution to it.
How do I handle a why question when I genuinely do not know the answer?
Say so directly, then reason a path. For example: I did not benchmark that, but here is how I would measure it, and here is what I would expect to see and why. This scores far higher than inventing a number or defending a choice you cannot justify. The panel is testing research aptitude and intellectual honesty as much as knowledge. Admitting the edge of what you know, then showing a credible method to close the gap, is exactly the behaviour the Prime track is selecting for.
What does a strong answer in this round sound like?
It names the specific decision and the property of the problem that drove it: I chose a document store because each record was self-contained and the read pattern was by single key, so joins added no value. It points at the diagram: this cache sits here, and if it goes cold the database takes the full read load, so I added this fallback. It quotes a measured number with its baseline. And it ends by owning the trade-off: I accepted slower writes to make reads cheap, because the workload was read-heavy. That is the altitude the panel rewards.
Why does the panel keep asking about scale and 10x load?
Because the Prime track is hiring for someone who will grow into a client-facing role fast, and clients ask what happens when usage grows. The panel wants to see that you understand which part of your design is the bottleneck and can reason about it, not that you have actually run at scale as a fresher. Point at the component that saturates first, explain why, and describe the first change you would make. Reasoning about the failure point honestly matters far more than claiming your college project already handles a million users.
Should I prepare to explain my project to a non-technical person?
Yes. One part of the round checks client-facing readiness by asking you to explain a technical decision to a non-technical stakeholder. The skill is to use an everyday analogy or plain outcome language without distorting the truth: explain why a choice saves time, money, or risk, not the implementation detail. Avoid both extremes, drowning them in jargon and dumbing it into something false. Practise saying why one decision mattered to the business in two sentences a manager would repeat to their own boss correctly.
How is the Prime managerial round different from Ninja and Digital?
The opening questions look similar across all three TCS tracks, but Prime raises the difficulty and the depth of the why follow-ups, because it is offered to the top slice of the National Qualifier Test cohort. Where a lower track may accept a correct definition, Prime pushes for the reasoning, the trade-off, and the behaviour under pressure. It also leans harder on research aptitude and client-facing judgment. Expect to be asked not just what you built, but why, what you rejected, and what you would change.

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.