how to hire software engineers: best and worst practices

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


#2: Good candidate experiences matter


#3: You’ll never have a perfect process


#4: You need to THINK about your process

The InterviewGoals & Questions02


Goals

Great employees, not great interviewees

Good in 6 months, not 6 days Reduce false negatives Keep candidates happy

9


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


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?


2. Bad Practices & False Negatives

Undefined “cultural fit” Interviewer assumptions Overly specific questions Not focusing on self

“We” not “I”


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


4. Evaluation

A factor in ALL interviews Err towards listing minor concerns

Even if it’s just a “feeling” Challenge your assumptions


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


1. Why?

Do they know the stuff they should? Do they have the relevant job

skills?



Only basic knowledge Requiring stuff you don’t really

need Too many factual questions


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


4. Examples

How does ____ work? How do you think it’s implemented?

DesignBig, meaty problems05


1. Why?

Tests: Ability to tackle open-ended problems Communication/teamwork skills A different side of problem-solving

Respects experience of senior candidates



Unreasonable knowledge expectations

Some candidates don’t know “the flow” Can’t ask questions More of a factual answer Don’t drive the process


3. Best Practices

Ask open-ended problems Encourage follow up questions Have candidate walk through Let candidate drive


4. Evaluation

Ability to make tradeoffs Ability to identify issues Separate knowledge from attributes Response to feedback


5. Examples

Design API for… System for Amazon book rank System for TinyURL OOD for a music library

AlgorithmsMake ‘em think06


1. Why?

Smart people do good work Hires adaptable people Very effective if done well



Easy questions Questions with “a ha” moments Well known problems (or patterns)


3. Best Practices

Ask the right questions Be nice and friendly Coach

MAKE THEM THINK


3a. The Right Questions

Medium-to-hard questions Multiple hurdles Unusual questions Avoid obscure knowledge


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


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


3c. Coach

Give hints as necessary Encourage examples (input/output) Remind them of key details Stop them from writing code too

early


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


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


Rand7: Given rand5(), implement rand7() Has “a ha” moment

5. Bad Questions


Sub Permutations: Given two strings, s and t, find all permutations of s within t.

5. Good Question

CodingPractical stuff07


1. Why?

Code quality matters Not everyone can translate

algorithm into code



Requiring every detail Tedious questions Taking over the testing Letting the candidate code too

early


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


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


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


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


Remember:

Err towards noting it on feedback

Be nice and friendly MAKE THEM THINK

48

THANK [email protected]

gayle in/gaylemcdgayle

how to hire software engineers: best and worst practices

Software