A guide to preparing for the system design/architecture interview

Recently someone asked if it was worth brushing up on Lamport timestamps or how to implement leader elections for an architecture interview. Short answer: no. Long answer: As you become a more senior software engineer, your interviews will concentrate less on the coding questions (though that’s still important not to screw up) and more on system design and architecture. You’re being brought in to take leadership on major projects and the company needs some assurance that you know some best practices and won’t be surprised when your service needs to scale up to 1000 QPS. A big part of that is knowing what the unique problems are that you need to solve and the problems that everyone has that are already solved. If you realize that your service will need to run on multiple servers for redundancy but you need to establish a primary host, great. That’s a lot better than not knowing. If you follow up with “here’s how I’d implement the logic to handle leader election”, that is a *huge red flag*. It’s cool that you know that, but the much better answer is “and I’d use Zookeeper to handle the configuration.” That tells me that you’ve actually seen this situation come up before and you know an efficient way to handle it. If I hire you and give you the responsibility to build a critical service, and you spend a month building and debugging something that has 60% of the functionality, 40% of the polish, and 0% of the production testing that Zookeeper already has, and then you commit to maintaining it, when are you going to build the thing I actually need? *Once you know that you need something, there is a big difference between knowing how to build it and knowing where to get it.* If you need to prep for an architecture interview, pick out ten or twenty major web sites/online services - I’d start with Google Search, Netflix, Foursquare, eBay, Uber, Airbnb, Square, and GitHub - and learn how they work at a high level. Learn enough to know what technologies they depend on, why you might use MySQL, MongoDB, Cassandra, or Bigtable, and be able to talk for an hour and a half about each one. I say an hour and a half because it’s possible that your interviewer wants to focus on some specific aspect instead of letting you pick what to concentrate on, so you’ll want to know something about database sharding or concurrency or torrents. Then learn about some of the most common tools used to handle frequently occurring situations - Redis, Zookeeper, Kafka, etc. Then if you feel confident about all that, pick some tricky little technology that you can show off with if you get the right question. I learned how to store geographical data in a sharded database to optimize for querying for nearness (geohashes with some data duplication) and it did come up a few times. p.s. I still don’t know what a Lamport timestamp is, and I’ve worked at Google, Uber, and Square, gotten a lot more offers than that, and I give 1-2 interviews a week. p.p.s. If you can do all these things, my team is hiring.