I Coached a Ex-Microsoft Manager for His Netflix Interview

0:00 For 19 years, John has built and led software at Microsoft. When the layoffs came, his tenure didn't make him immune. He's using the setback as an opportunity to take a shot at a role he's always wanted, engineering manager at Netflix. But a year later and many interviews in, he still doesn't have an offer. I see this all the time. John's experience was never the problem. The problem is that his stories don't show his leadership. I'm Steve Wynn. I spent close to 20 years at Amazon where I made it to principal engineer. And as a bar raiser, I personally conducted nearly a thousand interviews. Here are three things that I'll help John fix so he can nail his dream job's interview.

0:40 Cutting the corporate backstory so we make room for his leadership, owning his mistakes in a way that builds his status instead of shrinking it, and showing the technical depth he has instead of talking around it. Let's get into it. Today we're speaking with John. John, thanks for taking the time to come into the studio and have a conversation with me. you're our first engineering manager for this series. do you want to tell us about yourself? >> Yes, I'm a former software engineering manager at Microsoft. I spent 19 years there and my background is started first third of my career was in services building up on-prem services primarily, things like backup, file sharing, monitoring. The second third was transitioning those out of on-prem designs into into full full cloud. That was a lot of fun. That was also good opportunity for me to lead with influence but not direct authority.

1:34 >> Were you an IC for the first third? >> Yeah, IC for the first third and and the and the second third primarily. And the second third was was definitely leading multiple engineers, large groups of vendors. So, yeah. So, we moved all of our services into Azure and had an opportunity at that time to build a software as a service for data distribution which met an important need at the company for getting builds all over the globe in an efficient way.

2:05 Keeping development teams, teams that developed Xbox and and you know, other software solutions for Microsoft keeping them efficient through through data distribution channels. That was a lot of fun building that that software as a service natively on Azure. But the part of my career I'm most proud of is probably the last the last third, my last five five six years where I was managing software engineers in the networking space. We built a unified policy service. It was nice to bring in a software engineering team and and correct some of those issues. And yeah.

2:39 >> Awesome. What's your strongest story when it comes to behavioral questions? >> Behavioral questions, strongest story, I would say it would be finding ways to bring incremental improvement especially because the long-term, you know, the complete overhaul is many semesters, you know, probably 18 months. So you can't just keep customers and and stakeholders, you know, waiting for, you know, the ultimate plan. You have to, you know, incrementally deliver things that are going to provide value.

3:10 And and doing that at a time at Microsoft where you have a lot of security churn. There was what's called the secure futures initiative. They call it SFI internally which is a company mandate to say, "Hey, we need to do better at security and here's where you're not doing well. Everybody needs to pay attention to this stuff and and and make make it right." so you know, you're not only trying to rebuild a service, get credibility within the customer base again.

3:37 You have SFI coming in and then AI. A lot of demand in the company to show progress and to show adoption in AI. A lot of internal competition I would say, you know, who can do the next AI thing and and >> Yeah, that's probably something viewers can really relate to, I think. There was a moment, it still may be here, which is basically like, where can we slap AI on top of the existing? >> Mhm.

4:04 >> So, it sounds like your best set of stories are examples during this time when you were working at networking and sounds like it's a turnaround story. >> Yeah. >> In any turnaround story, I'm just curious, what needed to be turned around? What led What were the conditions that led to the team being the way that it was before? >> Mhm. >> And then, how did you turn it around? Some context, I think, would be useful is like, did you inherit a team or were you promoted to the team that was there? Like, what what were the >> Yeah, combination of both. my my manager and I had been working on my career traject- trajectory, so she had hired a few of the engineers knowing that I would eventually manage them. I was part of the hiring process there as well. And when I became manager >> So, it sounds like it was a new team, though.

4:51 >> Yeah. Yeah, that most mostly There were some that I was directly influencing, not managing, that I that became I became a people manager of. So, at least three. So, it was basically out of a team of eight, there was, you know, four new hires and and four existing. >> You said you inherited some software. >> This Yeah, the services in general, which came with software. >> Who did you inherit it from? >> Yeah, mostly the result of my team getting that service was due to reorgs.

