Live data from Hacker News

A senior engineer's guide to the system design interview

interviewing.io

211–220 of 399 posts

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

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

It was some time ago and a limited sample but at one point there a was google recruiting presentation at my school.

When asked a reasonably simple question regarding expectations during interviews the google employees that were present each gave a drastically different answer(even after hearing their colleague).

The entire group covered the who spectrum of possible responses which lead me to believe that there was definitely a luck of the draw factor in who you get.

Perhaps they are more adherent to a rubric in 2023 which leads to these study guide type posts. Large company bullshit has never been my jam though so I never applied to find out myself.

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

#212
post #87

Earlier quoted context omitted.

Being able to use something you've intimately worked on as part of your job is a huge advantage since you're so familiar with it.

There have to be parts of what you work on that are not covered by NDA. Solving problems like this would be indicative of someone we would want on our team.

When I worked at Apple they made it abundantly clear that EVERYTHING was under NDA. Even things like “what version of the standard library do you use”. Or “what are computers for”. And that any minuscule transgression of the NDA would result in me Being immediately deported, divorced, and likely put in front of a firing squad.

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

#213
post #152

Earlier quoted context omitted.

Show me a system you’ve worked on that wasn’t put together from knowledge from previous education and jobs (yours and others), documentation from vendors, stack overflow, code generators , etc. I would hate to be a stakeholder in a company whose value depends on employees not talking about and reusing the incremental skills and knowledge gained while working there.

This is a pretty common situation in the US for folks who work on government contracts.

Yup. I’m outside DC. Somewhere near half my software engineer (and adjacent fields) friends are under contract to either the military or NSA/CIA. Most of them with TS/poly clearances. Ask one of the what they’re working on and the most you’ll get is something like “dig data on platform X”.

If platform X is something public, they could talk about the platform. But, talking about any project specifics, implementation details, etc would be a felony.

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

#214

Earlier quoted context omitted.

When I interviewed with apple they said pretty much everything they do is proprietary and considered secret. I imagine for some of these people working there for years it would be hard to avoid breaking nda

Nobody forced those people into that situation.

There's a lot of nobody in the context of interviewers making it expressly harder for those people to stop being that situation.

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

#215

Earlier quoted context omitted.

When I interviewed with apple they said pretty much everything they do is proprietary and considered secret. I imagine for some of these people working there for years it would be hard to avoid breaking nda

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.

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

#216

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 is pretty cool. I’d probably have fun walking through some systems I’ve designed

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

#217

Earlier quoted context omitted.

When I interviewed with apple they said pretty much everything they do is proprietary and considered secret. I imagine for some of these people working there for years it would be hard to avoid breaking nda

But, if you’re a web developer you should be able to diagram what happens when a browser makes a request

Ok yes because that’s colleges level material. The subject here is Staff Engineer (L6) interviewing. So that will require nearly all the demonstration of value to be of high level professional context.

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

#218

Earlier quoted context omitted.

I work for a big tech co, and our interview training explicitly says to not ask candidates about systems they have built in the past, but to ask them to build brand new systems from scratch. This seems completely backwards to me. Is like saying "hey, do you know that relevant on the job experience that you have? we don't want to hear anything about it, here you have a made up scenario". Ok ok, that is a bit cynical.…

We don’t ask people to describes systems the worked on previously. We ask them to diagram a technical system that they understand well.

If you are an expert one one system that you have built and maintained for ten years, then that’s all you know.

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

#219
post #203

Earlier quoted context omitted.

We say specifically “diagram a technical system you understand well.” It’s going to be challenging to work in technology if the only technical system you understand well is the one you’re currently working on and only the parts that are under NDA.

I literally can't diagram 90% of the stacks I've worked on in the last 8 years because they're highly NDA.

So draw the block diagram of something you worked on in school. Or, I don't know, a radio or something, if you're a hardware person.

Someone who answers, "I can't draw anything for you because everything I know about is somebody's private IP," isn't going to get the job. At least, not if I'm doing the interviewing.

You must know something about something else. Right?

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

#220

First off, I'm not disparaging the content, I'm sure its good and useful in interviewing at most companies. ...that said. This kind of thing annoys me. You shouldn't have to study for an interview. Either you meet the requirement and have the experience or you don't. Reading books and stuff like this is really a cheat by the person being interviewed. You many have studied enough to "pass the test" but you really don'…

"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 minded people but irrelevant if the problem space doesn't depend on it.

PS: Someone could consider you a pretty junior engineer if you ship: "if(!!1 && b.some(e=>e>6)){

foo();

}"

because the you're increasing the risk of error in a codebase that would likely be maintained by people of varying skills. You write code to solve problems and you write code so regular earth humans can grok it and manipulate it to solve problems.

Writing code with a high risk of introducing problems and misunderstanding does not signal senior in many domains.

Post reply on HN