We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free

Behavioral Interview

Watch someone solve the netflix behavioral interview (l5 senior engineer) problem in an interview with a Netflix engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Netflix Behavioral Interview (L5 Senior Engineer)

Interview question

This behavioral interview focuses on Netflix's culture values including collaboration, candor, freedom and responsibility, and the keeper test. The candidate shares stories about leading cross-team migrations, handling difficult feedback situations, taking initiative on cost-saving projects, and contributing to team composition decisions. The interviewer provides real-time coaching on how to structure answers, balance technical details with behavioral insights, and demonstrate cultural alignment.

Interview Feedback

Feedback about Hipster Pangolin (the interviewee)

Advance this person to the next round?

Yes

How were their technical skills?

4/4

How was their problem solving ability?

4/4

What about their communication ability?

3/4

You were about 75% of the way there and had enough highlights that aligned with Netflix culture, so you seemed both enthused and a good fit. You had many of what I call golden nuggets, that, when I hear them in interviews, I know this person will fit in well. That includes enthusiasm for feedback, self-awareness of flaws, and openness to trying new ways of working. You were working at the level I expected for 10 years of experience, i.e., the L5 level you were interviewing for. That came out immediately in the cross-team collaboration question, where an L4 would have been working primarily within their team, not across multiple teams. You took on the role of project manager when needed, interviewed customers, and briefly discussed the challenges of change management. Other golden nuggets include touching on the business aspects of products, talking about money, and not just the tech. When you had someone added to your team who wasn’t a good fit, you were professional and empathetic, which can be difficult to teach, and it was good to hear. The main area of improvement is polishing the answers into stories. Reducing some of the technical explanations (unless they ask) and being clear on who all the characters are. Interviews are persuasive marketing, so storytelling is a helpful tool. All of your answers were mostly there, so polishing them and giving more business details will only make you seem more confident and a stronger candidate. Reducing the technical information (like I don’t need to know it used a data lake), but make it clear what the product was (an external tool for five teams of 20 data analysts that you wanted to bring internal to save direct and indirect costs). As a little extra to stories, add your emotional intelligence (i.e., showing you understood how someone else was feeling). Also, remember where you might accidentally show something you didn’t intend. Giving leadership feedback directly is excellent, but a manager hearing that story might think, "Oh no, did they not discuss with their manager first?" Are they prone to going over my head? A minor adjustment to the story would keep you from giving the wrong impression. You used “we” for everything, which is generally good because it shows you care about your team and work well together, but finishing with your exact role (I did this) can help show your personal leadership. Make sure you answer the specific question; sometimes you gave a general answer (which is a good way to start), but didn’t include the specific story until prompted (STAR method). You can ask, “Did I answer your question?” if you blank on what they said, and it's not a big deal; nerves are a part of interviews, and sometimes you need a reminder. It’s like getting hints in a technical interview: some are ok, but too many aren't good. We talked about rehearsing, and there is almost no way you can do it too much. You can write scripts for yourself to help you remember, but don’t read from them (or try to memorize them). Think about it like a set list from a concert, you want to hit all the highlights. Showing enthusiasm for the culture deck is good, and you can talk about what stood out to you and how you use parts of it (and how you would like to use other parts)

Feedback about Declarative Dragon (the interviewer)

Would you want to work with this person?

Yes

How excited would you be to work with them?

4/4

How good were the questions?

4/4

How helpful was your interviewer in guiding you to the solution(s)?

4/4

Everything was great. Did a great job at delivering good feedback that was actionable.

Interview Transcript

Declarative Dragon: Hi, can you hear me?

Hipster Pangolin: Yes, I can hear you. Can you hear me all right?

Declarative Dragon: Yes, uh, it's a little, uh, it's a little hard, but, um, I also have on, uh, speech-to-text to make sure I get everything you say.

Hipster Pangolin: So, okay, I'll lean forward a little bit. If it gets bad, just let me know. I can maybe adjust a little bit.

Declarative Dragon: Okay, yeah, I could, I could see what you're saying too. So it looks, it looks like it's picking it up Well, so I saw that you had— I should make sure before we start the interview that it's exactly what you wanted. So I saw that you wanted a [REDACTED] behavioral interview and you have 10 years experience. Is that correct?

Hipster Pangolin: Yes, it is.

Declarative Dragon: And it would be basically for a software engineering role. At 10 years, it'd be like mid to senior, right?

Hipster Pangolin: Yeah. L5.

Declarative Dragon: Yeah. Okay, great. I'm going to get started. Is there anything else you'd like me to know or anything else? I should know before I get started?

Hipster Pangolin: No, I think I might mention some stuff during it, but I think, I mean, the big thing is I do have my, I have two, actually this could be helpful maybe. So I have two of my interviews for this position. I'm trying to find this. Coming up, sorry, I should have this beforehand.

Declarative Dragon: I mean, if it's an L5, all the L5s are pretty similar, so.

Hipster Pangolin: Oh, okay. They just, they had a thing that was saying the things that they were concentrating on, okay, focus areas like passion, recent project, collaboration, product mindset, which I assume you probably—

Declarative Dragon: Yeah, yeah, so the [REDACTED] interviews go really hard on the culture deck, so I was gonna ask you if you'd read that yet. That's like the big thing. Definitely read through that comprehensively, and you wanna prepare stories that relate to things in the culture deck, 'cause that's what I'm just gonna ask you right now. And we can work through it so you're ready for your interview when it comes up. But it's, you know, a lot of companies, they'll say things and they don't always bring it up. But at [REDACTED], the culture is very strong and you'll hear phrases from the culture deck all the time. You'll hear freedom of responsibility, disagree and commit, farming for dissent, individual contributor. All that stuff is like we actually practice what we say. So that's why it's such a strong part of both behavioral and the software engineering interviews. Like, you'll, you'll even hear about it in a technical interview sometimes, not just behavioral interview. So that's how strongly they— yeah, yeah. Okay. All right. So why don't I just get started? At any point, if you want to, like, pause and ask me questions about anything, totally fine with that. And then I'll give us about 15 minutes at the end to discuss feedback unless you'd rather me just go straight through and then I could write up my feedback. Either way, let me know. Otherwise I'll just stop about 15 minutes before the end.

Hipster Pangolin: Okay. Yeah. Let's see how we go and maybe make a decision at that 15-minute mark.

