How do I design an arbitrary system in an interview?

How do I design an arbitrary system in an interview?

up vote  15 down vote favorite 3

A common question in Tech Interview is to design a particular system, usually an existing product of the company. For example, "Design Google Docs". What is the expected answer for such a question? I mean, such systems surely have a complex design which is beyond the scope of any interview. What are the interviewers expecting in such a short time? interview share | improve this question edited May 11 '11 at 16:52 user8 asked  May 10 '11 at 17:26 Shamim Hafiz 1,675 3 12 29

3   +1 A friend of mine was just asked this the other day. I said the same thing. I strive to ask open-ended interview questions. Ask the interviewee about their projects and the how's/why's of their design. This way they can tell me about something they already know and have done. Instead of stumbling through white-board design wondering whether to start at the requirements or make a bunch of assumptions because the obvious time limit... –   P.Brian.Mackey  May 10 '11 at 17:33 4   If it's an existing product, I'd shoot back with, "What do you find deficient in your existing design?" –   Blrfl  May 10 '11 at 17:34 3   "well.. step 1 would be contacting a lawyer to see if we're violating any trademark or copyright" –   Steve Evers  May 10 '11 at 17:41 9   "Mind if I see the requirements documents?" –   Joel Etherton  May 10 '11 at 18:30 2   "Never used it. What are its main features?" –   Steven A. Lowe  May 10 '11 at 19:52 show 6 more comments

8 Answers

active  oldest  votes

up vote  7 down vote accepted

Insight into how does your brain look at this problem. Here are a few starting points that I could see for how one could try to have this conversation: Top-down - Looking down from a very high level build out a design and flesh out the design as various components get done and here are a handful of components that I could see.... Bottom-up - Looking from the ground up, here are bits and pieces one could build to try to put together.... Requirement clarification - Asking questions about the projected scale, size, budget, and team used for this design. You could try to have a person code a very simplified word processor or you could plot to spend hundreds of millions of dollars to make the ultimate document management system that you believe is how you Google Doc taken to an extreme. Also in here is the ability to ask something like, "What do you mean by Google Doc? How much of that functionality are you wanting to duplicate?" questions as well. The key is how well can you communicate your thoughts and approach on tackling this kind of problem as you may get a user approach you and ask, "Psst, could you make something like this in 2 weeks?" that could actually happen. Thus, how you give the answer is more important than what is the answer. My personal opinion would be that past projects aren't a good idea here. What one is trying to find is what kind of creativity and communication skills in a new area rather than just recalling how something was done in the past. Chances are that while something that happens in the new position may be similar to something from the past, there may be just enough differences that the old solution isn't feasible. This is why while what may be built is similar to an existing application, there may be various customizations that make the solution quite different from the initial example. Interviews are a two-way street. Managers and other developers are rarely masters of interviewing so I'm not sure I see the value in trying to state that they should be subject matter experts at job interviews. Recruiters I could see expecting to know how to do an interview, but there are plenty of poor recruiters that could be used as examples of why this isn't always a good idea. share | improve this answer edited May 10 '11 at 19:25 answered  May 10 '11 at 17:41 JB King 16.1k 1 25 62

2   It is better to ask the interviewee about a project they are familiar with. This way you can see how their mind works during their true work process. You can stop them and ask for clarification of details to see just how deep their knowledge of their domain goes. "Why didn't you use an interface as a parameter to the method?" Then, its up to you as the interviewer to ask the right questions. This is proper as the interviewee is in your domain...not their own. –   P.Brian.Mackey  May 10 '11 at 18:35 1   +1 if I could: "The key is how well can you communicate your thoughts" ... unfortunately, I believe that the majority of both interviewers and candidates are deficient in this area. –   Anon  May 10 '11 at 20:23 add comment

up vote  6 down vote