5:23 So, these were people that I knew, that I worked with, that were now, due to reorgs, leadership made decisions to put their team in a different place in the organization and our team in that in that spot, which was called hybrid connectivity. >> Okay, so I think the thing here is like, we want to do we want to be a little bit We want to be slightly less corporate and like, specific about the way that Microsoft does things. So, like the stereotype of a Microsoft organization is just like really hierarchical.

5:57 >> Mhm. >> Lots of reorganizations, lots of decisions that are coming up from up high. And you may not be interviewing for a company with a structure that's like that. Yeah. Right? So, like the type of skills that would be necessary to to work well at Microsoft, we want to distill those into more general things and less Microsoft-isms, if that makes sense. >> Yeah. >> This episode is brought to you by Linear. They just published something that I think is worth talking about.

6:29 They opened with a new manifesto, issue tracking is dead. And what that means is that the behaviors around it, like the manual logging of issues, the prioritization back and forth, the grooming sessions, where half the room is just trying to figure out what's even in the backlog, these things are a thing of the past with Linear. I lived this nightmare at Amazon. >> >> We had mechanisms for everything. And don't get me wrong, I'm a big believer in mechanisms, but more often than not, the process of tracking the work took as much energy as doing the work. You'd come out of a sprint planning meeting and think, we just spent two hours so eight engineers could figure out what they already knew they needed to build.

7:08 What Linear has done is rebuilt the platform so that the stuff happens automatically. Your code, your decisions, your customer feedback, all of that context, all lives in one place. And Linear actually works from that. So, when something comes in, the system already understands what it is and where it fits. Nobody has to triage it manually. If you're an engineering leader and you want your team building instead of administrating the work, check out Linear. The link is in the description.

7:37 I think it makes a lot of sense to to maybe frame the problem outside of Microsoft politics. >> Got you. >> So, I might start with the hybrid connectivity >> Mhm. >> initiative that's there, right? So, instead of saying like, "Hey, you know, it was decided that there was a team that needed to be built, and I was part of that team, but I wasn't like managing those people, but it was kind of known like wink wink nudge nudge that they would eventually report into me, and there was through a series of reorganizations that occurred from, you know, people way above my pay grade, we inherited this thing."

8:08 >> Mhm. >> That's very true, but it's also kind of like dry. >> Yeah, yeah, yeah. >> Right? >> it, yeah. >> Let's just start with like the exciting part. >> Mhm. >> Right? Which is, you know, as exciting as, you know, I'm sure you guys did a bunch of stuff like hybrid connectivity. So, I would start there. I'd be like, "I was the manager of the team that was responsible for hybrid connectivity. Hybrid connectivity means >> It means the engineering workloads in Azure that engineering teams build up.

8:35 Many of them need connectivity back to corporate, and that is essentially what we did. We provided the self-service capabilities for an engineering person to go in and request that connectivity. >> So, depending on the company that you're interviewing for, they may or may not know about network. >> Yeah. >> Right? Now, if they don't, then I think it's important that you explain the problem here. And so, we want to explain it in a way that somebody that is technical can understand it. So, like so easy that a technical person can understand it, but not somebody that's like a network professional like you are.

9:12 >> We get the roads from the network team. Yeah. Our job is to is to make the roads accessible and to make them available. >> Okay, so basically at Netflix for this network engineering team, you can just kind of jump in and just be like, "Hey, we're a hybrid connectivity team. We're connecting people at Azure to our corporate network." >> Mhm. >> They would get that immediately, or they should. If you were interviewing at a just a regular software shop, you might need to explain that a little bit more, right? So, it depends on who you're talking to.

