Resources for learning system design.

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

nadbor
Posts: 8
Joined: Sat Jul 06, 2013 12:32 am UTC

Resources for learning system design.

Postby nadbor » Wed Feb 26, 2014 8:55 pm UTC

I'm interviewing with google and palantir and have others queued in case these two reject me. One topic they ask about which I'm not quite comfortable with is system design. By system design I mean mostly two things:
- object -oriented - UML sketching type of questions, often quite abstract like "design class hierarchy for a parking lot"
- more practical, performance oriented design - "how would you design youtube search feature"
I am not very good at either of these and have no idea how to practice them. Learning to solve algorithmic problems if not easy is at least straight forward. You read about the basic techniques and then practice them by solving problems from sites like leetcode or spoj until you feel confident. If you can't solve one, you read other people's solutions until you start seeing the patterns. As far as I know nothing like this process exists for system design questions. There are of course books on software architecture but they seem much too general to be of much use in the context of interview prep. I understand why it is harder to write a book "1001 system design problems and solutions" than "1001 tree traversal problems and solutions" but I don't think it's impossible. "Cracking the coding interview" for example contains a couple of such problems that I found very helpful - it's just that there were not nearly enough of them. Does anyone know of any resources for learning these things (books, blogs, videos - anything). Question - answer type of thing would be perfect, but I will take anything I can get.

I have asked this question on stackoverflow
http://stackoverflow.com/questions/22027599/resources-to-learn-solving-system-design-interview-problems
so far no answers. For the interested - Palantir has a relevant note on their blog
http://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/
It's at the same time informative and not very helpful.

lgw
Posts: 437
Joined: Mon Apr 12, 2010 10:52 pm UTC

Re: Resources for learning system design.

Postby lgw » Thu Feb 27, 2014 8:28 pm UTC

A writer writes. A designer designs. There's no other way to learn, AFAIK. So, practice designing simple things. Pick problems, where you understand the problem domain such as your technical specialty or day-to-day stuff, for which there's either an existing automated solution/product, or for which you could easily imagine one. Design that automation. See if you can take your design down to roughing out interfaces, then move on to the next one.

I loathe UML but if you must there's UMLet, which is quite awesome in it's simplicity. But simple boxes and arrows usually get the point across. A design should describe both dependencies (what class knows about what other class: minimize these) and workflow (how does data move around to solve the problem). It should be obvious how a design solves the underlying business problem (i.e., real world need of the user).

Easy to describe, hard to do. But practicing getting your thoughts in order without rat-holing on specific implementation details can help. Real-world coding from design to product, over and over, will give you judgment on the content of a good design, but that's really problem domain expertise more than design skill. Being able to clearly explain the solution such that someone else can code it is design skill.

For a junior programmer they're not really looking for either design skill or problem domain expertise, they're looking for both reasonable communication skills (can you explain technical ideas well enough to participate in design discussions) and signs that you understand real-world coding. Did you think about performance? Did you think about what things can go wrong outside of your control, and how you can recover or at least fail gracefully? Did you ask for more details about the problem's corner cases, and resolve ambiguity in the question before jumping in? That last one is a big deal. I've interviewed with most of the big names, and at every place except Facebook, they're more interested in whether you have a professional approach to problem solving than how fast you can bang out an answer for the most obvious case (Facebook really wants programming contest winners).

For a senior position it's quite different, as design skills become more central. In my most recent interview, I was asked to give a design overview for a quite complex problem involving tens of thousands of active servers as part of the phone screening, before they'd even bring me in for an interview. For my previous job, one interview session was "how would you design a hypervisor feature to move a running virtual machine from one host to another with no/minimal disruption." Fun stuff, actually, but I've never heard of such questions for non-senior positions.
"In no set of physics laws do you get two cats." - doogly


Return to “Coding”

Who is online

Users browsing this forum: Ereyokax and 8 guests