Declarative Dragon: Okay. Sounds good. All right. Let's start with, let's see, let's talk about collaboration. So collaboration is incredibly important, both at [REDACTED] and in general. So tell me about a time that you helped manage a cross-team collaboration.

Hipster Pangolin: Yeah, so we had a project here that we were doing that was part of it— it was part replacing a personalization engine. So kind of be a little more specific here, we wrote an internal CDP and we had certain teams that were using Segment as their CDP. And there was a very specific part of this that was the personalization engine when it comes to building user profiles. We had to work directly with some of these teams at our company that were using Segment's CDP to migrate them over to our own internal one. This is part of an overarching migration to get everybody on our own internal CDP, but it's kind of outside the scope of what this particular thing is that I'm mentioning. But essentially, we had to work directly with these teams that were using Segment, figure out what features they were using, and seeing— picking specifically the features that we knew were the most important. So there's multiple teams. I guess I should also add to this, like, we, we have multiple teams that use our product internal in the company. All of them use different parts of Segment's, uh, personalization engine, and we had to work with each one of them, kind of figure out, all right, well, what are the, say, 3, 4 main features that we need to bring over, uh, that's going to work the best for all these different teams. And yeah, that's essentially— we did that. We set up product meetings. Our team, we didn't have a dedicated product person, so we acted as the product members, worked with these teams, kind of gathered requirements, seeing what they were using and why they were using it, and we were able to migrate over. So one example of something that they were using that we weren't able to bring over that they thought that they really needed was this funnel manager. And essentially, uh, to build that internally, it would be very difficult and take a long time to do it. But we were able to find a workaround where it wasn't, say, 100% as precise as the funnel manager that Segment had, but it was about 95% effective for everything that they were using it for, um, with a, uh, with what we had already created. So we were able to get buy-in from them that, hey, this would be good enough for now and we could work on it longer term to get up that last kind of 5%.

Declarative Dragon: Okay. Was there anyone that was like difficult? Like, I just don't want to do this. I love my external version. You know, I, I, how did you handle people who just gave pushback? Because I assume there's at least one person who doesn't want to change what they're doing.

Hipster Pangolin: Yeah, for sure. I mean, that was part of the overarching problem that we ran into a lot when trying to centralize everybody onto our CDP, less so just on this personalization engine. But yeah, there was many teams that didn't want to have to go through a lot of the work that it took to migrate them over because, yeah, it was just shaking up their workflow. We, we We had to work with them a lot to figure out, okay, well, where are the pain points that you think you're going to run into? And we had to build some migration tools to help them move over to make it as basically as seamless as possible, or best we could, as seamless as possible to get them onto our own internal CDP.

Declarative Dragon: Gotcha.

Hipster Pangolin: Yeah.

Declarative Dragon: Sounds good. Let's talk about Actually, let me think it out a little bit more. Is there anything you would have changed about how that collaboration went now that you can like look back with 20/20 vision? I kind of love this because it helps you see how like how you grow through a project. So what, is there anything you wanna change about that project?

Hipster Pangolin: Yeah, I can kind of talk about this in two parts. So there's one, just kind of a note here, maybe we could talk about it a little bit. I always struggle with this of like where to be vague and where to get detailed. So I'll just kind of give my answer and kind of help me figure out which is best. Okay, so like to answer that question for the 20/20 vision, uh, one of the problems that we ran into early is when we were migrating them, we thought that we built enough tools to kind of help them move over early and kind of handle everything they might need, but it never was— it was tested via us but never never fully tested with their real production data. And so the first time that we did our, our like first migration over, it caused a lot of problems. It caused some site downtime. And obviously that with these teams that we had said like were already hesitant on moving over, that obviously added to a lot of the content there. So for the second round of migrations, once we kind of fixed those problems, we thought, okay, well, we have to do more migrations. How can we set something up to really build that confidence for them and for us? So we built basically this tool that allowed us to shadow all their current data into our, our new CDP. And what that allowed us to do is kind of asynchronously and offline be able to tell them, okay, well, here's like the things that we need to fix. This is when you do hit that switch to switch everything over. These will be the problems that will happen, so we need to address them now. So we did end up getting a little bit of that 20/20 vision and adjusting for it. So like, for now, I would have said we should have done that off the bat. Like, it's obvious whenever we did it for the second migration, like, it helped so much. We didn't have almost any problems, so we should have definitely had that off rip for those teams.

Declarative Dragon: Gotcha. Since you had a question about this, do you want me to give you feedback right now?

Hipster Pangolin: Yeah, that'd be great.

Declarative Dragon: Okay, so I think that went fairly well. I like that you explained the project to me. I think you could have made it a little simpler. You used— you said CDP like 5 times, and I don't think you said what CDP was. So I kind of picked up what it was that you had, and it, you know, external tool moving to internal, and you said personalization ended engine, I understood that. So like, I was like 75% there and I was able to understand the story. But it would be nice if you like explain that just like a little further, or don't explain that at all. Like, you know, don't say CDP, just say, okay, we're doing an external tool with, you know, data, and now we're moving to an internal tool. Like, you can keep it as simple as that because this isn't, you know, about the technical part of it, it's about the collaboration. So As simple as that is something you could use.

Hipster Pangolin: Yeah, that makes sense.

Declarative Dragon: And then I was gonna say one more thing, which is, you know, since this is about collaboration, you talked about like, okay, so we built more technical things. It would've been even better if you were like, okay, so we tested on our own and that wasn't enough, so we made sure to bring a partner in and test with them. And if you didn't do that, then I would say that is something you might learn for next time, is that, okay, First, we learned to bring in more data. But I think on the collaboration end, what I would love to do is have someone, have one person who's like a friend or a safety, like test it before we brought it to the whole team who weren't as excited about it. You know, you, you, you collaborate with someone who's excited first and then with the people who are gonna be difficult.

Hipster Pangolin: Yeah, that makes sense.

Declarative Dragon: So yeah, so it's only because it is a collaboration question as opposed to a, technical question, but I think it, I would say that was like, that answer was like 75% there. So just like a little tweak on that and then you've got it.

Hipster Pangolin: I gotcha. Okay. It's good.

Declarative Dragon: Okay. Any more questions on that one? I'll move to the next one.

