Live data from Hacker News

A senior engineer's guide to the system design interview

interviewing.io

291–300 of 399 posts

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

#291

Earlier quoted context omitted.

Well I mean your experience isn’t any different than applying for a job that uses Python when you’ve only used C++. Sure, they can train you to learn Python, but they’re specifically looking for a Python developer. They’re not looking for a generic “person that can learn stuff” when there are many Python developers out there that can pick up the job day one. In your case, you had to put in a lot of work because you e…

Weird example since letting you take an interview in a different language than they use is very common

I don’t agree because not all interviews work that way, especially for teams that write cpp and c — they don’t let candidates interview in JS for instance.

I had a high level eng join a domain specific team I was on and he didn’t do well because he didn’t know the domain very well. He had general skills around leadership and communication that someone of his level should have, and it kept him afloat, but for a high level technical IC you need to be at worst fluent in the domain and at best a technical leader in the group.

At lower levels of IC generalist is fine, the blast radius of your technical decisions is smaller so it’s less risky to learn on the job.

But yeah, not knowing the domain you’re going to join, whether it’s a type of work or a programming language, you won’t be as effective.

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

#292
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

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

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

#293
post #86

> Interviewers want to engage you in a back-and-forth conversation about problem constraints and parameters, so avoid making assumptions about the prompt. As someone who has conducted countless interviews at a FANG, I can not stress this point enough. The ability to just talk about a problem makes a big difference between a mediocre interview and a great interview. Besides, it's what makes an interview fun or lame.

Problem is: as candidate you don't know if "engaging in a back-and-forth conversation about problem constraints" is something the interviewers want. Some interviewers want it, but it's not always like that. And, no, usually discarding an entire company just because the interviewer on duty doesn't like "engaging" is BS.

Well good thing you don't have to read their mind. Communicate. Ask them. Like the above poster said, you are there to have a conversation, not deliver a lecture.

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

#295
post #279

Earlier quoted context omitted.

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…

> 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 Then we need a better test, but the gamification and badgering isn’t effective imo. > And once in a while some genius superstar 10x programmer comes along who is too good for these silly interviews... well that's fine we don't need that arrogance eith…

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.

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

#296

Performative interviews are bullshit. I’ve been working as an Engineer for 20 years - successfully. But you want me to “whiteboard” like a trained monkey?

> But you want me to “whiteboard” like a trained monkey?

Well yes, that's the point. You applied to be a Google code monkey and are surprised that they are asking you to do tricks?

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

#297
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…

Well folks, you heard it here. Average latency is rarely important and if someone presents a very standard and common way to reduce latency of a system, you should dismiss them because they should be aware that your specific system that they have no knowledge of would result in 99% of cache misses.

I used to work at Google long ago in the platforms division, in fact I worked on the BigTable cache (among other things, mostly related to performance). It would be very sad indeed if today's SRE book dismisses caching as a vital and standard optimization strategy and instead plays all kinds of gotchas with potential candidates as I believe you're doing.

With that said, you article you linked does not in any way support your claim about caching, on the contrary it hardly discusses caching at all. It's as if you just wanted to dump a document you thought I wouldn't read as a way to be dismissive.

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

#298
This is, unfortunately, painting an overly rosy view of the interviewer.

A lot of the time your interviewer is just going to be some senior person with an interview guide. They'll be asking you to design Netflix, without any experience with video or streaming themselves.

Rather than "trying crazy stuff", I've found that an important step is asking a few questions early in the interview to see if they understand relevant concepts. You can't take it for granted.

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

#299

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

If your employees go to a competitor and make a secret sauce that tastes the same, how do you judge what is the source of knowledge?

They can have used their skills to come up with a recipe that tastes the same because the requirements led to that outcome, or they simply copied your recipe.

If somebody from OpenAI goes to a competitor and creates something like ChatGPT, where is the line crossed that shows that company IP is transferred? The employee knows how to create the system because he knows how ChatGPT works. If he recreates a similar system but doesn't say that it is a copy of ChatGPT, is that applied skill or is that a violation of the NDA?

If it is a violation, how could he forget the structure of ChatGPT to genuinely come up with a new structure?

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

#300

This is, unfortunately, painting an overly rosy view of the interviewer. A lot of the time your interviewer is just going to be some senior person with an interview guide. They'll be asking you to design Netflix, without any experience with video or streaming themselves. Rather than "trying crazy stuff", I've found that an important step is asking a few questions early in the interview to see if they understand relev…

Interviewing is a two way street. You can judge the company as much as they judge you. If you find yourself in front of such an interviewer then move on somewhere else.
Post reply on HN