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

391–399 of 399 posts

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

#391

Post by Jiocus »

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…

This sounds like an enjoyable interview, even from the applicants point of view.

Do you follow up on your decisions to see how it held up regarding false positives you did accept, if any? I mean as related to the heuristics, not performance review generally.

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

#392

Post by dilyevsky »

emodendroket wrote: post #311
sockgrant wrote: post #292

Earlier quoted context omitted.

Was on a team this happened on and a lot of the l4 l5 Eng gossiped about how little our L7 knew

I don't think someone gossiping about how their work superiors are fools is really notably strange to be honest.

I dunno where you worked but this is def not normal at least within technical ladder ime

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

#393

Post by Kinrany »

mgraczyk wrote: post #150
yodsanklai wrote: post #132

Earlier quoted context omitted.

> I feel like I can easily see through interview practice or coaching, so I don't recommend spending more than an hour or so "preparing" for system design interviews. I'm very surprised by this recommendation which doesn't match my experience at all. First, lots of candidates don't have experience building such systems, so they need to learn by reading books and articles. Second, the candidates need to be familiar wi…

As an interviewer, my job is to differentiate between people who have experience vs people who have just read books and articles. I interview mostly L6+, so I will not recommend people who I don't believe have real experience building complex systems at scale. I think it only takes an hour or so to become familiar with the structure. I can tell during the interview if that's the problem and I will be very patient in…

What is the difference between real experience and books in your opinion? How similar does the experience need to be to the problem at hand for it to be relevant?

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

#394

Post by lazyant »

Quick thoughts:

  - System design interview changes depending on the company. At Facebook the interviewer said one sentence in the whole interview to me, no feedback or anything, so be prepared for nasty ones. At Google they hate if you use a particular product to solve your problem and everything needs to be backed up by numbers; they'll ask you how many servers you'd need for your solution ("bill of materials").   
  - Expanding on last comment, it's common to see in books and courses a basic math of number users -> estimate usage -> requests per second and storage needs but I've never seen anyone take one estimates about servers by computing processing (CPU/RAM) needed.  
  - This guide, like almost all resources in particular takes on the most common case of web design: client-server request/response (plus queuing). There are other completely different paradigms that show up less frequently and are harder to have experience on, like streaming and batch processing.  
  - As all guides given space/time limitations, some key concepts are hand-waved with a recipe-based approach.

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

#395

Post by nvarsj »

dilyevsky wrote: post #231
nvarsj wrote: post #159

Earlier quoted context omitted.

No offense meant, but your comment already shows your inherent bias. You are looking for people who have solved specific system design problems. That means you are already being overlay narrow in your selection criteria. I have a background in quant dev and HFT for example. When I was doing system design for big tech (at L6 level), I found that the kind of system design questions asked had very little overlap with my…

Like other commenter pointed out you were interviewing for what basically amounts to “tech lead” role without relevant experience. I’m not sure other L4-5s on the team would be happy if someone less experienced is hired in a TL role

Big tech interviews aren't team specific or even experience specific (with some exceptions). Teams do a wide variety of work, including stuff similar to low latency C++/Java, and team selection doesn't happen until after passing interviews.

It's not really a question of relevant experience at all - it's about passing the standardized exam that is a big tech interview. Experience comes more into play when doing team selection afterwards.

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

#396

Post by hnfong »

jamesdepp wrote: post #327

As someone that is still in undergrad but will be entering the labor market in a few years, this entire process makes me incredibly anxious to think about. Reading what some people go through to find decent jobs has been a huge stressor throughout my undergrad career. I was lucky enough to secure a good internship this summer (which took months of searching and getting ghosted). I’m not excited to run the rat race ag…

Luck plays a huge factor, but generally the crowd on HN are opinionated and bitter. That said, if you're really brilliant and way above your peers, the luck factor drops significantly. Anyway, your experience will likely vary. Don't worry too much.

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

#398

Post by roguas »

nvarsj wrote: post #159
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…

No offense meant, but your comment already shows your inherent bias. You are looking for people who have solved specific system design problems. That means you are already being overlay narrow in your selection criteria. I have a background in quant dev and HFT for example. When I was doing system design for big tech (at L6 level), I found that the kind of system design questions asked had very little overlap with my…

> Most of the challenge is understanding the internal technologies and figuring out who to talk to to get stuff done.

This is something interesting that often is skipped due to "sterile" nature of system design questions(solve puzzle). 90% of system design problems are tightly connected with how your org works internally. Can you depend on particular team or is it better to provide requested functionality internally. This is very often neglected but this moves or breaks stuffs.

Imagine you have to build a complete traffic system architecture for the city that will start settling in a year? It will likely be ongoing thing for you, you will observe how street layout works and adjust, build new streets, make city highway from point A to point B etc. but over time. Doing this apriori is going to go horribly bad.

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

#399

Post by [deleted] »

bradlys wrote: post #146
apsurd wrote: post #137

Earlier quoted context omitted.

Your point is good, but in making it, you sound like an adversarial interviewer. You and OP are actually agreeing with "the correct answer is it depends and now let's discuss context". This echoes my experience as interviewer too. It's a red flag when the candidate responds with "the correct answer". That's what OP is calling out. I'm replying here because I get the impression you're looking for "the right answer" as…

> Your point is good, but in making it, you sound like an adversarial interviewer. Most interviewers are adversarial. Let's be honest - if an interviewer wants you to pass a system design interview, they'll make it work. I see this with particular candidates all the time. If we want the person to make it through - we'll let them get through. If we don't want them to get through - no amount of correct and behaviorally…

[deleted]
Post reply on HN