The first phone interview was a coding interview. This was a really pleasant experience. The interviewer asked a good, challenging question, and we were able to have a good conversation around my solution, the implementation, tradeoffs, and then he answered questions I had about the company.

Unfortunately, the second phone interview for system design is where the negative experience occurred. The interviewer asked for me to design the backend for a popular website/app and specified that it needed to serve "Facebook-sized level of traffic/usage." It was a perfectly reasonable system design question, and I started off asking some clarifying questions, listing my assumptions based on these clarifications, and began explaining my thoughts on the high-level layout of the backend before I dove into the more nitty-gritty details of weighing the tradeoffs of certain technologies for various layers of the backend, read/write optimizations, traffic/storage growth, and explaining my technology choices.

At this point, the interviewer cut me off and asked that I work out specific numbers like the expected number of users, requests, storage, network traffic, etc. The request was very reasonable for a system design interview because you definitely need to keep these numbers in mind when designing the system and be able to work out these numbers based off assumptions. I had thought the Facebook-level usage comment and my clarifications/assumptions had covered this, but the interviewer was looking for more concrete numbers. Fair enough. However, at each point where I listed my assumptions, estimates, and reasons for choosing the estimates, the interviewer kept blocking me from moving on until I was able to deduce the interviewer's exact "correct" estimated number of expected users, requests, traffic, storage, growth, etc. (similar to those gotcha questions like how many windows are there in Manhattan, except with this interview, there were specific numbers the interviewer was looking for).

Trying to deduce these numbers took up more than 30 minutes of the 60-minute interview, not including the beginning of the interview where we both talked about our backgrounds. As a result, there was very little time to get to the actual design of the system. I think if we had instead spent up to 10 minutes going over these number estimations and not focused so much on me figuring out the exact magic numbers in the interviewer's head, we could have focused more on the actual meat of the problem, and it would have gone much more smoothly. After eventually figuring out the magic numbers, the planned system design in my head did not change because "Facebook-level usage" means global, highly-distributed, and billions of users, like I had specified at the beginning of the interview.

Long story short, I did not pass this interview. I'm not sure if this experience was a one-off because of the specific interviewer I had or if it was something that happens company-wide, but it was a very disappointing experience, to say the least.

Coincidentally, I was asked a very similar system design question the next day in an interview with another company, and it was an extremely pleasant experience. I offered similar clarifying questions and estimations at the beginning of the interview. We talked about high-level system design and then dove deep into each portion of the stack to talk about technology decisions, trade-offs, access patterns, and optimizations for reads/writes. The interview was more of an engaging conversation with the interviewer instead of guessing magic numbers.

Standard coding questions