Hipster Pangolin: Yeah, I guess like one other thing with this, right? So we, with the first question that you had started asking, I had talked about kind of the personalization engine. A lot of my stories come from kind of this one major project that I've, really been a part of, and it's kind of spanned many years, so I obviously have a lot of stories in there. But there is, there's definitely a ton of context too. And like you said, like with the mentioning the CDP and not maybe knowing exactly what I meant, I guess it's always hard for me to decide of like, okay, well, how much context is too much context? Um, some of your advice was good about like the how the just say it's a tool, like we have an internal tool and a third-party tool that we were integrating with. But yeah, I guess, is there any tips you have for managing how much context to give so you don't kind of blabber on for too long with just context and overwhelm the person?

Declarative Dragon: Absolutely. So the best thing to do is to practice explaining this project to someone who doesn't understand it. Like, maybe your mom or a neighbor or like a friend who works in a totally different industry. Try to explain it to them. And if they— their eyes start like glassing over, you know that you've like gone too far. And when you can explain it to them in that very simple terms, you're like, all right, I've got the most simple version of this. And then now whenever you're getting interviewed by someone, think about like what their level is at and you want to adjust it for that level, but you can always keep it at the most simple terms and start there, and then they might ask more questions, but it's always better to start, you know, the most simple and then build out, because even though, you know, like I'm an engineer with almost 20 years experience, I might not have worked on the exact same thing as you, so I might not know the exact terms for a thing that you're working on, like the same with what I work on with you. I would explain it in the most broadest terms, and then you'd be like, oh no, I get that, tell me more. And then I'd give more detailed technical terms. See what I mean? Does that make sense?

Hipster Pangolin: Yeah, it does. Okay, so I kind of leave maybe some breadcrumbs in there so that they can kind of dig in where they want to.

Declarative Dragon: Exactly.

Hipster Pangolin: And just stay like pretty high level at first. Yeah, let the interviewer dig in where they want to.

Declarative Dragon: Yeah, actually one of my favorite questions I usually start with is tell me about a project that you worked on recently that you enjoyed? Because that kind of— you can use that to set the stage of the whole interview of like, okay, you're telling me about this project and then you're going to just give me stories about this project. So, you know, if I don't ask that question or the interview doesn't ask that question, you can even start it. You'd be like, listen, before I get into collaboration, let me just tell you about this project first because I'm going to talk about this project for 45 minutes and different, you know, different things that went on because I worked on it for 10 years. So let me tell you about it real quick and then let me answer your collaboration question. And I think that's, that's helpful, right? Like it shows that you're like, I'm going to make sure you understand what I'm talking about and that I'm going to have a lot to talk about with this project.

Hipster Pangolin: Yeah, that makes sense.

Declarative Dragon: Okay, anything else or I'll do the next question.

Hipster Pangolin: No, we can go on to the next one.

Declarative Dragon: Okay, great. Let's talk about feedback. Feedback is super important at [REDACTED]. You want to be able to give feedback, receive feedback, and treat it like a gift and kind of take the emotion out of it. So I'm going to ask a couple different parts to this. The first is, have you ever had to give difficult feedback to a colleague or a manager? And how did that go?

Hipster Pangolin: Yeah, all the time. I'd say We can start with colleagues. So with my colleagues, I generally like to have a real, or like a real, in the beginning of the relationship being established, kind of immediately establish that I am very candid with things and I always want to give feedback and receive feedback. So starting out early and kind of immediately giving that feedback to them whenever I see something happening, I think really sets the relationship up to make both of us comfortable with giving that raw feedback. So you can kind of— I have found that the longer you wait to start giving good solid feedback, you tend to have to sugarcoat things more versus being kind of like that radical candor and really just being straightforward with them, straight to the point, so they understand that, hey, this isn't None of what I'm saying is, is for ill intent. Like, it is purely just with the best intentions possible. So giving feedback, I really try to harbor that culture in my, uh, in my teams. Um, so yeah, coworkers, we're, we're very much on giving feedback early and often. Then with management, I try to do the same thing. So like any type of senior leadership There's been times where senior leaders have, I feel, managed certain teams poorly that created a lot of problems with ICs working on these projects, and I've had to talk to them. For example, we had a team that was working on a data lake for us, and they were really siloed, and it was starting to cause problems with the teams that we were integrating with them. So I had to work with them and say, hey, I think that it's going to be better if we are going to be able to integrate these teams a little bit better so that your team isn't working as much in a silo. That will help both platforms by making sure that we're not causing each other problems, and then also make it easier for managing this product long term so that there's no like tech debt, or minimize tech debt going in and minimize tribal knowledge as well since these two teams work very closely.

Declarative Dragon: How did they take that feedback?

Hipster Pangolin: They acknowledged it. I'd given an example where this had happened once before with this particular senior leader that I worked directly with him, and I was kind of the one in the silo, and I had explained the kind of problems that had happened with that. And so I brought that back up. I said, look, this kind of thing's happening again. Remember last time we did this? It caused a lot of tech debt and a lot of time for that team that ended up managing that product to have to fix a lot of these problems because we were siloed. We didn't understand. So it's like, I think giving that example really helped them understand that, hey, this is happening again, and they were receptive of it. And then we started integrating the teams much closer together. There was a lot more simpatico between the two teams.

Declarative Dragon: Gotcha. So they took the feedback well and were able to change their behavior.

Hipster Pangolin: Yeah, and it was really just well because obviously it was happening a second time, but I think because I had given that feedback the first time on it, it kind of set it up where it's like, hey, same pattern's happening again. Um, and then they kind of were like, okay, I can see the parallels here. So I think they were a lot more receptive of it since we had talked about it once before. And I didn't kind of hold it back from them that first time.

Declarative Dragon: Taking some notes. So it sounds like you gave them feedback once and then they ended up doing it a second time, and then you gave feedback a second time and they were like, "Oh, we see the pattern here," and then they were able to change their behavior. So it, you You know, it took twice, but it did end up working.

Hipster Pangolin: Correct, yes.

Declarative Dragon: Great, that sounds great. Can you tell me about a time when you received difficult feedback and how that went?

Hipster Pangolin: Sorry, what was that last part? I missed it. You said when I received—

Declarative Dragon: When you— can you tell me a time when you received difficult feedback? So instead of you giving it, you received it, and how that went, and something difficult that was difficult to hear.

