This recruiter gives very specific prep notes. For the phone screen they basically told me the questions outright. They gave notes for the Onsite too, but the design questions themselves are very open ended, so the notes only help a little. For reference only ~
Database design: the interviewer was friendly and easy to talk to. His day-to-day work isn't DB internals, so I'm not sure whether I answered well. There's an OS validation service that writes to the DB, and a fleet management service that reads from the DB. There are basically no functional requirements, and the scale is fleet level. Strong consistency was required, and fault tolerance was asked in a lot of detail: if the primary write Postgres goes down, how does replication happen (async/sync), what if a read replica goes down, 2PC, quorum/consensus .. I mentioned TiDB in passing and I don't know whether that counts as a red flag. I wasn't asked to evaluate different DBs based on workload, so you can't fully trust the recruiter notes.
Notification system: the interviewer was very engaged and actively followed up. He pasted a very long block of requirements. I analyzed the scale and traffic pattern, and the random number I assumed could fit in Postgres, but he immediately stressed that there would be 1M/s writes, so that means bursty heavy writes. Then, following the usual playbook, I drew Kafka and Cassandra, and got asked why Cassandra writes are so fast (WAL). I went through the FR and NF from start to finish and added cache dedupe.
HM round .. I'm not sure how it went. He asked, since the industry already has usable solutions, why build our own wheel .. I talked about scale and cost. Half jokingly he told me to be honest with him, and asked whether the technical challenges I described were done by AI .. I said I hadn't started using Claude back then.
Discussion
Loading comments…