Live data from Hacker News

A senior engineer's guide to the system design interview

interviewing.io

21–30 of 399 posts

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

#21
post #18

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…

Feels like an Architect interview more than a Senior interview though

As a former (reformed?) non-coding architect, non-coding architects are a scourge on the industry. I know you didn't say "non-coding" but if it's a separate job, they're very likely not spending enough time coding.

Seniors should be able to build large, interconnected systems. IMO that's a basic skillset required to reach that level, and part of why I roll my eyes when I see people with 5, 4, 3 years of experience claiming to be seniors.

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

#22
I remember once I was interviewing for a senior position where the ask was something like "design a general purpose system for a REST layer on top of an ORM."

I had just finished implementing an OSS solution that did exactly that, including some upstream changes we made to improve the system, so I walked through exactly what we did, challenges we faced, etc.

I walked out of the interview feeling as though the interviewers and I didn't speak the same language; they might've said the same. Not only did I not get the job, I never got another communication from the company.

To me, senior level interviewing, especially at smaller companies, is fraught. A full 1/3rd of the companies I've interviewed at would not have been a good "culture fit," and I'm a picky interviewer. I expect, like coding tests etc, these interviews are not aligned with the real travails of the position - growing talent, managing time, triaging, and ensuring stability/capability.

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

#23
I got such fatigue from scrolling through so very much prologue, introduction, expectation-setting, and general "here is what we are going to say and here is how you may expect we will say it" fluff that I gave up, pages in, before getting to any apparent content.

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

#24

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…

One place I interviewed with last year did something similar in that it was more of a BYOSD (bring your own system design). So it meant I got a chance to think through complex systems I've worked on, mock up a diagram beforehand, and then present it to the interviewer. They then drilled down on a lot of components, why decisions may have been made, etc. Sort of like what you're saying.

Out of all the similar interviews I did last year for that type of round, I enjoyed that style the most. Rather than your typical "build me an {ecommerce site, social network, video streaming site, url shortener}".

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

#26

Earlier quoted context omitted.

That trivializes our profession and hard earned experience simply because a degree is not a requirement. It is ridiculous to say drag'n'droping something is halfway to being a systems designer. And the anecdote about "experience at facebook" was such nonsense. "I worked at facebook doing something other than distributed systems, and geez, I learned nothing about distributed systems". "QED!" p.s. I missed this ad hom…

Just because you work somewhere doesn’t make you an expert at what they do. My Home Depot cashier is incapable of installing the carpet I bought from them. There are levels. Everyone wants to pretend they have FB or Google scale when they are building only to find out they have Ruby on Rails scale after year 4. They don’t need a Stanford grad. They need a feature developer or someone who can break apart the monolith…

We're in mild agreement, so somewhere there has been a misreading/miscommunication on either my part or yours :O

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

#27

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…

hmm interesting approach, really like it. Where do you work? and are you hiring now?

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

#28

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…

best way of doing interviews imho. apart from anything else, it gives you a chance to show that you know how to design/implement a system that is perhaps more complex than the one you are being interviewed for

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

#30

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?

Post reply on HN