Design Interview# JobHunting - 待字闺中
w*z
1 楼
The Design Interview From the Interviewer's Perspective
Feb 7, 2015 123Views 6Likes 0CommentsShare on LinkedInShare on
FacebookShare on Google PlusShare on Twitter
Interviews are a medium which allow companies to assess a candidate's skills
and to determine if the candidate is a good fit for the company. This is
why many software companies believe that interviewing for coding skills
alone is not the best way to assess a candidate’s skill because it does not
give enough information about the candidate. Designing systems is a key
element that defines software development, and can be a very important skill
to assess when interviewing a candidate.
This is where the design interview comes in. The design interview’s purpose
is to understand how capable a candidate is at building a large scale
system. There exists a fundamental problem with conducting this interview.
Interviewers are trained to look for right and wrong answers. While in
regular interviews this is bad, as seen in this example Interviews Are Not
Exams, in design interviews it’s unacceptable. 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;
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
One of the common mistakes with design interviews is to ask questions
expecting a single answer. Questions with only one answer can judge if a
candidate can solve a puzzle, not that they can design. 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.
Remain in Control of the Interview
It is easy for a candidate to go down a rabbit hole, but it is the
interviewer’s job to stop them and stay in control of the interview. This
is especially true in design interviews. 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.
Add Requirements
In engineering design, requirements are changing constantly. Requirements
that were important at first become irrelevant, when the product starts to
come to life feedback influences requirements, and even after release the
changing ecosystem may enforce or remove design constraints.. It is
important to see how a candidate adapts to a changing environment. 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.
How to Evaluate the Candidate
Assuming most of the notes above were followed by the interviewer, here is a
breakdown on how to evaluate the candidate;
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.
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. 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.
TL;DR
The design interview poses an interesting challenge for interviewers, since
it requires the interviewer to take a more active role in order to
accurately assess a good candidate over a bad one. Great candidates will
shine, and horrible candidates will fall on their face, but there’s a small
difference between a good and a bad candidate, and depending on how the
interview is conducted, a candidate may not be able to show their true
abilities.
As a final comment, the design interview should be very important for a
senior engineer, since their job will likely consist of a lot of design, but
for a junior candidate it should be expected that they don’t have much
experience in this field. Design is something that can be learnt over time,
by struggling through projects and by interacting with other developers.
Feb 7, 2015 123Views 6Likes 0CommentsShare on LinkedInShare on
FacebookShare on Google PlusShare on Twitter
Interviews are a medium which allow companies to assess a candidate's skills
and to determine if the candidate is a good fit for the company. This is
why many software companies believe that interviewing for coding skills
alone is not the best way to assess a candidate’s skill because it does not
give enough information about the candidate. Designing systems is a key
element that defines software development, and can be a very important skill
to assess when interviewing a candidate.
This is where the design interview comes in. The design interview’s purpose
is to understand how capable a candidate is at building a large scale
system. There exists a fundamental problem with conducting this interview.
Interviewers are trained to look for right and wrong answers. While in
regular interviews this is bad, as seen in this example Interviews Are Not
Exams, in design interviews it’s unacceptable. 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;
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
One of the common mistakes with design interviews is to ask questions
expecting a single answer. Questions with only one answer can judge if a
candidate can solve a puzzle, not that they can design. 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.
Remain in Control of the Interview
It is easy for a candidate to go down a rabbit hole, but it is the
interviewer’s job to stop them and stay in control of the interview. This
is especially true in design interviews. 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.
Add Requirements
In engineering design, requirements are changing constantly. Requirements
that were important at first become irrelevant, when the product starts to
come to life feedback influences requirements, and even after release the
changing ecosystem may enforce or remove design constraints.. It is
important to see how a candidate adapts to a changing environment. 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.
How to Evaluate the Candidate
Assuming most of the notes above were followed by the interviewer, here is a
breakdown on how to evaluate the candidate;
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.
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. 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.
TL;DR
The design interview poses an interesting challenge for interviewers, since
it requires the interviewer to take a more active role in order to
accurately assess a good candidate over a bad one. Great candidates will
shine, and horrible candidates will fall on their face, but there’s a small
difference between a good and a bad candidate, and depending on how the
interview is conducted, a candidate may not be able to show their true
abilities.
As a final comment, the design interview should be very important for a
senior engineer, since their job will likely consist of a lot of design, but
for a junior candidate it should be expected that they don’t have much
experience in this field. Design is something that can be learnt over time,
by struggling through projects and by interacting with other developers.