9:40 Since you're talking to this Netflix team, that's that's a networking team, I think you can just jump right in. So, again, I would might say something like, "Hey, I was a dev manager. I was working on this hybrid connectivity initiative. It was an initiative as Azure was getting built out whereby devs there could access corp level resources and have connectivity there." >> Yeah. >> They would be like, "Okay, cool. I get it." Then, I think it's a good idea to paint a picture of kind of the culture that you were turning around.

10:11 >> And then, what do you mean by the culture of the company? >> Sorry. So, like you inherited the >> you mean? >> So, you you instituted a culture. >> Mhm. >> You had maybe a bad There was a bad track record of delivery, it sounds like. It sounds like there was also a bad track record of operational excellence. >> Mhm. Yeah, I'd say that's true. Yeah. The first thing we did in the in that type of situation was to have a lot of conversations around what the customer was missing. Like like what are they what are they seeking to improve?

10:41 >> Well, sorry. So, a recommendation is instead of jumping into the solution, >> Mhm. >> I would frame the magnitude of the problem. >> All right. So, the magnitude >> were very unhappy, maybe, is probably the the way to say it. >> magnitude here is a connectivity request that in most cases it was taking 2 weeks. That was problematic. And then, the other aspect >> is that a problem? >> Yeah, it's a good question. The problem is it puts engineering teams on hold from them doing their performing their engineering workloads >> Okay.

11:10 >> that that directly impacts software delivery. >> So, I might say something like, "When we were applied to the problem, customer requests were taking up to 2 weeks, which is a big issue because we were blocking really big initiatives within Azure cuz we couldn't get our act together." Then, I'm just like, "Oh, okay, cool. Like, that's kind of a big deal." But, without that context, you'd be like, well, maybe customer requests take a week and you guys were taking 2 weeks. It sounds fine.

11:38 >> And probably a bigger problem and or equivalent was the a lot of the effort to create this hyperconnectivity was manual still. So, network engineers were grabbing tickets and performing manual effort on the scale of 200 hours a month. That's a significant cost to do something that can be fully automated. And we stepped into that and into that problem of of engineers doing manual work, desiring it to be fully automated. >> I think we want to be a little bit careful about talking about manual versus automated work. And it will depend on the company that you're interviewing for. And I don't know what the particular thing is for Netflix.

12:16 But, I would agree. There's nothing special about pushing buttons on a keyboard or clicking on a mouse. >> Mhm. >> And so, if you have developers who are trained to go and write code, grabbing tickets so that they can like change some network configuration, right? And it just takes so many hours to do that. Yeah, you should automate it. But, that's not necessarily the problem The big problem is the customers that are trying to deliver mission-critical workloads in Azure not being able to do so because network is the bottleneck. If you could achieve >> Mhm.

12:48 >> the customer delight, if you were able to like take care of your customers, then you could shift your focus over to the developer thing and then like incrementally add efficiencies there. But, the big problem is not the dev work. The dev work The work needs to be done. I think the big problem is like the fact that you were a bottleneck to big deliveries. Like, there are levels to the different problems. >> here is is part of the reason it took 2 weeks was a result of the manual effort needed to make the connectivity, right?

13:18 >> Yeah. The The reason I'm deprioritizing that a little bit is because any manager >> Yeah. >> that saw that would be like, we need to automate this. >> Mhm. And so you don't you don't add any differentiation there. It's actually kind of the opposite. It would be like if a manager didn't recommend doing automation, then they would be a bad manager. >> Got you. That makes sense, yeah. >> So like, I think that it deserves a sentence. It doesn't deserve an entire problem framing from my perspective.

13:47 >> I get that. That makes I like how you said that, yeah. >> If there was some like finesse that needed to be done in terms of the automation, right? Like, hey, the right way to do it would have been to halt all work and build something up that took three months and we couldn't be servicing customers, like that's not going to work. >> Yeah. >> Right? And so we needed to incrementally apply this automation cuz at the end of the day automation is an investment. You take it takes some time to do the automation, and you don't save enough time to pay it back until some time in the future where the the you know, the cost curve just flips. There might be a situation where you have to make a big decision about whether to automate or whether to continue to do it manually, but then there's no time to do the automation. If you don't have anything like that, then I think the the automation part is really a sentence.

