Zoho Software Engineer — Interview Questions

Q: A large enterprise customer reports that their most-used dashboard now takes 47 seconds to load. It took 3 seconds six months ago. The underlying table has grown from 2 million to 28 million rows. The report runs a query with 4 JOINs, 3 subqueries, and GROUP BY across 6 columns on a PostgreSQL instance. You have access to the production database, the query execution plan, and the table schema. Walk through your diagnostic approach, what you look for first, and the most likely root causes given the growth pattern.

My first action is EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) on the exact query. I want actual row counts (not estimates) and buffer hit/miss rates at every node. Key red flags to look for: Sequential scans on large tables: If I see Seq Scan on sales_transactions (rows=28000000) , the planner isn't using an index. Either the index doesn't exist, or the planner's statistics are stale — it still thinks the table has 2M rows and estimates a sequential scan is cheaper. Check: SELECT reltuples FROM pg_

Zoho Software Engineer Interview Questions

Zoho's software engineering interviews are among the most rigorous in India's product ecosystem — and deliberately so. The company builds more than 50 products entirely in-house, runs its own data centres without public cloud providers, and expects engineers to write code they'd be comfortable maintaining five years from now. Unlike services firms that test algorithmic puzzle-solving in isolation, Zoho evaluates whether you can think like an engineer who owns a product end-to-end: from choosing the right data structure to debugging a production incident on infrastructure you personally manage. This guide covers all five rounds with the depth required to distinguish yourself at each stage.

Zoho's Interview Process for Software Engineer

Five rounds, typically conducted in a single day at a Zoho office (Chennai, Coimbatore, Hyderabad, or Pune). Round 1 — Written Test (~90 min): Pen-and-paper aptitude plus CS fundamentals (data structures, OS concepts, DBMS, networking basics). Eliminates roughly 60% of walk-in candidates. Round 2 — Basic Programming (~60 min): 2–3 coding problems solved on paper or a basic terminal; expects clean, compilable code in C, C++, Java, or Python. Round 3 — Advanced Programming (~90 min): 1–2 harder problems plus a system design or architecture discussion; interviewers probe reasoning at every step, not just final output. Round 4 — Technical HR (~60 min): Deep dive on past projects, CS fundamentals, and a design or optimisation question anchored in Zoho's product context. Round 5 — General HR (~30 min): Culture fit, career goals, and questions that test whether you've actually used and thought about Zoho's products. Offers are typically made the same day after Round 5.

Question 1: Designing a Contact Deduplication Service at Scale

Zoho CRM's contact database has grown to 50 million records across 500,000 customer accounts. Duplicate contacts have accumulated over time — some are exact duplicates (same email, different entry dates), others are near-duplicates (same person with a different phone number or slightly different name spelling). You've been asked to build a background deduplication service. Requirements: it must run without locking the production database; it must be recoverable (a crash mid-run should not re-merge already-processed records); it must route uncertain matches to a human review queue rather than auto-merging; and it must handle transitive duplicates (if A matches B and B matches C, all three should merge). Walk through your data structures, algorithm, and recovery mechanism.

Why interviewers ask this

Duplicate contact management is one of the most-reported issues in Zoho CRM's enterprise support queue — this is a real problem the team has solved. The question tests three layers simultaneously: data structure choice (inverted index, Union-Find, LSH), algorithmic correctness (transitive duplicates, false positive control), and systems thinking (idempotent processing, crash recovery). Weak candidates jump to "hash map on email" and miss both the transitive duplicate problem and the recovery requirement. Strong candidates ask about false positive tolerance before choosing an algorithm, then design the recovery mechanism before writing pseudocode.

Example strong answer

Before designing anything, I'd clarify the false positive tolerance. Auto-merging two contacts who are actually different people is a data integrity failure — far worse than leaving a duplicate in place. I'd set a strict confidence threshold (auto-merge only above 0.95) and route everything between 0.70 and 0.95 to a human review queue.

Layer 1 — Candidate pair generation without O(n²) comparisons

For exact matches (same normalised email or phone), build an inverted index: a hash map from normalised email → list of contact IDs. Normalisation matters: lowercase, strip whitespace, map googlemail.com to gmail.com. This runs in O(n) and catches roughly 65–70% of duplicates immediately.

