Post on 12-Apr-2017
Gayle L. McDowell | Founder / CEO, CareerCup
gayle in/gaylemcdgayle
Dev Interview TrainingHow to Interview Developers: Best & Worst Practices
Oct 15, 2015
gayle in/gaylemcdgayleGayle Laakmann McDowell 2
Hi! I’m Gayle Laakmann McDowell
Author Interview Coach Interview Consulting
<dev>
</dev>
(CS)
(MBA)
Core BeliefsPhilosophies around hiring01
Gayle Laakmann McDowell 4gayle in/gaylemcdgayle
#1: Interviews don’t need to mirror the real world
Gayle Laakmann McDowell 5gayle in/gaylemcdgayle
#2: Good candidate experiences matter
Gayle Laakmann McDowell 6gayle in/gaylemcdgayle
#3: You’ll never have a perfect process
Gayle Laakmann McDowell 7gayle in/gaylemcdgayle
#4: You need to THINK about your process
The InterviewGoals & Questions02
gayle in/gaylemcdgayleGayle Laakmann McDowell 9
Goals
Great employees, not great interviewees
Good in 6 months, not 6 days Reduce false negatives Keep candidates happy
9
gayle in/gaylemcdgayleGayle Laakmann McDowell 10
Core Question Types
Experience/Behavioral Questions Knowledge Design/Architecture Problem Solving/Algorithms Coding
10
Can be mixed and matched!
Behavioral/ExperienceWhat do you ask and why?03
gayle in/gaylemcdgayleGayle Laakmann McDowell 12
1. Why?
Is this a person you want to work with?
Technical expertise Has made good, interesting technical
decisions Culture fit/personality
Not arrogant, curious, initiative, etc Communication
Can they articulate impact?
gayle in/gaylemcdgayleGayle Laakmann McDowell 13
2. Bad Practices & False Negatives
Undefined “cultural fit” Interviewer assumptions Overly specific questions Not focusing on self
“We” not “I”
gayle in/gaylemcdgayleGayle Laakmann McDowell 14
3. Best Practices
Probe deeper Be nice and friendly
(Even if you feel differently) Stick to more technical discussions Challenge YOUR assumptions In every interview
gayle in/gaylemcdgayleGayle Laakmann McDowell 15
4. Evaluation
A factor in ALL interviews Err towards listing minor concerns
Even if it’s just a “feeling” Challenge your assumptions
gayle in/gaylemcdgayleGayle Laakmann McDowell 16
5. Examples
Dive into a technical project Walk through design on whiteboard Discuss tradeoffs, key decisions, etc Extensions to project (scaling, etc) Focus on personal impact
KnowledgeWhat do you really need?04
gayle in/gaylemcdgayleGayle Laakmann McDowell 18
1. Why?
Do they know the stuff they should? Do they have the relevant job
skills?
gayle in/gaylemcdgayleGayle Laakmann McDowell 19
2. Bad Practices & False Negatives
Only basic knowledge Requiring stuff you don’t really
need Too many factual questions
gayle in/gaylemcdgayleGayle Laakmann McDowell 20
3. Best Practices
Hard to acquire OR a red flag Relevant to job Discussions > fact grilling
Evaluation should be mostly qualitative OR: Questions easily Googled are bad
gayle in/gaylemcdgayleGayle Laakmann McDowell 21
4. Examples
How does ____ work? How do you think it’s implemented?
DesignBig, meaty problems05
gayle in/gaylemcdgayleGayle Laakmann McDowell 23
1. Why?
Tests: Ability to tackle open-ended problems Communication/teamwork skills A different side of problem-solving
Respects experience of senior candidates
gayle in/gaylemcdgayleGayle Laakmann McDowell 24
2. Bad Practices & False Negatives
Unreasonable knowledge expectations
Some candidates don’t know “the flow” Can’t ask questions More of a factual answer Don’t drive the process
gayle in/gaylemcdgayleGayle Laakmann McDowell 25
3. Best Practices
Ask open-ended problems Encourage follow up questions Have candidate walk through Let candidate drive
gayle in/gaylemcdgayleGayle Laakmann McDowell 26
4. Evaluation
Ability to make tradeoffs Ability to identify issues Separate knowledge from attributes Response to feedback
gayle in/gaylemcdgayleGayle Laakmann McDowell 27
5. Examples
Design API for… System for Amazon book rank System for TinyURL OOD for a music library
AlgorithmsMake ‘em think06
gayle in/gaylemcdgayleGayle Laakmann McDowell 29
1. Why?
Smart people do good work Hires adaptable people Very effective if done well
gayle in/gaylemcdgayleGayle Laakmann McDowell 30
2. Bad Practices & False Negatives
Easy questions Questions with “a ha” moments Well known problems (or patterns)
gayle in/gaylemcdgayleGayle Laakmann McDowell 31
3. Best Practices
Ask the right questions Be nice and friendly Coach
MAKE THEM THINK
gayle in/gaylemcdgayleGayle Laakmann McDowell 32
3a. The Right Questions
Medium-to-hard questions Multiple hurdles Unusual questions Avoid obscure knowledge
gayle in/gaylemcdgayleGayle Laakmann McDowell 33
3a. Reasonable KnowledgeData Structures Algorithms ConceptsArrayLists Merge Sort Big O Time
Hash Tables Quick Sort Big O Space
Trees (+ Tries) Breadth-First Search
Recursion
Graphs Depth-First Search
Memoization / Dynamic Programming
Stacks / Queues Binary Search
Heaps
gayle in/gaylemcdgayleGayle Laakmann McDowell 34
3b. Be Nice and Friendly
Intimidated candidates do poorly Candidates cling to every word
Use this! “Good job”, “great point”, etc.
Especially if they’re struggling or nervous
gayle in/gaylemcdgayleGayle Laakmann McDowell 35
3c. Coach
Give hints as necessary Encourage examples (input/output) Remind them of key details Stop them from writing code too
early
gayle in/gaylemcdgayleGayle Laakmann McDowell 36
3d. Phone Interviews vs. Onsite
Don’t “go easy” on the phone But avoid problems needing
diagrams Strings, hash tables, linked lists are easy
to draw Trees and graphs are hard
gayle in/gaylemcdgayleGayle Laakmann McDowell 37
4. Evaluation
Not just correct vs. incorrect How optimal? How quickly? How many
hints? Compare to other candidates
Early on you won’t be calibrated More of a “gut feel” than a metric
gayle in/gaylemcdgayleGayle Laakmann McDowell 38
Rand7: Given rand5(), implement rand7() Has “a ha” moment
5. Bad Questions
gayle in/gaylemcdgayleGayle Laakmann McDowell 39
Sub Permutations: Given two strings, s and t, find all permutations of s within t.
5. Good Question
CodingPractical stuff07
gayle in/gaylemcdgayleGayle Laakmann McDowell 41
1. Why?
Code quality matters Not everyone can translate
algorithm into code
gayle in/gaylemcdgayleGayle Laakmann McDowell 42
2. Bad Practices & False Negatives
Requiring every detail Tedious questions Taking over the testing Letting the candidate code too
early
gayle in/gaylemcdgayleGayle Laakmann McDowell 43
Goal: “Seemingly compilable” code. Don’t waste time
Do you really need that Node class? Encourage abbreviations, skipping
uninteresting parts, etc. Make it clear when they should/shouldn’t
code Encourage testing, refactoring, etc
3. Best Practices
Gayle Laakmann McDowell 44gayle in/gaylemcdgayle
4. Whiteboard vs. Computer
More communication
More thought More focus on
essentials
BUT: slow & tedious
Can be more comfortable
Can write faster
BUT: compiling can be distracting
gayle in/gaylemcdgayleGayle Laakmann McDowell 45
5. Evaluation
Look at structure and style But differentiate what’s trainable
Not about complete vs. incomplete Let the candidate test
Final ThoughtsThings to remember07
gayle in/gaylemcdgayleGayle Laakmann McDowell 47
Remember:
It’s on YOU to get the info you want Challenge your assumptions Separate “did they do X?” from
“can they do X?”
47
gayle in/gaylemcdgayleGayle Laakmann McDowell 48
Remember:
Err towards noting it on feedback
Be nice and friendly MAKE THEM THINK
48
THANK YOUgayle@gayle.com
gayle in/gaylemcdgayle