Hipster Pangolin: Yeah, I'd say, let me think of a good one for this. Yeah, I've gotten some feedback on kind of my communication style with others. With a lot of people that I interact with, I'm, again, I'm very straightforward. I don't, I try not to sugarcoat things, and it can be taken as a bit abrasive. There was a time where a particular team caused a little bit of an outage, and I went to them, and in thinking that I was just being candid with talking with them and telling them you can't remove— they basically removed some endpoints without doing some due diligence on whether it was being used or not. I told them, hey, you cannot be removing endpoints, this caused a major outage, and this is this caused a lot of problems and a lot of other people had to firefight this issue. And this was a team that I was, was not as familiar with. We hadn't really interacted much before except for me with one person on there. And obviously I said it a lot nicer than I did at the time, but the, uh, the engineer that was on there that kind of knew me said, hey, whenever you're interacting with someone that maybe doesn't know your personality or like maybe isn't as used to the kind of being so candid or being that straightforward, it can come out as brash and aggressive the way that you were saying it. So he basically was just giving advice on, hey, kind of know your audience, take a step back, kind of plan it out ahead of time, especially when people that you haven't interacted with before are there on the receiving end of that feedback. It definitely resonated with me. I could kind of put— like, take a step back and understand where not knowing me and having someone come up and kind of criticize you in a way on something that you worked on could be considered unthoughtful or a little harsh. So it helped me kind of learn how to frame my feedback for the audience that's going to be receiving it.

Declarative Dragon: Great. Would you like to do what we did for the next— for the previous question and go over that one right now, or you want me to keep going?

Hipster Pangolin: That works. Yeah, I like whenever it's like right top of mind, so it helps me remember.

Declarative Dragon: Okay, great. So I asked about a story. And you explained how you like to give feedback, and I really loved it. Like, that is, you know, I could, I could feel the hiring manager inside me going like, yes, this is what I want to hear. I want to hear that they give and receive feedback and they start it early and they establish relationships. That's very important to do. Love that. Then you started talking about the manager story. So you kind of skipped over the giving a specific time when you gave colleague feedback, which is, it's not a big deal because you then did give the manager story. So at first I was like, hey, he forgot to give the story, and then he gave the manager story, and I was like, oh, that's pretty good. The only thing I'd be careful about that manager story is that if you were talking to a manager, they'd be like, oh, this person's gonna go over my head and start talking to other people. So like, that is the only thing I'd worry about that story in terms of an interview, is that I would either phrase it like, oh, I talked to my manager first and he said, hey, or she said, give them direct feedback, right? Or this is a team that I worked with directly and this was like the leader of the team, you know, the project lead as opposed to a manager or like, you know, the lead of the team. And I knew that I could talk to them directly about this. And I gave my manager a heads up and they were fine with it. You know, just something to show that you understand that like, You know, giving feedback directly is good, but also talking to your manager is good. So like I would say at [REDACTED], we do both of those, right? Like you giving feedback to senior leadership, totally fine. You can give feedback to the CEO if you really want to, like they're happy to give feedback to anyone, but just that like politics of just making sure your manager knows first. So I would just give like one line mentioning that, that at least, oh, I talked, I mentioned to my leader and they said, hey, why don't you go talk to them directly or I'm going to go talk to them directly. Is that okay? And they were like, no problem. Just a little bit there, I think, would show self-awareness of politics. So I like that. And then I liked this self-awareness of like— because I could tell from that, you're like, oh, I'm a straight shooter. I don't sugarcoat it. I'm like, oh, that could lead to problems sometimes. And then you immediately told a story about how it led to a problem and you got feedback and you became more self-aware. And targeting your feedback to the audience, I thought was great. Like, that's a great line of like thinking about, you know, how they feel. If I was gonna add like one layer of like, you know, more icing on that cake, I would just talk about like, I didn't think that, you know, about their emotions. 'Cause, you know, if I'm imagining being the person who just caused the outage, I'm so embarrassed and unhappy, and I know I done something wrong. You don't cause an outage and think, I've had a great day today at work. You know, you think like, oh my God, people are going to come yell at me. I'm so embarrassed. And then someone that's not even my manager from some other team just comes over and says, you did this wrong. And they didn't even ask me any questions. They didn't say like, hey, do you need any help? Or like, hey, are you going to have like a debrief? Can I be a part of that? They just came over and started saying things instead of asking questions and they weren't aware of my emotional state, I could see that person getting upset. So I think the icing on the cake is to say that I also realized that I didn't take their emotions into account because I wish we're all robots. I mean, that'd be nice. We're engineers and we could all just give and take feedback very directly all the time. But we're not robots and that's why feedback is difficult and we all have to work on it all the time is because of that, because that extra layer of emotion. So that would be like, I would say if you didn't include that, it's not a big deal because the story was already, you know, story was already great, but that would just add like a layer of like, oh, he's self-aware and like emotionally intelligent.

Hipster Pangolin: Yeah. Okay. That's great advice. Yeah, definitely make sure to add that. I was trying to like kind of work that in there, but since you highlighted it, definitely seems like something I need to really emphasize on highlighting in there?

Declarative Dragon: Yeah, just like not just targeting towards the audience, but like understanding like, oh, I didn't think about how they felt at that moment. They were not ready to receive feedback. They weren't in like the zone. Like one of the things we'll do is we'll ask people like, hey, I'd love to give you some feedback about that. Do you have time right now? Or is this okay? Would you like written feedback instead of verbal feedback? Again, this is all like That's like bonus stuff that you learn on [REDACTED] that like if you bring to the interview, they'll just be like, oh, they already know how to do this. Great. You know, so I mean, but we have like classes on feedback and stuff. So that's all we go over it a lot because everyone has to get better at it.

Hipster Pangolin: Yeah. Okay.

Declarative Dragon: Let's do, let's do another question. How's that? How are we doing on time? Okay, good. We have at least time for another one or two more questions. We actually touched on a few things that are already on here, which is great, which is like self-awareness is a huge thing. Learning from failure is a huge thing. So like the fact that you talked about not doing something well and being more self-aware, you know, just like looking at my notes of questions to ask. Okay, let's talk about freedom responsibility. So freedom responsibility is a phrase that we use all the time at [REDACTED]. I've been there 6 years and we use it all the time. And, but it started to fade out of the, like, it's not in the deck anymore. You kind of have to like read between the lines. But in terms of engineering, the way it shows itself is that, you know, they give you a computer and they give you full access to everything. And, you know, some people like that and some people prefer more structure. So to make sure that you'll fit in well with the engineering culture at [REDACTED], Could you tell me a time that you kind of took leadership or, you know, created an idea as opposed to someone like giving you a ticket or giving you an assignment when you said like, hey, I see a problem, I've identified the problem and I've, you know, decided on a solution and this is what I'm, you know, this is how I think we should do this. And as big a project or, or, you know, problem that you solve, the better. Does that make sense?

