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.

▲

harimau777 19 hours ago | parent | next [-]

Isn't that just another kind of trick question? It seems like that relies a lot on the interviewee guessing that you aren't looking for a standard complex solution.

▲

theamk 17 hours ago | parent | next [-]

By "trick question", people usually mean the questions that won't occur in real job. This does not seem the case here.

I have no idea what the OP's actual questions was, but as a made-up example: If the problem is solvable with static sqlite database copied to every node during deployment, but candidate suggests master-master postgres cluster instead, I would not want them. I shudder just thinking what kind of monstrosity they'd build if hired.

▲

harimau777 17 hours ago | parent [-]

Maybe different people use the term differently? To me a trick question is one where answering it requires intuiting some specific secret to solving the problem. In this case, it would be intuiting that, unlike most interviewers, this one wants you to give a simple solution instead of showing off your knowledge of system design techniques.

	▲	quantified 15 hours ago \| parent [-]
		Every time they complexify it, they add latency, storage costs and probability of failure. It's all easily quantified.

▲

18 hours ago | parent | prev [-]

[deleted]

▲

OutOfHere 19 hours ago | parent | prev [-]

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.

▲

gen220 2 hours ago | parent | next [-]

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.

▲

quantified 15 hours ago | parent | prev [-]

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.

	▲	OutOfHere 8 hours ago \| parent [-]
		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.