Senior Software Engineers Jessica Berglund and Jordanna Kwok speak about working on the Netflix iOS App, what ABTests are like, about their team, and more about working at Netflix.
Senior Software Engineers Jessica Berglund and Jordanna Kwok speak about working on the Netflix iOS App, what ABTests are like, about their team, and more about working at Netflix.
Lyle: Hi, my name’s Lyle Troxell.
Michael: I’m Michael Paulson.
Lyle: We’re both software engineers at Netflix, and we kind of love the culture here.
Michael: I do.
Lyle: Yeah. A while ago I interviewed you, Michael, for my personal podcast talking about tech because you were doing a talk at a JavaScript conference.
Michael: Yeah.
Lyle: And it was a lot of fun having a conversation here at the office.
Michael: It was a lot of fun, and it was only reasonable that we keep doing it because it is so much fun.
Lyle: So we grabbed other people we were interested in for one of these hack days. We do hack-days things all the time here where we build fun things. And we pulled in like six different people and interviewed them. And these conversations were kind of designed to be just for people that work at Netflix.
Michael: Yeah.
Lyle: We’ve done about 20 episodes. We’ve gone all over the map to some degree. And we realized relatively quickly that these would be interesting for anybody, not even people that work at Netflix directly.
Michael: Absolutely.
Lyle: So what are we doing about that?
Michael: Well, we decided that we should probably do these publicly, and so we’re going to have podcasts devoted to what do we do on various teams and kind of the culture of Netflix and those individual teams.
Lyle: So these conversations are just people at Netflix working at Netflix and talking about what it’s like. I hope you enjoy them.
Jessica: My first job, I was called Jennifer for four years.
Multiple voices: We are Netflix.
Male Voice: That one was solid.
[Music]
Lyle: Jessica Berglund holds a bachelor of science in computer science from Central Washington University. She started her career as a QA engineer at WideOrbit and quickly transitioned to UI engineer, and after two years moved to a dev at Snapfish and then spent a year as a senior iOS developer at Kodak Alaris, which I’m assuming was like photo-focused company.
Jessica: It was Kodak.
Lyle: Was it different than Snapfish?
Jessica: Yeah. It was more of the same, but—
Lyle: Did it feel “corporatey” and weird or was it having a nice culture?
Jessica: No. It was more like Kodak Labs, so there was a team of four. I was one of the four, and we were basically trying to rapidly innovate on, you know, what makes Kodak and what is a Kodak moment. And so we worked in a co-working space, and it felt very much like a start-up but with the backing of a hundred-plus-year-old company.
Lyle: Which is kind of nice.
Jessica: It was really fun.
Lyle: Was that up in San Francisco as well?
Jessica: It was, yes.
Lyle: And then about a year ago you left and joined us here as a senior user interface engineer focused on iOS at Netflix. So, hi.
Jessica: Hi.
Lyle: Thank you for coming and chatting with us. Jordanna Kwok has a bachelor of arts and science in computer engineering from University of Waterloo and also a master of arts and science in systems design engineering from Waterloo. So you really were full-on to that whole education thing. Did you work on a PhD?
Jordanna: I almost went into a PhD. I had a few supervising academic professors asking me if I wanted to continue my master’s work into PhD, but I kind of discovered during my master’s degree that academia wasn’t really my thing. I really enjoyed industry, and I had—during my time at Waterloo, we actually had this interesting program where you would do four months of study, four months of work. So you had paid internships essentially.
Lyle: And that’s where you went to RIM for a while.
Jordanna: Yes.
Lyle: And what was that like? Is this in the heyday of RIM?
Jordanna: It was actually while they were kind of reaching their peak, kind of on the way up. And it was exciting, because Apple hadn’t come up with their iPhone yet at that point and the Blackberry was the thing.
Lyle: It was the hotness.
Jordanna: Yeah, it was the hotness at that time.
Lyle: And then when you actually left, you actually became a user interface engineer at RIM full time after leaving university?
Jordanna: Yeah.
Lyle: And you stayed there for quite a while and kind of moved up in doing different things. What was the feeling of RIM during that time? Did you see it start going down or the entire time you’re there, it was rocking?
Jordanna: It was in like super rocket mode, you know, fueling with the—with all the, you know, the stock price going up and everything. They were just hiring a lot. So growth was shooting up. When the iPhone came out, that’s when everyone was like, hmm, what do we have to do next?
Lyle: And you were there—
Jordanna: Yeah.
Lyle: ...because of course the iPhone comes out—You left in 2010 and went off to MeLLmo. I have no idea what—it’s an SAP company, some kind of...
Jordanna: Yeah. So MeLLmo was actually like a stealth name for a start-up company. This company worked on mobile business intelligence applications.
Lyle: So data mining?
Jordanna: No. it’s kind of like—you know, you might have used Tableau or something along those lines where you take like, you know, KPIs and then look at them.
Lyle: Analyze data.
Jordanna: Analyze data—
Lyle: Help people understand numbers.
Jordanna: Exactly. And, you know, have fancy charts and everything.
Lyle: And were you the fancy-chart person?
Jordanna: Yes.
Lyle: Oh, cool.
Jordanna: So that was very exciting.
Lyle: And what platform were they doing at that point?
Jordanna: At that point, they hired me originally for the Blackberry, given my experience there, and then we migrated over to Android because I was getting a lot of traction. iOS was their base platform, so it was mostly, you know, trying to diversify across different mobile platforms.
Lyle: Yeah. And so when you were there, you were doing RIM, and RIM was developed—What was RIM developed in—was the language?
Jordanna: They were using—at first they were using C++, then it became Java. So I have mostly a Java background, so moving from that, interestingly, into web at MeLLmo.
Lyle: Yeah. So at MeLLmo it was a lot of web development. Were you—was it three.js there or what were you doing for visualization there?
Jordanna: We wrote our own.
Lyle: Oh, you wrote your own. Okay. Yeah.
Jordanna: Yeah. And we did have an additional engineer who was doing like, you know, just 2D WebGL, which was really interesting.
Lyle: Yeah, yeah. Cool. So then four and a half years ago or a little less than four and a half years ago, you joined Netflix. And at that time Netflix mobile app—you worked on the iOS app—was a WebView app. Can you explain what a WebView app is?
Jordanna: Yeah. So a WebView app is essentially, you’re rendering a web application that is wrapped in a native application. So the native application itself is—at the time, I think it was still Objective-C. It was just written—in C++ actually and Objective-C, but inside the UI itself was rendered using web technologies. And it was almost like a browser within your app.
Lyle: Yeah. Okay. So at this day and age, and about three years ago, I guess, the iOS app was rewritten in Objective-C and it was a native application. And Jessica, you’ve worked here only since that migration, right? So you were hired in as an iOS developer and have never worked on the WebView app; you’re working on the existing app, which is Objective-C?
Jessica: Yes, that’s true.
Lyle: And I want to talk a little bit about what have been challenges for—what differences for working other places and here, we’ll touch upon if anything comes up. But what’s it like to work on such a prominent app on the App Store? I mean, what’s it feel like to do that every day?
Jessica: For me it’s pretty much what drives me. I love having impact. I love knowing that everything I do, millions of people use it and see it, and it totally highlights the whole freedom and responsibility of Netflix where I can really touch any part of the app and I can say, you know, absolutely that I did that and that was my decision. And it’s really great to be able to point at something and be like, “I did that.” I tend to whip out my phone during dinners, and I always point to the latest project I’m working on, like “That’s me.” And that is honestly—everything I’ve ever wanted was to have a career where I know that I’m actually bringing—I’m bringing joy to people and actually creating something that people enjoy.
Lyle: Yeah. It’s interesting the—as a software engineer, my career, most of the time people talk—you talk to them and they’re like, “I don’t understand what you’re talking about,” right, just an average person, right? But at Netflix, you’re like, “Okay, if you have that—You’ve used the Netflix application?” “Yeah.” “Okay, I do that.” There is this feeling of like, people go, “Oh, I understand.” Right away they understand even if they’re not a software engineer person.
Jessica: Yeah. It does make introductions much shorter, which is really great.
Lyle: You two worked and led this project that was a test, and it was a UI test, and it was a lot of development. I think it was—it was called WD-40.
Jordanna: Oh, yeah.
Lyle: Explain what this thing was.
Jordanna: So the code name really came from—actually I think it was our manager, Tom Richards. And he had this idea—and it was really engineering-driven; it wasn’t really—because we also work really alongside a product team, and they come up with a lot of ideas. But, you know, engineering also gets a lot of say into what the next projects can be and what we think would result in the positive experience.
Lyle: So this was led by engineer designers?
Jordanna: Yeah. And it was like thinking, hey, how can we make navigation smoother and, you know, WD-40, it’s supposed to make things smoother.
Lyle: Oh, that’s where the name came from. You know what WD stands for?
Michael: Really? You didn’t catch that one?
Lyle: No. I thought maybe the product was squeaky, but I thought that was kind of insulting. But, yes, makes things smoother. Do you know what WD stands for in the WD-40, the actual oil?
[Crosstalk] [00:08:29]
Lyle: Water displacement, the 40th attempt to displace water. So it’s actually not really a good like lubrication for long-term existence; it’s for expelling water from your joints. So people use it for like hinges, and if you do that, you just have to add it a lot. So it’s not—
Michael: I feel like there’s a star coming across, like the more you know...
Lyle: Anyway, so WD-40’s this project, engineer based. Let’s talk about what the app—Most people understand what Netflix app looks like. It’s a row of movies. What’s it called, Michael?
Michael: It’s a List of List of Movies, if we’re going to be honest.
Lyle: And describe what that means, like what do you mean by a List of List of Movies?
Michael: So you have a vertical amount of movies. Well, right now, is that even true anymore on the iPhone?
Lyle: Sure.
Michael: It’s true? Effectively, we have both a vertical set of movies, which means you can scroll up and down, and we have horizontal, which means you can scroll left and right. And they’re not actually movies; they’re really seasons and series.
Lyle: Shows and movies and—
Michael: But legacy, we were a DVD company and we had a List of List of Movies only. So we lovingly refer to that as the LoLoMo.
Lyle: So when you’re navigating on the TV or the website or the mobile app and you look at a box art and you’re kind of scrolling back different directions, that’s the general tactic of how we present videos. And those rows of course are kind of genre based. Like one of the rows might be horror movies; one might be comedian standups. And there’s—
Michael: “Because you like Bruce Willis.”
Lyle: Right.
Michael: “Because you watched” whatever.
Lyle: Right. And then that whole collection is of that type? Okay.
Michael: Yeah.
Lyle: So that’s the standard form. What’s WD-40 do? Jessica?
Jessica: Well, based on the name, we’re trying to reduce friction in browsing. And so one of the points of friction that we really focused on was this concept of you’re kind of pogo-sticking in and out of movies. When you’re looking for a movie or a show or any sort of thing to watch, you’re usually kind of comparing a couple of them and you’re kind of browsing in and out of different ones before you ultimately make your decision. And so with WD-40 we wanted to find a way where you can just really smoothly navigate from one title to another title without friction.
Lyle: So right now you see that list of box art and I’ll use an image. You click on it and it opens up what we call the display page. Then to see the next display page, you close that one, go to the next box art and click it again. And this has to do with not having hover states. On TV it operates differently; on a website it operates differently. But on a mobile device, you kind of—the finger just says go and what do you do at that point? Okay. So you—the display page did something different?
Jessica: So the average experience is you tap on a box art and a display page opens. You get some information, maybe a synopsis, cast, and then if you want to see a different box art, the most common path is just tap on the X and close it. We wanted to make it so that you can really explore easily. And so one iteration of WD-40 was to kind of take that row, that list concept, and kind of bring it as if you’re zooming into it. And so now you can see other titles left and right, including a synopsis and the cast for each of the titles, and just gracefully swipe until you find exactly what you want to watch.
Lyle: And it felt good. I mean, it was a hard engineering challenge I’m assuming. Yeah?
Jessica: Yes.
Lyle: When you guys do that, what kind of things did you run into in changing to that, from an engineering perspective? What was challenging?
Jordanna: I think actually the interesting challenge, at least from my perspective, was actually on the data side, because when you’re kind of pogo-sticking in and out, you’re kind of almost giving some friction in terms of how quickly you can request data. But then when you kind of add in some gestures, where you can smoothly go across multiple display pages—
Lyle: Swipe to the side, swipe to the side, swipe to the side, yeah.
Jordanna: Yes. It means that you have to start managing more data requests.
Lyle: Yeah.
Jordanna: Yeah.
Lyle: So that was a real challenge—
Jordanna: Hm-hmm [affirmative].
Lyle: ...like as the person’s swiping, you have to get data, but you don’t want to get too much data.
Jordanna: Yeah.
Lyle: And then if they swipe really fast, you might want to cancel that data.
Jordanna: Yes.
Lyle: So what do you do in that situation? Did you have to restructure and create a new model to handle that?
Jordanna: We did restructure a little bit of the data-fetching mechanism to be able to cancel properly. I think that was the one big thing that—we just assumed every time you hit the X, right, that okay, we can cancel there. But we didn’t have the ability to just, you know, cancel while, say, it’s swiped off screen.
Lyle: Yeah. What do you take advantage of, doing that, from like a real deep level? Do you use some kind of component structure in Objective-C to do this?
Jordanna: Yeah. Actually, the base of that was a UI collection view, and there was—You know, in UI collection view, you get a lot of delegate methods that are able to tell you, “Hey, this is going to end display,” and then you could base it off of that and, say, recycle things and cancel any in-flight requests.
Lyle: Michael, do you get a chance to play with it? WD-40?
Michael: I have not had a chance to play with WD-40. Well, I played with WD-40 but not this.
Lyle: The oil? Yeah.
Michael: I actually have questions about the data, the data fetching. So I was always under the assumption that you guys request all the data up front. So how do you—how was that a challenge, because I thought you already had all that data? So when you’re doing it, you’re actually requesting more data, correct?
Jessica: Yeah. So in the LoLoMo, we try to get as much data as we need just to render the LoLoMo. There’s sort of—with mobile, there’s two things that you have to balance. You have to balance making a limited number of requests, and then you have to balance how much data you need per request. So the LoLoMo is—it is, yes, one request and you get all the data, but it’s only what we have to display that particular view, so typically the box art and title. Once you go into the display page, there’s a lot of things that you need additionally, like the list of episodes, all of the metadata about those episodes. But you also need your, what we call volatile data, so things that change relatively often, so your—
Lyle: Like what?
Jessica: Like your ratings, your viewing history, if you viewed it, how much. And those things need to be requested at the time they view it. We want it in a timely manner. We want it to feel like up to date.
Lyle: Because I might like on television in the morning, watch an episode of some show, and then on the train ride into work, I pull up my phone and I want to see where I was when I was watching, not just the last time my phone loaded but where I was most recently. That’s the volatile data you have to refresh?
Jessica: Exactly.
Lyle: Okay. So that gets done on display page open. So that’s that extra—And the episode list sounds kind of challenging because we have lots of episodes sometimes. So you’re pulling all that art in and everything during that time, during swipe gestures? Yeah, it sounded good. Sounds challenging.
Jordanna: Yeah. And the episode, you can imagine some shows have many seasons, like 10 seasons of, I don't know—
Michael: Friends.
Lyle: Friends, yeah, exactly.
Jordanna: Yeah.
Michael: Lot of episodes.
Jordanna: Yeah. And that—you have to manage that request in the sense of, hey, can we fetch all of them at once? You know, you have to balance the payload size that might come in and the latency and the round-trip time.
Lyle: Versus the multiple requests which is more expensive because you have to turn the antenna on and off more times, yeah.
Jessica: Exactly. We investigated paginating, but there’s always the price you pay. Either you pay for the number of requests you make or the payload.
Lyle: Now, the other thing about this, about investment in time and energy when working on this, is that this is what’s called an A/B test. So, Michael, tell us what an A/B test is.
Michael: An A/B test is where you have two separate experiences in which you allocate an amount of users into each one that will give you a statistically significant amount of data to understand which one did better based on core metrics of the business.
Lyle: And the thing that’s neat about A/B tests is it gives you the [unintelligible] [00:16:07] to do something like an engineer-driven experience, right? Like, well, it might work; it might not work. Let’s put some resources on it, try it out, and see if people like it. And the reason why I asked if you had seen WD-40 is people didn’t like it or we didn’t keep it on. It was a failed test, or a successful test, depending on how you think about it. So how long did you guys work on that project?
Jordanna: I think it was several months.
Jessica: Yeah, it was at least two months.
Jordanna: I think it was originally—when we estimated it, it was like, oh, yeah, it’s going to be like five weeks or something. But because we worked in such an interesting environment—so we actually co-located with the design team this—for this particular project, and we went back and forth a lot, like just iterated. You know, we would almost prototype something for them to see and see if that’s what they were kind of thinking in their head. And yeah, that made it so that we extended the project a little bit longer.
Lyle: Yeah.
Jordanna: But when we did actually allocate—
Lyle: Meaning that it was sent to the users and some users got this experience and some users didn’t get the experience?
Jordanna: Yes. So we looked at some core metrics. And some of those core metrics did not perform as well as our control, which is the current experience. And obviously we had a hypothesis that, hey, maybe the navigation would actually let people explore more and they’ll stay on the app longer or look, you know, play more, find more things to play. In this case—
Lyle: We didn’t turn it on.
Jordanna: Yeah. We didn’t turn it on.
Michael: Are you guys going to displace water for the 41st time?
Jordanna: There’s isn’t a follow-up test where it’s like WD-40 the sequel, but we learned a tremendous amount during the process. And the challenge with tests is two parts. One, it’s you’re writing code that has to go to production, and so it has to be high quality. But yet the balance, it’s also a test, so don’t spend a year on it. And so you have to make some compromises, both in the engineering the architecture, but also in the user experience.
The second part is, you might be hitting some of your core metrics, so you might be improving some aspects but maybe offsetting user behavior. So you might have users doing something that is not conducive to them actually finding a particular title that they want to watch. So they might end up using this new feature more and enjoying it, but it doesn’t actually help them in the way that we hypothesized.
Lyle: But, Jessica, when you’re at dinner with your family and someone asks what you do, you were like, “I did this.” You pull out—That moment there is worth so much to you. I mean, isn’t it hard to like just go, “Oh, the last three months, you can’t even see what I did”?
Jessica: No, because there’s always something on the horizon. And that’s probably my favorite part about A/B tests, is it—there’s—nothing is stagnant here and there’s always something we can learn. And so there’s always a new and exciting project on the horizon that I can pull out at dinner and show off.
Lyle: So let’s talk about like you had to make some compromises. We’re not doing shortcuts; we’re doing compromises? Okay. So you had to make some compromises, understanding that this code that you’re developing needs to happen quickly, it needs to be stable, but also might be pulled out later. So what kind of things did you say, well, we could change this throughout the app, but we won’t? What kind of things were like that?
Jordanna: I think the core display page architecture, because the way it was written was really, you know, meant for “go in and out,” you know, you show one at a time. It was never meant for, hey, show possibly three at a time. And that was the one big thing that we didn’t want to touch.
Lyle: Yeah.
Jordanna: And that was a compromise. So we took, I guess you could say a shortcut, in that—we just re-implemented it in a way where it’s like, hey, take the existing one, make a copy of it essentially, and—
Lyle: Which is not something you normally want to do in software development because then it—you have two things to maintain.
Jordanna: Yes, exactly. So it does give us the freedom to make these decisions, like as an engineer, no one’s going to say, “Hey, you must do it this way.” Or your manager’s not going to tell you, “Hey, you must like re-architect this whole thing for this one test.” So you have a lot of say in terms of the direction in architecture implementation-wise, even timeline, you know, of these projects and tests.
Lyle: So you went back to the code and had to pull things out. And some things of course you actually didn’t get pulled out because it was used during the—I mean, during the time. Some things taken advantage of. From a learning perspective, you can pull the code out, get it to turn off, it’s not going to work anymore, you’re going to do something else now—What things did stay? What things were like, oh, that was an improvement? Or what things are going to stick with you in newer, future stuff?
Jessica: One of the things that we had to do was optimize a lot of our code. To get smooth, buttery 60 frames per second with as much rendering as we had on the screen, we had to actually go to our existing architecture and do a lot of optimization. So it was actually a win for the existing experience as—as was a win for WD-40.
Michael: Can you break that down, like how did you guys figure out what was slow, what was fast, what did you change?
Jessica: So one example, to get kind of into the nitty-gritty, is we tend to try to use best practices in laying out the actual UI, and both for just code readability and also future maintainability. But one example is that—of that is Auto Layout, which everyone has their opinion on. And we found, both with Auto Layout and also loading the views from SIBS, they’re—they have a price. Just like with network calls, all of those have a price to pay. And in this case, we didn’t have—we couldn’t afford that price. And so we had to rewrite the code, yes, in a compromise, in a way that might not be as maintainable in the future, but it sped up the user experience tremendously.
Lyle: Auto Layout is wonderful when you’re in an iPad environment where you can rotate the screen all the time. And so you design your views to actually re-layout any time the rotation occurs, and so Auto Layout’s convenient. But in—this thing only worked on the phone, and so you didn’t have to deal with a portrait experience. So some of the benefits of that wasn’t worth it, and of course that takes processing time to calculate those. So you yank them and it goes smoother. And is that staying in the now—the new display page, or the display page that currently exists, is that stuff now there?
Jessica: Yes. Yeah. Many of the components have now been rewritten kind of using a different layout engine, so it’s at least there for now until a new A/B test says otherwise.
Lyle: There’s this perspective of our culture that it’s a fearful place or a scary place because at any point you can just be removed, you know, fired if you’re not up to par. But you’ve been here for over four—I think four and a half years or so. Do you find—do you have a fear aspect of like, you know, major [unintelligible] [00:23:02] of your work gets thrown away in some sense. Is there—do you have any fear around that?
Jordanna: Not at all. That was actually—during my interview, it was one of the things that was brought up. Like I even asked questions around it just hearing from like Glassdoor or some other places where there’s a lot of feedback about fear or this culture of, hey, I don't know what’s happening behind my back. There’s really none of that. And it’s interesting because I understand how, you know, sometimes, you know, business requirements, something might need to restructure and teams change. That happens.
But the thing that’s really exciting about, at least mobile, is that it’s evolving all the time. So for example, the evolution where we went from a WebView app into a full-fledged native app, I mean, that gives you the opportunity to actually evolve with it, and that’s one thing that maybe another five years from now there’s going to be another evolution.
Lyle: Yeah.
Jordanna: Yeah.
Lyle: So the app right now is in Objective-C, and Apple has rewritten, made open source, Swift. And some companies are taking on Swift as the beast to use for the programming language, and at the same time, early on in the process, it was changing, iterating a lot, so if you did it too quickly—in fact, when Apple first released it, they’re like, “This is our roadmap.” You know, it was really clear that, “Here’s what we’ve made, but also here’s a roadmap.” At some point, though, Apple—it seems clear that it’s going to be time to move to Swift. Are you guys thinking about that and looking at that possibility? Jessica?
Jessica: We’re definitely thinking about it. It’s something that—So most of our meetings are basically self-directed. So we have a team meeting where we discuss Swift almost weekly, and it’s—we don’t want to just use a technology for the sake of using it. There’s—you know, it’s fun. I used Swift for an entire year before I moved to Netflix, and it is a lot of fun to use it. And it’s always fun to feel like you’re on the cutting edge.
But it’s, you know, there is a cost to that, too. And it’s something that we as individual engineers have to make that decision if that cost is worth it, or as my favorite coworker used to say, “Is the juice worth the squeeze?” And so when—I think it’s—at any one time any one of us can actually start writing what we want in Swift. And some of our code is written in Swift.
Lyle: That’s interesting. So you’re saying that you chat about it weekly as a group and at any point you guys could all decide to just do it. There’s like 20 people kind of involved in the development. At any point, you could be like, “This makes sense.” So it’s not really—like there’s not a mandate or any of that, but there is this aspect, as soon as you make that decision, you’re then kind of on this road of having to ride kind of two different programming languages. Is that a concern?
Jordanna: I think currently, you know, that is one of the concerns. Also currently around our billed infrastructure, it’s whether or not we have the time resources to support that, because it is adding additional cost there. Will this negatively impact our bill times, for example, or our distribution?
Lyle: Because one of the things we have in the app—in most of our apps we have all these tests that run. So one of the devs will—Jessica will—you’ll go ahead and remove WD-40 and submit that. And then the systems will build the app, deploy it to a whole bunch of tests. We have iPads and iPhones all over the place in different rooms here. And it will run through all these suites of things and say, “Oh, you made a mistake here.”
An error will occur, and you’ll fix that if necessary. And TV’s the same thing; website’s the same thing. So there’s this whole process of doing that structure, which also has—it’s not just about Jordanna deciding to put Swift in. It’s also about the entire pipeline. But no one’s saying, don’t do that. It’s more like, if you start that process, you’re kind of going to help shepherd that process.
Michael: So we should probably be a little bit more specific. At least at a lot of companies I’ve been at, every time you make one of those changes, it’s not just whoever those 20 people are in the room; you usually have to get buy-in from management or upper management. How much does that play a role in this? Like if you were to switch to Swift, there’s some obvious like institutional costs like, hey, we can’t do A/B tests for the next X months because it’s virtually impossible. How does that play into it?
Lyle: I don't know. I don't know anything about iOS, so in my world, if you were to say “I’m going to rewrite this,” it takes time. So I don't know how Swift work—it sounds like it’s very swift if you don’t even have to incur that cost.
Jordanna: It can live side by side with our Objective-C code. So there is no really—you know, it’s not like, hey, this is another rewrite of the Netflix application.
Lyle: Well, the question I think—the root of my next question is really like who makes these kinds of decisions on the team? If it’s a collaborative group, there’s a manager obviously that says yes or no, right?
Jordanna: So the interesting thing—at least this is from my experience in terms of like these big decisions around, say, language or infrastructure changes. A lot of it is engineer—like individual ICs like individual-contributors-driven in the sense that it’s kind of up to you to make the pros and cons and weigh them. And it’s not really your manager saying, “Hey, this is what we’re going to do. Give me reasons why.” It’s almost like myself presenting this to my manager and saying, “Hey, I have a case for going in this direction. Here’s some evidence.”
And then obviously it’s, you know, as a group on, you know, in like, say, 20 folks on our team—it’s not just our team specifically, but also the extended teams agreeing on it and having a good case for it and then leveraging your manager to really kind of make this a final decision, being able to propagate it beyond your immediate teams. That’s how I’ve been able to make any major change.
Lyle: Yeah. It feels more like a collaborative process, like a whole bunch of contractors talking about things, even when it’s your manager, which is neat. Lots of times though, I find the manager has a context that you’re just not aware of that’s like, “Oh, there’s that happening,” right? They might know something about, like prior to the global expansion, they might know that we’re about to expand globally but we haven’t made that public. And so there’s like a thought process of well, how that potentially could impact things.
So there’s a lot of other context that we just don’t have time to know about, even though we’re given that information in a kind of amazing way. Jessica, you’re the newest—in the four of us, you’re the newest to Netflix. What do you think about like the QBR documentation, all this internal documentation being available to you about how the company runs? Was it different than Kodak?
Jessica: It’s absolutely different. I’ve never seen so much open sharing of information. And if I have the time and energy to seek it out, it’s all there for almost everything I can read and learn about.
Lyle: So do you have the time to do that? To spend like looking at what next star we’re going to hire or anything like that?
Jessica: In the beginning, absolutely. I was so excited to learn everything, I think I read every single QBR document. And now it’s I pick and choose what’s more relevant to me in my job and also just what I’m interested in.
Lyle: Sorry. QBR stands for quarterly business review. It’s like the business documentation. All the execs and directors write up like what their unit is doing so that the entire company knows, and then we get access to all those things after the meeting happens.
Jessica: Yes. So those are my favorite bus reading material because I can just kind of crank up the text size and just read it in the morning and sip my coffee and it’s great.
Lyle: Yeah. Yeah, it’s fun. And it’s interesting, it doesn’t necessarily impact what we’re doing every day, but it sure is fun to see what’s happening. But also just the dialogue that happens throughout the company about what our next strategy would be, what could we do next and where should we choose to do things. And also like we have this open Q&A with the CEO, and he actually—Reed actually responds to questions posted there. Michael, I bet you participated a little bit there.
Michael: I have asked a question.
Lyle: And that’s fun to get kind of an honest answer internally.
Michael: We should probably explain that a touch more. It’s something that I think is very unique that we definitely did not have at any of the companies that I’ve been a part of, is that we have a fully open document internally in which you can ask any question you want, and someone from the C-suite will answer that question. Personally I asked why isn’t January 1st known as Netflix day.
Lyle: Because a lot of people watch Netflix on January 1st?
Michael: Yeah. It’s a great day to watch Netflix. And they didn’t really bite that idea. I think it’s still a good one, but maybe we’ll get that one next year.
Lyle: Do you guys do hiring? Like do you participate in interviewing new candidates?
Jordanna: Yeah, yeah. We’ve both been involved with interview panels within our team; also outside of our team.
Lyle: How? What do you mean?
Jordanna: Mainly for—especially if it’s around mobile, just getting a perspective of how we would be able to collaborate with this particular candidate.
Lyle: So let’s say a designer is being hired in the mobile team. You might actually interview that candidate as well?
Jordanna: Yeah, yeah. It’s possible. I haven’t personally, but it’s a possibility.
Lyle: Yeah.
Jordanna: Yeah.
Lyle: And we do that—that process is really about seeing how the people fit throughout the entire company.
Jordanna: Yeah.
Lyle: Did you interview Jessica?
Jordanna: I did.
Lyle: What did she do wrong?
Jordanna: I honestly—Wrong? Like—
Lyle: Did she make any mistakes? How did the process go?
Jessica: It was probably the—I wouldn’t say enjoyable because is any interview enjoyable? But as far as interview goes, it was the most enjoyable interview I had had to date. It was a much more relaxed environment, contrary to all the Netflix culture—
Lyle: Outside—
Jessica: ...of fear that we had talked about. I was met with zero of that. And I appreciated the interview because it really hit on what my—what actually working at Netflix would be like. I had a take-home project, which I always appreciate.
Lyle: So the interviewing process can of course—tech interview, can just be a whiteboard in a room and you ask some computer science question, you know, “make a link list” or something. That’s one process and flow. And the other one is a more deeper, thoughtful thing, this take-home idea.
Jessica: Yes.
Lyle: So they gave you a take-home and you spent some time developing something.
Jessica: I did. And it was great because I basically had to kind of defend my project. Or not necessarily defend, but speak with a passion of why I made certain decisions. So I was able to really think into how I wanted to be—what kind of developer I wanted to be and what kind of place I wanted to work. And then Jordanna was able to walk through it with me and see how I think. And so—
Lyle: And not just a superficial in the half an hour.
Jessica: Exactly, yeah.
Lyle: But actually like in a few hours of actually development you got to do by yourself.
Jessica: Yes. And we did do whiteboarding, too. I think having the variety is really beneficial, but I’d also like to highlight that every team here does their interview different.
Lyle: Totally true, yeah.
Jessica: And I also appreciate that because I get a real, true representation of what working on that team will be like. I’ve done interviews where it’s their standard process and then when you join the company, it’s completely different. It’s, you might as well have interviewed for a different company.
Lyle: Yeah. Like some companies will do like a boot camp process where the intern gets hired, and then they spend a lot of time training. And then at one point later on, they actually join their team, which here it’s not like that. The person that’s hiring you is like in full control. That’s the other thing that’s amazing is that manager, the hiring manager, though you meet other people and get a lot of feedback and stuff, they can decide, even if someone else at the company was like, “No, I don’t think so,” they could decide to hire the person anyway. So there’s a lot of authority at every level, which is kind of neat. Or a lot of—I don’t know if it’s authority—a lot of independence?
Michael: “Authority” I think actually, technically is the right word.
Lyle: Yeah. Okay.
Michael: So if you guys were to give some advice, especially Jessica, you just got done doing this not too long ago, what is some tips to be successful as an iOS interviewee? Interviewee?
Jordanna: Candidate?
Michael: Candidate.
Jordanna: Okay.
Lyle: Well, I mean, I—first, I don’t think that’s the way you think about hiring—think about getting a job. I don’t think it makes sense for an engineer to go, “How can I trick this company into hiring me?”
Michael: Well, no, because—
Lyle: Because that does not—in the long term, that will not work, right?
Michael: That’s not necessarily true. Like there’s a technique to whiteboarding. You should talk about what you’re going to do, talk about the boxes and arrows. And if you just come in there like I did fresh out of college, I’m like, “Oh, I got to do—link this. We got a node, we got this, we got”—You know, like that was the wrong approach. I was not being successful for the company in which I was hiring. And so what—Netflix is very, very different. I sat on a porch with the VP and talked about Montana. That was my interview, and I got hired I guess. Accidentally, but nonetheless—
Lyle: Well, Montana’s pretty awesome.
Michael: Montana is pretty awesome. That’s a plug for Montana. But how is that different—I mean, everyone comes in here probably with like the Google video, like this is how I’m going to be successful at a whiteboard tech company interview. Like how is it different? What makes—what are some steps to be successful here that probably isn’t going to work other places?
Jessica: I think being truthful about who you are and what you want. Usually when you interview, you kind of exactly try to mold yourself into what you think the company wants, and that’s doing no one a favor. When you get hired, now you feel like you’re not a good fit or you feel like you’re an imposter. And then when they hire you, they’re like, “Who is this? This is not the person I interviewed.” So I think just being really honest about yourself and also honest about what you want, and, you know, if Netflix meets that and you meet what Netflix needs, then it’s a great match.
Lyle: Okay. Let’s move on to imposter syndrome. Do you guys ever feel like you don’t know what you’re doing?
Jessica: If I say yes, then—
Michael: She both shook her head yes and no.
Jessica: That’s always the question where you’re like, should I say yes, because then I admit that I feel like I don't know what I’m doing, or should I say no?
Lyle: I have severe imposter syndrome all the time.
Michael: I can second this.
Lyle: That I have that?
Michael: Yeah, I can second that he—
Lyle: Thanks a lot, Michael. So there, the cat’s out of the bag. At least one person that’s been here for a while feels that way sometimes. Ever feel that way, Jessica?
Jessica: I would say constantly. I think that’s probably the nature of engineers, though. We’re always introspective, and so it’s just, I think, imposter syndrome is especially rampant in our industry.
Lyle: What about you, Jordanna?
Jordanna: Um...
Male Voice: No, I’m awesome.
Jordanna: It happens from time to time. When—it’s usually around things where it—you’re just completely uncertain about something, which is, again, like, you know, it’s something engineers go through often, where it’s like, hey, there’s a brand-new technology I’m not, you know, you haven’t read up on it, you’re not on board with it yet. Then you’re kind of like, okay, now I have to jump on board, and that’s when you’re kind of in that mode where—
Lyle: The vulnerable spot. Yeah.
Jordanna: Yeah. Because, you know, someone comes to ask you a question about it and maybe now you’re the resident expert in it, and you’re kind of like, “Well, I don’t really know, but”—
Lyle: You’ve been put in that position a couple times. So we’ve been working together for four and a half years or so.
Jordanna: Yeah.
Lyle: I’ve been here for four years. And I think actually you did hire me, which is kind of funny. Were you one of the hirees?
Jordanna: Yeah.
Lyle: And I guess I did okay because I’m here. But I’ve seen you quite a few times tackle something that’s completely new, experimental, not just like in the UI thing, but whole platform stacks. The decision to go—to move to a native environment, for example, you were highly involved in even a pretest before that. And that place is completely in an unknown. Did you like that feeling?
Jordanna: I like the challenge. I really like just seeing that—in—that’s how I guess I channel that feeling of being an imposter. I kind of go, “Okay, this is an uneasy feeling. How do I change that?” And it’s really kind of, really diving into it and just really understanding it. So that was one thing with when we were looking at native solutions, I had—I have never done Objective-C. It looked horrible [unintelligible] [00:39:47], right, you know, all these—
Michael: Have you grown to love it yet?
Jordanna: Uh...
Michael: It’s a love-hate, right?
Jordanna: It’s a love-hate thing, yeah, yeah. I loved some of the concepts, but, yeah, just typing it, it’s autocomplete.
Lyle: Yeah.
Jordanna: But yeah, like just not knowing when you’re in that kind of mode where you’re thinking, okay, I can’t really answer any questions about it, so what do you do to kind of fix that? And I just go headfirst into looking at—reading up on it and, you know, hands-on—being hands-on.
Lyle: Yeah. And of course the least you know right then, the more you study it, the better you’ll get at it.
Jordanna: Yeah.
Lyle: And you kind of know that, too. It’s like, well, no matter what happens, I can get better from this position.
Jordanna: Yes, yes.
Lyle: It sounds like you kind of enjoy that exhilaration of not knowing. It’s like—I have this vision of like getting on a sled in a mountain range you don’t know and just going for it.
Jordanna: yeah.
Michael: There’s some fear there, but that’s part of the joy of it.
Jordanna: It is. And it’s very satisfying after—like once you’ve gotten to the point where you really understand it and you can start making solid decisions with confidence around it, you get a lot of just satisfaction out of being able to say, “Yes, I can do this,” or “No, we can’t do this.”
Lyle: Yeah.
Jessica: I would like to say something that kind of highlights on imposter syndrome that I wish someone had told me. Because I’m not like Jordanna; I don’t like to be on the precipice. I’m happy once I’ve tipped off of it. That moment of tipping off of it is exhilarating—
Lyle: The top of the roller coaster.
Jessica: ...like I’m doing it. But sitting there and looking at this insurmountable task is just overwhelming. And so what I found to really combat that is find mentors. And I’ve been really lucky in my career to have some really good mentors. But especially at Netflix, I looked at every single one of my coworkers as a mentor because every single person has something to teach me. And so if you approach a problem as not “this problem is insurmountable,” it’s, you know, who are the mentors that can help me show the way. Because eventually you’re going to become a mentor yourself and you’ll realize kind of like the joy and the excitement and be able to help someone over that precipice, too. And so for someone starting out earlier in their career, look for the mentors.
Lyle: And even without starting up early, there’s this computer—you know, programming is this endeavor to try to build a complicated system and still wrap your mind around it. And the boundary of that is our ability to wrap our minds about it. The software could always get more complicated. It’s us that holds it back. And that’s why we have so many different paradigms of talking about things so we can encapsulate the complexity and understand it. So every time—and like that’s why this example of you find your code from three years ago and it looks like someone else wrote it, you have no memory of what it was or how it worked and then just like slowly comes back.
But basically it’s like it’s somebody else’s work. And so if Jordanna’s doing something about data management and you’re doing something about the display page scrolling and I’m doing something completely else and Michael’s doing something else, all of us are this weird like pinnacle of expertise in this very specific thing. And if any of us want to go do work in the other space, the mentor is that person, any direction you flow.
So it’s kind of like you’re constantly in this unknown spot and they’re an expert and also totally unaware of what everything else is. And I think that the imposter syndrome really gets amplified where you go and look at, wow, what Jordanna’s doing is incredible. Of course, she’s been spending weeks doing that and you have no idea of what it is. And so you feel like an idiot in that space. So yeah, it’s interesting.
Well, I got to say it’s a pleasure to work with both of you. I work with you all the time of course because I also do iOS development here—spoiler alert—and it’s really—it’s a pleasure to be able to have experts that are very knowledgeable but also very like sharing of what their knowledge is. We don’t have that thing of like this hard, difficult person. Everyone you talk to is like, “How can I help you?” So it’s an amazing experience. So thank you for being those kind of people as well. I appreciate it.
Jordanna: Thank you.
Jessica: Thank you.
Lyle: I got to go off to a meeting and you’re going to close down the room, right?
Michael: I am going to close this room down.
Lyle: Any other questions?
Jordanna: I just had a thought about feedback, you know, just working interpersonally with your teammates and the wider team, there’s a big culture here with giving feedback and as often as possible as, you know, immediately as possible actually before the actually official 360s come around. So I do appreciate that, because from time to time like someone will pull me aside and tell me, “Hey, you know, we chatted about this. I think you can improve on this” or—You know, it’s very candid here.
Lyle: Do you have an experience of that? Have I ever given you feedback you’ve acted on?
Jordanna: You have.
Lyle: Okay. Let’s talk about that.
Jordanna: Yeah. That one time I was completely stressed out. I remember that one time. And then I think you had—it was on Slack or something, you had mentioned some things, and I came over and I gave an answer really quickly and left. And I didn’t really follow up.
Lyle: And so my feedback to you was something about—I can’t remember what it was structured, but it was basically about when you—giving—you know, giving assistance or giving attention to somebody—
Jordanna: Yeah. Yeah, yeah, yeah. And I hadn’t stood around to really kind of process all of that and provide the assistance that you were asking about. I kind of gave an answer and I was like hoping that you’d figure it out. And to me, that was like, oh, okay, yeah, I—you know, before I go over, I should think, you know, hey, what is the correct approach to providing that—you know, what—the help.
Lyle: It’s interesting. That was probably three years ago that I gave that feedback, and I’ve—since then, I’ve never had that experience with you. You always are very open. And at the same time I’m also conscious that, because I said, “Hey, be more available,” that you might act more available to me and that I—So I have this feeling like any time I engage with you, I’ve got to decide, is this a time to interrupt her from what she’s doing. Which of course we should all be doing all the time anyway, right, like when’s the perfect time?
And that’s why these other side channels are really useful rather than coming to someone’s desk. So thank you for taking that feedback. I find that extremely challenging, when you get hard feedback about yourself and you look at it and go, yeah, I want to be the person that’s not like that; you know, I don’t want that—to have the trait, and change it. Whew. But it happens all the time.
Jordanna: Yeah.
Lyle: I’ve known people for years here, and I—at one point they were a certain way and now they’re different. And I think that’s happening because of that honest feedback we have.
Jordanna: Yeah.
Michael: The converse of that, have you had to give hard feedback? Have you avoided giving hard feedback and wish you would have?
Jordanna: Yeah, yeah. Definitely. Let’s just say that. That’s when, whenever 360s come around, that’s when I kind of type it out because it’s—for me it’s a little bit easier to give that feedback—
Michael: Yeah, the safe feedback—
Jordanna: Yeah. When I put it in writing.
Lyle: 360s are a feedback where we give feedback to everybody at the company so you can actually—you can write up something and just a really quick simple thing to say, “This is something you could do better” or “This is something you’re doing well.” And the intention is to do it with anyone you interact with, and everybody, because you’re basically taking that time to help improve them as a person that works here. So it’s hard to do that though.
Jordanna: Yeah. There’s a lot of thought that—I personally try to put into it, especially if it’s something where, you know, you can provide some constructive feedback, maybe some suggestions on how to improve on something.
Michael: But I mean, I am a little curious about iOS because we worked somewhat together on the performance and things of that nature with the JavaScript app, and then that obviously didn’t—it didn’t make it, and that’s okay. Do you ever wish you’d go back to JavaScript, or is just the love of square brackets just—
Jordanna: Uh...
Michael: ...flowing through you.
Jordanna: I generally think of a language as a means to an end. So for me it could be whatever language. But if I can build something with a great experience, I’ll use that language. And it just turns out that, when we were using WebView, it was really difficult to build something that was really smooth and that we were able to leverage all of the native I guess capabilities.
Michael: Makes sense. I don't know anything about iOS at all, and so I can imagine it would be awesome if we had the same performance that you guys get for Web because it is extremely difficult to make JavaScript awesome. I mean, the just-in-time compiling makes it great again at least. It kind of like almost comes back up to being something good, but it is always a very painful experience.
Do you have any like good points of what freedom and responsibility looks like? I mean, I have one that I always give, the classic one, inside the interview. I say that I think our expense policy is the best example of freedom and responsibility. No company I’ve ever been to has an expense policy of act in your best interest. Like the last company, I had a $35 seat upgrade that I could work the whole time, and I had to talk to like several people to expense $35, which seems ridiculous in hindsight. Whereas here, I don’t even think Jeff would have even known that I did that. And so it’s really awesome to work at a company that kind of permeates that. You just do what you need to do.
Jordanna: I have one. It’s actually because Jessica actually shuttles in every day from the city. And it’s a—it can be a long commute.
Michael: Yeah. I would assume so.
Jordanna: And sometimes it’s just, okay, maybe there are no meetings that day or she doesn’t really need to be present in the office. Why not just work from home and save whatever, five hours, five and a half hours—not sure what it’s up to.
Michael: I think it’s 17 at this point.
Jordanna: 17 hours.
Michael: People are bad drivers. I mean, it’s crazy.
Jordanna: Yeah, yeah. But I mean, it’s just as productive, someone working remotely as needed. So I see that as like, hey, it’s up to you, you know, you have the freedom to decide that, and also the responsibility to get a—you know, be productive in your everyday world.
Jessica: Yeah. Friday is not laundry day or “catch up with early happy hour at 2:00 p.m.” day. It’s, yes, I can work from home, but I absolutely have the responsibility to utilize that time effectively and get what I need to do, done. And I appreciate that because I’m treated, you know, treated like an adult—
Jordanna: Adult.
Jessica: ...which is—I appreciate.
Michael: It’s a little unusual I think in work culture.
Jessica: It is a little unusual. Yeah. there’s a lot of mandates at most companies that “You must do this. You must not do that.” And there’s no reason why, other than some historical three years ago somebody broke a rule and it caused a minor inconvenience and now everyone is inconvenienced. None of that happens at Netflix.
Michael: That’s my—that’s actually my favorite point. Here’s a question that—I’ve been struggling with this one for a while because I’ve been here for four years. I think that’s like the Silicon Valley dinosaur point, is like once you hit four years, you should leave a company. I’ve heard even two years, which seems ridiculous. What’s going to make you leave, Jordanna? Like I don’t think I can necessarily leave yet.
Jordanna: It’s interesting because mine is usually never around like the work I’m doing, because usually I find a way to make the work exciting. Usually it comes down to your team, your direct manager, or maybe even higher up the chain. And if something in that relationship is just not right, at that point I don’t care what I’m working on, right?
Michael: Yeah. Toxic environment.
Jordanna: Yeah, like a toxic environment. And right now like at Netflix that’s not the case.
Michael: Yeah. That’s—I mean, I was considering a new job for a while. And I mean, a good example is Jeff handwrote me a Christmas card and said nice—you know, said nice things. You know, it’s just one of those things where it’s just like, I’ve never had a boss that’s awesome. I mean, I’ve had good bosses, but I’ve never had a boss that I was like, this is the person with whom I’d like to try to be more like. And so it’s hard to find I think. I don't know. I haven’t also had that many jobs.
Jessica: It’s definitely hard to find. And when you’re—you’re working, yes, as a developer for 50 percent of the time, but the other 50 percent is you’re working with people. So those people have to be really good and really enjoyable to work with. And from my last company, I left specifically to follow a very excellent manager. And I think that just highlighted to me how much I value the people I work with. And the—at Netflix the people are top-notch—so far. No.
Michael: So far.
Jordanna: Oh, no.
Michael: Sorry, future people. Is there any challenges that you guys had so far, like partner challenges, things that make working difficult? Because I don’t—being on the originals team, it’s unique in the sense that I go to each one of these platforms. They each have their own kind of idioms if you will for how you should do things, and if you mess that up, people are [makes sound]. But you probably don’t have that problem because you are the idiom definers, if “idiom’s” the right word. “Idiosyncrasy”? Something. Anyways. You have your own specific flavor in which you program. Like how does—do you guys run into problems with how you make changes and hurt partners?
Jordanna: Oh, yeah.
Michael: Because we’re the partners.
Jordanna: Yes.
Michael: I don't know from the flip side.
Jordanna: Actually, yes. We don’t want to have angry partners.
Michael: That’s a reasonable thing to do.
Jordanna: Yeah, yeah. So, you know, even if you’re say defining the idioms, it’s—I don’t think it’s reasonable to say “You must follow this.” Like we can’t tell our partners that, “Hey, this is exactly what you should follow,” because each team and each of our partners, they have their own kind of almost like a team culture. They might do things a little bit differently because of business requirements. And there’s no one here saying, “Hey, you must do it this way or it’s wrong.”
Michael: Well, then that naturally gets into kind of conflict resolution, at least all the places I’ve been at. So team one has a problem and team two has a problem. It’s pretty much impassable or there’s some amount of tension that effectively they both go, “Hey, manager, help us out.” And managers, you know, I don't know what they do. They shut a door and they come out and there’s an answer. Does that work the same here? How do you resolve like inter-team problems?
Like Lyle. So Lyle’s a problem. I think we’ve well established that so far. I can’t wait for him to edit this because now he’s going to have to hear this. Like how would you—if you two came to an impasse, how would you solve it? Would it be as simple as just Jeff and Tom go into a room and out comes an answer or...
Jordanna: Well, if it was something between me and Lyle, I would get in a room with him or go—actually, I’d go outside, go on the trail and take a nice walk and talk it through. We’re all adults here, and it should be on us to kind of resolve that. But if it’s a bigger kind of challenge between the teams themselves, getting the manager to help, that’s a big thing.
Michael: I think that’s—I kind of wanted to highlight that because that’s a very unique thing, because whenever I’ve had problems at other companies, just like simple technology disagreements, it’s like you have to just cover everything in red tape and someone will figure out at some point. Whereas here it’s like, I’ve had some deep problems, like, “Hey, I think this is a really bad idea,” and they’re like, “I think you’re a really bad idea.” And then we start insulting each other, but at the end it comes out like we can actually just talk it out because we’re adults and I—And that’s a unique thing to have is a company that actually views people as adults. So I’m pretty happy about that.
Jordanna: Agreed.
Michael: Agreed. How much—do you feel like culture assimilated at this point, one year in, Jessica?
Jessica: At least for the iOS team. I think every team has a unique culture, too. So there’s the overall Netflix culture, but then each team has their own little flavor for it. So I feel like I’ve finally like settled into the iOS team. You know, it’s got its own special personalities that make coming to work really fun every day, and I’m not being sarcastic. It really does make work coming—make coming to work fun.
Michael: We got that. You fell into that one. We got that.
Jessica: But, yeah, I kind of—it took a little bit of time because it’s so different at Netflix than anywhere else I’ve worked. It’s much more bottom-up than top-down. I’m used to kind of just my manager just giving me the next project I’m going to work on, he just hands it to me, and then the designers just tell me exactly what it’s going to look like. And then usually product manager tells me when I’m going to be done. Like I don’t even have a say on the timeline. And—
Michael: And I hate that last part by the way.
Jessica: Absolutely, yes.
Michael: That hurts my feelings.
Jessica: Especially if it’s pseudo agile but then there’s a hard deadline, because that’s not exactly agile.
Michael: That’s the best kind of agile. “We have a timeline for your tasks.”
Jessica: Yes. “You get to iterate on this, but it doesn’t matter what you’re doing, as long as the end product is done exactly when I say it’s going to be done” So we have a lot of ability to pivot and make decisions that are both beneficial for us as developers but also for product. Like WD-40 was a really good example of that, of there was really great prototypes being made, but then we kind of came and said, “This is really expensive, but here’s alternatives that are cheaper that we can do.”
And so we actually went with a cheaper alternative because in the end it helped us answer the questions that we had. And I’ve never been able to—except when I working in the pseudo start-up, I have never had that experience before.
Michael: Yeah. Do you guys ever break production?
Jordanna: I did have something right before the holidays. This was before—
Michael: That is the worst time to have it.
Jordanna: Because we had to do a point release to fix it.
Michael: What’s a point release?
Jordanna: So it’s like a—so you might release a major version change, like 9.50 and then there’s a bug in it and it warrants enough that you have to resubmit to the App Store. And the App Store submission is—it does take a while, especially during the holiday season, because even—
Michael: Everyone’s doing it, right?
Jordanna: Yeah, everyone’s doing it; it might be backlogged; it might not make it out in time. And everyone’s being hit by this specific bug. And it my case it was two things playing back at the same time. We have our previews. And that was that, “Oh, I hit the play,” and I freaked out. I like—I stayed up late that night.
Michael: Do you guys get particularly worried—because we have the—you know the culture of kind of fear is what the outside like perception is. Do you feel worried when you break production? I mean, I broke it like a string of four times in a row, and I was like, uh, that’s probably not too good. But normally I don’t—I personally don’t have a problem when those things happen.
Jordanna: No.
Michael: It’s a learning experience usually.
Jessica: Yeah. I think, especially in this point in my career, I’ve progressed a little bit beyond fear, because if I haven’t caused production issues in the decade I’ve been working, then I’m not doing anything. Production issues are just a way of life. And you do everything you can to protect against it, but in the end we’re all human.
Two days ago I created a bug that crashed a relatively large percentage of users. I mean, we’re still talking probably sub 1 percent, but that’s huge. And we had to do a point release and fix it. And so it’s, you know, it is of course embarrassing to realize that you submitted something that actually caused a crash, but I also learned from it and I won’t do that exact same issue ever again. And I think that’s the key, is learning from it.
Jordanna: Yeah. And we tend to lean forward in terms of, you know, instead of rolling back to a previous build, it’s like, okay, fix it and move forward.
Michael: Yeah. We try to do that too on website. It’s kind of a gamble, like if you get a big enough bug, it’s a hard one to try to push through. But it’s usually the best, I think, decision. The end.
Jordanna: Yay.
Michael: Thank you guys. We appreciate you guys coming.
Jessica: Thank you.
Jordanna: Thank you.
[Music]
Jessica: My first job, I was called Jennifer for four years.
Lyle: Why?
Jessica: She just called me Jennifer and then—
Lyle: Is this at WideOrbit?
Jessica: This was at WideOrbit. And I thought she was such a nice woman and I didn’t want to make her feel bad, so I just let her call me—
Lyle: Isn’t there a Friends episode like that?
Jordanna: Wow.
Michael: If there’s not—there’s definitely a Seinfeld episode about not knowing someone’s name.
Lyle: That’s what I meant, Seinfeld, yeah. Wow, so that’s a long time. Did you tell her when you left?
Jessica: No, I didn’t. And to this day, she probably is like looking me up on LinkedIn like “Where’s this Jennifer Berglund?”
Michael: You should friend-request her.
Jordanna: Yeah.
Michael: Just really throw a curveball.
Jessica: She won’t know. She’s like, “Oh, is this her sister?”