14:42 >> Yeah. So you're put the emphasis on the two-week delivery. >> I think so. >> and that's that's the problem. >> Yeah. There's some other So maybe some of the consequences of not automating the way that you would like to would be good to to bring up. So some things that come to mind are morale. >> Yeah. >> Hey, you know, I had a part in the hiring of this team cuz I was the leader there, and I wanted to hire A players, but it was really hard to sell working on a team where you just grab tickets and then like updated some network configuration.

15:13 >> Yeah. >> Right? And you didn't have time to to to do the automation. That sounds like now I'm like perking my ears up a little bit because the work needs to be done. But like, what did you do as a leader to like frame that work, right? So that you could retain those people. >> It's clear John has real management experience. But like a lot of smart people, he can't tell which parts of the story give him agency and which parts deserve one sentence before he moves on.

15:38 The automation is a sentence. What John decided and the hard call he had to make when the plan broke, >> >> that's the story. This is exactly why I wrote my book, The Technical Behavioral Interview. There are several techniques in there to help you easily split we into me and show you how to build an answer around the latter without feeling grimy about it. >> >> It's important to remember that the interviewer isn't grading the project.

16:01 They're grading you. Let's work through this with John. So I'm asking you like how did you do it? >> in in this case the folks doing the manual work were on on a pure team. Tightly connected, but a separate separate discipline. But equally valuable for us to take their manual effort down to zero, from 200 a month to zero. And and show that cost savings. Mostly because of the organizational shifts we're requiring those network engineers to be more invested in design, future-thinking designs, versus spending their time deeply embedded in in manual manual keyboard work.

16:36 >> about it. Like I think to make this story really shine would be to frame it in terms of a choice. >> Mhm. >> The way that you framed it right now is like either we invested in automation or we didn't invest in automation. But the out there would be like, well, duh. Why wouldn't we just invest in the automation and turn it from like something to zero? So is there was there a choice there? >> The choice there was no it was an obvious thing that we had to do, you know? The other aspect of the story was prior teams had put investments in automation in an attempt to bring that manual effort number down to zero. It just didn't work right.

17:14 >> Okay, so why? Why didn't it work? >> Mostly because of I would say bad data. You're making software decisions on on data that's not that's not good. If your software goes out and and makes a decision to go make configurations in places based on source data that's irrelevant or not correct, it's it's going to implement the wrong thing. >> Why didn't they use good data? >> Yeah, it's it's one of the things that we as a team identified as a as a root cause and as a immediate thing we had to go and address.

17:45 >> You know. >> I understand that you identified it as a root cause, but like I'm going to assume that they're rational actors that wanted to do the right thing. >> Yeah. >> So like how did your team identify that they were using the wrong data when the team that was doing it before did not make that realization? >> By seeing some of the problems that like the misconfigurations that would come back as incidents. >> Okay.

18:09 >> So, you know, something would get deployed, network would get stood up and it wouldn't work or it would be misconfigured in a way that caused damage. Let's take an example like you take an IP that's already assigned to a system, you assign it to another system, right? That's going to create conflicts on the network. >> Yeah, that sounds like a bad idea. >> So >> So they were doing the equivalent of that? >> Some of the software that we took over did that.

18:34 >> Okay. >> So these were things that you wouldn't necessarily know right away until an incident occurred until you dug in and investigated it. So >> Yeah, I I mean so I believe you. I just it seems to me like a network engineer should know better. >> The network engineer in this case I would say would know better and even the software engineers who built the first set of software solutions knew better. >> But >> I would I would say that this was a result of maybe lack of testing, maybe early in career folks, not a lot of senior oversight. I'm just guessing at this point.

19:10 >> Yeah, so I think to really cuz again there's like the story needs to make sense. >> Yep. If you're saying like hey, it was it was difficult to invest in automation. A team before that had tried, but they had failed. >> Mhm. >> Then I'm like, okay, cool. Then you say, okay, well, we did some root cause analysis and they were doing some pretty iffy things. And so then the question just becomes like, why were they doing iffy things? These guys are professionals.

