Uber SDE-1 India 2025: All 3 OA Problems Solved, Rejected at Google Sheets LLD

TL;DR. Solved all 3 OA problems within the time limit (easy-medium, medium, hard). Cleared the DSA round with a graph problem involving multi-source BFS and Dijkstra optimization. Then, in the LLD round, the candidate was asked to design a simplified Google Sheets with cells, formulas, dependencies, and updates. She jumped straight to implementation without asking clarifying questions, struggled with cycle detection and update propagation, could not articulate her design choices, and the interviewer was unconvinced. Rejection. The feedback was direct: strong problem-solving, weak design communication. Source post linked at the bottom.

This is not a guide on how to prepare for Uber's LLD round. This is the post-mortem of a specific rejection where everything before the LLD round went right, and one failure mode in one round ended the loop. The failure mode is instructive because it is the single most common reason SDE-1 candidates fail LLD rounds across product companies in India: treating LLD as a coding problem instead of a design conversation.

The verified candidate

The candidate disclosed her first name and her general preparation status but not her previous company, YOE, or educational background. What she did disclose is the per-round breakdown, which is the more useful signal for anyone preparing for Uber SDE-1.

The Online Assessment: 3 problems, all solved

The candidate solved all three problems within the time limit. The preparation was consistent LeetCode and Codeforces practice, which means competitive programming background, not just interview prep.

Solving all 3 OA problems at Uber is above average. Many SDE-1 candidates solve 2 of 3 and still advance to the interview rounds. Solving all 3 suggests strong DSA fundamentals, which makes the subsequent LLD rejection more striking: the failure was not a skill gap but a mode-switch failure. DSA mode (solve the problem, optimize, code it) does not transfer to LLD mode (clarify, design, then code).

Round 1: Technical DSA, multi-source BFS with Dijkstra optimization