For near-duplicates (name variations, missing fields), comparing all 50M × 50M pairs is infeasible. Instead, apply locality-sensitive hashing (LSH) on each contact's name and company tokens. LSH groups records with similar strings into the same buckets with high probability, reducing the candidate pair space from O(n²) to O(n log n). This catches cases like "Priya Sharma" versus "P. Sharma at Infosys Mumbai."

Layer 2 — Similarity scoring

For each candidate pair, compute a composite score:

Email: exact match = 1.0, same domain only = 0.2

Name: Jaro-Winkler distance (handles transpositions and abbreviations better than Levenshtein for names)

Phone: normalise to E.164 format first, then exact match

Company: fuzzy match after stripping suffixes (Ltd, Pvt, Inc, Corp)

Email is the strongest signal. If two records share a normalised email, confidence is already above 0.95 and they auto-merge. Everything else requires combined signal.

Layer 3 — Union-Find for transitive duplicates

The key insight: duplicates are transitive. If A matches B and B matches C, all three belong in one merged record even if A and C never directly matched. Union-Find (Disjoint Set Union) handles this in O(α(n)) ≈ O(1) amortised per merge. At the end of each account's processing, each Union-Find tree root represents the "surviving" contact; all others point to it and get archived.

Recovery mechanism

Before processing each account, write a row to a dedup_runs table: {account_id, status: IN_PROGRESS, started_at}. After completing an account, update to COMPLETED. On service startup, skip all COMPLETED accounts and retry IN_PROGRESS ones from scratch. This gives exactly-once processing at the account level without distributed locks.

The human review queue writes candidate pairs to a dedup_review table. A CRM UI surface lets account owners accept or reject each suggestion; accepted merges fire a ContactsMerged audit event.

At this complexity, the service processes roughly 50,000 accounts per hour — a full scan of 500,000 accounts completes in 10 hours, well within an overnight batch window.

Follow-up questions

"After deploying the service, an enterprise customer reports that 200 of their key contacts were incorrectly auto-merged and their data is corrupted. The contacts were archived two weeks ago. How do you recover?"

"Your LSH buckets are generating too many false positive candidate pairs — the human review queue has 2 million unreviewed records. How do you reduce queue depth without missing real duplicates?"

Question 2: Atomic Upgrades Across Zoho's Billing and Subscription Services

When a Zoho CRM customer upgrades from the Free tier to the Professional plan (₹1,299/user/month), three things must happen atomically: the billing service creates an invoice and charges the card; the subscription service upgrades the account's feature tier; and a compliance event is written to the audit log. These are three separate microservices. If payment succeeds but the subscription upgrade fails, the customer is charged but still sees Free features. If the subscription upgrades but payment fails, Zoho gives away a paid plan. Design a system that ensures all three steps succeed together — or none of them do — without using distributed locks or two-phase commit. How do you handle a crash mid-way through?

Why interviewers ask this

This is a direct simulation of a problem Zoho's platform team has solved in production. It tests distributed systems maturity — specifically whether the candidate knows why 2PC breaks under failure and whether they understand the Saga pattern as the production-grade alternative. Weak candidates propose synchronous chained API calls (no atomicity) or reach for 2PC (correct concept, operationally fragile). Strong candidates recognise that true distributed atomicity requires accepting eventual consistency, and they design compensating transactions before writing any code.

Example strong answer

I'd solve this with an orchestrated Saga pattern combined with the Transactional Outbox pattern.

Why not 2PC? Two-phase commit holds locks across all three services while the coordinator waits for "prepared" confirmations. If the coordinator crashes after receiving all confirmations but before sending "commit," all three services are stuck in an uncertain locked state. At Zoho's upgrade volume, that fragility is unacceptable.

The Saga design: Break the upgrade into a sequence of local transactions, each paired with a compensating transaction:

Billing — create invoice (status = PENDING). Compensating: mark invoice CANCELLED.

Payment gateway — charge card. Compensating: issue refund.

Subscription — upgrade tier (status = ACTIVE). Compensating: revert tier to FREE.

Audit log — write compliance event. (Append-only, no compensation needed.)

