R3 Whiteboard Cut-Off round·Engineering·Easy·20 min

Zoho Software Developer Interview for ACET — R3 Whiteboard Cut-Off

Q: What does Zoho Round 3 actually test for ACET CSE and AI and DS toppers?

Round 3 is the famous Zoho cut-off round. It tests whether you can walk through your approach in plain words before writing code, hold a clean conversation about complexity and trade-offs, generalise your solution when the interviewer changes the input, and proactively name empty-input and single-element edge cases. It tests modular design discipline on bigger problems like Call Taxi Booking or the Set Get Unset Commit Rollback key-value store. It is run on paper or whiteboard, in C or C plus plus or Java, with a Zoho Senior Engineer sitting beside you for seventy-five to one hundred and eighty minutes. ACET CSE and AI and DS toppers reach this round only after clearing R1 and R2.

Q: How should an ACET candidate structure their answer to a Zoho Round 3 problem?

Start with two or three clarifying questions on input range and edge cases. Then state the approach in two or three sentences before picking up the marker. Walk one worked example out loud. State expected time and space complexity. Only then write code, narrating decisions as you go. Before you say you are done, list three test inputs including the empty input, and dry-run at least one of them. If the interviewer pushes back with a different input value, trace through the new input on the board without rewriting your code. This sequence is what Zoho R3 evaluators specifically watch for from ACET candidates.

Q: What are the most common mistakes that get ACET candidates rejected in Zoho R3?

Top failure modes reported by candidates: jumping into code without explaining the approach first; making a loop-bound off-by-one mistake on a pattern problem and failing to trace through a new input value; never writing or even mentioning a single test case; not handling the empty-input or single-element edge case; staying silent through your own coding instead of narrating; optimising for finishing speed instead of design clarity. Even strong coders from ACET fail R3 on these specific behaviours when they treat the whiteboard like a LeetCode submission rather than a design conversation.

Q: How is the AI Zoho interviewer different from a real Zoho R3 evaluator that ACET candidates face?

The AI persona Karthik Vasanth is modelled on a twelve-year Zoho Senior Engineer with mentoring tenure at both Chennai Estancia and Tenkasi. It uses the exact pushback patterns real Zoho evaluators use: what if I gave you n equals fifteen, before any code what is your approach, give me three test inputs including the empty input. It never breaks character, never says it is an AI, and never tells you what is being scored. It speaks in plain Indian English and stays on the whiteboard frame throughout. The difference from a real evaluator is that you can practise this round end to end without travelling to Estancia from Puducherry.

Q: How is scoring done in this practice session?

The session generates a transcript-backed scorecard after you finish. It measures approach-first discipline (did you state the algorithm before writing code), worked-example fluency (could you dry-run on the original input), generalisation under pushback (could you handle the new input the interviewer threw at you), edge-case proactivity (did you name empty input and single element before being asked), complexity narration (did you state big O without prompting) and module discipline on the design problem. You see which of these you cleared live during the session and which the report flagged at the end.

Q: What should an ACET candidate do in the first two minutes of the Zoho R3 round?

Before any code: ask the input-range question (what are the bounds on n), ask the edge-case question (what should the output be for n equals zero or n equals one), and ask the language question (is C plus plus acceptable). Then state the approach in two or three plain sentences. Then dry-run on one sample input out loud. Only after that pick up the marker. This sequence costs you ninety seconds and buys you the signal that this is a design conversation, not a LeetCode race. Zoho R3 explicitly rewards this opening regardless of which college the candidate is from.

Q: How do I handle the what if I gave you n equals fifteen pushback in Zoho R3?

This is the single most common Zoho R3 pushback after the candidate finishes the n equals ten worked example. The correct move is to trace through n equals fifteen on the whiteboard without rewriting your code. Use your existing loop variables. Walk row by row. If your code is correct, the trace will produce the expected output. If your trace breaks, do not panic, do not rewrite from scratch. Say out loud where the trace broke (the loop bound on row three drops one element), then patch only that line. The evaluator scores the diagnostic move, not whether your first draft was perfect.

Q: What does a strong Zoho R3 answer sound like on the whiteboard?

