This post has been de-listed
It is no longer included in search results and normal feeds (front page, hot posts, subreddit posts, etc). It remains visible only via the author's post history.
Over the last several years I've done a bunch of technical interviews for Senior SWE roles, and have frequently found myself in a ~1hr system design interview at some point in the process. This is the part that usually trips me up the most despite any prep or studying I've done, in large part because the form these interviews take always seem wildly inconsistent with both eachother, and with all the prep material I've seen.
First there's the base question itself. Every resource I've looked at for system design seems to revolve around the same basic question format: design a system that does x, sometimes this is a self-contained thing and sometimes they use some existing website like Twitter or TinyURL as the example. But in practice I only get a question like this about 1/4 of the time, at other points it's something more akin to a coding assessment where they want me to write some function and explain any additional services called or resources involved. Other times I've had interviews that were more about if I knew the basic concepts of system design: how do you define functional requirements, non-functional ones, how do you scale a system horizontally vs. vertically, etc. Still other times I have interviewers trying to drill down into knowledge on specific tools and the interview becomes less "design a system" and more "tell me how you would use Kafka and Redis in this scenario".
I run into this same problem when I try to study for these interviews as well. For instance I've been going through https://github.com/donnemartin/system-design-primer the past several days and I've noticed that here the example solutions for System Design problems get pretty in depth in terms of defining exact scale of reads/writes a system expects, doing back of the napkin calculations for individual field sizes or estimating how much data is being processed in each transactions. These are levels of depth I don't recall ever being asked or expected of me in a SD interview.
So I guess ultimately my question is: How do y'all figure out how deep to go with system design, both in preparing/studying and in the interview itself? Just defining the general diagram of how the system works, what the data structure is like, and the API calls? Do you go in depth on exact numbers for how many times each of those API end points are being called, how large the average row in a given table is, etc.? Do you get into specific tools/software or just keep things high level (e.g. saying "I would use a NoSQL database" vs. "I would use a document database" vs. "I would use MongoDB")?
Subreddit
Post Details
- Posted
- 7 months ago
- Reddit URL
- View post on reddit.com
- External URL
- reddit.com/r/Experienced...