http://www.programminginterviews.info/2013/11/how-to-answer-software-design-interview-questions.html
Design principles and philosophy: Before you even start your broader system design, talk about your design philosophy. That is, what are your guiding principles for a good design. For example, simple, robust, scalable, resilient to failures, etc.
Product requirements,
System requirement.
Which features would be Pri-0 versus Pri-1 and why: This is an optional part and you might give this more attention if the interview is more focused on product design than a system design.
Architecture:
Here you would define various components of the system, how they interact and the data flows. You would also talk about data redundancy, database backups, load balancing, etc.
Measurement and logging
Performance characteristics: You should also spend some time discussing the performance characteristics of your proposed architecture. Pay special attention to key operations and high traffic sections.
Geo-redundancy.
Define how the solution would scale.
Security
Talk about stability/health checks.
-- Local redundancy, failovers, uptime are important factors.
Deployments/Zero downtime
Think and define how zero downtime and rolling deployments will happen.
Proposed enhancements/improvements:
Since this is a first pass on design, talk about alternate design and different technologies.
For example, RabbitMQ versus QPID, PostgresSQL versus Cassandra. e
http://itgeekworkhard.com/study/2014/09/20/system-design-interview/
Clarify the constraints and identify the user cases
High-level architecture design
Component design
For each component, you need to write the specific APIs for each component.
You may need to finish the detailed OOD design for a particular function. You may also need to design the database schema for the database.
Clarify the scenario, write out user cases
Special system requirements such as multi-threading, read or write oriented.
Define objects
Map identity to class: one scenario for one class, each core object in this scenario for one class.
Consider the relationships among classes
certain class must have unique instance, one object has many other objects (composition), one object is another object (inheritance).
Identify attributes for each class: change noun to variable and action to methods.
Use design patterns such that it can be reused in multiple applications.
http://www.nomachetejuggling.com/2010/04/06/avoiding-the-big-design-interview-question/
What the interviewee is expecting...
Generally this question is asked to feel out someone's OO skills. Do they understand inheritance, polymorphism, abstraction, etc? Can they describe the relationship between a plant, flower, and petal (a flower is-a plant, and has-a petal)?
Talk with the interviewee about the requirements.
Start as simply as you can and only draw a new box when you've extracted enough information from the interviewer to deem it warranted.
https://www.linkedin.com/pulse/technical-design-interview-guide-success-joey-addona
The question will not have one right answer and the interviewer expects a good candidate to clarify the problem.
A good candidate will ask questions to clarify what is expected out of the design, and make sure their understanding of the end product is correct before continuing.
Once the product is clear, it is important to understand how the product will be used. Who is the target audience? If it is a program, what type of security will be needed? What should the end user experience?
How will it scale? These are the questions that need answers and the design decisions made should reflect the answers provided by the interviewer.
One of the worst interviewing experiences for an interviewer is a candidate who is messy.
Design is all about thought before implementation.
It is important that the whole solution makes sense and works together from the start. A candidate cannot just start to design big parts and then start to elaborate about what is happening in the middle, then move to the beginning, change a lot of things, jump to the end, change the middle, return to the end, and etc. It is confusing, and makes the candidate seem like they are unable to think through their approach.
Starting at the beginning and proceeding until the end and answering questions, and making multiple passes if necessary, is the best way to approach this problem.
They can do this by converting assumptions into questions such as “can I assume X?”. The interviewer should clarify if the candidate can or cannot make the assumption.
It is even better if the candidate can rephrase the assumption as a question. Instead of “I’ll assume that the max number of applicants is 100”, the candidate can ask “What is the maximum number of applicants this application should expect?”.
This shows a deeper attention to detail as well as a better comprehension and gives the impression that they are a stronger candidate.
A candidate should also give the interviewer explanations of the design. To say “we will use a lucene data store” is not useful. It is better if the candidate explains why they are making the decision, such as why a lucene store instead of an sql database?
A big mistake candidates make is assuming their decisions are obvious. It is likely the interviewer understands what the candidate’s doing and why, but ultimately the interviewer wants the candidate to explain their decisions.
The purpose of a design interview is to understand how someone thinks, and there is not one set way of thinking. Because of this variety, there will be many acceptable answers Here are some points on how to correctly judge a candidate in a design interview;
http://skife.org/interviews/design/2010/10/27/favorite-interview-question.html
to-read:
http://www.objectmentor.com/resources/articles/xpepisode.htm
http://www.sgdevs.com/2013/12/interview-question-design-object.html
Epic List of Interview Questions
http://katemats.com/interview-questions/
Design principles and philosophy: Before you even start your broader system design, talk about your design philosophy. That is, what are your guiding principles for a good design. For example, simple, robust, scalable, resilient to failures, etc.
Product requirements,
System requirement.
Which features would be Pri-0 versus Pri-1 and why: This is an optional part and you might give this more attention if the interview is more focused on product design than a system design.
Architecture:
Here you would define various components of the system, how they interact and the data flows. You would also talk about data redundancy, database backups, load balancing, etc.
Measurement and logging
Performance characteristics: You should also spend some time discussing the performance characteristics of your proposed architecture. Pay special attention to key operations and high traffic sections.
Geo-redundancy.
Define how the solution would scale.
Security
Talk about stability/health checks.
-- Local redundancy, failovers, uptime are important factors.
Deployments/Zero downtime
Think and define how zero downtime and rolling deployments will happen.
Proposed enhancements/improvements:
Since this is a first pass on design, talk about alternate design and different technologies.
For example, RabbitMQ versus QPID, PostgresSQL versus Cassandra. e
http://itgeekworkhard.com/study/2014/09/20/system-design-interview/
Clarify the constraints and identify the user cases
High-level architecture design
Component design
For each component, you need to write the specific APIs for each component.
You may need to finish the detailed OOD design for a particular function. You may also need to design the database schema for the database.
Clarify the scenario, write out user cases
Special system requirements such as multi-threading, read or write oriented.
Define objects
Map identity to class: one scenario for one class, each core object in this scenario for one class.
Consider the relationships among classes
certain class must have unique instance, one object has many other objects (composition), one object is another object (inheritance).
Identify attributes for each class: change noun to variable and action to methods.
Use design patterns such that it can be reused in multiple applications.
http://www.nomachetejuggling.com/2010/04/06/avoiding-the-big-design-interview-question/
What the interviewee is expecting...
Generally this question is asked to feel out someone's OO skills. Do they understand inheritance, polymorphism, abstraction, etc? Can they describe the relationship between a plant, flower, and petal (a flower is-a plant, and has-a petal)?
Talk with the interviewee about the requirements.
Start as simply as you can and only draw a new box when you've extracted enough information from the interviewer to deem it warranted.
https://www.linkedin.com/pulse/technical-design-interview-guide-success-joey-addona
- A candidate needs to clarify the problem by asking lots of questions.
- A candidate needs to explain what they are doing, and why they are doing so, in a clear manner.
- A candidate needs to end up with a complete solution which is not too messy.
- A candidate needs to be honest about their own knowledge.
- A candidate needs to know how their solution will scale.
- A candidate needs to know how and be able to redesign.
- A candidate needs to have a broad knowledge base about their subject.
- A candidate needs to have knowledge of how a full system.
Gather Intel
Design questions are supposed to test a candidate’s ability to design from start to finish so they will be intentionally vague in order to evaluate the process.
A good candidate will ask questions to clarify what is expected out of the design, and make sure their understanding of the end product is correct before continuing.
Once the product is clear, it is important to understand how the product will be used. Who is the target audience? If it is a program, what type of security will be needed? What should the end user experience?
How will it scale? These are the questions that need answers and the design decisions made should reflect the answers provided by the interviewer.
Break Down The Problem
Breaking down the problem into its major components is one of the key elements of design.
Jumping into solving the problem is not a good choice, as it tends to show the candidate is inexperienced and not thinking of the project as a whole.
A good candidate will take the time to break down the problem into its key components, and then proceed in describing how they envision each piece to work, followed by diving into extra details.
Do Not be MessyJumping into solving the problem is not a good choice, as it tends to show the candidate is inexperienced and not thinking of the project as a whole.
A good candidate will take the time to break down the problem into its key components, and then proceed in describing how they envision each piece to work, followed by diving into extra details.
One of the worst interviewing experiences for an interviewer is a candidate who is messy.
Design is all about thought before implementation.
It is important that the whole solution makes sense and works together from the start. A candidate cannot just start to design big parts and then start to elaborate about what is happening in the middle, then move to the beginning, change a lot of things, jump to the end, change the middle, return to the end, and etc. It is confusing, and makes the candidate seem like they are unable to think through their approach.
Starting at the beginning and proceeding until the end and answering questions, and making multiple passes if necessary, is the best way to approach this problem.
Communicate Your Design Decisions
A candidate has to make sure that assumptions and decisions are communicated.
This shows a deeper attention to detail as well as a better comprehension and gives the impression that they are a stronger candidate.
A candidate should also give the interviewer explanations of the design. To say “we will use a lucene data store” is not useful. It is better if the candidate explains why they are making the decision, such as why a lucene store instead of an sql database?
A big mistake candidates make is assuming their decisions are obvious. It is likely the interviewer understands what the candidate’s doing and why, but ultimately the interviewer wants the candidate to explain their decisions.
Ask Questions
As stated earlier, questions are important because they show that the candidate understands complexity and end goals.
A candidate should be constantly clarifying points, and makings sure they understand what the interviewer wants from the situation.
Interviewers for Software Design and/or Architecture problems do not expect the answer to be clear, and if the candidate just jumps into designing, the interviewer will feel the candidate is inexperienced and too trigger happy.
The more details that a candidate asks for, the more they show a deep understanding of design.
Wanting to know how many users to program for, or what tradeoffs need to be made, is something that happens in companies every day, and seeing that a candidate is able to do this in an interview will make the interviewer feel that they could trust this person if they were working with them.
A candidate should be constantly clarifying points, and makings sure they understand what the interviewer wants from the situation.
Interviewers for Software Design and/or Architecture problems do not expect the answer to be clear, and if the candidate just jumps into designing, the interviewer will feel the candidate is inexperienced and too trigger happy.
The more details that a candidate asks for, the more they show a deep understanding of design.
Wanting to know how many users to program for, or what tradeoffs need to be made, is something that happens in companies every day, and seeing that a candidate is able to do this in an interview will make the interviewer feel that they could trust this person if they were working with them.
Be Honest About Knowledge
Interviewers do not give design interviews to test a candidate’s technical skills. If a candidate never worked with databases and told the interviewer that they have little experience, but still make an effort to understand and design something with their limited knowledge, the candidate can still do very well in the interview.
The interviewer will be evaluating how the candidate thinks and not if they know every possible system in every way. As long as the candidate is able to learn, not knowing something specific is not a blocker as the candidate only needs to ask for a simple explanation of what is needed before continuing.
The interviewer will be evaluating how the candidate thinks and not if they know every possible system in every way. As long as the candidate is able to learn, not knowing something specific is not a blocker as the candidate only needs to ask for a simple explanation of what is needed before continuing.
Know How To Scale
The candidate is usually expected to explain how their software will then be able to work across multiple machines, and usually why it’s necessary.
A candidate should know what will happen to their databases, or in memory information, once it is split across machines.
A candidate should know what will happen to their databases, or in memory information, once it is split across machines.
Do Not be Afraid to Redesign
If the candidate realizes that what is asked for cannot be added in a nice way, and they redesign, this is points in their favor.
If the candidate decides to make abrupt changes and assumptions to accommodate the design change, at the expense of making things messier or more confusing, it would contribute to points against them.
It is important for a candidate not to redesign too much, since they will appear as inexperienced or unsure to the interviewer. The way for a candidate to avoid this is to consider the possible additions that will be proposed, and make a system that can adapt to change.
Alternately, a candidate can redesign portions of the solution instead of redesigning the entire thing.
If the candidate decides to make abrupt changes and assumptions to accommodate the design change, at the expense of making things messier or more confusing, it would contribute to points against them.
It is important for a candidate not to redesign too much, since they will appear as inexperienced or unsure to the interviewer. The way for a candidate to avoid this is to consider the possible additions that will be proposed, and make a system that can adapt to change.
Alternately, a candidate can redesign portions of the solution instead of redesigning the entire thing.
Know How Things Work… Even Just A Little
It is important for a candidate to know a little bit of everything when it comes to computers, even if their knowledge is not in depth, and even if the candidate has never actually used it.
https://www.linkedin.com/pulse/design-interview-from-interviewers-perspective-joey-addonaThe purpose of a design interview is to understand how someone thinks, and there is not one set way of thinking. Because of this variety, there will be many acceptable answers Here are some points on how to correctly judge a candidate in a design interview;
Define Expectations
Clarifying the point of the interview will give a better result in analyzing the candidate. Many candidates have little to no experience with design interviews, so expecting an understanding of how to act in a design interview can create a negative atmosphere even for a good candidate. Explaining the goal of the interview, advising that there will not be an exact solution, and stressing the importance of clarifying requirements if the candidates dives right into solving the problem can help provide an appropriate base from which an interviewer can fairly judge a candidate.
Choose Questions Without Answers
The point of a design interview is to assess the candidate’s ability to create a system.
If the candidate provides a working solution, is able to adapt to requirements, and defends their choices with valid points, their performance is good indication of what they can do once hired.
There are many paths to the same result, and expecting something to be solved a specific way can make a great future employee come off in a negative light.
If the candidate provides a working solution, is able to adapt to requirements, and defends their choices with valid points, their performance is good indication of what they can do once hired.
There are many paths to the same result, and expecting something to be solved a specific way can make a great future employee come off in a negative light.
Remain in Control of the Interview
A good way for the interviewer to maintain control is to ask the candidate to talk through a high level design, have them draw it out on a whiteboard, and then explain a more detailed design of each component based on the interviewer’s prompting. Once they design the top level, then the interview can progress with more specific points. This requires the interviewer to know the question rather well, and stay ahead of the candidate, while understanding their thought process and subject understanding.
Dealing with Design Flaws
One of the most important things to do in a design interview is to challenge the candidate’s design. Whether the design is right or wrong, the act of explaining and defending a design is an important skill for developers. Developers have to justify their designs every day, and explain why it is the best approach. Pointing out that a weakness in the candidate’s design, and seeing how they react and change their design is important because of its real life implications. Removing points for a bad design is reasonable, but if the candidate is able to fix the issue quickly and correctly then they should be able to redeem partial credit.
Ability to Grow >= Ability to Know
When a candidate uses lots of buzzwords (REST, Kafka, Database Partitioning, etc), challenge their knowledge of the subject and dive into some specifics before moving on.
This will allow the candidate to demonstrate how much they know, and give a better indication of their expertise.
The ability to learn and grow also gives a good indication of how well they’ll perform in a job.
An interviewer should do this by giving hints to help unblock the candidate. If a candidate gets hired, they’ll need to learn at a fast pace, so learning and adapting in an interview should be considered a good thing.
Too many hints will indicate a weaker candidate, but some hints and learning in an interview is important, because they won’t know everything when they are hired.
This will allow the candidate to demonstrate how much they know, and give a better indication of their expertise.
The ability to learn and grow also gives a good indication of how well they’ll perform in a job.
An interviewer should do this by giving hints to help unblock the candidate. If a candidate gets hired, they’ll need to learn at a fast pace, so learning and adapting in an interview should be considered a good thing.
Too many hints will indicate a weaker candidate, but some hints and learning in an interview is important, because they won’t know everything when they are hired.
Add Requirements
When a candidate creates a reasonable first design, the interviewer should change the requirements.
Asking the candidate to consider a lot of users or add a new feature will help understand how the candidate adapts. It is also important to note how “hacky” their solution becomes.
Good candidates will re-design in such a way that it appears as though the modified design was the original intent, whereas bad candidates will keep hacking through the product, and it will look messy in the end.
Asking the candidate to consider a lot of users or add a new feature will help understand how the candidate adapts. It is also important to note how “hacky” their solution becomes.
Good candidates will re-design in such a way that it appears as though the modified design was the original intent, whereas bad candidates will keep hacking through the product, and it will look messy in the end.
A Great Candidate (Type: Rare, Action: Hire on sight!)
Great candidate will need little to no help with their design, after they’ve gathered all the proper requirements by asking clarifying questions.
They will make a high level design, and then give details.
The design will make sense and the interviewer will have trouble finding problems with it.
When asked to explain parts of the design, the candidate will describe how the component works clearly and correctly. When asked to expand the design due to new requirements, the candidate will modify the design cleanly, or if necessary, re-design components.
They will make a high level design, and then give details.
The design will make sense and the interviewer will have trouble finding problems with it.
When asked to explain parts of the design, the candidate will describe how the component works clearly and correctly. When asked to expand the design due to new requirements, the candidate will modify the design cleanly, or if necessary, re-design components.
Good Candidate (Type: Common, Action: Hire if other interviews also go well)
A good candidate will clarify requirements, and start building a high level design.
Design flaws pointed out by the interviewer will be quickly fixed. When asked to explain parts of the design, the candidate will have little to no trouble explaining each component. They will have a high level understanding of the system, and will be able to adapt their design to new requirements. The design may appear a little hacked together by the end, but the overall design still looks like something that could be used to help build a real product.
Bad Candidate (Type: Common, Action: Hire if new to design)
A bad candidate will likely jump right into the design, and have to be asked to clarify requirements.
Mistakes will be common, and the interviewer will end up finding problems with their design often. When design flaws are found, the candidate will have some trouble fixing them, but ultimately will be able to.
Mistakes will be common, and the interviewer will end up finding problems with their design often. When design flaws are found, the candidate will have some trouble fixing them, but ultimately will be able to.
When asked to justify or expand the design, the candidate will have trouble doing so due to incorrect initial design or lack of knowledge. Their end design will have parts that are incomplete, and the design will often feel hacked together.
Horrible Candidate (Type: Rare, Action: DO NOT HIRE)
A horrible candidate will usually have no clue where to start. They will need the problem broken down for them, instead of breaking down the problem by themselves. When asked to implement a single part, they may do well, but will be unable to think of the project as a whole. There will be a lot of problems with the overall design, and the end result will either be a spoonfed result where the interviewer(s) gave so many hints that the solution was practically given to the candidate, or a result that is so far from complete that it would be useless in real life.
Given a hard drive with one terabyte of data, arranged in 2^32 key/value pairs, where the keys and values each have lengths of 128 bytes, you need to design, build, and deploy (by yourself) a system that lets you look up the value for a given key, over the internet, at a peak rate of 5000 lookups per second. The data never changes. Let’s design that system.
There is additional information available if the candidate asks for it, things like requiring responses in 100 millis at the 90th percentile, that the budget is, “well, we don’t know how much it is going to be worth until we see it in use for a while, so try to do it cheap, if it is too much we’ll just not bother building it,” and that we have a datacenter and a switched network we can put it on, but no pre-specified servers. We want 99.9% availability, measured on a monthly basis, but are not offering an SLA to consumers. The keys are not distributed evenly within the keyspace. Requests are distributed evenly (and randomly) across the keys (I do this to make the problem easier). Etc.
I’m looking for quite a few things as we go through the question. The first is their opinion of “a terabyte of data” and “5000 lookups per second.” Do they consider this to be a lot of data, or a fairly boring amount, same with the lookups per second. Leaning either way isn’t a failure, it is just information gathering for me, and referencing it against how you represented yourself in your resume, cover letter, and phone screen.
I’m looking to see what additional information the candidate wants. Again, this is mostly to try to understand the candidate
I expect the candidate to design something that will work. Gimmick answers (put it in S3 and put up a web server that 301’s over to S3, etc) are valid, and you get some points for reasonable ones, but you still have to design an in-house version. I expect the solution to be within reasonable bounds for hardware, etc. Most folks do some kind of hashing scheme on the key in a front end server, and fan out to some database (or database-like) servers behind that. This is a fine answer.
One interesting side-bit, it is fascinating to see the folks who decide they need to implement a database. Usually they don’t phrase it that way, they just start talking about on-disk hashing schemes, mmap, and so on. While I am positive, given reasonable time, the problem lends itself to a hyper-efficient custom solution, I consider this to be a bad path compared to “slap it in $(database)” – frankly, you are not going to significantly outperform cdb or tc. I generally ask these folks if they think the problem of looking up a key by value has been solved before, especially given the two weeks to be live in production requirement.
Once they have a design, I ask about details, what technologies languages, etc. I generally remind folks that they have to have it in production two weeks from right now, and they need to implement it themselves, so they should probably stick to things they are very comfortable with, or can run a very quick experiment on to validate. I’ll then poke and and prod for their level of understanding of the tools they choose. I am looking for them to have a stong understanding of the strengths, limitations, and nuances of their go-to toolset.
Now the fun part begins, the followup question is, “how is it going to fail?”
Candidates usually either start listing everything they can think of, or immediately start describing how to add data-level redundancy. If so, I’ll rephrase it as “what are the most likely things that will make it fail?” This is actually my favorite part. From experienced folks, I expect a pretty accurate rundown of why things fail, from junior folks I expect at least good first-principles reasoning.
Depending on time, and how interesting it has been going, I’ll then either dive what we need to do to target 99.9% uptime, 99.99%, and so on. Alternately, I dive into a different question.
I love this question as my role in interviews is generally to determine how they think about and design systems. Is this someone who you can hand a problem description to, or just a task list? Do they bring a very different way of thinking about systems to the team (which can be either good or bad, depending on their approach)?
I get to feel out a lot of quality attributes, such as their familiarity with running a system as compared to handing it to ops, how much they have invested in mastering their tools, their balance between buzzword compliance and bedrock technologies, etc. You can certainly fail this question via a number of means, but it is set up to help me understand candidates more than grade them.
Interestingly, the question has been picked up by a number of other folks at Ning, mostly when we got larger and I stopped being involved in every engineering hire. Other folks generally used it in other ways, looking at other things. Most commonly for diving into algorithms and implementation details (what hash algorithm, if you are doing front end in PHP, let’s whiteboard code it out, etc). Sometimes I’d interview a candidate who had already been asked the question, and they usually got upset when I pressed forward on it anyway (usually after asking who asked the question, so I could make sure they hadn’t used it in the same way). “Then it should be easy, what was your answer?” got us past the first part and into the fun stuff, anyway!
Sadly, solid state drives killed the question, time for something new :-)
http://www.objectmentor.com/resources/articles/xpepisode.htm
http://www.sgdevs.com/2013/12/interview-question-design-object.html
Epic List of Interview Questions
http://katemats.com/interview-questions/
