← Uber Interview Insights

Uber·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say
Jun 2026

Summary

Uber SWE interview focused on a Union Find problem involving ride-sharing logs. The main coding question wasn't too bad but the follow-ups kept coming and that's where things got interesting.

Questions Asked (3)

Q1

Given plain-text ride-sharing logs (each entry has a timestamp and indicates that user A shared a ride with user B) and a list of all users, find the earliest timestamp at which all users become connected.

Algorithms & Data Structures
Author's notes

Went in having seen something similar on a prep forum so I had a rough idea.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Sort the log entries by timestamp, then process them in order using a Union-Find (Disjoint Set Union) data structure to merge connected components. After each union, check if the number of connected components equals 1 (or if all users belong to the same set); the timestamp of the union that achieves this is the earliest time all users are connected.

Pro tip: Mention that you can optimize the connectivity check by maintaining a count of connected components and decrementing it on each successful union, avoiding an O(n) scan after every merge. Also, clarify edge cases like disconnected users or empty logs.

1. Clarify and Validate Input

Confirm the log format, whether timestamps are unique, and if all users are guaranteed to appear in the logs. Discuss handling of users who never share a ride.

2. Choose Data Structures

Select Union-Find for efficient merging and connectivity checks, and a map to assign each user to a unique index. Consider sorting the logs by timestamp.

3. Process Logs Chronologically

Iterate through sorted logs, union the two users in each entry, and after each union check if all users are connected (e.g., by tracking component count).

4. Return Earliest Timestamp

As soon as the component count reaches 1, return the current timestamp. If the logs end without full connectivity, return null or indicate impossibility.

5. Analyze Complexity and Edge Cases

State time complexity O(E log E + E α(N)) due to sorting and near-constant union-find operations, and space O(N). Discuss edge cases like single user, no logs, or disconnected groups.

Key Points to Mention

  • Union-Find (Disjoint Set Union) with path compression and union by rank for near O(1) operations.
  • Sorting the logs by timestamp to process in chronological order.
  • Maintaining a count of connected components to efficiently check when all users are connected.
  • Handling users not present in any log (they remain isolated, so full connectivity may be impossible).
  • Time and space complexity analysis.
  • Edge cases: empty logs, single user, duplicate timestamps, and disconnected components.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

How would you extend the solution to handle multiple types of log entries, not just ride-sharing events?

Algorithms & Data StructuresTechnical Trade-offsAdaptability & Ambiguity
Author's notes

This is where I started stumbling a bit.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the current solution's architecture and the new log types to understand the extension scope. Then propose a modular design using abstraction and polymorphism to handle diverse log entries, while discussing trade-offs like performance and maintainability. Emphasize adaptability by suggesting a plugin-based or schema-driven approach that can evolve with future log types.

Pro tip: Demonstrate foresight by discussing how to handle schema evolution and backward compatibility, as Uber's systems must process logs from various services with changing formats. Also, mention the importance of monitoring and alerting for new log types to ensure smooth integration.

1. Clarify Requirements

Ask questions to understand the current solution, the new log types, their volume, velocity, and variety, and any constraints like latency or throughput.

2. Identify Abstraction Points

Determine where to introduce abstractions, such as a common log entry interface or a parser factory, to decouple processing logic from specific log types.

3. Design Extensible Architecture

Propose a modular design using design patterns (e.g., Strategy, Factory, or Plugin) and consider schema registry or configuration-driven parsing for flexibility.

4. Discuss Trade-offs

Analyze trade-offs between generality and performance, complexity, and development time, and suggest metrics to evaluate the solution.

5. Plan for Evolution

Outline how to handle future log types, including versioning, backward compatibility, and monitoring for new types.

Key Points to Mention

  • Use of design patterns like Strategy or Factory to encapsulate parsing and processing logic per log type.
  • Schema evolution and backward compatibility to handle changes in log formats without breaking existing pipelines.
  • Performance considerations: overhead of abstraction, potential need for type-specific optimizations.
  • Scalability: ensuring the solution can handle increased volume and variety of logs.
  • Monitoring and observability: tracking metrics per log type and alerting on anomalies.
  • Testing strategy: unit tests for each log type handler and integration tests for the overall system.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

What is the approximate time complexity of your solution?

Algorithms & Data Structures
Author's notes

Said O(n log n) for sorting the logs plus near-linear for the union-find operations with path compression.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

State the time complexity of your solution clearly and confidently, then briefly explain how you derived it by analyzing the dominant operations in your algorithm. If applicable, also mention space complexity and any trade-offs you made, showing awareness of efficiency.

Pro tip: Always relate the complexity to the problem constraints and expected input size—this demonstrates that you understand the practical implications and can make informed engineering decisions.

1. State the complexity

Clearly state the time complexity using Big O notation, e.g., O(n log n). Be precise and avoid vague terms like 'fast' or 'efficient'.

2. Explain the derivation

Briefly walk through the key parts of your algorithm and identify which operations dominate the runtime. For example, if you have nested loops, explain how they contribute to the overall complexity.

3. Mention space complexity

If relevant, state the space complexity and explain what data structures contribute to it. This shows a holistic understanding of resource usage.

4. Discuss trade-offs

If you made any trade-offs (e.g., using extra space to reduce time), mention them and justify why it's acceptable for the given problem.

5. Relate to constraints

Connect the complexity to the problem's input size and constraints. For example, if n is up to 10^5, an O(n^2) solution might be too slow, so you optimized to O(n log n).

Key Points to Mention

  • Big O notation and its formal definition
  • Dominant operations and how to identify them
  • Space complexity and auxiliary space
  • Trade-offs between time and space
  • Best, average, and worst-case scenarios
  • Practical implications for large inputs

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.