A strong answer narrates the approach in plain words for thirty seconds, asks for the input range, dry-runs the sample out loud, then writes code while saying things like this outer loop walks each row, this inner pointer jumps by the row index because the gap grows by one each row, here is the off-by-one I am avoiding. After coding, the candidate volunteers three test inputs including the empty input, runs at least one, and states time and space complexity without being asked. When the interviewer pushes with a new input, the candidate traces through it on the board without rewriting. This is the bar Zoho R3 evaluators rate as exceptional.

Q: What is the difference between Zoho R3 and the IT-services technical interview at TCS or Infosys that ACET candidates face?

TCS, Infosys, Wipro and Cognizant volume-hire rounds are shorter (twenty to forty minutes), softer on design depth, and pay 3.5 to 4.5 LPA at the fresher level. Zoho R3 is seventy-five to one hundred and eighty minutes on a whiteboard with no IDE, in C or C plus plus or Java only, and feeds into a 6 to 18 LPA offer band across Project Trainee, Software Developer, MTS and Schools of Learning tiers. The conversational pushback, the approach-first rule, the modular design discipline on Call Taxi and Railway Reservation problems, and the no-library-call expectation are all unique to Zoho versus the IT-services giants and represent a meaningful jump from the ACET 2.75 LPA campus average.

Q: Is Python allowed in Zoho Round 3?

No. Round 3 at Zoho is conducted in C, C plus plus or Java only. Python is generally not accepted. Plan your whiteboard syntax accordingly. This matters because some pattern-printing and string-manipulation problems are markedly more verbose in C without StringBuilder or list comprehensions. Practise in the language you will actually write on the board, and be ready to explain pointer or memory choices in C, or object boundaries in Java, when the interviewer asks. If you only know Python from your ACET AI and DS curriculum, focus your remaining prep time on porting your three strongest DSA solutions into C plus plus or Java.

20 min · 1 credit · scorecard at the end

ZeroPitch Research Desk

Updated 2026-05-27 · Newly added · be among the first to take it

Field: Engineering
Company: Zoho
Role: Software Developer
Duration: 20 min
Difficulty: Easy
Completions: New
Updated: 2026-05-27

What this round is about

Topic focus. Three canvas problems back to back: a diagonal pattern-printing problem, an in-place string expansion problem, and the Set Get Unset Count Begin Commit Rollback key-value store that mirrors how Zoho Catalyst datastore behaves. ACET CSE and AI and DS toppers reaching R3 face this exact mix.
Conversation dynamic. The Senior Engineer will refuse to let you write any code until you have stated the approach in plain words, asked your clarifying questions, and dry-run a sample on the canvas.
Round format. Seventy-five minutes on the canvas (live AI practice mode), in C or C plus plus or Java only. No IDE, no compiler, no internet. The interviewer is sitting beside you the whole time.
What gets tested. Approach-first discipline, generalisation when the interviewer changes the input value mid-problem, proactive naming of empty and single-element edge cases, narration of time and space complexity without being asked, and modular design on the key-value store.
What you control. You pick the language (C, C plus plus, or Java) and the order of attempting the three problems. The diagonal-pattern problem is the warm-up, the in-place string expansion is the structural test, and the Set Get Unset Commit Rollback datastore is the architectural close. Starting strong on problem one buys runway on problem three.

What strong answers look like

Approach in plain words first. Thirty seconds of here is what I am going to do, here is the outer loop, here is why the inner increment grows by row index before you start sketching.
Clarifying questions on input bounds. What is the maximum value of n. Can n be zero. Can the input string be empty. What if the digit after a character is zero. Two or three of these before any code.
Dry-run on the worked example out loud. Trace n equals ten on the canvas, name each row's starting number and gap, only then write the loops.
Generalisation under pushback. When the interviewer says what if I gave you n equals fifteen, you trace through the new input on the canvas without rewriting your code, and you say out loud where the new input lands.
Time and space complexity narrated unprompted. Sounds like: this is O of n squared time because the outer loop runs n times and each row prints up to n numbers, and O of one extra space since I print as I go. The Senior Engineer rewards candidates who state complexity before being asked.

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