Hipster Pangolin: Yeah, it does. Um, okay, I have a couple of them. I think that like, okay, here's a— here's just like a quick question. When answering these, this relates kind of to the first story. I know you said that they could be good in the beginning, is kind of talk about, hey, there's this project they work on, could talk about a lot of questions. I guess this kind of relates to it where I can just be like, hey, this is part of that same project I was talking about, and here's kind of how everything started. That's, I guess, like a good way to go about introducing this.

Declarative Dragon: I think you just want to level set it one level above and say, instead of a, you know, in my mind a project has a, you know, beginning, middle, and end, and it stops. Well, like a product kind of goes on for a long time because you create it and then you change it and then you maintain it and then you add features and then you write it a second time because now it's all old, you know. So a product is like a level above. So when describing it, I would talk, if you've worked on it, you know, for 5 years, I would say at that point it's a product and I would level set, hey, this is the product and then here are different projects I worked on or features as part of that product. So here's an initiative I, you know, did after working on that product for a year, I noticed this and, you know, put myself forward.

Hipster Pangolin: Yeah, gotcha. Okay, I can kind of talk about this. It plays a little bit into one of the first questions we had talked about. Around the CDP, this product that we were building. And really the way it had started with everything was we had this third-party tool, this using Segment, and there was a lot of, for our main data processing pipeline, and half of the teams were using this and half of the teams were using an internal custom-built pipeline. We knew that the internal one wasn't ready to— like, it wasn't feature-rich. We needed to build on it a lot. It had its own problems, while the Segment one also had problems, namely things like schema validation, and data governance was a major one that teams just weren't getting out of that. So we saw that management was having a lot of discussion on, okay, hey, do we build on top of the current current pipeline that we have now and kind of add more members in there and kind of build it up, or do we go and go all in on Segment? So classic build versus buy. Well, the few of us that knew both of these products pretty deeply, we went in, we— I guess some more context— by the end of the year, our Segment contract, this third party that we were using, was was up for renewal and we had to make a decision by then. I think we had about 10 months. So we were able to go in and show and kind of, we built an MVP pretty quickly of this showing that like, hey, we can actually build this thing internally. We can accomplish most of the things that teams are using the third-party tool with, obviously not 100% parity, but pretty good parity with it. And we can also level up our current pipeline to make it scalable and more robust and more feature-rich for the future, kind of just give it its needed update from things that Segment did have. So yeah, we pitched this, we got, we ended up getting some buy-in and we were able to go build this new pipeline. Yeah, so we were, we were just, yeah, given the, just given the information and allowed to make a decision based on that. There was a lot of features in there that were needed that were lacking in both sides. So basically we took as much as we could, the best of both sides and kind of trimmed out the worst of both sides. And overall, at the end of the day, through all the humps, like, teams were very satisfied. The cost was reduced by a ton. I mean, I think it was like 10% the cost of what we were paying on our Segment contract. So we reduced it like $2 to $3 million for the, uh, per year for Segment. We were able to get it down to about $200,000 a year. Um, data was able to move faster through the pipeline. So with Segment, to get to the analytics data lake was something like an hour, and then we were able to do it in about 10 minutes. And then for the personalization engine as well, something we talked about at the beginning, uh, we— Segment was about 5 minutes, we were able to do it about 500 milliseconds. So, uh, lots of, uh, benefits for everybody, and it's been a success ever since.

Declarative Dragon: Wow, that sounds great. I think that this, the project and the answer you're giving, oh wait, should I, you want feedback right away, right?

Hipster Pangolin: Yeah.

Declarative Dragon: Okay. No, just double checking. Um, the, I think the story is good. I think you should stick with this story. Um, number one is like what the first question I asked is, um, like I wrote down my notes to ask you is like, talk about the cost and you did it at the end and I loved it. That's like, that's like the, a business, like ding, you know, like highlight, that's a great thing to talk about. So just take that, move that to the beginning, right? Be like, we, you know, 'cause one of the things with external and internal is that you pay a lot more for external, but with internal you have obviously engineering and compute costs. So it could be something you recognize in your pitch, like, hey, this is costing us, you know, $3 million a year, but you could pay, you know, 2 engineers and by the second year, it'll only be costing you $200,000. So only 10% is part of the pitch. I think that would add to it as when you were talking about the pitch part of it. So it's like, it's just reorganizing the way you talk about it, but I think it was great. I was so happy to hear you say cost 'cause that shows like a business acumen that is important to like leadership pitches, right? 'Cause a lot of, some people don't take that into account, right? Like they'll don't take into account that You know, just because the engineers want to do it doesn't mean it's cheaper because engineers cost money, keep you cost money, all that other stuff. So knowing the cost of your pitches, I think, is a big highlight in the interview. So that I really loved. I had something to add again, I feel the case because you talked about pitching it. If you talk about how you pitch it, it'd be nice. So like, did you write a memo? Did you give an actual presentation? And then it was a little confusing in the story. I wanted like a little more here where it was like, you know, he said that leadership was trying to figure out what to do. And I wasn't sure what the, like, the timeline was where it was like, you noticed a problem. You heard leadership just like talking in the hallway and you were like, oh, let me do this for you. Let me, you know, my team is interested in helping with this. Or was it leadership was like, Hey, there's a problem. Can you pitch this for me? So like, however you recognize the problem, that like little bit of communication, I think just like clarify how that went, I think would be good. I think you take some of the technical stuff out to make it more clear, because some of the stuff, it was, it was unclear. It was like that. It was like the muddled middle of technical stuff where it was like, You know what I'd like to hear is like what team you are helping and how much you help them, right? So like the team is, I wasn't sure whether it was sales or data. When you told me the first story, I thought it was a sales team because it was personalization. And then the second time you said the story, I was like, oh, is it a data team they're helping? So if you could just like clarify, like we're working on a tool for a data, there's a bunch of data teams. Some of them were working on external tools, some internal. So that was great. It was like, you know, You know, there was like a variety. It was costing us $3 million a year plus the maintenance on this other tool. Nobody actually really liked either of those tools. They were both missing features. The thing you said about the API time, loved it. Please highlight that as fast as possible because that is great. Whereas like, you know, the speed. So like, and you could even like go into that a little more and be like, hey, there were 10 data teams. They were working on these tools that took them, you know, an hour to get what they needed, but with our new tools, it only took them 5 minutes, you know, like it decreased the labor time so they were able to do more for the company. You know, that's one of the things I talk about at work is like, you know, because I work, actually I'm not supposed to tell you too much, but like what I work on, I have to like talk about how it saves time So people can, you know, do more stuff as opposed to just like working less hours. So like, I think that's like a thing that people like, business people enjoy hearing, like increased productivity, like they're able to, you know, do stuff in 5 minutes so that it can make the company more money, you know, and that knowledge of what I did and how it affected the company as a whole. That is like, that's another like golden thing. That's a super highlight. So like, I think you have it in your story. I would just like add these little, you know, like you said, like the breadcrumbs, like take out some of the more technical stuff. You know, for this question, it doesn't matter. Like the speed, yes. What exactly, you know, you know, talking about like data lakes and stuff, you don't need that. You just need to talk about saving money, saving speed, helping the people, pitching it, and how it went like well. You know, the results of doing it and how, you know, it made you like, hey, this is— this went so well. I would definitely be happy to do this again. You know, like showing that like you enjoy the experience. That's also good because remember how I talked about in the question, I was like, hey, we do this at work and but some people don't like it, right? Like people aren't a good fit for [REDACTED] if they don't like taking charge and solving problems as opposed to passively receiving tickets and like work at different companies. You know, it's just, it's just a culture style. So if you say I did this and I really enjoyed it, I think that like adds as bonus. It is all that I said makes sense. I know there's a lot at once.

