←back to thread

191 points foxfired | 5 comments | | HN request time: 0.839s | source
Show context
quantified ◴[] No.45110714[source]
Ha. I like to give a systems design scenario that rewards simplicity. Candidates who complexify it (usually in very predictable ways) get rejected. The few who see the simple path have been great hires. Because they also asked the right questions.
replies(2): >>45110828 #>>45111069 #
1. OutOfHere ◴[] No.45110828[source]
Thank you! What are the right questions for a candidate to ask?

As a candidate, I feel that I should ask the interviewer if they're seeking a simple solution or a very scalable one. In this way, I can try to tune the response to the specific interviewer's expectations.

replies(2): >>45112387 #>>45118499 #
2. quantified ◴[] No.45112387[source]
In this case, the most scalable is the simplest. Do the math on where errors can occur and accumulate, storage costs, latency, where rate-limiting can haunt you. The "throw in every feature you learned in certifications" will mess it all up.
replies(1): >>45114718 #
3. OutOfHere ◴[] No.45114718[source]
Huh. The most scalable solution is never the simplest. Simple solutions scale fine up to a point, and no more. The two are at odds.
replies(1): >>45120268 #
4. gen220 ◴[] No.45118499[source]
I always begin system design interviews by repeating and clarifying the framing of the question. Some simple ones: "what kind of service/website is this? what's our expected peak load today? 2 years from now? 5 years from now? [regarding data structures] what's the biggest value we'd reasonably want to store?"

You're backing into things like QPS, size of the data you're responsible for hosting, uptime requirements, real-time requirements, write load vs read load.

Often the natural walk is "let's assume it's a low load, design for that, and then we'll get to higher load at the end". Other times, it's an actual systems-y problem they're facing as a company, and that they have a putative solution to compare your knowledge against.

But yeah it is generally really important to codify and at least state (if not explicitly clarify) your assumptions before recommending a solution.

5. quantified ◴[] No.45120268{3}[source]
It's not whether it scales. It's _how_ the components scale.