Dev Interview Training

Понравилась презентация – покажи это...

Слайд 0

Dev Interview Training How to Interview Developers: Best & Worst Practices Oct 15, 2015

Слайд 1

Hi! I’m Gayle Laakmann McDowell Author Interview Coach Interview Consulting <dev> </dev> (CS) (MBA)

Слайд 2

Core Beliefs Philosophies around hiring 01

Слайд 3

#1: Interviews don’t need to mirror the real world

Слайд 4

#2: Good candidate experiences matter

Слайд 5

#3: You’ll never have a perfect process

Слайд 6

#4: You need to THINK about your process

Слайд 7

The Interview Goals & Questions 02

Слайд 8

Goals Great employees, not great interviewees Good in 6 months, not 6 days Reduce false negatives Keep candidates happy ? 9

Слайд 9

Core Question Types Experience/Behavioral Questions Knowledge Design/Architecture Problem Solving/Algorithms Coding 10 Can be mixed and matched!

Слайд 10

Behavioral/Experience What do you ask and why? 03

Слайд 11

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?

Слайд 12

2. Bad Practices & False Negatives Undefined “cultural fit” Interviewer assumptions Overly specific questions Not focusing on self “We” not “I”

Слайд 13

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

Слайд 14

4. Evaluation A factor in ALL interviews Err towards listing minor concerns Even if it’s just a “feeling” Challenge your assumptions

Слайд 15

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

Слайд 16

Knowledge What do you really need? 04

Слайд 17

1. Why? Do they know the stuff they should? Do they have the relevant job skills?

Слайд 18

2. Bad Practices & False Negatives Only basic knowledge Requiring stuff you don’t really need Too many factual questions

Слайд 19

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

Слайд 20

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

Слайд 21

Design Big, meaty problems 05

Слайд 22

1. Why? Tests: Ability to tackle open-ended problems Communication/teamwork skills A different side of problem-solving Respects experience of senior candidates

Слайд 23

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

Слайд 24

3. Best Practices Ask open-ended problems Encourage follow up questions Have candidate walk through Let candidate drive

Слайд 25

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

Слайд 26

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

Слайд 27

Algorithms Make ‘em think 06

Слайд 28

1. Why? Smart people do good work Hires adaptable people Very effective if done well

Слайд 29

2. Bad Practices & False Negatives Easy questions Questions with “a ha” moments Well known problems (or patterns)

Слайд 30

3. Best Practices Ask the right questions Be nice and friendly Coach MAKE THEM THINK

Слайд 31

3a. The Right Questions Medium-to-hard questions Multiple hurdles Unusual questions Avoid obscure knowledge

Слайд 32

3a. Reasonable Knowledge

Слайд 33

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

Слайд 34

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

Слайд 35

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

Слайд 36

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

Слайд 37

Rand7: Given rand5(), implement rand7() Has “a ha” moment 5. Bad Questions

Слайд 38

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

Слайд 39

Coding Practical stuff 07

Слайд 40

1. Why? Code quality matters Not everyone can translate algorithm into code

Слайд 41

2. Bad Practices & False Negatives Requiring every detail Tedious questions Taking over the testing Letting the candidate code too early

Слайд 42

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

Слайд 43

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

Слайд 44

5. Evaluation Look at structure and style But differentiate what’s trainable Not about complete vs. incomplete Let the candidate test

Слайд 45

Final Thoughts Things to remember 07

Слайд 46

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

Слайд 47

Remember: Err towards noting it on feedback Be nice and friendly MAKE THEM THINK 48

Слайд 48