How to Interview Like Google (But Better) - SVCC

Gayle L. McDowell | Founder / CEO, CareerCup

gayle in/gaylemcdgayle

How to Interview Like Google (or not) – But BetterBest & Worse Practices

Oct 1, 2016

gayle in/gaylemcdgayleGayle Laakmann McDowell 2

Hi! I’m Gayle Laakmann McDowell

Author Interview Coach Interview Consulting

<dev>

</dev>

(CS)

(MBA)

How People HireCurrent strategies00

gayle in/gaylemcdgayle 4Gayle Laakmann McDowell

HowWe

Hire

Problem-solving questions

Onsite “real-world” tests

Homework Take-Home Tests Prior experience References

Gayle Laakmann McDowell 5gayle in/gaylemcdgayle

It’s all broken There’s no “perfect” interview. Always false negatives. Always false positives.


Problem Solving

Intelligence matters (a lot)

Lots of communication

Ability to push through hard problems

Intimidating Prep helps Other ways to

be “great” Can turn off sr.

candidates Lots of bad

questions


Onsite Real-World Tests

See real-world skills

Identifies current skill set, not potential

Lack of communication


Homework

Sees real-world skills.

Cheap & easy

Identifies current skill set, not potential

Candidates can feel exploited


Prior Experience

It matters Lots of

communication

Some can “talk a good game” Some can’t…


References

Prior experience is good

Hand-picked Different

companies have different needs

Not always 100% honest

gayle in/gaylemcdgayle 11

z

Gayle Laakmann McDowell

Not

ToMention…

NONE evaluate work ethic or ability to focus

(which isn’t necessarily constant anyway)


z


WhatTo

Do?

Find what’s right for you

Identify the flaws Make it as un-broken

as possible

Core BeliefsPhilosophies around hiring01


#1: Good candidate experiences matter


#2: Smart beats knowledgable


#3: It’s On You To Get What You Want


#4: Nothing Is Perfect

The InterviewGoals & Questions02


Goals

Great employees, not great interviewees

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

19


z


Standard Intervie

wStructure

1. ~5 min resume/behavioral

2. Technical questions3. ~5 min questions

for you


Core Question Types

Experience/Behavioral Questions Knowledge Design/Architecture Problem Solving/Algorithms Coding

21

Can be mixed and matched!

Behavioral/ExperienceWhat do you ask and why?03


What We Look For

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?


Engineers don’t like interviews

Hostility towards “cheesy” questions

Don’t “get” interviewing


Styles of Behavioral Questions

Open-Ended Discovery “Tell me about _ project”

Situational “Tell me about a challenging project”

Hypotheticals “How do you handle conflicts?”

Open-Ended Discovery


Example Questions

“Walk me through your resume” “Tell me about the projects you’ve

worked on.” “Tell me about your job. What do

you like?”


• Candidates feel…


The Good and Bad

Gives opportunity to talk about what they want

Finds stuff not on their resume Won’t throw them off But…

Unstructured, might not get info you want

Situational


Example Questions

Tell me about a time when you faced a conflict

Tell me about a time you had to influence people

Tell me about a difficult decision you had to make


Avoid Hypotheticals

Best Practices


Avoid priming


Avoid too specific questions


Avoid superlatives


Drill Deeper

• How & Why

• SAR (Situation, Action, Result)


Be Reassuring


Know What You’re Looking For


Cross Check


My Favorites

Resume walk-through Do it yourself first, to set the stage

Hobbies & stuff not on your resume Warn that it’s okay to not have anything

Past projects and work Walk through design on whiteboard Discuss tradeoffs, key decisions, etc. Extensions to project (scaling, etc.) Focus on personal impact


z


Check

YourInterviewers

Is the question likely to annoy a candidate?

Did they go beyond surface level?

What did they learn? Are they sure they

learned that?

KnowledgeWhat do you really need?04


Examples

What’s the difference between __ and __?

What are the benefits of __? What does __ mean?


Goals

Assess candidate’s skills Relative to position needs Relative to expectations

Make candidate’s experience feel valued


Avoid “quizzing”


Be nice (even when they mess up)


Knowledge Should Be…

Hard to obtainor

A red flag to lack



My Favorites

How does ____ work? How do you think it’s implemented? Teach me about ____.


z


Questions

For YourInterviewers

Was it a discussion? Did you probe deeper? How long would it take

to teach this depth? If the candidate didn’t

know something: Why not?

Were you positive & reassuring?

DesignBig, meaty problems05


Why?

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

Respects experience of senior candidates


Might be unexpected


Beware of insider knowledge


Encourage them to drive


Coach your candidates


Evaluation

Ability to make tradeoffs Ability to identify issues Separate knowledge from attributes Response to feedback Higher standards for more senior

candidates


Examples

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


z


Questions

For YourInterviewers

Did the candidate need to really think?

Did you go deep? Did you help the

candidate through?

AlgorithmsMake ‘em think06


Why?

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


Bad Practices & False Negatives

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


Best Practices

Ask the right questions Be nice and friendly Relevant when possible Coach A slow & fast solution

MAKE THEM THINK


The Right Questions

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


Reasonable KnowledgeData Structures Algorithms ConceptsArrayLists Merge Sort Big O Time

Hash Tables Quick Sort Big O Space

Trees & Graphs Breadth-First Search

Recursion

Linked Lists Depth-First Search

Memoization / Dynamic Programming

Stacks / Queues Binary Search

Heaps


Do not ask…

Dijkstra’s algorithm Tree balancing Topological sort A*


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


Coach

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

early YOU manage the time


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


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

Bad Questions


More Bad Questions

Implement a stack with a singly linked list

Reverse order of words in a sentence

Merge two sorted arrays Find duplicates in a string Given a book, find unique words &

occurrences Replace spaces with “-”


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

Good Question

Hard questionMany partsEasy knowledgeUncommon


Max Alive: Given a list of people with birth/death years, find peak population

Good Question

Medium difficulty question

Several optimizationsEasy knowledgeUncommon


z


Check

YourInterviewers

Did the candidate need to really think?

Is the question unusual?

CodingPractical stuff07


Why?

Code quality matters Not everyone can translate

algorithm into code


Bad Practices & False Negatives

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

early


Don’t waste time Do you really need that Node class? Skipping uninteresting parts, etc.

Okay to make-up reasonable syntax Make it clear when they should/shouldn’t

code Encourage testing, refactoring, etc Don’t stress about compiling

Best Practices


Compiling Code

Requires a lot of overhead Do it only for good reason


Evaluation

“Seemingly compilable” code Look at structure and style

But differentiate what’s trainable Not about complete vs. incomplete Let the candidate test What is this telling you?


z


Check

YourInterviewers

What did you learn about the candidate’s coding?

Can the issues be fixed?

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?” What did ___ tell you about the

candidate?


Check Your Interviewers

What did you learn from this question/answer?

Were they happy and supportive?

Did they challenge the candidate?

THANK [email protected]

gayle in/gaylemcdgayle