---

| Context

I wrote this essay with the intent of providing a philosophical guide to my peers, when interviewing candidates for internships, new-grad, and seasoned roles at Netflix.

I hope you find it useful!

Note: This IS NOT a guide for applying to Netflix. This essay provides guidance in facilitating an interview and pulls on broader themes.

| How to Use this Document

The contents of this document should be seen and regarded as a philosophy versus a rubric or dogmatic approach to interviewing.  

I highly suggest reading through the document in linear fashion versus jumping around to the various sections.

| Goals

After reading this document, you should have better insight and tactics in the following: 

• How to structure your interview hour
• Foster a collaborative environment with your candidate
• Get a better signal of whether the candidate is a good fit or not

| Introduction

Interviewing is scary and nerve wracking for most people.  I challenge you, my colleague, peer, coworker, and internet stranger, to make it less scary from within. 

We all do our best when interviewing candidates but we painfully understand that we can’t always say yes to a candidate even though, from a brief conversation, we get the sense there is potential or they’re simply a good person.  

If you don’t remember anything from this document – try to remember at the least:  we were all on the other side of the screen, table, desk at one point in our career, or at several times in our career.  Interview and lead with empathy, compassion, and curiosity during the interview. 

At Netflix and other companies I’ve worked at, I’ve tried really hard to ensure that the interview environment is not adversarial.  We want to be building relationships with future colleagues and provide an atmosphere where they can do their best work.  We want fellow colleagues and candidates to be successful! 

| Preparation

Preparation is key to ensuring that you, the interviewer, have a consistent methodology to interviewing.  For the candidate, this ensures they’re being evaluated fairly and have a clear understanding of interview expectations that may or may not have been set by others in the process. 

When was the last time you timed yourself to get through a technical phone screen question with a Code Signal IDE?  I bet it probably took you upwards of an hour.  I know that’s how long it took me to code through a question from the 2022 cohort technical phone screen.  

The above callout helps frame what I’m trying to illustrate:  we expect our candidates to have good, thoughtful answers which means we have a responsibility to really understand and know the questions we’re asking.  Hold yourself accountable to the process.   

This is covered elsewhere in the interviewing training but I can’t stress enough that an interviewer should sit down for some time to truly understand and synthesize an opinion of the problems we ask candidates. 

We should understand the facets of the questions we’re asking, from time and space complexity, to the various sorting algorithms that make a solution optimal or sub-optimal.  Spend some time coding the question or reasoning about it for yourself.  Doing this yields far better interviews versus attempting to follow the solutions provided or worse, going into the interviews completely unprepared. 

| Interview Structure

Similar to the preparation above, having a predefined interview structure in your mental model helps provide a consistent and fair experience for yourself and the candidates.  

Below is the typical 1 hour format I’ve used over the last several cohorts:  

0 – 2 Minutes  

Introduce yourself and what you do at Netflix and close this section by communicating the timeline you’re reading through right now.  

2 – 5 Minutes

Ask the candidate to introduce themselves and share a little about their journey thus far. 

5 – 7 Minutes

Transition to speaking about the exercise they’re going to be collaborating with you on and kick off the interview itself.  

7 – 9 Minutes

Prompt or ask the candidate to spend a few minutes to read through the exercise and gather their thoughts and approach. 

9 – 45 Minutes

This is the bulk of the interview time.  We’ll dive into this part next in the Interview Facilitation section.

45 – 59 Minutes

Close the session with the candidate.  Ask them if they have any questions they’d like to ask you! 

Thank them for their time and share any next steps, if any.  

| Interview Facilitation

In this section, I’ll go over the various reasons why the timeline works well and the reason behind the careful timeline curation. 

In the first few minutes, you may ask, “Why don’t we just have the candidate read the question on their own?”  The answer is, if we come back to the idea of being a collaborative partner for the candidate, we want to shift candidates out of this adversarial mode they may be in and switch over to a mindset where we can explore a solution together.    

Provide a high level overview of the problem and explicitly state and remind the candidate what metrics you’re tracking:  decision making, communication, algorithm design, computer science fundamentals, working code, etc…  

This high level explanation is helpful because it satisfies facets we often take for granted in the hybrid interview environment:  people receive and process information via auditory means, visually, or a combination of both (and other means that aren’t relevant here).  

This provides two main wins:  it gives the candidate an opportunity to internalize the question and secondly it slows down time for them. 

By slowing down time for the candidate and clearly stating our goals of the exercise, it’s now in the hands of the candidate to demonstrate their skills in all the facets we’re seeking. 

One may state, “The candidates should be high caliber, they know what to expect!” or “They should already know how to perform a technical interview with these expectations.”  In my personal philosophy and experience, I’ve found being dogmatic about these opinions has never proved to be useful to hiring the right or wrong candidates.  

Those opinions contain a bias that the candidate has had some external forces, training, or education in interviewing – which I think is sub-optimal.  I’ve personally had the privilege of attending a university with strong, strong technical interview prep.  However, I’ve mentored a lot of university students, where technical interview preparation or training isn’t even on the school’s radar much less on the students’ mind.  We can debate this at length – hence the philosophical nature of this document! 

