Dev Interview Training


The Presentation inside:

Slide 0

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


Slide 1

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


Slide 2

Core Beliefs Philosophies around hiring 01


Slide 3

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


Slide 4

#2: Good candidate experiences matter


Slide 5

#3: You’ll never have a perfect process


Slide 6

#4: You need to THINK about your process


Slide 7

The Interview Goals & Questions 02


Slide 8

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


Slide 9

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


Slide 10

Behavioral/Experience What do you ask and why? 03


Slide 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?


Slide 12

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


Slide 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


Slide 14

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


Slide 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


Slide 16

Knowledge What do you really need? 04


Slide 17

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


Slide 18

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


Slide 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


Slide 20

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


Slide 21

Design Big, meaty problems 05


Slide 22

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


Slide 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


Slide 24

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


Slide 25

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


Slide 26

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


Slide 27

Algorithms Make ‘em think 06


Slide 28

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


Slide 29

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


Slide 30

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


Slide 31

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


Slide 32

3a. Reasonable Knowledge


Slide 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


Slide 34

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


Slide 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


Slide 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


Slide 37

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


Slide 38

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


Slide 39

Coding Practical stuff 07


Slide 40

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


Slide 41

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


Slide 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


Slide 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


Slide 44

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


Slide 45

Final Thoughts Things to remember 07


Slide 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


Slide 47

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


Slide 48


×

HTML:





Ссылка: