Live data from Hacker News

Ask HN: What is best way to do hands-on practice for system design?

news.ycombinator.com

21–30 of 98 posts

Re: Ask HN: What is best way to do hands-on practice for system design?

#21
I know this isn't really what you asked, but I've administered hundreds of software engineer interviews, and there are two very common mistakes I see when it comes to system design:

1. Not clarifying the problem. The very first thing out of your mouth should be a series of questions that helps you define the requirements more clearly. Identify use cases. Try to understand the scale; questions that start with "how many" are good ones.

2. Not being concrete. For example, I had a design problem I'd give people that usually wound up with them sending lots and lots of messages in real-time from one system to another. But when pressed, very few people were able to describe the contents of those messages in any detail.

Just thought I'd pass that along in case it's helpful to you. And I'll second what a lot of other folks here are saying: the best way to learn this is to get experience.

Re: Ask HN: What is best way to do hands-on practice for system design?

#22
You don’t actually want that, I think. In practice systems start small, and stuff is added to them gradually. I consider this as a much bigger challenge than designing a “complex” system right from the start. The trick is to be able to keep a system clean over time, not to design it for a year and then just write down the code. So it’s fine to start with your small apps, but instead of throwing it away try to keep adding stuff to it and release more advanced versions say, every month.

That being said, there are a few well known examples of systems that are somewhat complex right from the start. Ecommerce comes to mind: build a configurable ecommerce framework that supports multiple stores, multiple vendors, multiple channels, CC and cash payments, multiple currencies, international delivery etc.

Re: Ask HN: What is best way to do hands-on practice for system design?

#23

Hmm. I think you might be getting at two different questions. One: How do you get better at systems design? Build stuff -- lots of stuff. If you're interested in designing particular kinds of systems (say, planet-scale web services...), then get a job at a company that does that kind of thing. Two: How do you get better at systems design interviews ? That's much easier; you can just throw money at the problem. Use on…

Big plus-one for the Systems Design Interview channel. I learned a lot from watching those videos (repeatedly) when I was preparing.

Re: Ask HN: What is best way to do hands-on practice for system design?

#24
post #21

I know this isn't really what you asked, but I've administered hundreds of software engineer interviews, and there are two very common mistakes I see when it comes to system design: 1. Not clarifying the problem. The very first thing out of your mouth should be a series of questions that helps you define the requirements more clearly. Identify use cases. Try to understand the scale; questions that start with "how man…

And I would add :

3. Not being specific about any technologies. Instead of using a "SQL Database" and a "cache", just say "PostgreSQL" and "Redis". It's an interview, if you're not specific, I will start thinking you don't have any experience with Redis or Postgres. If you really don't have any, I will find out anyway.

Re: Ask HN: What is best way to do hands-on practice for system design?

#25
System design interviews have so far been a bit hit or miss for me. All the interviewers seem to be looking for something, but I’ll be damned if I know what it is.

I think I’m inclined to incrementally solve potential problems with the system (as introduced by the interviewer), where a lot of these interviews seem to want you to anticipate all issues.

So asking lots of questions about what they want is probably a first.

Re: Ask HN: What is best way to do hands-on practice for system design?

#26
post #24
post #21

I know this isn't really what you asked, but I've administered hundreds of software engineer interviews, and there are two very common mistakes I see when it comes to system design: 1. Not clarifying the problem. The very first thing out of your mouth should be a series of questions that helps you define the requirements more clearly. Identify use cases. Try to understand the scale; questions that start with "how man…

And I would add : 3. Not being specific about any technologies. Instead of using a "SQL Database" and a "cache", just say "PostgreSQL" and "Redis". It's an interview, if you're not specific, I will start thinking you don't have any experience with Redis or Postgres. If you really don't have any, I will find out anyway.

I would think it doesn’t matter? Whether we use redis, memcached or anything else is irrelevant to the point, which is that you want ‘something’ to function as a cache.

Re: Ask HN: What is best way to do hands-on practice for system design?

#27
post #21

I know this isn't really what you asked, but I've administered hundreds of software engineer interviews, and there are two very common mistakes I see when it comes to system design: 1. Not clarifying the problem. The very first thing out of your mouth should be a series of questions that helps you define the requirements more clearly. Identify use cases. Try to understand the scale; questions that start with "how man…

> But when pressed, very few people were able to describe the contents of those messages in any detail.

Can you explain why this matters? It’s an architecture interview right? Not an API/Worker/Queue design exercise.

It’s not like I don’t expect someone to be eventually able to figure out the contents of the payload, I’d just not expect it to be at the forefront of their mind.

Re: Ask HN: What is best way to do hands-on practice for system design?

#28
post #24
post #21

I know this isn't really what you asked, but I've administered hundreds of software engineer interviews, and there are two very common mistakes I see when it comes to system design: 1. Not clarifying the problem. The very first thing out of your mouth should be a series of questions that helps you define the requirements more clearly. Identify use cases. Try to understand the scale; questions that start with "how man…

And I would add : 3. Not being specific about any technologies. Instead of using a "SQL Database" and a "cache", just say "PostgreSQL" and "Redis". It's an interview, if you're not specific, I will start thinking you don't have any experience with Redis or Postgres. If you really don't have any, I will find out anyway.

I would advise against it. Two reasons: - if the person interviewing you know the specific tech you picked, you give them an opening to control the interview. They can go anywhere they want and you would likely fall short unless you know the stack in&out

- when you pick specific technology, you also have to defend why this one specifically. For ex, why redis and not memcache or why only postgres and not redshift..

If you keep it at sql and no-sql, you can easily defend the answer and control the interview

Re: Ask HN: What is best way to do hands-on practice for system design?

#29
I know you didn’t ask for this but Me and couple of my friends at big tech who have given and taken 500+ interviews, do mock interviews for each other and references.

For reference we do paid 45 mins mock interviews. In case you are interested, dm me and I can share more details.

Re: Ask HN: What is best way to do hands-on practice for system design?

#30
post #24

Earlier quoted context omitted.

And I would add : 3. Not being specific about any technologies. Instead of using a "SQL Database" and a "cache", just say "PostgreSQL" and "Redis". It's an interview, if you're not specific, I will start thinking you don't have any experience with Redis or Postgres. If you really don't have any, I will find out anyway.

I would advise against it. Two reasons: - if the person interviewing you know the specific tech you picked, you give them an opening to control the interview. They can go anywhere they want and you would likely fall short unless you know the stack in&out - when you pick specific technology, you also have to defend why this one specifically. For ex, why redis and not memcache or why only postgres and not redshift.. If…

I would also advise against it. At this level i would expect the more abstractive way of thinking. I don't see a reason to go so much in detail right now. Model > tools.
Post reply on HN