19:34 And so I think trying to find a diplomatic way of saying like they assigned some junior level people and there was a culture there of not testing their stuff. And network stuff is kind of hard to test. >> Yeah. >> Right? I think just removing the I'm guessing part from the response, I think shows a little bit of like diplomacy and tact cuz you don't want to throw anybody under the bus. >> right, right. >> But you need to be realistic about it.

19:59 >> Yeah. >> Yeah, so I think it's just like, hey, we did we did a turnaround. when I inherited the team, it was business as usual for a little while. I didn't want to rock the boat, but I decided that like, hey, if we're not going to make the same mistakes as these other people, I was going to dedicate some time for my team to go and do some research first. That was actually kind of difficult to do because we had all of these demands. We were blocking we were in the critical path and blocking all these Azure teams from doing all their stuff, but I thought it was really important that if we were going to be successful this time, that we learn the lessons of the previous of the previous teams. We did that analysis and we found three what we would consider root causes for why the previous teams had failed.

20:41 We poked a little bit at that. We had some reviews and then we decided that yeah, those were those were probably the right root causes. And so when we automated all of our stuff, we didn't run into those things from the past, right? And so that I think would demonstrate some leadership. It's a complete cohesive story and we don't have to talk about all of this like corporate like Microsoftisms or like reorgs and all of that other stuff, right? And then I think it clearly demonstrates what your role is as a manager on this team, right? Because you're not doing the thing.

21:13 >> Mhm. >> You are providing air cover and saying like, "Hey, we should do some research." I yeah, I would like to do some research, but I have all of this other stuff. It's like, "Hey, go do that research. I'm going to provide the air cover for you to go and do that." >> Yeah. Yeah, no, that's clean. Yeah, I like that. >> Yeah, I do think that's a that's a that's a pretty good story. We need more of those.

21:34 >> Especially You know, I the the aha moment I'm getting here is take the organizational stuff out and focus on what I'm bringing in as a manager, what the team is bringing as a team due to my leadership and pointing them in the right direction. >> Yeah. >> That's an aha moment for me cuz I I can I can see myself in prior interviews really putting a focus on, "Well, it happened because of a organization change." And trying to, you know, and and it it just it lengthens your answer.

22:01 It it hides, you know, some of the some of the meat. So, thank you. Yeah. >> Absolutely. And, you know, if we want to talk about it, so, you've been out of Microsoft for almost a year now. >> Yeah, almost. >> How many interviews have you done since then? >> Oh, boy, I'm ashamed to say. 12 to 15. >> Okay. Do you get a sense of why offers weren't extended to you? >> In the beginning, I didn't listen to some of your advice.

22:28 >> >> So, I definitely wasn't interview ready. I definitely, you know, when I heard the news, I went right in. Honey, I'm getting a job right away, you know? This isn't going to be long. And I I got interviews right at Amazon, my first one, actually. I got crucified. >> Can you think of a question that they asked you that you were unprepared for? >> Right. Like, question one, you know, system design. I'd spent some time, but definitely not enough. I mean, he he we went after me. Like, I pinned myself into a corner and And was like I was just getting punched and couldn't get out of the corner. So, and then question number two, design Amazon locker, right right right some classes.

23:08 You know, till by the time I got to the the questions that I felt I would excel in, you know, tell me about a time, you know, you had to let someone go, you know, or tell me about a time, you know, I couldn't get out of the thought process of where I'd failed in that. So, one, jumping right in was was a mistake. And then I I felt like I got my legs under me in I would say October, November and I had some good interviews.