An orchestrator service drives these steps in sequence, triggering the next step on success or initiating the compensation chain in reverse on failure.

The Outbox pattern for reliable event publishing: After the billing service commits the invoice record to its DB, how do we guarantee the InvoiceCreated event reaches the message broker? A network failure between DB commit and broker publish leaves a committed invoice with no event — the Saga never progresses.

Solution: write both the invoice record and a row in an outbox table in the same local DB transaction. A lightweight outbox poller reads unpublished rows and publishes them to the broker, then marks them published. The DB transaction guarantees both rows appear together or not at all. This gives at-least-once delivery, so every downstream step must be idempotent — use {saga_id}_{step_id} as an idempotency key to detect replayed events.

Crash recovery: Each Saga's state machine is persisted in the orchestrator's database. On restart, the orchestrator reads all in-flight Sagas and resumes from where they left off — retrying a step or triggering compensation. Because every step is idempotent, retrying a completed step is safe.

If payment fails at step 2, compensation runs steps 2c → 1c. The customer sees "Payment failed, no changes made" — tier stays Free, no invoice exists. The whole compensation chain completes in under 500ms.

Follow-up questions

"Your Saga orchestrator crashes while processing 5,000 simultaneous upgrades during a flash sale. When it restarts, how do you determine which Sagas need compensation vs. which just need to resume?"

"The payment gateway confirms success but the HTTP response is lost in transit — the billing service never receives it. How does your design ensure the customer isn't charged twice when the service retries?"

Question 3: Optimising a Critical Query in Zoho Analytics

A large enterprise customer reports that their most-used dashboard now takes 47 seconds to load. It took 3 seconds six months ago. The underlying table has grown from 2 million to 28 million rows. The report runs a query with 4 JOINs, 3 subqueries, and GROUP BY across 6 columns on a PostgreSQL instance. You have access to the production database, the query execution plan, and the table schema. Walk through your diagnostic approach, what you look for first, and the most likely root causes given the growth pattern.

Why interviewers ask this

Database performance is a daily reality at Zoho Analytics — query latency directly affects customer retention. This question tests whether a candidate can diagnose systematically rather than guess, and whether they understand how databases execute queries at scale. Weak candidates immediately suggest "add more indexes" without diagnosing the root cause. Strong candidates run EXPLAIN ANALYZE, read the execution plan, identify the specific bottleneck, and propose a targeted fix.

Example strong answer

My first action is EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) on the exact query. I want actual row counts (not estimates) and buffer hit/miss rates at every node. Key red flags to look for:

Sequential scans on large tables: If I see Seq Scan on sales_transactions (rows=28000000), the planner isn't using an index. Either the index doesn't exist, or the planner's statistics are stale — it still thinks the table has 2M rows and estimates a sequential scan is cheaper. Check: SELECT reltuples FROM pg_class WHERE relname = 'sales_transactions'. If it shows ~2M, statistics haven't been refreshed. Fix: ANALYZE sales_transactions;.

Hash join spilling to disk: If work_mem is too low for the hash table, PostgreSQL spills to disk. Look for Batches: N where N > 1 in a Hash Join node. Fix: SET work_mem = '256MB' for the session and re-run.

Subquery materialisation: Three subqueries each scanning large tables and getting materialised into temporary results compound the problem. Check whether any can be rewritten as window functions or pushed into CTEs that the planner can optimise.

Most likely root cause given 14× row growth: Stale planner statistics combined with missing composite indexes on the GROUP BY and JOIN columns. At 2M rows, autovacuum keeps statistics fresh. At 28M rows with high write volume, autovacuum may not keep up.

Fix sequence:

ANALYZE sales_transactions; — rerun query. If it drops below 10s, statistics were the issue.

If still slow: create a composite index on the highest-selectivity filter columns: CREATE INDEX CONCURRENTLY idx_sales_account_date ON sales_transactions(account_id, created_at) WHERE deleted_at IS NULL. The partial index skips deleted rows entirely.

If the GROUP BY across 6 columns is the bottleneck: add a materialised view pre-aggregating common dimensions, refreshed every 15 minutes.

Long-term: partition the table by created_at (monthly). Queries with date range filters scan only relevant partitions.

