What is the Netflix interview process?

Recorded February 24th 2021 – watch the full episode on YouTube.

What do you look for during an interview, and more broadly what does the Netflix interview process look like?

Jordanna Kwok: I have to say there are some similarities to maybe some other bigger tech companies. There are also many differences. In terms of what we look for, in the technical space we are certainly looking for the baseline skills. And that's what we ask – we don't ask LeetCode questions, so my team shies away from the brain teasers, the complexity analysis, and so on, mainly because we don't find that we use that on a day to day basis. Maybe once in a while, but the majority of the time you're using your iOS fundamentals. How do you use a collection view? How does concurrency work? You need to download, I don't know, 10 images – how do you make sure that they're cached properly? These types of things where real problems that engineers will all encounter day to day at Netflix, so those are the types of questions that we will ask in most of the technical panels.

There's a little bit of a process that we do go through. First it is a conversation with my recruiting partner or myself just to see if this the right role for you and also for you to assess us – is it the right role for yourself?

"We don't ask LeetCode questions, so my team shies away from the brain teasers, the complexity analysis, and so on, mainly because we don't find that we use that on a day to day basis."

Say for example you're looking for, I don't know, building out SDKs and libraries and frameworks, and you are very much infrastructure type of engineer. But on my team, if I'm looking for a very product-UI-centric engineer, there might not be a match there. Even though you have the technical iOS chops, it might not be the thing that you're looking for, and it might not be the thing that we're looking for. Then maybe this isn't the right fit right now, until we find the right role.

So that would be the first step, and the second step would be a technical screen. It would be with an engineer on the team, and we would ask the iOS fundamentals. So, GCD, memory management, stuff like that. And assuming that all of those questions are answered and go well, that's kind of like the baseline, and we want to keep it fairly standardized because it gives us a good idea of where people are at and can eliminate the bias.

Then we would move onto a virtual onsite, because we can't actually bring you into the office – the offices are not open for interviews. So, during the virtual onsite we kind of break it down into different days now. We used to have a full day, although you can still opt for the full day if you really wanted to. We give people the choice, make it super flexible, but there are two more technical panels and you would be meeting with other engineers on the team to walk through them.

One of them is around problem solving. Again, not brain teasers, not LeetCode, but more a day to day problem. We might give a scenario, for example, or maybe a systems design type of question. And it really isn't whiteboarding unless you want to draw something and show it, but it is talking through how you would solve those problems. As for the second panel, this is the one I think a lot of people have questions about – “do you do live coding? Look over the shoulder type of coding exercise?"

"I think the take home test is more representative of what you're going to actually experience in the workplace."

So, we debated between doing something like that versus a take-home test, and we ended up landing on the take home. Some people might like the live coding challenge, but we do find there's a lot more pressure that is put on engineers, especially like, “am I getting the syntax right?" So I think the take home test is more representative of what you're going to actually experience in the workplace. Because you're going to get an open ended question like, “build an app that does something." And then you go do it, it's very ambiguous for sure, but how would you navigate that?

At work it's the same thing: you're given a problem, or you're working with a product manager and they're like, "I have this idea, how would you build it out?" And it's not like you get a pixel perfect spec every single time – you need to build something, a lot of times it's open to interpretation, so how would you manage that? And how would you spend your time? Because you don't want to spend a whole week on this take home exercise, right?

Paul Hudson: It's really challenging, you know?

Jordanna Kwok: Yeah, so it’s about what trade offs are you trying to make? Because engineering is about trade offs, and if you think about it, in the real workplace it's the same thing, right? You could say, "there's this feature I'm working on, it's going to take me six months." And it's like, okay, could it take three months? What are the things that you're thinking about as an engineer in terms of scope and what is possible in the time that you have?

"Even if things don't work out, we try out best to give some amount of feedback."

Paul Hudson: I love how many times you've said the word “real.” This all sounds very real, which is great – it's not artificial coding tests or complexity algorithms or who knows what. It's actual, real world iOS tasks again and again to see how they're going to solve the kind of thing they might solve on the actual team in three months time. And that's presumably much more valuable to you because you can get a better idea of whether this person would fit into your coding style, or has the right kind of ideas, or is thinking about design as well as performance – that sounds perfect for you.

"We have hired people on their second or third interviews, so I just want to say that it's not like just because you didn't make it through the interview process doesn't mean that you're not going to get a role in the future."

Jordanna Kwok: Honestly I don't know what the interview process for different companies are like these days, but it certainly is much more applicable to the job itself, what we try to strive for. And we also try to strive for making it fun for people, because most people coming in, I would hope that the take-home exercise is something that maybe they've learned something through the process or they found that, this was a great way for them to exercise maybe their creativity.

And even if things don't work out, we try our best to give some amount of feedback, which is not what most companies will do. We'll try to at least say, "Hey, maybe there was this thing, maybe your UIKit skills in this area weren't what we would expect", but at least this gives you the opportunity as a candidate to go back and work on them and come back again, come back and interview again down the road. And we have hired people on their second or third interviews, so I just want to say that it's not like just because you didn't make it through the interview process doesn't mean that you're not going to get a role in the future.

Sponsor Hacking with Swift and reach the world's largest Swift community!