| Interview Facilitation Part 2: Getting Signal

Similar to the timeline I utilize above, I pick one question from each interview type to utilize for the duration of a cohort.  By being consistent in the questions I ask, I develop a baseline for candidate performance and build timeline milestones to help drive the interview process.  I’ll discuss the idea of timeline milestones in the next few paragraphs.  

The timeline of milestones in this context is a rough estimate of where a candidate should be at key points in the interview question.  These key points vary for each type of question you’ll be asking!  I typically use 1 or two interviews to gather baseline data for the timeline.   

The next few paragraphs, I’ll use a contrived example of conducting a technical phone screen and what those milestones look like. 

Listing out the milestones: 

• First 7 minutes the candidate shared their design and approach
• By the 25 minute mark the candidate has a working, first-draft solution
• By the 45 minute mark the candidate may have provided an optimized solution or even written test cases for their solution

Using those milestones from the example and personal judgment, I’ve established that on average I can expect candidates to have a working solution by the 30 minute mark (+/- 5 minutes).  By the 45 minute mark, I can expect an optimized solution with test cases.  

I want to call out explicitly, I’m not judging a candidate how quickly it takes them to build a solution, I’m using the time component as a way to help move the interview along.

How does this help facilitate the interview?  

With this data in hand, you can begin to understand when and how to nudge your candidate or provide hints during the interview process.  It helps keep things moving if the candidate gets stuck and provides you a signal into how to steer the interview.  To reiterate, these milestones should be used as coarse grained controls in interview facilitation.  

Your next question may be, when and how should I provide hints and nudges if the candidate is stuck? 

My suggestion here is to give the candidate a minute or two to wrestle with the problem they are facing.  

It becomes fairly obvious if they’re stuck:  erasing / commenting out large chunks of code, rewriting large parts of the function, talking around the problem…  This sounds familiar, right?

Once you start seeing these patterns, it’s time to step in: 

• Can you give me an idea of what you’re stuck on? 
• What happens if we try this approach? 
• Talk me through the bug we’re facing. 
• Have you thought about approaching the problem this way? 
• Let’s go back to the less complex model and work through the changes you were implementing… 
• What would happen if we approached it this way instead? 

When the candidate isn’t stuck and maybe just forgot to mention something, be direct and ask: 

• I saw you implemented that data structure, why is it the best one for this solution? 
• Can you explain the time complexity of the loop you just wrote? 
• I see you’re implementing XYZ, could you explain your thought process on why you chose this path? 

And the next question you’re probably queueing up, but isn’t this giving them too much help?  I don’t particularly believe so.  

The strong candidates will be able to communicate their process and drive the interview nearly to completion.  The average performing candidates will receive the small nudges and hints and quickly get back on track.  The candidates that aren’t a good fit will receive and need many nudges and will unfortunately spend a lot of time in a sub-optimal solution or debugging code that is fatally flawed.  

| Interview Facilitation Part 3: Body Language

Lights, camera… Action?  You’re on camera!  

As interviewers, we need to remember that candidates can see our facial expressions and some of our body language. 

Similar to in-person interviews (remember those?) and public speaking guides, lead with “open” body language.  For example, don’t cross your arms and recline back in your chair but perhaps try to sit or stand up-right and show engaging body language. 

Engage the candidate by nodding, smiling, or verbally affirming that they’re heading in the right direction during their exercise.  

I wouldn’t trivialize this whole point by saying, “Smile more!”  That’s not the point – in a remote interview setting, it’s important that we continue to provide non-verbal queues to our candidates, so we can express interest and curiosity in their approach. 

| Interview Facilitation Part 4: Handling Q&A

In an interview setting, candidates are often excited and ready to throw a barrage of questions at the interviewer, covering our culture, tech stack, and how shows are produced, stored, and streamed. 

Q&A during an interview should be treated in a similar fashion, be open and willing to share what makes Netflix great but it’s important to realize that some information is not ready for public sharing. 

Similar to the earlier call out of being prepared, it’s good to have some opinions and thoughts for some high-level questions candidates may ask: 

• What’s Netflix like day to day? 
• What are things you enjoy or don’t enjoy working at Netflix? 
• What’s been your favorite thing to work on? 

In technical interviews, it’s often a slippery slope when a candidate is interested in our technical infrastructure and is super passionate about diving deeply into an aspect that may actually be proprietary or confidential.  

Attempt to answer the candidates questions to the best of your knowledge but don’t hesitate to simply state, “I’m sorry, that’s information I can’t share.”  

| Closing Thoughts

Hopefully by now you’ve got some context, tools, and tips to help drive towards the three main goals of this document: 

• Structuring your interviews
• Facilitating the interview
• Getting a better signal of the candidates’ fit

I wrote this memo with the intent that it helps provide a mental model, reduces the barrier to entry for us to interview our future colleagues, and increases our interview performance with our candidates.   

We were all there at some point in our careers and it’s our responsibility to ensure we get the best candidate while flexing our values and setting up our candidates and ourselves for success.  

Please reach out to me with any comments, questions, or feedback!