A senior engineer's guide to the system design interview • Hacker News Board

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

#371

Post by fileeditview » Fri, Mar 03, 2023, 3:56 PM UTC

reactordev wrote: post #8

eternalban wrote: post #3

"You can pass system design interviews even if you’ve never designed distributed systems before. If you have copied files between machines with drag-and-drop, you are halfway there. If you implemented clients or servers or have opened network connections, you’ve got this. This guide will teach you the most important 20% of information that will appear 80% of the time in system design interviews. By the end of this gu…

The reality is you can become an engineer with no degree whilst you can’t become a surgeon with no degree. The criticism of the writing is dismissing that a lot of people want to go for that promotion or higher tier but due to imposter syndrome or lack of confidence, abstain. This guide is to help them overcome those fears and level up. If you have an issue with people leveling up, good luck to you.

I don't know how this is elsewhere but in Germany you cannot become an engineer without a degree. You can work somewhere in an engineering field but you are no engineer.

And BTW here computer scientists / programmers / developers are officially also not engineers.

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

#372

Post by Swizec » Fri, Mar 03, 2023, 4:06 PM UTC

Naracion wrote: post #343

Swizec wrote: post #114

Earlier quoted context omitted.

> 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 theory yes, in practice ... if that's true, why would anyone ever hire you for your experience? You wouldn't be allowed to use it.

(coming from the standpoint of a historically non-technical individual contributor who is leaning towards technical now, and asking because I want to learn): But isn't that exactly why you as an interviewer would pose a problem, set up the context that is potentially similar to the work your project would require, and see how the interviewee navigates that?

Yes, it is. I would want to know how a person solves my problems.

And I sure would hope they bring all their experience to bear! Just because they learned about CDNs at their previous job and “everything is proprietary”, I don’t want them to suddenly forget how CDNs work.

Very little is actually unique between software businesses. We’re mostly just doing data bureaucracy.

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

#373

Post by eschneider » Fri, Mar 03, 2023, 4:45 PM UTC

bcrosby95 wrote: post #241

eschneider wrote: post #109

Earlier quoted context omitted.

Sure. But the level of description that you're giving in an interview can be pretty generic/non-proprietary. If that wasn't the case, then you really can't reuse any knowledge from job to job and that's just not so. Sure, every company is going to have their 'special sauce' components, that ARE proprietary, but nobody's going to expect you to unpack those.

I doubt it's common, but my friend had an experience where they kept trying to direct him towards specific technical topics of particular interest to the business. He worked for their competitor, but not in the capacity the interviewer was trying to delve into, so in addition to scummy, it was pointless and annoying. At some point my friend cut the interview off.

Which is the proper thing to do.

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

#374

Post by rednerrus » Fri, Mar 03, 2023, 4:46 PM UTC

emodendroket wrote: post #191

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…

To be honest, since I have to go through preparing for the standard style of interview before a job search anyway, all these novel forms seem like annoyances.

We’ve found that candidates prefer this because it doesn’t require a ton of prep. Talk about something you know well in a conversation with other engineers. Do some minor diagramming as you go to help us understand. It’s thirty minutes with no gotchas.

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

#375

Post by nfoz » Fri, Mar 03, 2023, 5:00 PM UTC

John23832 wrote: post #313

nfoz wrote: post #284

Earlier quoted context omitted.

What's the sour taste -- what's the problem? Like, what's wrong with being interviewed by someone with less experience than you?

How can someone less experienced that you gauge your competency for a position that requires more experience than they have? That’s before wondering why they’re asking a question to gauge my competency when they don’t even understand the nuance of the question themselves. An interviewer working on google’s enterprise nosql db but not knowing about (at least on a surface level) the breadth of nosql dbs doesn’t seem cr…

If my house had a pest problem, I would need to hire an expert in pest-control. I need to do that without being an expert myself. How should anyone be able to hire someone with more experience than themselves, in your view? I've sometimes had to 'hire my own boss'.

Maybe the criteria for the problem was less "did they check these boxes" and more "could they be a collaborative mentor willing to work with even the junior members on the team" in the context of designing a system.

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

#376

Post by volkk » Fri, Mar 03, 2023, 5:07 PM UTC

John23832 wrote: post #305

paxys wrote: post #295

Earlier quoted context omitted.

Cool then go design a better process that picks out the best engineers on the planet without asking them any engineering questions. Clearly you are smarter and have accomplished more than anyone at any company you have interviewed with, so it should be a cakewalk for you. Heck you can make billions by finally cracking the tech interview problem.

