Phone Screen:
Coding: Given point coordinates, points less than k apart needed to be merged into a group. I used union-find. The follow-up asked what to do if there were a lot of points and they were very sparse, and how to reduce the computation.
System design: Design a metrics-aggregation system. Each vehicle collects data about obstacles on the road, such as locations. There weren't many vehicles, but there was a huge amount of data. Exactly what the data was was also vague, including but not limited to the locations of surrounding objects and so on. Uploads happened once an hour, with petabytes of data. The requirement was to find the requested data quickly. Questions included which database to choose and how to make queries faster. For data within five minutes, access should be faster and the granularity lower; for data within a year, the reverse.
Onsite:
Hiring-manager behavioral: Talk about a previous project, making clear its scope, my role, and the overall design; defend the design and discuss the biggest challenge. In the remaining fifteen minutes, the hiring manager asked a system-design question: how to design an autonomous-vehicle simulator that simulates driving situations, takes a model as input, and produces "actualization" as output. Testing quick thinking, I guess? The hiring manager was on that team, which was why he asked. I was completely unprepared.
Concurrency coding: Some behavioral questions and a self-introduction, why Nuro, and so on, followed by writing a versioned key-value store with get, put, and delete. For example, get(key, version) needed to return the number closest to that version number. Delete could also take a version, deleting everything after that version while keeping everything before it. I proposed an ArrayList and a TreeMap, but the interviewer said TreeMap was too expensive: use a list and binary search. I wrote binary search by hand, though there should be a library function, if one is available. For deletion, there were approaches such as using -1 as a marker in the array. Then we got to the main question: avoiding race conditions. There were only five minutes left, so I didn't write code. I suggested a lock; the interviewer said it wasn't efficient. I suggested a read-write lock; still not efficient enough. Then the interviewer said to use MVCC, Multi-Version Concurrency Control. By then, there was no time left to write code.
Algorithms: LeetCode 42.
System design: The vehicles had uploaded petabytes of data, retained for one year. Design an internal data-search tool. A query specified a range of certain data, and the number of rows returned could be limited. Each row was very large, and memory couldn't load all the data. I didn't need to consider ingestion, but did need to cover storage, queries, search, and so on.
HR required the onsite to be in person and booked lunch for me. This was my first in-person onsite in many years. After the interviews, HR asked a lot about my previous level, pay expectations, why I had left my last job, and other personal questions. In the end, I didn't pass. :)
Their vehicles from the collaboration with Uber and Lucid are about to launch in Mountain View this year. They had some poor strategic decisions in the past. Now that they're hiring again, things might be improving, but I can't judge how much.
Discussion
Loading comments…