Hipster Pangolin: Yeah, no, for sure. I can see exactly like it's definitely making sense.

Declarative Dragon: Okay, great. And then the only thing I would add to is like I noticed in the first question and in this question, we said we a lot, which is wonderful. You're talking about your team. You know, that is how we want to answer questions. I would just add a little bit of like what exactly your role is, you know, in some of these. So you can say like, we did this project, we did this. And, you know, my role was I, I, you know, we worked, you know, half and half on this. We wrote the memo together, we pitched the project together, we implemented it, you know, together. I helped break down some— this part of it, like however you broke down work, right? Like, oh, I took over, you know, the API and they did the, the, um, some of the service layer, whatever you did, however you broke up the work, you know, it is just nice to hear you, your personal role, because sometimes we can, like, you wonder as an interviewer, like, okay, they're saying we a lot, like, did their team do this and they happen to, like, jump on the bandwagon, or were they, like, the leader of this? And like, I heard a little bit in the answer where you're like, me and this one other person who had senior, you know, experience noticed this. And I was like, okay, that's like, you're getting like 75% there, but just like really nail it in. And I will say that, like, I don't know if you notice this, when I give you feedback, I repeat myself. Repeating yourself is good, you know, not in like real life, but in interviews, because, you know, they don't know you and you want to get the highlights to them. You know, you want the interviewer at the end of the interview to remember specific highlights. So if you're just hitting on them over and over again, that's fine because it'll help them remember it. So don't feel bad about like repeating yourself because, you know, this is all new information to them. So it'll actually help them remember it.

Hipster Pangolin: I got you. Yeah, that makes sense. Yeah. And then with the we thing, yeah, because I'm so conditioned to just like always saying we, but I see what you're saying, right? We're saying like, set it up with like, hey, we as this team, but then really digging into exactly my role in it because like you said, they might not know if I just know about what happened versus like what I contributed to directly. So I think that's kind of the mindset I guess I'll take in there. Of really digging down where I was doing things.

Declarative Dragon: Absolutely, absolutely. And like, you know, it's all about like, you think about, you know, because I, everyone has experienced both ends of it. Like, I've interviewed and I've also been the interviewer. So like, we know what you're thinking coming in and we try to like pull the stuff out of what you're saying, right? And really, really foil it. Okay. Let's see, I think we have time for another question. We still have 40 minutes. I think because we're doing feedback throughout, we won't need a lot of time at the end unless you have a lot of questions saved up for me. Let's see. Okay, at [REDACTED] we have something called the Keeper Test, which is very well known. It's one of the things that people are like, Hey, I don't know if I'm ready to work at [REDACTED], they have something called the Keeper Test. And as you've read the document, you know it's about deciding whether people are right for the team. As someone who's been at a company for a long time and in leadership, I'm wondering if you've ever had to contribute to any discussions about this, whether either as part of a team where you were like, hey, I can't have this person on my team, or with a manager saying, hey, I think this person Is it working out? Are they coming to you and asking your opinion? You know, I know you're not a manager, but as someone in a senior position, this may have happened to you. And has this ever happened to you?

Hipster Pangolin: Yeah, so kind of the way that our review cycles are set up and how we do reviews, there is actually a question directly on there that I do think is great, especially for management to see, is it's Do you— if you were starting a new team, would you want to have this person on your team? And I think that that is one of the best signals for kind of seeing who works well with teams. I enjoy that, right? Like, I've always kind of taken the mindset also of, hey, if we were interviewing this person again, would we— and they had the skill set that we're able to see, like, would we actually hire them? Um, and yeah, I've kind of had those discussions with my manager before about this, of saying like, hey, certain people, it might just be better for them to not be on this team. Maybe this team, it doesn't set them up for success and doesn't also set us up for success. So it's best to just kind of find somewhere better that might fit them better in their career and it also helps us. Like, it's not— I guess the best way of saying is like, it's not benefiting anybody for certain people to be on certain teams if they're just like, they're just not that fit for that particular team. I think that kind of covers the main question there. I feel like there was one more. I think it was—

Declarative Dragon: okay, so I think you had the general answer of like, I really like that you talked about that it was in the performance review. I just to add a little bit to clarification, my question would have been like, oh, do you do 360 reviews on everyone? So I wasn't sure whether you were talking about like, if you're talking about your manager, and then I seem like you were talking about people on your team. So just to clarify, like, hey, as part of our reviews, we, we get asked this question, would you have you know, these 4 people that you worked with for the last 6 months on your new team, right? Just, just be clear who they're asking the question about. Um, I really like talking about you when you talked about the interview stuff and like, would you bring them back on or would you rather have, you know, a new person? Like, that's, that's great and more, more golden nuggets there. Um, let's see, the— oh, and then you talked about like, yeah, it's not just, you know, Dem, you know, you kind of coached it like it could be just like a bad team team fit. Um, the only thing you missed is a specific example. You know, you talked about it more in general terms and how you did it, and like, so you were like 75% away there, and then I think you just lost— that was the, the end part of the question. So if you want to answer that final part of the question, I think that would be helpful for you.

