Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A senior engineer's guide to the system design interview

interviewing.io

Post reply on HN
Print view View original

361–370 of 399 posts

Re: A senior engineer's guide to the system design interview

#361

Post by Yoric »

yieldcrv wrote: post #139
azornathogron wrote: post #30

Earlier 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?

At this point I just build on top of other take-home projects I've done and pretend like its my portfolio.

That, I must admit, is extremely tempting.

Re: A senior engineer's guide to the system design interview

#362

Post by Yoric »

spike021 wrote: post #24
rednerrus wrote: post #9

We'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…

One place I interviewed with last year did something similar in that it was more of a BYOSD (bring your own system design). So it meant I got a chance to think through complex systems I've worked on, mock up a diagram beforehand, and then present it to the interviewer. They then drilled down on a lot of components, why decisions may have been made, etc. Sort of like what you're saying. Out of all the similar intervie…

How did it go?

Asking for a friend who's going to have exactly that kind of interview in 10 days :)

Re: A senior engineer's guide to the system design interview

#363

Post by time_to_smile »

mgraczyk wrote: post #53

I am on the interviewer side of ~1 system design interview per week and have done probably around 100 of them at Google and other companies. Most of the advice here is good, although it could be condensed quite a bit. The biggest red flag for me as an interviewer is when candidates list off concepts or technologies they don't understand. DO NOT say things like "we can't do this because of the CAP theorem" or "we shou…

> although it could be condensed quite a bit.

I bet I can condense this even more: it's yet another FAANG shibboleth that starts out as a good idea and the evolves into a ritual candidates need to perform until they can identify that they are "in".

Google Algorithm/Whiteboard interview has morphed into a generation of robots that can solve any LC problem but are incapable of building anything real in software.

Currently I think there are more books out there on "passing the systems design interview" than there are on actual systems design.

Re: A senior engineer's guide to the system design interview

#364

Post by bluedevilzn »

mgraczyk wrote: post #260
Kranar wrote: post #257

Earlier quoted context omitted.

But that's not true, the total latency including a cache is: P(cache_hit) * cache_read_latency + (1 - P(cache_hit)) * cache_miss_latency Assuming your scenario of 99% cache misses, that means you need a cache whose read latency is less than 1% of the cost of a cache miss. There are plenty of ways to design such a cache so that you still get a net performance benefit, even in your greatly exaggerated scenario. One ver…

You are talking about minimizing the expected or average latency, which is very rarely important. The actual goal will depend on the broader system but typically you want to minimize the latency of the worst 95%, 99%, 99.9% etc of requests. Whether or not the cache reduces latency depends on the distribution of the cache hits. In practice, items that miss a simple LRU cache often have the longest latency in other par…

I work on Ads latency at Google. If we remove our cache, our p95 will definitely suffer. We have experiments to confirm this.

In fact, one of the key projects that is being worked on is to improve caching to reduce latency both at median and at tail.

Re: A senior engineer's guide to the system design interview

#365

Post by John23832 »

sophonX wrote: post #358
John23832 wrote: post #314

Earlier quoted context omitted.

If you want to explain what a timeseries db is to someone who has no clue in a 45 minute (already time constrained) systems design interview (where you’re supposed to be actually showing how you would design a system), be my guest.

The issue could be time management and every database has same set of features but different implementations. One of my teammate keeps talking and sometimes loses the context. We usually step and get on track. He has improved a lot in past few months. You might be in similar boat.

I know how to give concise descriptions of complex problems. The issue was that the interviewer didn’t understand the proposed tool.

Every db definitely does not have the same set of features. The read and write characteristics of dbs vary widely, the underlying storage and indexes vary as well.

There’s a huge difference in usecases between postgres (relational), redis (in memory cache), and influxdb (timeseriese)

Re: A senior engineer's guide to the system design interview

#366

Post by rco8786 »

stale2002 wrote: post #173
rco8786 wrote: post #103

Earlier quoted context omitted.

> 98% of what you'd be inclined to diagram out and explain for a system design interview isn't remotely proprietary Maybe we're just on different wavelengths, but literally every single thing I work on that would be a good candidate for this sort of interview is extremely proprietary...and I'm just working on regular ol' backend services at [generic big tech].

If the entirety of your web development knowledge is NDA'ed, then what good are you as a potential employee anyway? You wouldn't be able to build anything, as all your knowledge is NDAed!

What on earth are you even talking about? I can't build anything, because the stuff I have built is covered by NDA?

Re: A senior engineer's guide to the system design interview

#367

Post by John23832 »

sophonX wrote: post #357
John23832 wrote: post #278

Earlier quoted context omitted.

> There's a good chance at my career phase I have more experience than the interviewer. This happens a lot. I was once in the process for google and was asked a time series systems design problem. I said, “lets throw this in a time series db”. The interviewer had no idea what a time series’s db was. Mind you this was an interview for Google Cloud and the person worked on SPANNER. They also has been at the company for…

why not design it ? Anyone can say to throw in a time series db but what about it's internals ? How do people judge if you can build or add a feature without asking you to design something ?

The proposed problem was not to build a time series database. It’s a system design interview.

Re: A senior engineer's guide to the system design interview

#368

Post by eternalban »

monsieurbanana wrote: post #39
eternalban wrote: post #32

Earlier quoted context omitted.

I somewhat take issue with this. (3+ decades of very hands on (read: coding) architecting, including some learning experiences in orbit. I've been coding code-doodling since teenage years.) A lot of what non-coding architects traditionally brought to the table has been taken over by experts designing OSS protocols, data formats, etc. Take things like data frames that are now exploding in ML space. Seniors today, agre…

I always thought that non-coding architects still had at least some background in coding. What does the path of a never-had-coded architect looks like?

Possibly effective doodling in the design space of systems? I personally hacked at untold number of experiments with different approaches, and was doodling like mad over at least a decade. I have bookshelves full of notebooks covered with object graphs, system sketches, etc. It's not just coding.

Re: A senior engineer's guide to the system design interview

#369

Post by lampshades »

brunooliv wrote: post #319

I will read this as it seems really good. However, it always feels like a catch-22 problem to me, in the sense that, if you've never worked at a large company before, you can't claim to have truly used or understood large scale systems properly to work on them or design them in production. I got rejected from a large tech company after failing system design and this was exactly their reasoning: "you seem to know the…

I took a downlevel to get my foot in the door.

Re: A senior engineer's guide to the system design interview

#370

Post by _dain_ »

rickreynoldssf wrote: post #117

First off, I'm not disparaging the content, I'm sure its good and useful in interviewing at most companies. ...that said. This kind of thing annoys me. You shouldn't have to study for an interview. Either you meet the requirement and have the experience or you don't. Reading books and stuff like this is really a cheat by the person being interviewed. You many have studied enough to "pass the test" but you really don'…

I've never written a line of Javascript in my life but that test looks trivial.

    a.filter(x=>1)
guessing that arrow looking thing is syntax sugar for a lambda that always returns a 1, then it's implicitly cast to boolean true in the filter, so nothing gets filtered out and b ends up just the same as a.

    !!1
not not 1 -> true

    b.some(e=>e>6)
at least one element of b greater than 6, clearly true

so both arms of the && are true, so foo() gets called.

I don't think this is a very good test if someone like me can pass it just by making educated guesses.

Post reply on HN