It's about seeing your thought processes in action; they're not interested in a solution, but how you would approach solving the problem, what questions you would ask, what issues you would identify, etc. Given the example of Google Docs, the obvious issues that come to mind are things like storage, security, scalability, availability, client interface design, browser compatibility, etc. How would you divide responsibility up between server and client? How would you handle backups? What happens when a server goes down? What would you do with "abandonded" documents (stuff that hasn't been accessed or modified in a long period of time)? Again, the point is not to solve any of those issues, but to identify them, talk through them, brainstorm a bit about how to address them, etc. share | improve this answer answered  May 10 '11 at 18:22 John Bode 5,905 9 28

add comment

up vote 5  down vote

Especially for senior developers, I think these questions can be very good. They show that a developer is capable of moving from a large, complicated description toward a realistic implementation. Even with a totally unfamiliar system, you should be able to do a number of interesting activities for the interviewer: Gather requirements to answer the question (e.g., scope) Break the problem down into more manageable pieces; possibly identify interfaces or objects that might be needed, or break the logic up into front-end, back-end, DB, etc. Demonstrate familiarity with the structure and concepts behind that type of system, e.g., web apps in the case of Google Docs Show what you tend to focus on when presented with a design problem (Object design? SQL tables? Design patterns?) Show the boss a preview of what it will be like to develop a new system with you, where the boss walks in with a spec and says, "What would it take to build this?" This question is just a higher-level version of "Describe the object hierarchy you would use for this . . ." "Describe the interface you would design for this . . ." "Design a set of relational DB tables for this data . . .", etc. that would be given to junior to mid-level developers. In lower level developers, the interviewer might be evaluating the person's long-term potential for growth in the company, or just seeing what they do when faced with a large problem that could possibly be overwhelming. share | improve this answer answered  May 10 '11 at 19:58 Ethel Evans 4,492 12 32

So an expected answer to the question is some UML diagrams, simplified at least? –   Shamim Hafiz  May 11 '11 at 6:01 1   I think simplified UML would be a common part of the answer. Server diagrams could also show up. The key thing is to show that you aren't stymied by the size of the problem and that you can move smoothly from a vague concept to a real architecture (with concrete - not vague - problems to be solved). And then communicate that architecture. The interviewer might also be listening for whether you go for current best practices or head towards solutions that are out-of-date. –   Ethel Evans  May 11 '11 at 18:05 add comment

up vote  1  down vote	I had an interview recently where I was asked to design an elevator control system. Basically they want to see your approach to the task. If you're being asked this question, they probably have a very high-level job in mind for you. Congrats. share | improve this answer answered  May 10 '11 at 18:43 Mike Brown 15k 2 25 58
	add comment

up vote 1 down vote

The key thing is how you go about solving problems versus the merits of the solution you give, and if you are capable of dealing with big-picture problems. I think one important thing to do is ask questions about the requirements. Don't just make assumptions that will enable your pet solution to work. For example, you may happen to know some really nifty method for printing documents that you may be tempted to jump right into describing. But Google Docs doesn't print directly; it produces a PDF that the client then prints. So if you start with that, you'll have blown half your time solving a problem that's not not part of the problem, and have demonstrated that you're more interested in using your hot technology than solving the customer's problem. share | improve this answer answered  May 10 '11 at 18:59 JohnMcG 1,383 3 12

add comment

up vote 1 down vote

I'm one of those guilty parties who frequently ask this type of question in interviews. (For the record, I also ask similar questions about their "favorite project.") The reason I ask is that it's something we frequently do around here. We get design engineers from all sides of an interface, someone from systems engineering, someone from test, and someone with some knowledge of customer use cases for the feature. We stand around a whiteboard and say, "Okay, how are we going to build this thing?" Often you know very little about the new feature at that point and are only there because of your expertise in your part of the system, but you are still expected to contribute productively. It's not just a hypothetical academic exercise. As far as what kind of answers I expect, take for example, designing a system to download new firmware from a server, through 20 embedded line cards in a central office to upgrade 5000 set top boxes in the field at once. Assume there is very little spare capacity on the link between the server and the line cards. Bad answer: Um, I would probably use ethernet or something like that. Good answer: How large an image are we talking about? [Around 7 MB.] Well, you'd want to make sure service wasn't affected during the download. You'd need extra flash or RAM to store two images at once. You'd probably want to cache the image on your line cards in order to avoid downloading the same image over and over from the server. Being embedded, your line cards probably have limited CPU themselves, so you might need to serialize the downloads in order to leave enough capacity for service. You'd want some way to verify the image was good and fall back to the old version if it didn't work. You'd need some way to retry a few times and report errors to a human if the upgrade fails. If you have different brands of set top boxes, you'd need some kind of way to identify which image you need to send it. Those are almost word for word transcriptions of two different candidates. Most candidates are somewhere in between, but usually get there in the end with a little prompting, which is perfectly okay. We're not looking for the next Einstein here, just an indication that you can actually reason intelligently about the kinds of problems we work on every day. share | improve this answer answered  May 10 '11 at 22:27 Karl Bielefeldt 48.7k 12 92 205

where do you work and do you need new employees? :D –   Maggie  Nov 11 at 22:22 add comment

up vote  1 down vote

I suspect that what the interviewers want to hear is: Google Doc is a web interface for a word processor. User documents are typed and stored, and are retrievable by the user on the same or a different computer. What would you like to discuss further? Then, the ball is in the interviewer's court. If she wants more detail, she can ask. What the interviewer is looking for is, can you look at a problem or a product, and extract the design? share | improve this answer edited May 11 '11 at 14:16 answered  May 10 '11 at 17:34 Gilbert Le Blanc 2,096 7 17

1   Answer is good, but don't think the Interviewer will be satisfied with it. Reading on posts so far, it seems such questions are not popular among interviewees. –   Shamim Hafiz  May 10 '11 at 17:37 -1 @Gilbert Le Blanc - The "ramp up" time defined by Brook's law in The Mythical Man Month makes this question silly at best. If we know it takes roughly 6 months to learn to add value to a software project, what can be expected of "design extraction" in a mere 6 hours? en.wikipedia.org/wiki/Brooks%27s_law –   P.Brian.Mackey  May 10 '11 at 17:43 1   @Shamim Hafiz: Based on your question and comment, I'd say this question is not popular because you and others have a hard time narrowing the scope of the question. JB King's answer is more complete than mine. His bullet points are all valid ways of narrowing the scope of the questions, although I'm partial to top-down first, then requirement clarification. In plainer English, first draw the analogy, then highlight the differences. –  Gilbert Le Blanc  May 10 '11 at 17:46 4   If I was interviewing I wouldn't be pleased with that answer. The answer here just tells me what google docs is, something I already know already. –   whatsisname  May 10 '11 at 18:00 1   @whatisname - I think the interviewer would want to know the answer to the question (or a ballpark) in the context of an interview. –   Morgan Herlocker  May 10 '11 at 18:43 add comment

up vote  -1 down vote

In order to handle this type of interview questions, you will need to have a general interest in understanding "how things work", not just in projects you're interested in but also projects that you feel are too remote from your experiences. This means reading blogs, articles, http://www.infoq.com, Hacker News, etc. Even the hardware bluffs from Coding Horror. Despite that fact that you will forget most of what you've read (because those information aren't connected anyway to your work personally), there might be some tidbits which are the "seeds of imagination", and a tiny fraction of those seeds will germinate when you meet a similar problem in the far, far future. So, the interviewer is perhaps interested in your reading habit (as part of your hobby) and see if you have a regular habit to collect seeds of ideas from random places. share | improve this answer answered  May 10 '11 at 19:43 rwong 5,322 12 32

Uh, I don't know about you, but I look a lot more favourably upon developers who formulate designs based on facts and experience rather than stuff they read on a blog once. –   Aaronaught  May 10 '11 at 20:07 @Aaronaught: of course real experience from similar projects is infinitely more valuable than heard ideas. But when you are tasked with a project in an area where you don't have experience, do you just give up the opportunity? (Assuming you let the employer know that you do not have relevant experience and the employer is okay with that) If you decide to take it, then how do you start? You start with lessons learned from other people, other companies and so on. You can't start from nowhere. Perhaps you were right downvoting me because the OP seems to be interviewing for a senior position, but –   rwong  May 11 '11 at 4:31 (continued) please don't underestimate the importance of lessons learned from other sources. –   rwong  May 11 '11 at 4:33 Fair enough, maybe the downvote was undeserved (although I can't remove it at this stage). Still, I really don't think that an interviewer would ask a question like this to learn about what you read; if they were, they would just ask what you read. What's important is to ask the right questions so you learn how it is supposed to work, not go off half-cocked based on scattered bits of information that may or may not be related. –   Aaronaught May 11 '11 at 14:07 add comment