Jumping straight to code. Picking up the cursor before saying a word about the approach. Mitigation: physically put the cursor down until you have said three sentences.
One-input fluency. Tracing n equals ten cleanly then freezing on n equals fifteen. Mitigation: always trace at least two values of the parameter before claiming the algorithm is general.
Silent coding. Going quiet for two minutes while writing. Mitigation: narrate the loop you are about to write before you write it, even if it slows you down.
No test cases. Saying I am done without listing test inputs. Mitigation: before declaring done, write three test inputs on the canvas including the empty input.
Memorising one input and failing on the next. Tracing n equals ten cleanly then blanking when the interviewer changes the parameter to fifteen. Mitigation: never claim the algorithm is general until you have traced it on at least two values of the input on the canvas, pick one small and one larger value before declaring done.

Pre-interview checklist (2 minutes before you start)

Recall your approach-first phrase. Have a ready opener like before I write any code, let me state the approach so you do not blank under pressure.
Have three clarifying questions ready. Input range, empty input behaviour, allowed language. Use one or two of these in the first minute.
Think of two test inputs per problem type. A normal case and one edge case (empty, single, max). You will need these to dry-run before declaring done.
Identify your weakest data structure. If you are shaky on stacks or hashmaps, decide now whether you will solve infix-to-postfix or frequency-sort if it comes up, and which approach you will use.
Pull up the Zoho Catalyst datastore mental model. Set, Get, Unset, Count, Begin, Commit, Rollback. The transaction stack is the only non-obvious part. Have a one-line picture in your head before you walk in.
Re-read your last three pattern-printing solutions. Loop bounds are the single biggest source of off-by-one rejections in Zoho R3.

How the AI behaves

Probes every claim. Asks for the underlying loop logic, not the headline algorithm name. If you say merge sort, the next question is why that and not quick sort here.
No mid-interview praise. Will not say great answer or perfect or strong attempt. Will acknowledge specifically what you did, then push deeper.
Interrupts on code-before-approach. If you reach for the cursor before stating the approach, the Senior Engineer says stop, tell me the approach first.
Pushes back with what if I gave you input X. After every worked example, expect a new input value and a request to trace it on the canvas without rewriting.
Rejects done without a dry-run. If you say I am done without writing three test inputs on the canvas, including an edge case like empty or single-element, Karthik asks you to dry-run before moving on.

Common traps in this type of round

Loop-bound off-by-one on the diagonal pattern. Treating the last row as length one when it should be a single starting number with no gap. The trace on n equals fifteen exposes this.
String expansion with library calls. Reaching for split or replace when the rule is in-place, no built-in functions. Plan the character-and-digit pointer pair before coding.
Commit case treated as no-op. Implementing Set Get Unset cleanly then leaving Commit as just discard the rollback stack. The interviewer always asks for the commit-case optimisation and expects you to talk about nested transactions.
Silence under pushback. Going quiet when asked what if I gave you n equals fifteen. The evaluator scores the diagnostic narration, not whether your first draft was right.
Treating the canvas as final code. Refusing to cross out and patch. Saying done before listing test inputs. The canvas is a first draft; the conversation is the artifact.
Optimising for finishing speed. Racing through all three problems with no narration. Evaluators have rejected candidates who finished early but could not explain why their solution was correct.

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.

1Diagonal Descending Pattern
Given an integer n, print a diagonal descending pattern of numbers from 1 up to n. Each row contains a descending diagonal of values.
Example inputn = 10
Example outputRow 1: 1, 3, 6, 10 Row 2: 2, 5, 9 Row 3: 4, 8 Row 4: 7
- 1 <= n <= 50
- No external libraries. Loops, arrays only.
- Use the canvas to sketch your logic, draw, write pseudocode, or freehand whatever helps you think. The AI sees what you draw.
2In-Place String Expansion
Take a string where each character is followed by a digit specifying how many times to repeat that character, and produce the expanded string. No split, replace, or built-in expansion library calls.
Example inputa1b2c3
Example outputabbccc
- Input alternates character then digit, always paired.
- Digit is single-digit, 1 to 9.
- Solve with a character-and-digit pointer pair, not regex or library helpers.
3Key-Value Store with Nested Transactions
Design a key-value store supporting Set, Get, Unset, Count, Begin, Commit, and Rollback. Begin starts a transaction. Rollback undoes everything since the most recent Begin. Commit merges everything since the most recent Begin into the parent scope. Nested Begins must be supported.
Example inputSET a 10 / GET a / BEGIN / SET a 20 / GET a / ROLLBACK / GET a
Example output10 / (sets) / 20 / 10
- Operations: SET key value, GET key, UNSET key, COUNT value, BEGIN, COMMIT, ROLLBACK.
- Nested Begins: Commit folds into parent scope, not into global.
- Count returns the number of keys whose current value equals the argument.

