Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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:
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.
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.
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.
-t.
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?
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.
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.