Hipster Pangolin: Yeah, so for the example, right, uh, we had a data engineering team that kind of got disbanded, and they were finding places to put some of these data engineers, and they we put one of the data engineers on our team, which is more of like a doing less data engineering and more software engineering. This person wasn't, they had not worked on those kinds of systems that we have and we tried help coaching him, but a lot of it just, it wasn't the right fit for his skillset and he was really struggling, especially coming from being a senior onto a team where he doesn't have a lot of experience and expectations were high for him. Uh, and yeah, it kind of just, it was not set up for success for him, uh, in this role. And so we worked, I worked directly with my manager helping find him a data team that he could land on where it would be best for him because he was ending up writing a lot of code that was having to go and be fixed and kind of slowing down parts of the team.

Declarative Dragon: So that's what it is. I think that's a great story. I think that's very relatable. I think there's— I wouldn't actually add much to it. I think it was great. I would only just like clarify that, like, you know, I think you kind of said this. I'm just looking over, you know, my notes here and it's, you know, So a team disbanded and they just needed to find a role for him. Otherwise he'd lose his job, which is like super relatable. This happens all the time in companies where they just like move people around without being very thoughtful about it. And they put him on your team. He was a senior data engineer and very good at data engineering, but they put him in a software engineering role and, you know, you tried to coach him, but he actually didn't really want to do that. Like, that's not his career ambitions. So you and your manager, you know, after some time you realize like, hey, this is going to be a good fit. And he was like, I mean, it sounds like this person agreed with you. And when you help them find a data engineering role, you're going above and beyond. You know, like the fact that you did that, that means that, you know, you care about your company and you care about people and you realize that sometimes, you know, it's not— it's just not— doesn't make sense. You know, some people don't want a role and they're put in it because of bureaucracy. So, you know, it's best not to have them in it. So I think that's a great answer. And that's— I've got minor feedback and that's it. But like otherwise, I think that's an excellent answer.

Hipster Pangolin: Okay.

Declarative Dragon: Okay.

Hipster Pangolin: So it seems like for that, I just really missed out on the examples. So always have like good direct examples for each one of these things.

Declarative Dragon: Right. It's that whole like STAR method that we're supposed to tell you about over and over. So you've probably already heard this before. For. But just, yeah, just being very specific helps us relate to you. If you think about in general, try, you know what an interview is, it's a persuasive argument. That's what you're trying to do. You're trying to persuade me that you should work there. And one of the things that makes persuasion work is storytelling, because people love stories. So you think of it as like persuasion and marketing and get yourself into a different headspace and where it's not like, you You know, they're not interviewing you for like a magazine article, right? Like if, if they were interviewing you for a magazine article, I'm apparently old doing that example. Podcast. They're interviewing for a podcast. You would obviously say different things than this. So I think getting your headspace in that it's a marketing project for you. You're doing a persuasive argument. You're trying to tell stories that convince them that you should be hired, that you understand [REDACTED], that you you know, read all the documentation and you're going to fit well, you're going to be additive to the culture. That whole like mindset, I think, really helps when you're trying to like organize your words.

Hipster Pangolin: Yeah, that makes sense. Okay, cool.

Declarative Dragon: Just taking some notes. I got to not forget what I say because I have to write it all down after this. You have it. You have it written down. Okay, so we have about 10 minutes left. I could do one more question, or if you have any like general questions for me, we could use this time for that.

Hipster Pangolin: I do have a quick question. So, okay, I've read through the Culture Memo and it is something that I do genuinely enjoy, right? And I think one thing that I worry about is getting in there and maybe touching on points where I really related to the culture memo. Uh, and for— let's just take for example, like, candor is probably the one that I relate to most in those, the 8 values or whatever they would be called. Uh, and being like, yeah, I mean, I love receiving feedback. I always try to push hard to get people to give me feedback as quick and as early as possible, kind of things that we talked we talked about in one of those questions that you had asked. How do I— what's like a good way to kind of integrate these things without sounding like it's rehearsed? Because I worry too much where like I do genuinely agree with this stuff and work it in and being truthful, but it could feel like I'm worried about it maybe sounding too rehearsed and too set up, right? Or trying too hard. What I'm like, I'm genuinely serious.

