Waymo Software Engineer Interview Experience — A Four-Round Onsite With Two System Design Problems

A recruiter reached out to me on LinkedIn. Apparently the company's valuation went up 4x earlier this year, so they've been hiring a lot lately.

The onsite was four rounds total.

Round 1: System Design

Design a Matchmaking Service:

• Join matchmaking queue
• Cancel matchmaking request
• Match two compatible players
• Notify both players when a match is found
• Handle disconnects and expired requests

Round 2: Coding

(The post doesn't give any detail on what this round covered.)

Round 3: System Design

Design a global caching service for small images. The service is backed by a single database — the reason for having only one database is out of scope and should be treated as a fixed constraint. The system needs to handle hundreds of thousands of image requests per second globally. Images can be updated in the database, and reads from the cache should remain highly performant. It is acceptable to serve stale images for a short period of time after an update. I had to design the read path, update path, cache hierarchy, cache invalidation or refresh mechanism, and failure handling for this system.

Round 4: Coding

Say there are two different software components that sense and track surrounding objects, called System A and System B. Each system tracks objects independently and assigns its own string ID unique within that system. The two systems sometimes track the same real-world object, but may use different IDs for it. I had to design and implement an ObjectTracker that supports the following API:

• addLink(a_id, b_id) — declares that a_id in System A and b_id in System B correspond to the same real-world object.
• addObservation(observation) — adds an observation coming from either A or B.
• getHistory(system, id) — given an ID from either system, returns the complete observation history for that real-world object across both systems.

The returned result needs to:

• include all observations from both System A and System B;
• be sorted in chronological order by timestamp;
• preserve each observation's original source, source ID, and metadata.