The fix for this case is almost certainly: ANALYZE, one composite index, and a work_mem increase. That typically brings a 47-second query on 28M rows to under 2 seconds.

Follow-up questions

"After adding the composite index, the query drops from 47s to 4s. The customer wants under 1s. What are your options?"

"Six weeks after your fix, the query is slow again — 35 seconds, 35M rows. What's happening and how do you build a more permanent solution?"

Question 4: Building a CI/CD Pipeline Without Cloud Managed Services

Zoho runs its own data centres and does not use AWS, GCP, or Azure. Your team must design a CI/CD pipeline for a new product that will serve 10 million users. You have bare-metal servers, a private network, and standard Linux tooling. No managed services — no EKS, no CloudBuild, no RDS. Design the full pipeline from a developer pushing to a feature branch through testing, staging, and production deployment. How do you handle rollbacks, zero-downtime deployments, and secrets management without cloud-native tools?

Why interviewers ask this

This question specifically probes whether candidates understand Zoho's infrastructure philosophy or are entirely dependent on cloud abstractions. Zoho values engineers who can build and operate the underlying systems, not just configure managed services. Weak candidates describe AWS CodePipeline and are visibly lost when told there is no AWS. Strong candidates recognise the core concepts are identical — the difference is which open-source tool implements each stage.

Example strong answer

The pipeline stages are identical to any cloud deployment. The difference is which tool implements each one.

Source and trigger: Self-hosted Gitea or GitLab CE. Every push to a feature branch triggers a webhook to the CI server.

CI server: Jenkins (self-hosted) runs the pipeline: compile → unit tests → integration tests → build Docker image → push to private registry. Drone CI or Woodpecker CI work well for a lighter footprint.

Artifact registry: Self-hosted Harbor — it adds vulnerability scanning and RBAC on top of the basic Docker registry. Every successful build produces a versioned image: registry.zoho.internal/product:git-sha.

Test environments: Kubernetes on bare metal (kubeadm). Feature branch builds deploy to an ephemeral namespace, run integration tests against a test DB, and tear down after the run. No persistent resources consumed between runs.

Production deployments: Kubernetes rolling updates with maxUnavailable: 0 and maxSurge: 1 — brings up one new pod before terminating one old pod, guaranteeing zero downtime. Readiness probes ensure traffic only routes to fully started pods. If any new pod fails its readiness probe, the rollout pauses automatically.

Rollbacks: Kubernetes retains the previous ReplicaSet. kubectl rollout undo deployment/product reverts in seconds — faster than a new deployment because the previous image is already pulled on every node.

Secrets management: HashiCorp Vault (self-hosted). Secrets are never in environment variables or Docker images. A Vault agent sidecar authenticates via Kubernetes ServiceAccount tokens at pod startup and injects secrets as mounted files. Secret rotation triggers an automatic rolling restart.

The one hard part without cloud: Auto-scaling. AWS can provision a new node in 2–3 minutes; bare metal takes 10–15 minutes. Solution: maintain a warm pool of pre-provisioned worker nodes. The Kubernetes Cluster Autoscaler integrates with Zoho's internal provisioning API to draw from that pool during traffic spikes.

Follow-up questions

"A production deployment is 60% complete when monitoring shows error rates spiking on the new pods. The rollout is still in progress. How does Kubernetes handle this, and what do you do manually?"

"A developer accidentally commits a secret key to a public GitHub mirror of an internal repo. What's your incident response?"

Question 5: Debugging a Silent Data Loss Bug in Zoho WorkDrive

A WorkDrive team lead reports that 0.3% of file uploads are silently failing — the user sees a success confirmation, but the file is not stored and is not retrievable 24 hours later. This has been happening for at least two weeks. The system has three components: an upload API server, an internal blob storage service, and a metadata service that records file names and owner IDs. Walk through your debugging approach, what you suspect the root cause is, and how you verify it.

Why interviewers ask this

Silent data loss is one of the most serious production bugs possible. This question tests debugging discipline under a vague problem statement: the candidate must define what "silent failure" means technically, form hypotheses, and design targeted experiments to confirm or eliminate each one. Weak candidates list generic steps without forming hypotheses. Strong candidates immediately identify the three possible failure points, hypothesise which is most likely, and design a targeted query to confirm it in minutes.