Declarative Dragon: Yeah. You like honestly care and you honestly want to be a part of it, but you don't want to sound like you're just like, you know, I see where you're going, where you're like, you don't want to sound like someone who's regurgitating what they wrote down so that you sound good for the position. Yeah, it's definitely tough. I think actually you can't rehearse too much because I think most people aren't like professional speakers, so they don't— they're not rehearsed and polished. So You know, you didn't sound rehearsed or polished to me. So I think I wouldn't worry about being too rehearsed, right? Like, I'm going to tell you what I've interviewed at [REDACTED] ages ago. You know, I took the culture memo and I wrote a story for every, like, that, you know, everything. And I had it sitting in front of me and I didn't read them. But like, I was pretty close to reading a paragraph that I'd already written and it was fine. You know, like, they weren't like Oh, you're, you're too prepared for this, right? Because no preparation is good. It shows that you, you care. You know, one of the questions we talk— I have, if we have more time, is like, why [REDACTED]? And like, you're answering that question by showing, you know, you went through the memo, you thought about it, and like these things really stood out to you and really, you know, were a highlight for you. So, you know, what I'm thinking about my, my interviews that I did or interviews that I've, you know, I've done an uncountable number of interviews at [REDACTED] at this point. Other people, you know, I like hearing the highlights of why [REDACTED] would be a good fit for them. So, you know, when I interviewed, my big thing was like, I didn't have the freedom and responsibility in my current company. I joined a startup because I thought I'd be able to do a lot of fun stuff quickly, but there was more bureaucracy at a startup than it was at [REDACTED], which is like It's such a boggling thing to think about. But like, it was a good story for me to like catch on to and be as part of the thing. So yeah, so number one, I don't think you can be too rehearsed because I don't think you'll ever be, you know, unless you're planning to be a professional speaker, ever be that polished that, you know, but don't, don't read exactly what you've written. But don't worry about rehearsing it. Rehearsing it just makes you sound like, you know, confident, right? So like, if you— after this practice, you're gonna probably polish up these answers, and you might practice them a few times, but you're never going to practice them so many times it's going to sound bad. So I wouldn't worry about that. Um, I think by giving exact stories, it shows your actual enthusiasm, right? It— you're not making stuff up to like try to fit it in. You're actually showing how I tried to change the culture and work in a way at my current company that is similar to [REDACTED]. So I think going to a company like [REDACTED] where they already have this culture, you know, really will give me the freedom to do great work. Right. So telling the stories about like how you took initiative and you give feedback, it just shows that it wouldn't take too much to fit you in. Right. Like as the interviewer, one of the things I'm thinking about is like, what would I have to coach this person on, right? Like, there's literally no perfect person, you know? Like, if there was, we, you know, there'd be no amount of money to be able to buy them, right? So, um, there's always going to be— they're really good at this, this is something we need, we'd have to coach them on this, you know, or I think I can coach them on this, they're coachable. So, you know, hearing that self-awareness and things that you're not perfect at, that like adds to that, like, okay, here's the things they're really good at and here's something that I might have to help them with, but then that combines with the technical skills of the other interviews where they're like, okay, but they're really good at data manipulation and personalization engines, and that's what we really need for this role. So coaching them a little bit on how to, whatever it is that you want to improve on yourself, that's not gonna be too bad, right? So there's always weighing those pros and cons. So you don't have to be, perfect. You do need to be self-aware about things that you need to be better at. So like, that's where that story was great about the self-awareness of the feedback. So does that, does that answer your question about like the polished and like trying to get your enthusiasm and candor through? I think that, yeah, that's important in anything, any interview. And I think that by being, just being yourself, you'll be able to do it.

Hipster Pangolin: Yeah, for sure. And then just like kind of one other little thing, like, is it I like some of the terminology that's used in it because I've always lacked a good term for things that I've been thinking. So for example, like the informed captain, right? And then farming for success. Is me integrating that kind of language into my stories considered like, hey, this person really is making sure that they have read this memo and are abiding by what [REDACTED] is all about? Or is it kind of seen as, hey, they're trying too hard to just kind of, kind of, you know.

Declarative Dragon: I think if you talk about it before you say it, I think that's a great, you're like, you know what, let me tell you this story about where I pitched this project. And then after I pitched it, I was able to be an informed captain. And we use a different term at our company. We use team leadership. But I saw that the term that [REDACTED] uses is informed captain, or however you wanna phrase it. You can be truthful about what you're doing. And I think that makes it very clear that you're not just like, you know, I know you're trying, I think where you're going is like, yo, I don't wanna be too like brown nosy, right? Like you don't wanna be too like over the top and soothe so that you look fake. And I think by being clear that you're like, oh, I noticed that you call it this. Here's what we call it at our company. Here's how I did this, right? Or like, here's, you know, when I pitched it, I had to go to a bunch of teams and get information from them. And I see that you call it farming for dissent. And one of the things that, you know, I'm going to give an example. This may be true or not with you, but one of the things that [REDACTED] does that I think I've not seen a lot of other companies do is disagree and commit. They disagree, commit. I've seen it done very well where it's like, you know, I've seen places where people will argue you through until you give up, right? But like here they can give you feedback, they can tell you, but like they're done, right? After that, they, you know, if I say, you know, I'm the informed captain, I'm making this decision and you have to support me in it. They have, you don't actually have to say that, but you have to say like, hey, I'd love for you to just agree and commit with this. Pretty much everyone does because they know that that's the culture. So you could say something like, hey, you know, it took so much time going back and forth and I see that you have this disagree and commit culture. And, you know, I think it would be something that I'd love to get more practice in and be a part of because it's, it's actually difficult as engineers. We all think we're right, you know? Yeah. So like if someone has a problem and you see them like, oh my God, this is gonna go horribly wrong. Everything's gonna, you know, go, go poorly. This is the perfect way to do it. I'm going to tell them, and they ignore you completely and say, you know, you need to disagree with me. I'm done with this. And you say, okay, that's what I need to do. But inside, you might be going like, oh my God, this is gonna go poorly, and you don't want to be a part of it. But it doesn't matter how you feel inside. You still have to, you still have to, you know, help them, help them see their vision. And the interesting thing is, I think that I've learned is that there's no right answer to anything. There's always trade-offs on any engineering problem. So [REDACTED], by doing disagree and commit, it helps us broaden our minds of like what the right answer could be because it could be that their answer solves something I didn't even think of and it causes a problem. Sure, it causes the problem that I thought of, but like it actually solves so many other problems that this problem doesn't matter. Does that, does that make sense?

Hipster Pangolin: Yeah, yeah, yes, for sure.

Declarative Dragon: Well, you can look it up. Sorry, go ahead.

Hipster Pangolin: No, I was just saying, yeah, definitely it registered. I know what you're saying, how to set it up. Like, yeah, it doesn't seem like the brown isn't right. Yeah, I mean, I like that.

Declarative Dragon: Yeah, and again, you can talk about like, hey, I saw this, we don't do this at our company, I'd love to be better at it. And you know, that's, you know, just kind of slip it into your, your stories. I think it looks And by the way, sorry if I interrupt. That is one of my challenges, but it is so much harder without the video to not interrupt. So pardon me for all my interruptions I have already done for the past hour.

Hipster Pangolin: No worries at all. I did not even notice.

Declarative Dragon: Okay, so we are at time. Is there any final questions or any of my feedback was unclear? Clear. I will write— I will try to capture everything written as well so you have everything, but I think you should have everything from this call. Is there anything I can— any feedback that I gave you that you need clarified or anything else?

Hipster Pangolin: No, nothing at all. It was all very clear. Thank you very much. This was super helpful.

Declarative Dragon: Awesome. All right, well, good luck on your interviews. And I'm sure you'll do great because practice is the number one way of getting better and doing well in interviews. So have a great interview time.

Hipster Pangolin: Thank you. Good luck.

Declarative Dragon: Bye.

Hipster Pangolin: Bye-bye. You're welcome.

Declarative Dragon: Bye-bye.