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