The problem was a graph-based problem involving multi-source BFS. The candidate started with a multi-source BFS approach and then the interviewer (or the problem's follow-up) required optimization that extended to Dijkstra's algorithm, likely involving weighted edges or shortest-path computation from multiple sources.

What the candidate did right in this round

Three things, explicitly noted in the source post:

1. Explained approach clearly before coding. The candidate walked through the BFS approach, discussed why BFS works for unweighted shortest paths, and then articulated why Dijkstra's becomes necessary when edge weights are introduced.
2. Covered edge cases. Disconnected components, single-source degenerate case, negative weight handling (Dijkstra does not support it, mention it proactively).
3. Implemented a working solution. Not just pseudocode. The code ran.

The interviewer was satisfied. This round was a clean pass, and it demonstrates that the candidate's DSA skills were not the issue. The issue was entirely in the next round.

Why this round matters for the rejection narrative

If the candidate had struggled in the DSA round, the LLD rejection would be unsurprising: a generally underprepared candidate fails across rounds. But the candidate did not struggle. She excelled. The DSA round was solved with optimization, edge case coverage, and clear communication. The LLD round failure is therefore not a preparation gap but a specific, identifiable failure mode: the inability to switch from "solve the problem" mode to "design the system" mode.

Round 2: Low-Level Design, simplified Google Sheets (the rejection round)

The interviewer asked the candidate to design a simplified version of Google Sheets. The required features included: cells that hold values or formulas, formulas that reference other cells (e.g., cell A3 = A1 + A2), a dependency graph between cells, and update propagation (when A1 changes, A3 must recalculate).

This is a well-known LLD problem. The core design challenge is managing the dependency graph: detecting cycles (cell A1 references A2 which references A1), determining the correct evaluation order (topological sort on the dependency DAG), and propagating updates efficiently without recalculating the entire sheet.

The specific failure mode

The candidate's own words from the source post: she "jumped too quickly into implementation" without asking sufficient clarifying questions.

Here is what that means in practice:

What the candidate did: Opened the editor, started writing a Cell class, started implementing formula parsing, and began coding update propagation. Within 15 minutes, she had partial code for cell storage and formula evaluation. Within 25 minutes, she hit the cycle detection problem and could not integrate it into her existing code structure cleanly.

What the candidate should have done: Spent the first 10 to 15 minutes asking clarifying questions and sketching the design on a whiteboard or shared doc. Questions like:

Without these questions, the candidate designed for an ambiguous problem. When the cycle detection requirement became apparent mid-implementation, her code structure could not accommodate it without significant rework. The interviewer saw a candidate who could code but could not design.

The architecture the interviewer was looking for

The candidate struggled specifically with cycle detection and update propagation. These are the two components that require the dependency graph to be correct and maintained incrementally. If you start coding cells and formulas without designing the dependency graph first, you will hit these issues 20 minutes into the round and not have time to recover.

The communication failure

The interviewer's assessment, per the candidate's feedback, was that her "design communication" needed improvement. This means:

1. She did not articulate her design before coding. The interviewer could not see the shape of the system before code started appearing. In LLD rounds, the interviewer needs to understand your design in the first 15 minutes so they can guide you if you are heading toward a dead end. If you start coding silently, the interviewer cannot help you until the dead end is already reached.
2. She did not talk through trade-offs. Why a DAG and not a general graph? Why topological sort and not BFS? Why reject circular formulas instead of marking them as errors? These are the trade-off discussions that signal design maturity to the interviewer.
3. She did not handle pressure well when stuck. When cycle detection became a problem, instead of stepping back and redesigning, she continued coding forward into a structure that could not accommodate the requirement. The interviewer saw someone who doubles down on a failing approach instead of pivoting.

Round 3: Hiring Manager / Behavioral

The hiring manager round was conducted, but its impact was reduced because the LLD round had already produced a failure signal. Uber's evaluation is round-by-round: a strong behavioral does not compensate for a failed technical round at SDE-1.

The topics covered were standard behavioral fare: projects you have owned, teamwork examples, situations involving conflict or ambiguity. The STAR method works here. But the candidate's own assessment was that this round could not overcome the LLD result.

The rejection feedback

The feedback was specific and actionable:

The feedback confirms that the rejection was entirely attributable to the LLD round. The candidate's DSA skills were not questioned. The OA performance was not questioned. The single failure mode was the approach to the design round: code first, think second.

The Google Sheets LLD problem: how to actually solve it

For anyone preparing for this specific problem (and it appears at Uber, Google, Flipkart, and several other companies), here is the approach that passes:

Phase 1: Clarify (0 to 10 minutes)

Ask every question in the table above. Define the scope. Agree on constraints with the interviewer. Write down the agreed scope on the shared doc before touching code.

Phase 2: Design (10 to 25 minutes)

Sketch the core classes:

• Spreadsheet: holds a grid of cells, provides setCell(row, col, value_or_formula) and getCell(row, col) APIs
• Cell: stores value, formula (if any), dependsOn list, dependedBy list
• DependencyGraph: manages the DAG, provides addDependency, removeDependency, hasCycle, topologicalSort
• FormulaParser: parses a formula string into an expression tree referencing cell addresses

Walk the interviewer through the dependency graph management. When setCell(A3, "=A1+A2") is called: parse the formula, identify dependencies (A1, A2), check for cycles (DFS from A3 through the dependency chain), update the dependency graph, evaluate A3, propagate updates to any cell that depends on A3.

Phase 3: Code (25 to 50 minutes)

Implement the core path: setCell with cycle detection, evaluation, and propagation. Skip the formula parser if time is tight (hardcode a simple expression evaluator for +, -, *, / on cell references).

Phase 4: Edge cases and testing (50 to 60 minutes)

Discuss: what happens when a cell is deleted? What happens when a formula references a non-existent cell? What happens when the sheet grows to 100,000 cells and one cell triggers a cascade of 10,000 recalculations?

The LLD communication gap, and how to close it

Five lessons from this specific rejection.

1. LLD is a design conversation, not a coding sprint. The first 10 to 15 minutes must be clarifying questions and design sketches. If you open the editor before minute 10, you are almost certainly heading toward the failure mode this candidate hit.
2. OA excellence does not compensate for LLD failure. Solving all 3 OA problems is irrelevant if the LLD round fails. Uber evaluates rounds independently. A perfect OA buys you nothing in a failed design round.
3. Cycle detection and update propagation are the core of spreadsheet LLD. If you recognize "Google Sheets" as the problem, immediately think: dependency graph, topological sort, cycle detection with DFS. These three concepts are the skeleton of the solution. Everything else (formula parsing, cell storage, API design) is flesh on the skeleton.
4. Talk through trade-offs out loud. The interviewer cannot assess your design thinking if you code silently. "I am choosing a DAG because formulas cannot have circular references, and topological sort gives me a correct evaluation order" is a sentence that takes 10 seconds and dramatically changes the interviewer's assessment.
5. When stuck, step back and redesign. The candidate doubled down on a code structure that could not accommodate cycle detection. The correct move is to stop coding, acknowledge the structural issue, sketch the required change, and then implement it. Interviewers respect pivots. They do not respect stubbornness.

Questions about Uber's LLD round

Was this candidate a fresher or experienced? The source post says "currently preparing for software engineering roles" but does not disclose years of experience, previous company, or educational background. The OA performance (all 3 solved including a hard/contest-style problem) suggests competitive programming experience.

Is the Google Sheets LLD problem common at Uber? Spreadsheet design appears at multiple companies for LLD rounds. Uber, Google, and Flipkart have all used variations of it. The core concepts (dependency graph, topological sort, cycle detection) are transferable to other LLD problems involving dependency management.

Would a different LLD problem have changed the outcome? Unlikely. The failure mode was not specific to Google Sheets. It was the approach: jumping to code without clarifying questions and design discussion. This failure mode would manifest with any sufficiently complex LLD problem (parking lot, elevator system, snake game, chess engine).

How long should you spend on clarifying questions in an LLD round? 10 to 15 minutes of a 60-minute round. This feels long if you are used to DSA rounds where you clarify in 2 minutes and start coding. LLD is a different mode. The interviewer expects, and rewards, thorough clarification.

Can you recover from a weak LLD round with a strong HM round? At Uber SDE-1, no. Uber evaluates technical rounds independently. A failed LLD is a failed LLD regardless of behavioral performance. At SDE-2 and above, there is slightly more flexibility because the bar raiser adds a separate calibration signal.

Verification and source

This analysis is anchored on a published Medium post by Anshika Gupta with per-round detail including the OA structure, DSA round topic (multi-source BFS/Dijkstra), LLD problem (Google Sheets), and the rejection feedback. Original post: Uber SDE 1 (2025) Interview Experience

PapersAdda's verification standard requires a publicly identifiable source URL, per-round detail from the candidate, and an outcome statement. This post meets all three. The candidate described each round, the specific failure mode in the LLD round, and the rejection feedback.

Read next on PapersAdda

• The SDE-2 success story at the same company: Uber SDE-2 (L4) India 2025, 6-round gauntlet with job scheduler machine coding to offer, how the loop looks when the machine coding round goes right
• The Amazon SDE-1 comparison: Amazon SDE-1 onsite 2026 Tier-2 engineer's real 4-round loop, a different company's SDE-1 process where LLD is combined with the coding round
• The Amazon SDE-2 escalation: Amazon SDE-2 (L5) 2026 Tier-3 engineer's real 5-round loop to ₹60L, where LLD is an independent round at the senior band and SOLID discipline is the scoring signal
• The Microsoft new-grad benchmark: Microsoft new grad 2026 4-round interview real questions, a different company's approach to evaluating entry-level design thinking