'

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


×

HTML:





Ссылка: