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?

  • 4
    +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... Commented May 10, 2011 at 17:33
  • 6
    If it's an existing product, I'd shoot back with, "What do you find deficient in your existing design?"
    – Blrfl
    Commented May 10, 2011 at 17:34
  • 5
    "well.. step 1 would be contacting a lawyer to see if we're violating any trademark or copyright" Commented May 10, 2011 at 17:41
  • 12
    "Mind if I see the requirements documents?" Commented May 10, 2011 at 18:30
  • 4
    "Never used it. What are its main features?" Commented May 10, 2011 at 19:52

11 Answers 11


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.

  • 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. Commented May 10, 2011 at 18:35
  • 2
    +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
    Commented May 10, 2011 at 20:23
  • 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." Actually all that will do is test their recall of design work they have done already. The interviewers are mostly looking to see how they will attack new problems. Commented Jan 11, 2014 at 19:23

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.

  • 2
    So an expected answer to the question is some UML diagrams, simplified at least? Commented May 11, 2011 at 6:01
  • 3
    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. Commented May 11, 2011 at 18:05

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.


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.

  • 1
    where do you work and do you need new employees? :D
    – Maggie
    Commented Nov 11, 2013 at 22:22
  • 1
    While all the examples for what you call a "good answer" might be relevant. The question was to "Design a system that....". Considering that this is an interview situation so one would expect to only have 5 to 10 minutes at most to answer, most of what you identified seems off in the weeds for an interview solution. Where is the actual solution in your "good answer"? Once the person has the "happy-day" solution then they could start considering the "what-ifs" that you are referring to in your "good answer". But by then, I would think time has run out.
    – Dunk
    Commented Jan 23, 2015 at 17:38

I also ask this kind of question, and I agree with most of the other answers. Maybe it would help interviewees to understand WHY this type of question is important? Suppose we have an important business decision to make, and in order to do it, we need to build a new system. If someone runs up to you and asks what it would take to build a system that does X, can you give them an insightful answer that predicts the major challenges and resources required?

A junior programmer has no idea where to start. They are not ready to start talking without a detailed specification. A senior programmer will instantly see that there are many facets to the issue, and will attempt to hone in on a challenge. You don't have to architect every aspect, just identify an architectural challenge and then figure out how to address it.

Consider the issue of Google Docs:

One interesting thing is the shear scale of requests that will be coming. You can't just get a single server and deploy your code to it - this is a larger undertaking. A successful interviewee might zero in on this and will describe the types of resources that will be needed, and some of the technical challenges in implementing at that scale, with an application that not only has state, it shares state across multiple users.

Another interesting thing about Google Docs is that multiple people can edit at the same time. A successful interviewee will be able to discuss mechanisms for making sure the resulting doc isn't garbage, and a truly great candidate will realize that different methods of synchronizing or merging edits will have a big impact on performance and UX. Maybe even discuss variations: A shared document editor for writing code should probably use a different method of resolving conflicts than the typical Google Doc, because there are different consequences to things happening in a different order or having slightly different structure.

There's no single right way to create an app like Google Docs, you don't have to identify what you would do for every trade-off, but it's really great to find an area that has an interesting issue, and clearly explain what the trade-offs might be.


  • I upvoted because you are the only answer who geared their answer to an "architectural" design solution. As that is the best you could do in the context of an interview for a problem of the given scope. An interviewee who understands that an architectural solution is all that can be accomplished, shows that they know what they are doing.
    – Dunk
    Commented Jan 23, 2015 at 17:47

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?

  • 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. Commented May 10, 2011 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 Commented May 10, 2011 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. Commented May 10, 2011 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. Commented May 10, 2011 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.
    – user3792
    Commented May 10, 2011 at 18:43

For me, if the person doesn't start off with identifying the key use-cases/stories then that would be enough to know they aren't prepared for a position requiring this particular skill.

Afterwards, they should be able to come up with an architectural solution based on the key use-cases/stories. Hopefully they used some systematic process for identifying modules other than pulling them from their.... I wouldn't expect much more from an interview situation for the solution.

However, I might pick one of the architectural modules and ask for a more detailed design, just to see if they have some design skills. It would also be nice to see that they consider the failure cases/performance issues. But I suspect at this point, we would be running into a time wall. Thus, I really couldn't penalize them for not considering these issues because there's only so much time and I think it is reasonable for them to assume that considering every possible scenario is not expected out of a time-limited interview situation.


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.


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.


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.

  • 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
    Commented May 10, 2011 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
    Commented May 11, 2011 at 4:31
  • (continued) please don't underestimate the importance of lessons learned from other sources.
    – rwong
    Commented May 11, 2011 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
    Commented May 11, 2011 at 14:07

The point behind asking this kind of a question is to gain an insight into your mind. A common question I use is to ask programmers to design a system that can simulate PacMan.

And yes, I look for use cases first, it shows me that the person is thinking. Then, for multithreading, consideration of data structures first (ones that could be used for the problem, then more appropriate or specific ones with the whys of the decision).

This is a considered must for senior development positions. It is both silly and pointless for people to sit and answer questions on sort implementations at this level of developer experience. System design is what I would expect at this level.

Not the answer you're looking for? Browse other questions tagged or ask your own question.