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

381–390 of 399 posts

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

#381

Post by John23832 »

nfoz wrote: post #375
John23832 wrote: post #313

Earlier quoted context omitted.

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 juni…

> If my house had a pest problem, I would need to hire an expert in pest-control.

The result from the expert is that you as the layman can look around and see no pests (which anyone with their naked eye can do)… you’re not judging them on their knowledge of pesticides.

> 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.

This is a fantastical maybe. The interview was system design.

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

#382

Post by John23832 »

volkk wrote: post #376
John23832 wrote: post #305

Earlier quoted context omitted.

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 t…

Frankly, you don’t anything about what it’s like to work with me.

But to answer more genuinely, it’s a fact that most developers have never and will never work at web scale. Also, if you have ever worked at a FAANG, you would know that a majority of the topics that are involved in these hazing loops aren’t directly used in the dad work of most developers.

Rather than focusing on me, focus on the point I was making about the deficiencies in the hiring loops of tech companies.

It’s not ego it’s the reality of working in tech.

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

#384

Post by emmo »

kridsdale1 wrote: post #215
rednerrus wrote: post #125

Earlier quoted context omitted.

There’s no place where we are asking you to diagram the system that you’re working on. We ask you to diagram a system you understand well. Are you using messages queues, container orchestration, network components, cloud infrastructure, Java/rust/go/Python/etc.? Tell me about one of those components and how they connect together in theory vs the specifics of your system. Everyone who works in technology works with, m…

I worked at apple in the past. It would be a violation to answer your questions.

I feel like I'm either losing my mind or people are being deliberately obtuse now.

He's not saying they ask you to give a full overview of the way Apple architects their systems, he's saying they ask you to explain how a basic Kubernetes deployment might look, or how you might go about setting up some kind of backup system, or literally any of a million different technical things that you might have knowledge of and interest in.

How could things like this possibly be under NDA? If you weren't able to use any of this knowledge, you would be completely crippled in your work.

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

#385

Post by danielmarkbruce »

rco8786 wrote: post #103
eschneider wrote: post #92

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. 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…

> 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].

That would fall into the 2%. At least in my experience, the 98% number is in the ballpark. If you are working on backend services in big tech, what you are building is quite different than most software systems.

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

#386

Post by [deleted] »

meese712 wrote: post #275
Infinitesimus wrote: post #220

Earlier quoted context omitted.

"I'm known for hiring the best engineers". BUT if you're really known for hiring the best engineers, please show us your accomplishments! You just told us you look for trivia which means you're great at hiring engineers who are good at language trivia. That set has a pretty small overlap with "best" engineers. "Best" itself has a small overlap with "useful" engineers. Your trivia knowledge is great to impress like mi…

This is not trivia. For better or for worse truthy evaluation is a fundamental part of the language which is what this code snippet appears to be primarily testing.

[deleted]

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

#387

Post by xapata »

meese712 wrote: post #259
xapata wrote: post #122

Earlier quoted context omitted.

> best engineers Precision is different from recall. You're asking trivia. I'd rather ask questions that can't be studied for, only practiced through years of experience. I also sometimes hire people who don't know JavaScript, yet.

Don't see how you could consider the question they posed to be trivia for someone who knows javascript? Abuse of truthy evaluation is very rampant. All the JS codebases I've worked on are filled with `if (!myArray.length)` and etc. I would be very sad if anyone with a year of JS experience couldn't get this problem.

By trivia, I mean it can be thoroughly explained in a paragraph or two.

Separately, if it's the kind of thing that can be learned in less than a year of experience, it's not helpful for determining whether someone should be hired as a senior engineer.

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

#388

Post by strus »

I develop desktop and embedded applications, so do a different work than distributed systems engineers, but I wonder - do you often build systems from scratch and therefore need to have all this knowledge?

Because in every job I've worked in the past 10 years, I landed in an established project, that was developed years ago, and my work was to maintanace and add new features. Most of these projects were too big and complicated for one person to know how they work in every detail - even the ones that were there for the very beginning always said something like "after all these years I don't know how half of the things are implemented".

So, from my perspective, an interview question where someone asks me to design a complex system entirely on my own, in details, is just stupid, as I am pretty sure I will never do anything like that in my life. But maybe webdev is a different story?

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

#389

Post by sophonX »

John23832 wrote: post #365
sophonX wrote: post #358

Earlier quoted context omitted.

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)

You are supposed to structure it. I know their internals on a high level but I work with internals of a oss engine. I know how their read / write paths vary, data structures for storage, for locking, for request scheduling, checkpointing algorithms, scheduler, etc.

The point is you've to structure your knowledge in a way the other person can understand. There is no value for any company, if you can't share whatever knowledge / experience you've in a structured format.

Not everyone is familiar with internals of commonly used tools but the underlying patterns or concepts remain the same.

If you can't explain that, then you are lacking in communication skill or maybe no one ever gave you feedback. It's just a matter of time.

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

#390

Post by sophonX »

John23832 wrote: post #367
sophonX wrote: post #357

Earlier quoted context omitted.

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.

[flagged]
Post reply on HN