Example strong answer

My first question: what does "silently failing" mean precisely? Is the blob written but metadata not recorded? Is the blob not written at all? Or are both written but the retrieval path broken? The answer changes the investigation completely.

Hypothesis tree:

H1 — Blob write succeeds, metadata write fails silently. The upload API writes the blob, gets success, then calls the metadata service. If the metadata service returns a transient error and the API swallows it, the blob exists as an orphan but is unfindable.

H2 — Blob write fails but the API returns success anyway. A bug in the upload API — it's not checking the return code from the blob service, or it's catching exceptions without propagating the failure to the user. The 0.3% rate suggests a specific error condition: full disk on one blob node, or a bug triggered by a specific file size range.

H3 — Both writes succeed but retrieval is broken. Least likely — the user could retrieve immediately after upload if this were the case.

Verification sequence:

First: query metadata for 1,000 recent uploads and check whether their blob IDs exist in the blob storage index. If metadata records point to non-existent blobs, that rules out H3.

Second: cross-reference upload API logs with blob service logs by file ID. If the blob service shows failed writes for file IDs that the API logged as successful, that's H2 — the API is swallowing errors.

Third: check whether 0.3% correlates with a specific variable: file size, file type, specific API server instance, specific blob storage node. A correlation to one server instance immediately points to hardware or a configuration issue.

Most likely root cause: A specific blob storage node is experiencing intermittent write failures (full disk or corrupted partition) and returning error codes that the upload API is swallowing. The 0.3% rate corresponds to the fraction of uploads routed to that node.

Immediate mitigation: Remove the suspect node from the upload rotation. Audit the past two weeks to identify orphaned blobs and notify affected users. Long-term: the API must treat any non-success blob response as a hard failure — "Your upload failed, please retry" is far better than silent data loss.

Follow-up questions

"After identifying the faulty node, you discover 18,000 user files were silently lost over two weeks. How do you communicate this and what is your recovery process?"

"You've fixed the bug. How do you build an ongoing integrity check that would catch this class of issue within hours rather than two weeks?"

Question 6: Thread-Safe Distributed Rate Limiting for Zoho's API Gateway

Zoho's API gateway handles 50,000 requests per second. Developer accounts are rate-limited to 1,000 API calls per minute. The current rate limiter is a single-threaded in-memory counter — it's a single point of failure and is becoming a performance bottleneck. Redesign it to be thread-safe, distributed across multiple gateway instances, and accurate to within 5% of the limit under concurrent load. Walk through your design and the concurrency primitives you'd use.

Why interviewers ask this

Concurrency and thread safety appear in every Zoho Advanced Programming round. The question tests whether a candidate understands the difference between in-process synchronisation (CAS operations, atomic primitives) and distributed synchronisation (Redis Lua scripts), and whether they can reason about the accuracy-vs-performance trade-off that's inherent in distributed rate limiting.

Example strong answer

The core tension: a perfectly accurate distributed rate limiter requires a central atomic counter every request consults synchronously — but at 50,000 RPS, that counter becomes the bottleneck. The practical solution accepts a small accuracy error (your 5% tolerance) in exchange for much better performance.

Design: hybrid local token bucket + Redis central counter

Each gateway instance maintains a local token bucket per account (in-process, using AtomicLong in Java or std::atomic<int64_t> in C++). The local bucket holds a pre-fetched "local quota" — a fraction of the per-minute limit allocated to this instance. Every time the local quota is exhausted, the instance fetches more tokens from a central Redis counter.

The Redis counter: A Redis HASH stores {account_id: current_count} with a 60-second TTL. To check remaining quota, the instance runs a Lua script on Redis that atomically increments the count and returns the new value. Using a Lua script is critical — it ensures the read-increment-return is atomic and cannot be interleaved with another instance's operation.

Pre-fetching to reduce Redis load: Each instance pre-fetches a batch of tokens — say, 50 — from Redis in one INCRBY account_id 50 call. The instance then serves 50 requests locally before touching Redis again. This is a 50× reduction in Redis calls vs. per-request coordination.