Lol woah. I’m just giving my perspective on the problem. Your response seems like you’re hurt. Maybe I’m not the one with an issue after all.

To be honest, you seem like the one with an issue. You're rejecting the general norm which is at this point painful, and everyone agrees, but it's the best thing we have. Your excuse to rejecting it is your own ego shooting outwards -- "99% of people haven't done what i have." That's cool and all, and I'm sure you're a very smart person, but just by the fact that you wrote this, I can tell you might be very painful to work with and would already be a huge red flag. Kill your ego and your experience in the world will be much better

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

#377

Post by yunwal » Fri, Mar 03, 2023, 5:47 PM UTC

mgraczyk wrote: post #149

yunwal wrote: post #127

Earlier quoted context omitted.

> People with real experience will have encountered this problem and know that you have to spend time investigating to find the root cause of the backpressure, otherwise you could add capacity to random things without reducing the queue occupancy. Are your queue consumers getting throttled by some downstream service? Are your workers CPU bound? The "right" answer here is basically "we should figure out why the queue…

This might be true of SRE roles, but not really true for most engineers, particularly not where I currently work. I wasn't completely clear but what I'd be asking for here is how to predict and design for bottlenecks, not how to mitigate active disasters. Also making a queue bigger is a bad reflexive response to queues being full. I was very involved in the SEV review (postmortem) process at Facebook and witnessed lo…

> Also making a queue bigger is a bad reflexive response to queues being full.

Depends on the function of the queue. If it's a dead-letter queue, there's literally no downside besides a likely-trivial amount of cost. If the problem is upstream of the queue, and the queue is actively feeding well-functioning consumers, yeah, it could make things way worse. This is where being an experienced engineer comes in. Also having 2-person approval like you would for any code changes. Point still stands that you should take low-risk actions to mitigate if they're available to you before root-causing.

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

#378

Post by fatnoah » Fri, Mar 03, 2023, 5:57 PM UTC

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…

> Now that I'm in the system, the other stark reality is that little of this system design matters. Most of the challenge is understanding the internal technologies and figuring out who to talk to to get stuff done (like pretty much every big company).

A few years ago, I did my round of "big tech" interviews as a manager and was somewhat naive in that I did zero prep work, but I did have almost 2 decades of actually building systems. I found system design to be the "easy" and fun part of the process (including at Google). However, if I didn't have experience with scaling and redundancy in web applications, it wouldn't have been nearly as fun.

That said, once I was in the door (different big tech co), there was absolutely zero need for any of that knowledge. Now that I'm back at a startup, it's all relevant again!

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

#379

Post by arolihas » Fri, Mar 03, 2023, 6:01 PM UTC

LastTrain wrote: post #192

leeny wrote: post #129

Earlier quoted context omitted.

Hey, founder of interviewing.io here. We actually did zero thinking about SEO. We had someone look at this guide at the end through an SEO lens, but then we decided that that would make the content not as good and would make the guide less readable. (As an aside, I think in recent years, the spirit of SEO has become more about just making good stuff and less about hacking...) Anyway, it wasn't for SEO. It's hard to e…

> It's hard to edit stuff well because we're so passionate about what we wrote here, and we probably should do another pass. No way, I’m dying here. “… and my main weakness is probably that I care too much…”

These people don’t have to think about SEO because it’s already been embedded into them. BS corporatespeak at their very core, the perfect type to sell interview gaming.

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

#380

Post by Salgat » Fri, Mar 03, 2023, 6:41 PM UTC

rednerrus wrote: post #335

djur wrote: post #233

Earlier quoted context omitted.

The problem you're asking them to solve is a legal one, but you are not interviewing lawyers. I have never worked for a single employer that didn't require an NDA, and the NDAs are always written in a way that can be easily interpreted as "do not tell anyone anything about what you do here".

The question is not tell me what you do in your current job. The question is describe a technology or system that you understand well. Do you understand how the underlying systems work? You don’t have to tell me that your current company uses kubernetes to describe how kubernetes works. Your current job can’t keep you from describing how kubernetes works. Kubernetes is just an example here you could pick any technolo…

You're asking them to explain a technology they use while expecting them to tiptoe around what they're actually allowed to say about how they applied the technology. And you say this replaced your system design interviews. It sounds to me like someone explaining what Kubernetes is won't do nearly as well as someone who can explain in-depth how they applied Kubernetes to their job.