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

351–360 of 399 posts

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

#351

Post by aurbano »

everydayentropy wrote: post #255
stale2002 wrote: post #173

Earlier quoted context omitted.

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!

This comment is a prime example of how the non-technical founder understands the world. Proprietary systems are company IP. Talking about the design of the system is protected by the NDA, which the exercise described above is asking the candidate to do. You hire for the skills to develop your own proprietary system. The employer doesn't own the skill. The employer owns anything those skills produced for the employer.…

I think they mean something like:

[Client]->[Cloudfront]->[Load balancer]->[ECS service in a VPC]->[RDS/other internal systems]

* Replace the above with any other cloud provider, or just commercial/open source tools that do the same job running in a VPS or whatever *

I can't see how any of this could be claimed to be protected by an NDA or similar, as this is just a highly standard architecture.

If you work on a proprietary system that has a specific architecture just don't mention that of course. I think the above allows us to discuss things pretty well, talk about introducing caching, why each layer is there, TLS termination, authentication/authorization concerns and implementation, secrets management...

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

#352

Post by alistairSH »

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!

It’s the difference between being asked “how would you design a Twitter clone?” and “How did you design [current employer’ssystem]?”

The first is generic (unless you happen to be a current Twitter employee). No NDA impact. The second is asking you to reveal details of a proprietary system covered by NDA (or if you’re a Fed contractor, covered by various classification laws).

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

#353

Post by joenot443 »

azornathogron wrote: post #30
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…

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?

What is the vector you’re concerned about here? You sketch out a diagram so well that the company you’re interviewing with takes a photo and secretly integrates it into their stack? Then your past employer catches wind of this, realizes you were the only person in the world to understand this system, so they go after you for damages? Sorry man, I don’t see it.

I understand that you see your past work as “proprietary”, but in the real world the vast, vast majority of us do not work on systems shrouded in such secrecy. There’s nothing interesting or proprietary about CRUD infrastructure and I genuinely can’t think of a situation where you’d be exposing yourself to any real risk by explaining it to a new employer.

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

#355

Post by mysticllama »

best system design interview advice i got (and put to successful use in loops with goog and fb) was to not try to give the "right" answer -- it's like a professor grading papers on a topic they've taught countless times, you have more of an opportunity to fail than you do to succeed. instead, be decisive and give answers or approximations for any questions that arise, and bring your unique perspective to the problem -- in my case i have a background in mobile app development, so i spent a lot of time speaking to those use-cases.

if you try to cover every base and fret about everything being optimal, you're going to barely have time to get started.

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

#356

Post by sophonX »

blue039 wrote: post #177
hot_gril wrote: post #156

Earlier quoted context omitted.

Companies already look at resumes, and the interview is a good way to double check things in a pass/fail manner. It's not like the SAT where you take a single test that sorta determines where you go, but even that is useful as a broad measure. Like if I'm in a top school's admissions and see 1800/2400 (idk the new scoring), there'd better be an explanation. If Amazon saw my resume and I couldn't explain to them gener…

These interviews are not gutchecks. They are shibboleth checks. I can design you a nice document, do the research, put the pieces together, etc with the big picture. I may not know a ton about AWS or another cloud provider but I can put the document together that describes how it will be looking when it's done. That is architecture . Somewhere between UML and word documents. What these interviews are checking, and th…

You are interviewing for the wrong companies. You are a great fir for infra teams or something like my team :)

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

#357

Post by sophonX »

John23832 wrote: post #278
blue039 wrote: post #112

Earlier quoted context omitted.

Yeah, I don't think I want a job that asks such questions. I've done the webscale BS. I've done actual architecture that exists in reality. At this stage in my career there's nothing an interviewer can do but insult me. You might say that this is hubris about my own skill but it has nothing to do with how good I am. My resume has a LOOONG track record of consistent work in the industry. Call my references, do some ac…

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

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

#358

Post by sophonX »

John23832 wrote: post #314
paxys wrote: post #283

Earlier quoted context omitted.

If you can't be in a room with a more junior engineer and explain your ideas in simple language by drawing a few boxes on a whiteboard, then yeah you are probably not a good fit for these positions.

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.

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

#359

Post by layer8 »

layer8 wrote: post #228
nfw2 wrote: post #209

I think there may be an error in part 2 of this guide where it talks about ACID. To my understanding, the C (Consistency) in ACID is referring to the structure of the database. In other words, a SQL table can't be updated in such a way that violates the column definitions and constraints defined by the table. In this guide, it seems to be talking about strong consistency vs eventual consistency when discussing ACID,…

Yes. The Consistency property means that at the end of every transaction, the resulting data state in the DB will be consistent with the schema definition, including any constraints, triggers, etc. In other words, no transaction will result in invalid data with respect to the schema definition. This is similar to soundness in programming languages.

To add: Strong vs. weak/eventual consistency is more related to the Isolation property of ACID.

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

#360

Post by sophacles »

paxys wrote: post #279
John23832 wrote: post #100

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

I get what you are saying, but I have done tech recruiting for a long time and the reality is that everyone claims they have built complex production systems at scale. Everyone has lofty resumes with the choicest buzzwords. Everyone can come up with war stories about how they single-handedly kept the internet alive. And everyone can write the names of a dozen references who can vouch for all of this. The moment you s…

You're asking the wrong question. You want the people with stories about how they broke the internet and remained on the same team or even advanced.

Those are often the people with enough skill that they were put in a position that they could break it in the first place, and who provided enough value that even afterwards they were still allowed the opportunity to do it again.

Like the airplane bullet hole story.

Post reply on HN