Interview framework

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

Approach-first Whiteboard Discipline

How consistently the candidate states the algorithm in plain words and asks clarifying questions before writing any code on the whiteboard, every problem.

22%

Generalisation Under Input Pushback

How cleanly the candidate traces a new input value through their existing code without rewriting when the interviewer changes the parameter.

20%

Edge Case Proactivity

Whether the candidate volunteers the empty-input, single-element, and digit-equals-zero cases before the interviewer prompts them.

16%

Big O Narration And Defence

Whether the candidate states time and space complexity unprompted and defends the number when the interviewer pushes back on nested loops.

14%

Modular Design On Commit Rollback Store

Quality of the key-value store design, especially the nested-Begin Commit and Rollback semantics that mirror Zoho Catalyst datastore behaviour.

16%

Reflective Self-awareness On Close

Whether the candidate can name a specific moment they would do differently rather than claiming the round went perfectly.

12%

What we evaluate

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

Zoho R3 Approach-First Whiteboard Discipline22%
Generalisation Under Input Pushback20%
Edge Case Proactivity (Empty, Single, Digit-Zero)16%
Big O Narration and Defence14%
Modular Design on Commit Rollback Key-Value Store16%
Reflective Self-Awareness on Round Close12%

Common questions

What does Zoho Round 3 actually test for ACET CSE and AI and DS toppers?

Round 3 is the famous Zoho cut-off round. It tests whether you can walk through your approach in plain words before writing code, hold a clean conversation about complexity and trade-offs, generalise your solution when the interviewer changes the input, and proactively name empty-input and single-element edge cases. It tests modular design discipline on bigger problems like Call Taxi Booking or the Set Get Unset Commit Rollback key-value store. It is run on paper or whiteboard, in C or C plus plus or Java, with a Zoho Senior Engineer sitting beside you for seventy-five to one hundred and eighty minutes. ACET CSE and AI and DS toppers reach this round only after clearing R1 and R2.

How should an ACET candidate structure their answer to a Zoho Round 3 problem?

Start with two or three clarifying questions on input range and edge cases. Then state the approach in two or three sentences before picking up the marker. Walk one worked example out loud. State expected time and space complexity. Only then write code, narrating decisions as you go. Before you say you are done, list three test inputs including the empty input, and dry-run at least one of them. If the interviewer pushes back with a different input value, trace through the new input on the board without rewriting your code. This sequence is what Zoho R3 evaluators specifically watch for from ACET candidates.

What are the most common mistakes that get ACET candidates rejected in Zoho R3?

Top failure modes reported by candidates: jumping into code without explaining the approach first; making a loop-bound off-by-one mistake on a pattern problem and failing to trace through a new input value; never writing or even mentioning a single test case; not handling the empty-input or single-element edge case; staying silent through your own coding instead of narrating; optimising for finishing speed instead of design clarity. Even strong coders from ACET fail R3 on these specific behaviours when they treat the whiteboard like a LeetCode submission rather than a design conversation.

How is the AI Zoho interviewer different from a real Zoho R3 evaluator that ACET candidates face?

The AI persona Karthik Vasanth is modelled on a twelve-year Zoho Senior Engineer with mentoring tenure at both Chennai Estancia and Tenkasi. It uses the exact pushback patterns real Zoho evaluators use: what if I gave you n equals fifteen, before any code what is your approach, give me three test inputs including the empty input. It never breaks character, never says it is an AI, and never tells you what is being scored. It speaks in plain Indian English and stays on the whiteboard frame throughout. The difference from a real evaluator is that you can practise this round end to end without travelling to Estancia from Puducherry.

