[deleted]
A senior engineer's guide to the system design interview
91–100 of 399 posts
Re: A senior engineer's guide to the system design interview
#92We've gone away from system design interview questions on my team. We ask people to diagram something technical they understand well and the team digs in and asks questions to understand depth and breadth of the candidates understanding. For us it works much better. It's a chance to see how well candidates do in following instructions. It gives you a chance to explore depth and breadth of their knowledge on something…
I like this... in theory. But I don't think I'm allowed to give you a system diagram and detailed explanation of systems I've worked on, because obviously they're proprietary. That seems like a problem. How do your candidates normally work around this? Does everyone just talk about hobby or open-source systems they've worked on?
98% of what you'd be inclined to diagram out and explain for a system design interview isn't remotely proprietary. People are generally looking for a high-level overview of a system you've worked on to see a) that you've really worked on it and b) you can explain it such that it makes sense.
Sure, folks will ask you to drill down here and there for more detailed info, but if someone pokes on something where the details really _ARE_ proprietary, it's fine to just say that and offer to drill down somewhere else.
Re: A senior engineer's guide to the system design interview
#93Earlier quoted context omitted.
It’s hard to tell between those who know their stuff, and those who are good at memorising all the various courses that tell you what to say. By telling the candidate what system to design you make the latter’s job easier.
If someone can quickly learn enough about a system that they can convince a domain expert they understand it well in a deep technical discussion, they're probably a good candidate for hiring, since your business likely consists of many complex systems, and the candidate will theoretically be able to onboard faster.
Attaining high level understanding and speaking convincingly about it are entirely different skills from knowing how to build it. Interviews are always a proxy anyway, your job will never be solely comprise of convincing people of your expertise. Sooner of later you have to do exercise it somehow. Unless you're the CEO, that is. The higher you go the easier it is to make a career out of being in the right places at the right times.
Re: A senior engineer's guide to the system design interview
#94Earlier quoted context omitted.
Few people at software companies are designing systems from scratch nowadays. If they are, they'll be gluing together third-party middleware applications like database systems, queues, proxies, load balancers, etc. A general understanding of computer architecture, programming language theory, networking and common protocols and formats is more valuable. At that fundamental level, they won't be using recent fancy buzz…
If you havent designed a system from scratch, or designed a major change, you arent a senior engineer.
these "system design interviews" often focus on systems at the scale of major consumer internet companies, e.g. "design youtube", "design twitter".
How many systems of that scale even exist? 100? Only the core developers of those systems would be considered "senior engineer"?
Re: A senior engineer's guide to the system design interview
#95I think it's funny how they say you don't need experience to pass one of the interviews. Last time I went in to one of these as an experienced engineer I probably said all sorts of things they didn't want to hear like there's no point building a scalable system until you're sure your product has traction. That and I kept trying to extract imaginary requirements. I still have no idea what they wanted to hear so I just…
> Last time I went in to one of these as an experienced engineer I probably said all sorts of things they didn't want to hear like there's no point building a scalable system until you're sure your product has traction. So.. you argued with the interviewer about their question being 'invalid'. That's not going to be a winning strategy. If you have to insist on making comments like these, a better way to express it wo…
I don't know why you assume I was rude about it. I phrased it all equivalently to how you said. A lot of my background was in tech services so I'm very well practiced in asking these kind of questions. They pretty much waved off all of them saying it wasn't relevant.
Re: A senior engineer's guide to the system design interview
#96Earlier quoted context omitted.
There’s no penalty. There are plenty of technologies that you’re working with that aren’t under NDA. We’re not asking you to diagram what you’re working on, we asking you to diagram something technical that you understand well.
Being able to use something you've intimately worked on as part of your job is a huge advantage since you're so familiar with it.
There have to be parts of what you work on that are not covered by NDA. Solving problems like this would be indicative of someone we would want on our team.
Re: A senior engineer's guide to the system design interview
#97Earlier quoted context omitted.
I like this... in theory. But I don't think I'm allowed to give you a system diagram and detailed explanation of systems I've worked on, because obviously they're proprietary. That seems like a problem. How do your candidates normally work around this? Does everyone just talk about hobby or open-source systems they've worked on?
98% of what you'd be inclined to diagram out and explain for a system design interview isn't remotely proprietary. People are generally looking for a high-level overview of a system you've worked on to see a) that you've really worked on it and b) you can explain it such that it makes sense. Sure, folks will ask you to drill down here and there for more detailed info, but if someone pokes on something where the detai…
I'm not a lawyer, but wouldn't anything you or anyone else developed on company time at another company be owned by that company and thus proprietary?
In practice I can't imagine the spirit of any law would be violated by doing an architecture diagram, but it seems likely (to me, at least) the word of the law would be violated.
Re: A senior engineer's guide to the system design interview
#98Earlier quoted context omitted.
Exactly. Not to mention high level business logic could be inferred from system architecture. Sure sounds like a good way to perform recon on a target company.
We say specifically “diagram a technical system you understand well.” It’s going to be challenging to work in technology if the only technical system you understand well is the one you’re currently working on and only the parts that are under NDA.
I have the opposite question from other people in the thread - this seems pretty open-ended.
Just as an example, I do bioinformatics work, and "technical system" for someone I'm interviewing (as I understand your question) might encompass any of:
- a workflow manager: how it works under the hood, common patterns for modularity/reuse or configuration
- a specific pipeline: the stages of cleaning and quantifying raw data, the rationale for various stages and the tools chosen to execute them (including how to benchmark various methods against each other)
- a specific third-party tool: theoretical details of the algorithm, practical considerations for when to apply one over another
- familiarity with common general-purpose packages or APIs (e.g. pandas, numpy, scikit-learn)
- QC: common metrics for QC'ing various experimental data, how to decide if data is "good enough", how to troubleshoot biological vs technical (lab) vs technical (computational) sources of error
- biology: technical details of an experiment, the technologies generating the data, or the underlying biology
- data analysis: how to choose and make relevant figures, any of many data-science/ML topics (e.g. clustering), connecting data to relevant domain questions
- devops: data storage/management on HPC or cloud, HPC job schedulers, any of many cloud topics (e.g. IAC, setting up a database or cloud execution of a pipeline)
I'm more curious about how you guide a candidate towards selecting a system that gives you the most relevant perspective on their thinking and skillset - do you provide any suggestions, or are there typically pretty evident choices based on the role?
Re: A senior engineer's guide to the system design interview
#99Earlier quoted context omitted.
> DO NOT say things like "we should add a cache to reduce latency” We should add a cache to reduce latency tho…
yeah, not sure what is too hard to understand about that. Perhaps it depends on the context but I highly doubt you can go wrong by saying a cache should be added to reduce latency.
The way it typically fall aparts for my candidates is I ask about optimizations, they say X could be cached, then I ask about cache invalidation and lo and behold, it didn't even occur to them that the cache needs to be invalidated at some point, so they blurt something along the lines of doing the entire expensive operation again and checking it against the cache, or something similarly nonsensical.
More common than I'd like to admit.
Re: A senior engineer's guide to the system design interview
#100I think to be frank, this gamification of interviews is BS.
I’ve built actual production systems at scale. The fact that I need to follow a guide to “demonstrate” my ability to someone who 9/10 hasn’t built (or couldn’t build) anything at scale in production shows where we are in the absurdity matrix.