Accuracy: With K gateway instances each pre-fetching 50 tokens, up to K×50 tokens can be "checked out" simultaneously. For K=10 and a 1,000/min limit, up to 500 extra requests could pass in a burst — a 50% overage, too high. Reduce pre-fetch size to max(1, limit / (K × 10)). For 10 instances, pre-fetch = 10 tokens, overage risk = 100 tokens = 10% — within your 5% threshold for most traffic patterns.

Within-instance concurrency: The local bucket counter uses a CAS (compare-and-swap) loop to decrement without a mutex. AtomicLong.compareAndExchange avoids lock contention on the hot path.

Failure mode: If Redis is unreachable, instances fall back to local-only counting — rate limiting becomes per-instance rather than global. A 1,000/min limit across 10 instances becomes 10,000/min in degraded mode. Acceptable for a brief Redis outage; blocking all traffic because rate limiting is broken is worse.

Follow-up questions

"Two instances simultaneously check out the last 100 tokens. Both serve 100 requests. The account makes 1,200 requests instead of 1,000. Your SLA allows 5% overage — is this acceptable? How do you tighten it if not?"

"A developer sends 1,000 requests in the first second of every minute, then is blocked for 59 seconds. How does a token bucket handle this differently from a fixed window counter, and which do you use?"

Question 7: System Design — Zoho WorkDrive File Sync Engine

Design the file synchronisation engine for Zoho WorkDrive — the component that keeps files in sync between a user's desktop client and the cloud. Requirements: handle concurrent edits from two different devices; handle offline edits that sync when connectivity is restored; support files up to 50GB; and support a team folder shared by 100 users where any member can edit any file. Focus on the sync protocol, conflict resolution, and the edge cases specific to a multi-user shared folder. You don't need to design the storage layer.

Why interviewers ask this

WorkDrive is a real Zoho product and the sync engine is one of its hardest engineering problems. This question appears in Round 3 and Round 4 for senior candidates. It tests system design breadth — distributed state, conflict resolution, event-driven architecture, and client-server protocol design — and whether the candidate can reason about edge cases rather than just describing the happy path. Weak candidates propose "last write wins" and stop. Strong candidates recognise that last-write-wins destroys data in concurrent edit scenarios and propose a conflict resolution strategy grounded in the nature of the data.

Example strong answer

The hardest problem in file sync is not the happy path — it's what happens when two people edit the same file simultaneously and one is offline. Let me design around that constraint.

Version tracking with vector clocks

Each file has a version vector: a map from device_id → lamport_timestamp. When device A edits a file, it increments its own component: {A: 5, B: 3}. When the cloud receives this, it compares against the stored version. If the incoming vector strictly dominates (every component ≥ the stored version), it's a clean update. If the vectors are concurrent (A has edits B doesn't know about and B has edits A doesn't know about), that's a conflict.

Sync protocol

On connect, the client sends its current version vectors for all files in the sync folder. The server responds with a diff: files where the server version is newer than the client's. For each changed file, the server sends an rsync-style binary delta (not the full file) unless the file was created or deleted.

For large files up to 50GB: chunked upload with a resumable token. Each 8MB chunk uploads independently with its chunk index. The server assembles the file only when all chunks arrive. The client tracks which chunks succeeded and re-uploads only failed chunks after a network interruption — never restarts from zero.

Conflict resolution

For text and structured files (DOCX, XLSX): three-way merge using the common ancestor version and both divergent versions. If edits don't overlap (A edited paragraph 1, B edited paragraph 3), merge is automatic. If they overlap (both edited line 47), surface a conflict file: save the original as filename (conflict copy - Device A - timestamp).docx and notify the user.

For binary files (images, executables): three-way merge is not meaningful. Apply last-write-wins based on wall-clock timestamp, and save the losing version as a conflict copy. The user sees both and decides which to keep.

Shared folder with 100 concurrent users

Each file edit generates a FileChanged event published to a fan-out queue partitioned by folder ID. All 100 subscribed clients receive the event and pull the delta. To avoid a thundering herd (100 clients simultaneously pulling after one edit), add jitter: each client waits random(0, 30) seconds before pulling.

For server-side consistency: use optimistic locking. Each file write includes the client's expected version vector. If the server's current version doesn't match, the write is rejected with a CONFLICT response and the client must re-fetch, merge locally, and retry.

Offline edits