How is scoring done in this practice session?

The session generates a transcript-backed scorecard after you finish. It measures approach-first discipline (did you state the algorithm before writing code), worked-example fluency (could you dry-run on the original input), generalisation under pushback (could you handle the new input the interviewer threw at you), edge-case proactivity (did you name empty input and single element before being asked), complexity narration (did you state big O without prompting) and module discipline on the design problem. You see which of these you cleared live during the session and which the report flagged at the end.

What should an ACET candidate do in the first two minutes of the Zoho R3 round?

Before any code: ask the input-range question (what are the bounds on n), ask the edge-case question (what should the output be for n equals zero or n equals one), and ask the language question (is C plus plus acceptable). Then state the approach in two or three plain sentences. Then dry-run on one sample input out loud. Only after that pick up the marker. This sequence costs you ninety seconds and buys you the signal that this is a design conversation, not a LeetCode race. Zoho R3 explicitly rewards this opening regardless of which college the candidate is from.

How do I handle the what if I gave you n equals fifteen pushback in Zoho R3?

This is the single most common Zoho R3 pushback after the candidate finishes the n equals ten worked example. The correct move is to trace through n equals fifteen on the whiteboard without rewriting your code. Use your existing loop variables. Walk row by row. If your code is correct, the trace will produce the expected output. If your trace breaks, do not panic, do not rewrite from scratch. Say out loud where the trace broke (the loop bound on row three drops one element), then patch only that line. The evaluator scores the diagnostic move, not whether your first draft was perfect.

What does a strong Zoho R3 answer sound like on the whiteboard?

A strong answer narrates the approach in plain words for thirty seconds, asks for the input range, dry-runs the sample out loud, then writes code while saying things like this outer loop walks each row, this inner pointer jumps by the row index because the gap grows by one each row, here is the off-by-one I am avoiding. After coding, the candidate volunteers three test inputs including the empty input, runs at least one, and states time and space complexity without being asked. When the interviewer pushes with a new input, the candidate traces through it on the board without rewriting. This is the bar Zoho R3 evaluators rate as exceptional.

What is the difference between Zoho R3 and the IT-services technical interview at TCS or Infosys that ACET candidates face?

TCS, Infosys, Wipro and Cognizant volume-hire rounds are shorter (twenty to forty minutes), softer on design depth, and pay 3.5 to 4.5 LPA at the fresher level. Zoho R3 is seventy-five to one hundred and eighty minutes on a whiteboard with no IDE, in C or C plus plus or Java only, and feeds into a 6 to 18 LPA offer band across Project Trainee, Software Developer, MTS and Schools of Learning tiers. The conversational pushback, the approach-first rule, the modular design discipline on Call Taxi and Railway Reservation problems, and the no-library-call expectation are all unique to Zoho versus the IT-services giants and represent a meaningful jump from the ACET 2.75 LPA campus average.

Is Python allowed in Zoho Round 3?

No. Round 3 at Zoho is conducted in C, C plus plus or Java only. Python is generally not accepted. Plan your whiteboard syntax accordingly. This matters because some pattern-printing and string-manipulation problems are markedly more verbose in C without StringBuilder or list comprehensions. Practise in the language you will actually write on the board, and be ready to explain pointer or memory choices in C, or object boundaries in Java, when the interviewer asks. If you only know Python from your ACET AI and DS curriculum, focus your remaining prep time on porting your three strongest DSA solutions into C plus plus or Java.

What does Zoho pay ACET Puducherry candidates if they clear R3 and the rest of the loop?

Standard Software Developer offers range from 4.5 to 7 LPA. Member Technical Staff (MTS) is around 6.6 LPA. Pre-placement offers and Schools of Learning premium-batch hires can reach 12 to 18 LPA for top performers. ACET historically sees a small number of Zoho hires each year and the offer band lands meaningfully above the ACET 2.75 LPA campus average. Salary lands on which side of this spread based on R3 conversation quality and tech-HR fit, not on raw R3 lines of code. Clearing R3 strongly is the single biggest lever on the offered band for any ACET candidate.

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.