23:32 I I'd interviewed early with Oracle. That was a good loop. Six six rounds. As to why I didn't get the offer, they don't they don't give you feedback. So, my guess is is, you know, for manager roles, they're they're probably they probably have a pool of people internal that are fighting for those roles as well and, you know, great job of companies are growing people inside, you know. >> Yeah. >> So, few other opportunities, Anduril Industries. That was another sit-down, deeply technical design classes, you know, and it exposed a weakness for me in that type of setting, you know, sit down, choose a language, write me a class that does data distribution, you know, like like it transfers a file into the cloud, you know, what So, I immediately I I I got help, you know, I went to a peer of mine, actually someone who works at Netflix who who does who coaches on the side and got help from him. I dug in in in that aspect, got a little more confidence. So, and then I I decided to really pivot toward AI engineering a little bit cuz that's where a lot of the roles were and, you know, big fan of Byte Byte Go, loved the AI engineering track there.

24:38 Used that as a springboard to get connected with other communities, you know, the ML Ops community and I'm I just started building. I just started getting my hands on on code >> Mhm. >> and using that as a means to carry confidence versus leak coding. I I wasn't getting any benefit out of that. Carry me in into now. I'm I'm working with a a early phase startup. We're building you know, something that's under NDA, so I can't talk too much about it, but I'm active and growing this startup that has good legs. It's going to get funded. It'll probably lead to an offer, but I'm I'm really excited about Netflix. It's that's a dream role for me actually. It's in a space that I'm comfortable with. I'm familiar with it. I'm glowing over just knowing, you know, it it's it's the scale of Netflix, the talent density, those types of things. I'm looking forward to getting a shot at, so.

25:26 >> Great. >> Yeah. No, I think, you know, I'm glad that you you leaned in after getting punched in the face with some of those other interviews. The best way to to interview is to do interviews. >> Yeah. >> And if you don't do those interviews, then you're just guessing when you do your preparation. You go and you get rejected and then all of a sudden it's like, okay, there's a lot of clarity >> Yeah. >> around what you need to work on.

25:50 >> You wrote a blog post. It was a while ago and it was like, pick your companies, save your best company for last. >> Yeah. >> And you can't you can't control that timing. You know, I've had a long string of interviews and now now Netflix is here, so I'm pretty pretty excited to >> Yeah. One thing I'll also say is you'll either get that offer from Netflix or you won't, but because it's been close to a year, you can just start the process over again. You can go and back and interview with those same companies again and then they'll entertain that.

26:20 So, it's just a matter of time for you. >> Oh, yeah. I believe that. >> I'm very bullish on John. Okay. Let's do this. What's the question that if I asked it would strike the most fear in you? Want to hear how I turned John's biggest mess up into one of his strongest stories? The full breakdown is in the members version on YouTube and on my Substack. Both linked down below. Now, let's get back to it. The thing that turns a good interview performance into an exceptional one is when you're able to teach the person that's interviewing you about a subject that they know deeply.

26:54 Two examples here. One, I was hiring a system system development engineer. Back then, it was much more of an operational role. The guy I interviewed, he he answered all of my coding questions, and then he taught me a whole bunch about systems. And I'm like, I've I've been in that world for a little while, and I was like, this guy's great. We hired that guy, and he just zoomed back up, right? The other thing is like, I'm hiring for a head of YouTube right now.

27:19 >> Mhm. >> And I think that I'm like really into YouTube. I've been self-educating, you know, I have a relatively successful channel. So, this would be the first time for myself that I would be hiring somebody that's like better than me at a thing that I think that I'm pretty good at. It turns a an okay interview into an exceptional one if you're able to teach them something that they don't know. It's really easy when it's a subject that you don't know very well.

27:44 >> Mhm. >> For instance, if I were to hire a head of sales, you know, I don't know that much about sales. If I was like, "Hey, teach me about something about sales." It would be very easy for that person to do that. One thing that I'll I'll recommend here is there's going to be a moment where they're going to be like, "Do you have any questions for me?" >> Mhm. >> And so, I think what it would be really you know, it's a great signal is that you go and find a Netflix blog post or some video that they've created that has something to do with the networking that you may be like part of that broader organization. And I would like you to just basically be like, "Hey, I read this article. I found it to be super interesting." And then, what I'd like you to do is ask a question about a specific aspect of it that you're curious about that was maybe glossed over or maybe is sensitive or something like that to the person that is probably the most technical on your loop. And that signals that you like you take bias for action, you actually are understand the engineering concepts, and that you can form a like an impressive question about the technology. So, a little bit of homework for you there.

