From: http://www.mitbbs.com/article_t/JobHunting/32884861.html

发信人: wwzz (一辈子当码工), 信区: JobHunting
标  题: Design Interview
发信站: BBS 未名空间站 (Mon Feb  9 12:44:52 2015, 美东)

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.
--
※ 来源:·WWW 未名空间站 网址：mitbbs.com 移动：在应用商店搜索未名空间·[FROM: 208.]