When a device reconnects, it replays its local edit log (a SQLite journal on the device) as a sequence of versioned patches. The server processes each patch in order, applying merges as above. The local journal is cleared only after the server acknowledges each patch — if the connection drops mid-replay, the unacknowledged patches are resent.

Follow-up questions

"User A has been offline for three days and edited 400 files. They reconnect over 3G. How does your sync protocol prioritise which files to sync first, and how do you handle the case where the server rejects some patches as conflicts while others succeed?"

"A ransomware attack encrypts all 10,000 files in a shared folder on one compromised device and syncs the encrypted versions to the cloud. How do you detect and respond to this?"

Question 8: Reverse a Linked List in Groups of K

Write a function that takes the head of a singly linked list and an integer K, and reverses the nodes of the list in groups of K. If the remaining nodes are fewer than K, leave them in their original order. Example: given 1→2→3→4→5→6→7 and K=3, return 3→2→1→6→5→4→7. Requirements: (1) implement iteratively without recursion; (2) analyse time and space complexity; (3) handle K=1 and K larger than the list length correctly. You have 25 minutes.

Why interviewers ask this

This is a staple of Zoho's Basic and Advanced Programming rounds. It tests linked list pointer manipulation, edge case awareness, and the ability to write clean code under time pressure — often on paper. Zoho's interviewers care about clean pointer handling and correct reasoning about edge cases, not just arriving at the correct output. The iterative constraint specifically tests whether candidates can manage multiple pointer anchors without the crutch of recursion.

Example strong answer

Let me think through the structure before writing code. For each group of K nodes I need to: (1) check that K nodes actually exist; (2) detach the group; (3) reverse those K nodes in place; (4) reconnect the reversed group to the already-processed portion. I need three pointer anchors: prev_group_tail (last node of the already-reversed portion — starts at a dummy head), group_start (current group's first node, becomes the new tail after reversal), and kth (current group's last node, becomes the new head after reversal).

class ListNode:
    def __init__(self, val=0, next=None):
        self.val = val
        self.next = next

def reverseKGroup(head, k):
    dummy = ListNode(0)
    dummy.next = head
    prev_group_tail = dummy

    while True:
        kth = get_kth_node(prev_group_tail, k)
        if kth is None:
            break  # fewer than k nodes remain — leave as is

        group_start = prev_group_tail.next
        next_group_start = kth.next

        # Reverse k nodes in place
        prev = next_group_start
        curr = group_start
        for _ in range(k):
            nxt = curr.next
            curr.next = prev
            prev = curr
            curr = nxt

        # Reconnect: kth is now the new head of this group
        prev_group_tail.next = kth
        prev_group_tail = group_start  # group_start is now the new tail

    return dummy.next

def get_kth_node(node, k):
    while node and k > 0:
        node = node.next
        k -= 1
    return node  # None if fewer than k nodes exist

Complexity: Time O(n) — every node is visited twice (once by get_kth_node, once by the reversal loop). Space O(1) — only a fixed number of pointer variables, no recursion stack.

Edge cases:

K=1: get_kth_node returns the first node immediately. The reversal loop runs once per node, each pointing to its successor — the list is unchanged. Correct.

K > list length: get_kth_node returns None on the first call. The while loop breaks immediately. The list is returned unchanged. Correct.

K equals list length exactly: The entire list is reversed in one group. On the second iteration, get_kth_node returns None and the loop breaks. Correct.

The dummy node is the key to clean code — it eliminates the special case for updating the head of the list and lets prev_group_tail always be a non-null node.

Follow-up questions

"Modify your solution to also return the total number of nodes that were reversed across all groups."

"Now implement the same function recursively. Which version is more readable and which is safer for very long lists — and why?"

Preparation tip

Zoho's SWE interviewers care less about whether you know obscure algorithms than whether you think carefully before you code. In every round — from the written test to the Technical HR — the most consistent differentiator is candidates who ask one clarifying question, state their approach out loud, and identify at least one edge case before writing the first line. Zoho hires engineers who build things that last: code that's readable, systems that are recoverable, and designs that acknowledge failure modes. That combination of clarity, edge-case ownership, and engineering discipline is what moves candidates from "technically competent" to "offer."