28:50 >> No, I definitely got it. >> Tell me about a time your team's goals were out of alignment with another team that you relied on in order to reach your goal. >> The example I provided around hyper-connectivity, you know, for us to bring that number of of 2 weeks average provisioning time down to less than a day, it required us to have changes upstream on a completely other team. You know, we we wanted to automate, we wanted to >> they responsible for?

29:20 >> They were responsible for the security approvals. So, when somebody you know, put a firewall in place, it has to be approved. The process was was bifurcated. It was someone provisioned the network, then they went to security and got approval for their open ports. >> Oh, really? >> So, so, you know, we wanted to connect that and we wanted to streamline that and and we wanted to do it. You know, so, when we went in to say, we've got a design, we want to do these things, it was like, oh, we can't do that for a year.

29:52 >> It's not it's not a priority for them. >> It wasn't a priority for them. We really had to go to work and I I had to go to work and and help change that priority. And I did that by identifying the impact, the you know, how it would, you know, improve customer experience, how it would, you know, effectively raise a lot of awareness. >> So, your counterpart is another dev manager on the team that needed to do the work?

30:16 >> Yeah, it's a completely different organization. >> Okay, so, they don't even report into your management chain. Okay, >> So, we wanted APIs, we wanted auto approvals, and these are things that they didn't have in in place or at least they weren't prioritizing at that time. So, >> So, you made your case, hey, it's going to be so much better for customers, it's going to our processing is going to be awesome. And what did you do when they said no?

30:40 >> >> So, when they said no, it was just it was just around I need to make a I need to make a better case, but what we decided to do was okay, how about we do some of the work? Right? Why don't why don't you, you know, give us access to your branches. We we know where to make the changes. Why don't you let us do it? And that changed their mind because they didn't want us to go in and do, you know, they couldn't say no to us code having. When we made the arrangement to, you know, come in and and and do things, they softened up a bit. Well, okay, well, maybe we can do that, you know, and so what we saw out of that was you know, accelerating their their plan to do auto approvals for, you know, known secure, you know, port ranges. And then they actually did agree for us to, you know, build an API ourselves that we would own. It was actually a better choice for us to own it end to end versus us ask them to own it. You know, it was a great accomplishment cuz that would open the doors for auto approvals, gets ingested into our system through our API, gets validated, and then from validation it goes into, you know, the implementation side of of firewall rules.

31:44 >> Yeah, I I like this story. I like it because you didn't really just like go straight to to escalation. >> Yeah. >> Right? You didn't go nuclear on it, either. There's a little bit of horse trading. You didn't get exactly what you wanted. but it also seems kind of reasonable. They're like, yeah, we can auto approve for specific cases. We're not going to give you this blanket auto approval functionality. You came in and turns out like you should have been responsible for some of this other stuff. Historical reasons, the system was working in the other way. My inner critic is just like that was a little too smooth.

32:22 >> >> You know, and so I think there was probably a little bit more friction than you're communicating. And so like if we can just have like maybe a little bit more like but >> Mhm. >> rather than and then. >> Yeah. >> If if that makes sense to you. >> No, I there's definitely friction in the in those types of things. Anytime you're asking another team that's already past planning, you know. >> Yeah, so maybe we bring that in.

32:49 >> you know, so it's like all right, you're past planning, you've already committed to your stakeholders on your side, and now you're either going to have to decommit something or work this work in, you know, somehow. >> Yeah, so I think maybe we don't want to belabor it, but just be like it's not just that we were deprioritized. It's like at Microsoft we do these big upfront plans. >> Mhm. >> And so they every team has a bunch of stakeholders, and there's a whole bunch of stuff we end up having to cut. And so the stuff that we commit to and prioritize, like those tend to be high priority things.

33:20 >> Yeah. >> You come in and you're basically like, "Hey, let's do auto approvals. Like, let's just do all this stuff." It's like, "Where were you when we were doing our planning?" >> Yeah. >> Well, you didn't know that you needed to do it when the planning had occurred. So, you come in like the Kool-Aid Man. >> Yeah, yeah. >> And you're like, "Hey guys, like we want to do all this stuff." They're like, "Hold on, guys. Like, we can't do this, right?" And so I think it's just adding a little bit of that to it. And if you know like what their road map was, cuz typically the things that they're prioritizing, sometimes you need to be like, "Yeah, that's actually way more important than the thing >> Yeah, yeah.

33:51 >> that I'm asking for." So, if you can get a give a sense of like what those priorities are. Another thing is often times there's a miscommunication about the level of effort. And so, when you come in and you're like, "Hey, can you do this, this, and this, and this?" It's like they're I'm asking their senior engineers like "How long is this going to take?" And they've like padded it like three times. And you're like, "Dang, like we don't have we don't have 6 months to work on your stuff."

34:14 >> Mhm. >> Often times you'd be like, "Hey, they thought that we were asking them for a ton of stuff. But, you know, turns out like we did a ton of work on our side, and we just we as much as we could we minimized the impact on their team." Also turns out architecturally that it made a lot of sense for us to own a lot of what they did. So actually we framed it in terms of like a migration of responsibilities that didn't make sense to them to us. And so I think that that makes it a little bit more realistic.

34:44 >> is true. So You weren't even there and it's all true. >> Yeah, >> >> I know because they all play these you know, these story we all told the same stories. Right? And so people with like a ton of experience like we've seen a lot of this stuff play out. I like your story because you're demonstrating it's just like hey, there's a let's not forget that there's a benefit for the company. The whole reason we have these processes and bureaucracy is not to keep the processes and bureaucracy there. Like we're not trying to protect the the old way of doing things, right? It's like we need to get some stuff done. Like how can we get stuff done without like upsetting everything? So just like adding a little bit of like flavor in terms of the fact that like there was some friction. It wasn't this Pollyanna story where it's just like I asked and they said no, but then I went back and then I said like hey, how about this?

35:34 And then they were like yeah, that's great. >> Yeah. >> And then we got it. >> Yeah, you're you're 100% right. So >> All right, John. Well, thanks so much for taking the time to speak with me today. Takes real guts to be vulnerable in front of people on camera. So I'm really glad that you came. >> No, it's a it's a Thanks for having me here and I learned a lot. So thank you. >> Awesome. Here's what stood out to me about John. His experience was there.

35:59 What was missing was knowing what to focus on when he told his stories and how to keep his own contributions as a manager on display. So here's the system I'd leave you with. It's the spine of the first half of my book and it comes down to three pillars. First, choose stories based on the role and the level that you're targeting. >> >> Tell the story whose scope matches the job that you want, not necessarily the one that you're the proudest of.

36:22 Second, always put yourself at the center of the story. Build the answer around your decisions and your judgement, so the interviewer hears what you did, not what the team did. Otherwise, the interviewer is just going to ask the inevitable follow-up question. And third, always connect it to the impact. Tie your contributions straight to the outcome that they care about. Get those three things right, and you'll stop hoping that the interviewer connects the dots, because you'll hand them the dots already connected. The full framework is in the book, linked down below.

36:56 >> I'm John DeLongba. I'm a former senior software engineering manager at Microsoft. I now understand that there's places in my answers where I can add like technical depth, and there's places in my answers that I shouldn't go too deep in. I would say it doesn't hurt you to get coaching. It doesn't even hurt you, even if you have to spend money to get coaching. It it it will never it'll never hurt you. it's an opportunity to practice.

37:26 and and that is is gold. If somebody's nervous about getting coaching, I'd highly recommend getting coaching. It's an opportunity to practice, and especially from a seasoned professional like Steve, it's it's gold.