Transcription
This is Amed. He's an ex-AWS senior engineer with 12 years in the industry, and he's trying to break into staff. Amed has the stories to get there. A 4-week migration with 20 partner teams, a disagreement with a principal engineer, two years leading a project end-to-end. But like a lot of smart engineers, he just doesn't know how to tell them in a way that sounds staff-level.
I'm Steve W. I spent close to 20 years at Amazon. I made it to principal engineer. And as a bar raiser, I personally conducted nearly a thousand interviews. The three things that I'll help Amed fix are making sure that he actually answers the questions being asked, telling stories that indicate that he's at the staff level instead of senior, and communicating scope so his stories actually land with impact.
If you're in the Seattle area and want to be featured in an episode, a link to the application is in the description. Let's get into it.
Amed, thanks for coming in today. What's the thing that you're the most afraid about when it comes to interviewing?
>> Basically, when it comes to behavioral interviews, the most thing that gets me nervous and worried about is how can I get the right answer or exactly what the interviewer is looking for. So once the interviewer has a question in his mind, I have lots of situations that came to my mind from my past, like 10 years. But sometimes it feels like, does that really the thing that the interviewer is looking for, or actually I should think about something else? And sometimes I'm worried that I start to speak about the situation and I have like my train of thought going very smoothly, then I figure out, oh no, does that really answer your question or not? So that's what's getting me nervous about interviews.
>> Okay, don't worry, there's uh, you know, I can totally help with that. Let's pretend it's a real interview and then, um, we'll go through a bunch of questions and then after that, we'll debrief and then I can give you a plan for for helping out your with your problem. Sound good?
>> Sounds good.
>> All right, let's do it. So to start off, can you tell me about yourself, Amed?
>> Sure. So my name is Ahmed. I'm a senior software engineer. I have been in the industry for almost like 12 years right now. So I started my career back in Egypt. Uh, I started like a junior engineer, worked in a couple of local companies. Then I joined AWS, that was back in, um, 2016 in South Africa. I spent there about three years, um, working uh, AWS and then moved here to Seattle just before COVID, like almost end of 2019.
>> Yeah.
>> And, um, I was working as AWS, um, health or. So I got promoted there two times, uh, till I became like senior engineer and, um, I just left Amazon, um, couple of months ago.
>> Okay. How long were you a senior engineer for?
>> Almost 3 years.
>> And then how long have you been in Seattle for? Sorry, was it 20 right before COVID, you said?
>> Yeah, it's almost like six years now.
>> Okay. All right. So let's just jump into the behavioral interview. So since you're interviewing for a staff position, something like that, tell me about a time you had a conflict with a teammate or a manager.
>> Are you looking for the result or the situation itself and how I dealt with that?
>> So both. Okay. True. When you mentioned that I had like some stories that came to my mind and, uh, one of them at camp is I have been working on a design and I had a conflict with one of the engineers reviewing my design, like a teammate, basically, and we had like some discussion and argument and, um, we went through this argument like by discussion with a senior engineer in the team. At this time, I wasn't a senior engineer, I was, um, like an SD2 level engineer in Amazon. And, um, we worked through this, uh, discussion together. We had some discussion with other senior engineers and the team, me, the manager in the team, uh, until we resolved the conflict. I can't go into some details, but just to want to make sure that that and that that kind of situation that you're looking for, how I dealt with that.
>> What was the conflict?
>> The conflict, basically, I had a, I was working on a design and I came up with a solution that can, it's a little bit complicated, but, um, not not complicated, but it required more work and building more components because I saw some potential issues on the simple way that everyone thought about. And after research and experiment, I, I figured out that that will be a potential issue in the future. So I wanted to basically protect us from that and came up with a little bit, not complicated design, but more like required building more components and required more work, >> to to get it. I wrote a design document and came up with evidence, uh, and some experiment from what I did, and, um, came up with different solutions. One of them is a simple, simple one, straightforward one, and the other one that required more work and, um, reviewed with the team, got some feedback, got basically some questions about, okay, how did you experiment that? What was the issue that you expected from this solution? Um, simple one, basically, and, um, what your call, basically, because I came up with a different solution and I have to came up with, um, like one pick one, uh, solution. We discussed that as a team, I managed to convince most of the team, except one engineer who thought like, okay, no, I don't think that's right.
>> That was the senior engineer?
>> No, he wasn't senior engineer.
>> Okay, so another mid-level engineer?
>> Yeah, at this time, yeah. And, uh, like started to discuss that and he went to do some homework, basically, to prove that his point correct. I went to do my homework to prove that, not to prove my, but more research, like, okay, maybe he's right, maybe I was missing something. Will it be actually an issue, or I'm just overcomplicating the solution just to make my design more fancy? So I was convinced, he was convinced, we had an argument about that. So we decided like, okay, let's go to the senior engineer and see what he thinks about that. We had a discussion with the senior engineer. He was more aligned to my solution because he was convinced that this actually, the simple one will be mainly like bite us in the future, basically.
>> If we went with that, bite us in the future in terms of potential, uh, data loss, in terms of potential overhead on the on-call and ops work. So we had a discussion as a team with the senior engineer and the manager, and we decided like, okay, that's basically the route that we're going to take, is the suggested solution. So we went and implemented this way, and it, during the release, one of the steps is basically to make a load test, and during the load test, we figured out that, okay, the other solution, the simple one, would cause more problems if we went with it, because the that the system would not behave in the way that we want with this data load. So as a result of that, we had like a real tangible, uh, example that this solution, the one that they came up and convinced the team with, is the one that we should go with to the production. We, we did that and we deployed, and it was sustainable on the, in terms of like, after we released, it was reliable and sustainable as we expected.
>> Okay, here's where almost everyone loses the interviewer. The opening. Most people start a story with a ton of background about the company, the team, and the technology involved. It just takes way too long to get to what you did. If you start this way, you want to flip that around. The first sentence out of your mouth should be the entire story compressed into one line, if at all possible. In my book, I call this the headline, and it's the most important sentence of your entire story. Your goal is to name the problem you faced, the action you took, and why it mattered. Something like, "Let me tell you about a time when I discovered our processing delays were caused by database locks, not the network issues everyone assumed, and I fixed it by redesigning our update logic, which sped the system up by 16 times." That one line confirms you understood the question and signposts exactly where you're taking them. The trick is that you want to reverse engineer the interviewer's notes. You hand them the sentence you want them writing down. Then you pause and let them steer. I break the full structure down in the book. Back to it.
>> So for that example, how do you think you did? Was it a good example?
>> I think, yeah, I think it's answering.
>> Is it a staff-level example?
>> Uh, it's staff-level example. Uh, in terms of No, I, it's not.
>> No, I would say like some type of behavioral questions. But I think maybe they are kind of the same for some levels in terms of like that's why I ask the question is like, what actually looking for from the conflict level? Like, how, how big is the conflict should be? Will it be like technical or will it be strategy conflict or will it be?
>> It can be any type of conflict.
>> Okay.
>> But I think for any question, your answer will tell you what level the other person is. So if you told me like, hey, I don't know what level Amed is, but here's his answer to this question. Tell me what level he is.
>> Mhm.
>> What level do you think that Amed would be?
>> I would say like senior.
>> Senior, even though you basically said, hey, the answer to this question is we went to my senior engineer and he agreed.
>> That's, that's a good point because one of the things that I think it makes sense to to discuss is like, how far I should go with my examples. So mainly I.
>> Yeah. No, we can, we'll get there. I think the big thing here is I think that's a really solid mid-level answer.
>> Mhm.
>> I actually think that it's not a good senior-level answer and it's definitely not a staff-level answer.
>> Is it because I mentioned that we went to discuss with senior engineer?
>> That's one of the reasons as well.
>> Okay.
>> This episode is brought to you by Linear, and they just published something that I think is worth talking about. They opened with the 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 2 hours so eight engineers could figure out what they already knew they needed to build." 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.
So, I'll give you an example. If I were to answer that same question, I have a story where I disagreed with the vice president. So, if I just on the surface, if I told you about a time where I disagreed with the vice president, I didn't, uh, report into that person, but I disagreed with them and I had to interact with him and all of this other stuff, what level do you think I would be?
>> What level?
>> Yeah. Right. And so I do think that the level of the belligerence, if you will, the people that are involved in the story, it really matters. If you disagreed with a principal engineer, that kind of makes me think like, oh, okay, well, this guy can actually push back against a principal engineer. I think that's great.
>> Yeah.
>> Right. If you're like, oh, there was a, there was a mid-level engineer that didn't like an aspect of my design, I think you're playing at mid-level engineer stakes just on the surface of it.
>> Right. So that's one thing I, I think if I were you, I would, I would think about like an example where there was a conflict or a disagreement for as high of a level as you can, you can think about for your experience. Okay? But let's just take this example and and flush it out. So that's the first thing.
>> The second thing is in this example, you turned out to be right. I think what you want to do in, in a lot of these situations is to talk about how the other person could have been right, >> as well. Stories where you're obviously right and they're obviously wrong. Um, they don't tend to be good stories because the reason people ask this question is they're going to go and hire a bunch of smart people and they're going to put all of these smart people in the room and then they're going to be, of course, there's going to be conflict there. We used to have like a weekly principal and senior principal meeting in my organization at at Amazon. We didn't agree on anything, right? That's just the natural state of things is there's going to be a lot of disagreement, right? And so the, the question is like, can we make progress despite the fact that there are disagreements, or is like everything a hill that you're going to die on, right? And it shouldn't be. One thing about your story is I would have loved to understand the choices here. I think what you said is like one side is like, hey, it's a slightly more complicated solution that's more involved and it'll take longer, and the other person was pushing back and said, do we really need that? Can't we just do the simple, straightforward way? I would have loved a little bit more detail there, and I might have asked it in a follow-up, which is just like, what was the consideration? What was the thing that they were really pushing back on? Like complicated versus not complicated isn't the right framing. You had said something around data loss, like maybe I would expand into that. What's one more layer down without going into crazy detail? What was the actual trade-off? What was the, the basis for the disagreement?
>> Basically, is, uh, one of the solutions that will require more storing the old data and compare against them rather than just go on the fly and rely on the basically that downstream that we're using that will sustain and load.
>> You wanted to build like a version store, at least like keep the old values?
>> And, and he's basically like, "No, let's just update everything when we need to update it."
>> Yeah. Just trust the downstreams and I think they can scale. And.
>> Was it like a control plane of some sort?
>> Yeah.
>> Okay. So, the way that I would say it is I think you were, you were trying to, you wanted to say really, really high level with the disagreement because you didn't want to get into all the details, but I think that's a false dichotomy. You can just go one layer down in terms of the details so that we can frame the disagreement a little bit more, >> without going into, hey, he wanted to use consistent rights and, you know, and I wanted to do like eventual consistency or whatever, like we don't have to go at that layer, >> but we can just go one layer down, right? So you could have said something like, hey, we were working on a control plane system, clients call in and, uh, set their values. Uh, I wanted a, a more robust system where we kept like the old values in case they wanted to roll back. Maybe a little bit more guardrail so they couldn't shoot themselves in the foot.
>> Mhm.
>> And my, uh, my colleague said, like, why would we waste our time with that? We need to trust our clients more and they know what those values are. If we get pulled into every update, that's just going to overload our team. Why can't we just push something out that's a little, uh, more simple, and then we can add more layer on, more complexity later if it's needed? I think that makes it sound like, oh, okay, well, there's two rational people that have a real choice in front of them. Nobody's right. In a sense, like your colleague was also right.
>> Yeah.
>> Right. And so whenever we talk about conflict, we have to talk about we just had a difference of opinion. It wasn't like I was obviously right and he was obviously wrong or vice versa. You also talked about escalating it to like a senior engineer. That's the thing that was a yellow flag. It's just like, why does everything need escalation? And so I think part of me would have been like, hey, we tried to work it out on our own. We weren't making any progress. And so I was like, hey, let's just, how about we just go to our senior engineer, you know, we can both make our case and then they can choose which one is right.
>> Yeah.
>> Right. Instead, the way that you positioned it was like, oh, I went, we went to the senior engineer, and obviously he was on my side.
>> Yeah.
>> Because we were thinking about the future. Right. So that's that's kind of a little bit more like, yeah, I'm definitely right. This guy's not right.
>> I think it makes sense to some extent. I was trying to avoid this route of saying like he was wrong. Uh, because one of the things that I mentioned is I want to do my homework to make sure like I'm not missing anything and he could have been right.
>> So that's what I was trying to do. Maybe the words didn't serve me well here, but I was my intention was trying to avoid this route because I just hate to say like, I'm, I'm right and he's wrong.
>> But the thing is, even if you went to go do your homework, it also sounded like you went to go do your homework so that you could argue that your side was right. Maybe you could have done some homework and then shared the result with the person that disagreed with you. Instead of just being like, "Hey, obviously this is correct." And then I escalated to my senior engineer and he thought I was correct, and then I did the homework, and then, um, you know, I had results and data, right? You could have just been like, "Hey, I tried to make my case. I went and got some data. I presented that data to him. He still wasn't budging." And then only as a last resort did we escalate. I think it's a good example for an SD2. I don't think it's a good senior-level example, and I don't think it's a good staff-level example, but I think if you were trying to, if you were going to keep this story, that's how I would position it. Do you have an idea for what you would, an example that would be senior or staff?
>> Yeah, I think I have much better examples.
>> If you have an example where you push back, you have a disagreement with the principal engineer at Amazon, I would so much more prefer that than one where you were like wrestling with another mid-level. I.
>> Think that's the first one that came to my mind. But.
>> Instead of you delivering that, um, let's workshop the story so we can start off on a good foot. Right. So, can you give me the headline for this story with the principal engineer?
>> So basically the summary for it is, was I was working on a big project. I had an idea how we can came up with a solution that we can protect basically our downstreams from taking more ownership on how they manage the data on their side. So we can, we can leverage our data that we consume from like our, uh, upstreams. So we can protect the downstreams because we already know how they, um, suffering kind of from service, like it was a legacy service, and they were basically suffering from some data load on their side and how they keep it consistent. And this was like a, we, we were in the same org. So it was like a strategy-level, uh, thing on the org to how we can, uh, protect this service from being overloaded with data.
>> Yeah. I, so for this story, like, let's start with the conflict.
>> Yeah.
>> Right.
>> Yeah.
>> Again, we want to do just-in-time context.
>> Yeah.
>> I think I understand your side. Let me tell you about a time where I thought that my, you know, my team was in a spot where we could do more for our downstream clients so that they didn't have to worry about all the overhead of maintaining this data or whatever it was. But my principal engineer thought, >> let them do it, basically.
>> Yes. Because >> because that's, um, that's gonna make our service a little bit complicated that we're gonna deal with. We're gonna deal with some situations in the future in terms of how data is stored in our site, are presented, that they are basically built for that, their service built for that, they have the capability to do it. >> Like, although they are maybe suffering from it a little bit, but if there, let's fix it there instead of on our side.
>> Yeah. So, I would say something like, you know, let me tell you about a time when I disagreed with a principal engineer. I thought that my team could do more for downstream clients and that we could manage a lot of the data and the workloads for them, and that would make them sort of happier with us. They would have to do less. But my principal engineer thought, like, let them do that work. That's part of their responsibilities. You shouldn't actually be doing all of this stuff. I don't even need to know the underlying, like, data architecture. I don't need to understand what the, the processing is. The interesting part is this disagreement that you had to work out with the principal engineer, and you were a senior engineer at this time.
>> Yeah.
>> If that's the setup, if you could, you know, tell the rest of the story, I'd be like, "Yeah, this guy's a staff-level engineer, right?" Depending on on what you did.
>> Yeah.
>> Okay. So, let's continue with the story. So, yeah, we, we discussed about that and we came up with a strategy like, okay, let's, let's not do it right now. So I was convinced from the principal engineer that, okay, maybe that's not the right thing to focus on right now.
>> Although like I've been think, like it basically for me it was a disagree and commit.
>> Right. So you, you disagreed. I disagreed with the sentiment that, okay, let them do it, let them fix it there. If they cannot do it, they have to handle it. M.
>> It's not our responsibility basically to do it.
>> And, um, I disagreed and committed to that. So I adjusted my design to basically have the idea there, but it's not something that we're going to implement right now.
>> We moved with our design, we implemented, we deployed in production, and maybe a couple of months later, we figured out that they are suffering from it.
>> Okay. And what was, why?
>> Because they didn't have the capability to handle the load that we put on them.
>> Okay. So part of this discussion is you were intercepting traffic from these downstreams.
>> Yeah.
>> And so you were like, we're in a better spot. We can aggregate all of the load.
>> Exactly.
>> We can handle it. And your principal engineer is like, no, just give them the traffic. They should be set up for it. You said your thing and then, and then you disagreed and you committed, and you're like, fine, we won't do it. And then it turned out that you were correct.
>> Yeah. Yeah, it turned out that it's, it was much easier for us to do it, um, less expensive, and we can handle it much better because of our situation, not just because of how, because basically the other service was legacy and they have to deal with other data storage issues. Uh, on our side, it was much easier to do it.
>> Okay.
>> And, um, yeah, a couple months later ended up that we are actually implementing this solution.
>> Okay. So then you went back and you did it the right way.
>> Yeah.
>> Okay. How satisfying of a story do you think that is? The one that you just told.
>> In terms of what? Satisfying in terms of.
>> The interviewer. Do you think that he would like that that story or not?
>> If we break it down, um, yeah, I think it was argument that I stood up to my idea.
>> And I try to show a case from what I think is the right thing to do. After like discussion with the principal engineer, I had to disagree and commit.
>> So I'm not really pushing too much. So not creating like a bad environment and, uh, try to push from. So basically having, if we think about that from Amazon, uh, principles, that's have a backbone and disagree on commit.
>> Yes.
>> And, uh, at the end, be right a lot.
>> Well, it's more of a be right a lot for the principal engineer, not for you. Right. Let's think about it this way. Um, when you disagreed and committed and then did it the way that the principal engineer did. What would I think make this story really shine is that you turned it into a reversible decision when you guys figured out that you needed to actually take the load and so you re-architected things to take the load from your downstreams. Was it relatively easy to do or did it take, like, was that a really big effort?
>> It was another project, um, that me myself, like they used my design, but me myself didn't implement it. Uh, so I wouldn't say like relatively easy, but compared to the other, yeah. Compared to the other effort that had to be done on the downstream. Yeah. To the.
>> So because it was easier, what I would say is at the end of the day, the principal engineer was the one that was going to make the call. And so, you know, I had to disagree and commit after I said my piece. But what I did was that when we were developing the solution, we made it a little bit easier to reverse course if afterwards the traffic had to come to us.
>> You probably did some things that you were just kind of like anticipating, like, hey, maybe, maybe if we need to reverse this decision, it'll make it slightly easier.
>> So when we implemented it, we made it slightly easier for it to come back to us. And so when it turned out that I was ultimately right, two things here. One is that you should make sure to not rub it in the principal engineer's face. I think it's a good idea to take it back to the principal engineer. So maybe in the future, if you have something similar, and just be like, hey, turns out, uh, when we made that call, it wasn't the right one. Then you can just be like, did we make the right choice or not? I think it's a really senior-level thing to do to understand that we are all operating in this environment where there's some risks associated with our choices. We don't, it's not a game of perfect information. We're not playing chess where everything is out on the board. It's more like we're playing poker, and there are some things that we see and some things that we don't see. So we shouldn't fall into this trap of looking only at the outcome. But, I do think that closing the loop with the principal engineer and saying something like, "Hey, there were some things that we saw and some things that we didn't see. Here's how it worked out. Did we make the right call knowing what we knew back then?" Right? And are there any lessons for us to take forward? I think if you were able to do that in your story, that really makes the story pop. Does that make sense? Was there a, was there a moment where you went back to the principal engineer and you were like, "What the heck?"
>> No, actually, it was the call from the principal engineer that he came back to me and said like, "Okay, I think we should have done it this way." So.
>> Great. Okay. So, that was left out of your story, right?
>> Maybe I didn't mention that.
>> Again, I think the way that you position that is is really important, right? Just to, to really punch up your story. We're going to say like, "Hey, during our implementation, we made it a little bit easier to reverse course, but I still committed and we did it the way that the principal engineer wanted." And then you can be like, "Hey, turns out I was right. It's okay. I didn't rub it in his face." He came back to us. He came back to me.
>> Yeah.
>> And then we talked. What was that? What was that conversation like?
>> No, it was like a smooth conversation. Like I had a very good relation with the principal engineer. So, it was very smooth, like, okay, it turned out that we want to have this component on our side. So, we will do it.
>> Yeah. And because you had done a little bit of extra work during the implementation to make it reversible, it was totally fine. Yeah.
>> If we can kind of like put those pieces together, I think those would be, uh, that's a senior to staff, >> like staff-level, uh, example. You feel better about the, the answer to that one?
>> Yeah.
>> Okay. Good. Amed just told a much stronger conflict story, and the reason it's stronger is that he disagreed with someone above his level, but he left out the single best detail in the whole thing. After the disagreement, the principal came back to him and said, "Amed, you were right, and that they should have gone with your approach." That's the best detail, and Amed almost completely dropped it. Here's why that's gold: There's a huge difference between you saying you were right and the other person coming back and telling you that you were right. If you say it, you kind of sound arrogant, and the interviewer starts wondering whether you're the difficult one to work with. When the principal admits it on their own, it's exactly the kind of signal that levels you up because you showed the conviction to push back on someone above you but still commit to the decision. The mistake Amed made is one I see constantly. People think that the disagreement itself is a story. So they stop at, "We ended up going with this plan," or "We agreed to disagree." But the outcome is the part the interviewer writes down. If your judgment got validated, especially from above, you have to put that in the story. Back to it.
So, uh, tell me about a time you delivered under really intense time constraints.
>> Yeah, remind me, was one of the biggest releases that I have done. Um, so we had a big project to deliver and, um, basically it was that the complexity of the delivery wasn't just that we are releasing in production. It was the complexity that we're replacing one of the component that exists already with another component. So like a, not a component, basically like a big multiple components. So it was like kind of migration, lift and shift kind of things, and the complexity came with how, uh, the ecosystem will behave once we have the migration. So you have lots of upstreams and downstreams, and to align all the timelines across these multiple teams was a challenging part, and it was tight on time. That we had lots of things to finish on our side, and I was a lead for the, the project, and it was actually tight to make sure that all the upstreams and downstreams are actually gonna deliver on time, because if one of them slipped, the whole project slipped.
>> Okay. So I had to work with the team to basically focus on, focus on what's left to do to get our piece delivered, and work with other teams to see on their side what's left on their side to deliver on their time so we can make the end-to-end story successful. So this time, we were, we were working on the normal, um, scrum processing in my team. So I had the decision with my manager to switch that to like, let's move it to Kanban board. Let's move it, let's move fast. So let's list all the things that we have in our, in our side to get it done, and worked with the team to make sure like who is responsible for what component so we can move fast. So spoke with one engineer, that's your area, you are special in this one, let's get it done. Another engineer, let's get it done, and my piece, let's get it done. At the same time, I worked with the TPM so we can align across all other teams that consuming our APIs so they can deliver their time.
>> And making sure that how we can facilitate you, how basically we can solve things for you, maybe the onboarding much easier to our APIs.
>> Also worked with other team that was like kind of downstream as well to our data to our service to make sure that they are right on time. So what can we do on our side? Let's help you with this implementation. We are going to make sure that, um, we'll provide you like a client much easier to to onboard to, and, uh, we're going to explain everything to you. If you want to like, if you want to some of us working with you to delivered, we can offer that as well. I also worked with, um, like the stakeholders during, like they had a back-and-forth to go through our all the things that left on our side to work to them, like, okay, what are the move more like strategic way is how we can make sure that what we deliver or what we're working on is P0 for you, prioritize everything with them and the product manager and our SDM to get what's really important for them to get delivered first, and if something not really important that they thought it's P0, we worked with them. We had a couple of features that we worked with them to say like, okay, that's not really a P0. We can't go without it. Let's move fast for now. So we had like lots of conversation with them to make sure that we deliver something valuable and on the same time, we're not just, I'm not saying wasting, but we're not working on the most important things right now. So I had to manage all these parties together to make sure that we deliver on time, and the timeline was very tight because it has been moved multiple times because of us sometimes, because of other teams sometimes, but it was like a set date that we had to meet. I think the, the most important things that I have been working on is two main things. The one I mentioned that we're working on the right priorities, and the other one is how to make sure that that each team is like team members are more focused on one thing, not just working across the board with different things. So helping like one engineer working for example, just for one example, working on, uh, operational excellence.
>> So they are not just focusing on multiple things at the same time, just focus, hyperfocus on one thing and get it done. So that's how I managed the deadline, how I managed all the team members and all the assets that we have to meet the deadline, and, um, we ended up to actually have like, um, like meet the deadline, and, uh, we had like a whole room thing to release, and it was successful at the end. We managed to release in that time, the first main component, and then we broke it down, the other component to deliver, but wasn't that tight deadline.
>> Okay. How do you think you did with that story? From your feedback before, I believe I strongly believe that this is like a staff-level because it's working across multiple teams, multiple personas, and making sure that everything is aligned together to get the things delivered. I tried my best to make sure that not go into details, >> and summarize what actually the actions have been. Yeah.
>> I have talked to to each stream or stream.
>> To get it done. Um, yeah, I think it's.
>> Okay. So, I, I would agree with you if, if the numbers make sense and the scope makes sense, I think you might have gone a little too high-level.
>> Yeah.
>> With the story. And so, whenever you, uh, are asked like about delivery and tight deadlines, you want to think about it like a movie. Like, how impossible of a situation are you in right now? If you're able to get out of that situation, you'll be like, "Dang, that guy's pretty good." So one thing is, I think you want to give a sense of how crazy the timeline is. How aggressive is the deadline? Right? So when we joined the movie, Ahmed had how many weeks or months to deliver?
>> It was a long-running project. So, but I would say like from four to six weeks.
>> Okay. So you're like, let's just say it's four weeks. So Ahmed was put in the situation where he had to deliver something in four weeks. Can you point out like the incongruity or the asymmetry between four weeks and like what you had to deliver? Why was it difficult?
>> Yeah. Okay. I thought I mentioned that in my story, but it was difficult basically because we had lots of work streams that we need to.
>> Yeah. So, lots of work streams can be like two or one, >> or like 50, right?
>> Yeah.
>> So, I think one thing that it's difficult for us is like, it's difficult to communicate how big something is.
>> We start to run out of like words. We can be like big, like really big, like gigantic, enormous. Those are people could say that forever. So what I think would be helpful is to give like a relative size comparator. And so, is there something where the number is just like kind of obscene for a month? Maybe you can say something like, hey, we had to deliver something in four weeks that we delivered something similar to that last year, and it took us four months. Right? Then I'll be like, dang, like you, you're being asked to move like 400% faster. The number of work streams is difficult. You could, it's like story points, they don't mean anything. I can tell you that something is like seven story points, and you're like, I don't know, that depends on the team.
>> Yeah.
>> Right. And so I was like, is there a way for you to communicate the size and scope of this project?
>> Yeah. I think that's a tricky part is how can you communicate the size and of the project without going into.
>> So what I would say is something like, um, the number of partners.
>> Yeah.
>> So the number of upstreams and downstreams. So like the number of dependencies that are there. We had to work with 20 teams.
>> I'm just picking a number.
>> No, actually, it was close to 20.
>> Okay, good. Yeah. So if it's like anything where you have to get, where you have to get 20 teams to do something for you, and they're in the dependency chain, a month is not enough time. Like a month is 30 something days. Are you going to really, like, work with that many dependencies in 30 days? Like, that's pretty nuts, right?
>> So like, let's add that critical bit of detail. Like, how many teams were there? Let's, we'll use 20. So, yeah, and then I think, uh, how many P0 were there that you had to push back on? P0, you mean like they set a P0, and we had to push back to get P1 or P2s? We're about.
>> Well, no, so there was the initial list of P0 and P1s.
>> And then there was the actual list of P0 and P1s that you delivered with, and usually those aren't the same thing.
>> So like.
>> Yeah, we had to push, like, the numbers we had to push about three or four, but they are main features, so they would take us at least four weeks to implement.
>> Okay, three, there are three or four big, and how many did you do, you, uh, launch with?
>> A lot, like 20 plus.
>> Okay. You had to cut some pretty significant scope.
>> The thing is, is how, because as you mentioned, like, I can say we had to push one feature, but this feature is big, that will take us at least a month to deliver.
>> Can you give, like, what was that feature?
>> We had to implement kind of data dubbing on one of our components.
>> Dubbing and undubbing. So that will, will include like lots of data migration and data merging, and so some of the P0s that we had to push wasn't that big, but we have been focusing on the things that we actually, no, we cannot do it in four weeks. So that's the way that I've been saying like, we're trying to thought about the strategic way is what are the actual P0s, >> that is meaningful for them, it's we cannot, that's non-negotiable, we cannot release without them, or what are the features that actually they thought that it's P0, but after some thoughts from us and some discussion with them, is no, it's not actually P0, or it's not actually P0 on the way that has been written as a P0, so we can compromise on some of the feature there. So that's the strategic way that we.
>> So what I would say is like, just going back to setting the stakes.
>> Yeah.
>> Like, why is this a big project? Right. So I would say something like, hey, let me tell you about a time when we had to deliver on something in four weeks. That's really ambitious because there were 20 teams that were involved upstream and downstream. And so something similar that we had built last year took us double the time or three times the amount of time. And so we were being asked to do it in four weeks, and that, that timeline was not negotiable. They, they weren't going to move the timeline back. On top of that, the list of P0, right, the must-haves was just way longer than it should have been. They wanted everything. So we were in this spot where there was a high amount of complexity due to the number of partners that we had. The timeline was not movable, and they wanted a whole bunch of stuff, and we had to like sit there and educate them and really push back on on what was there. If that was true, then I think that, yeah, that's like the senior engineer, staff-level example, right? But we're, we have to anchor on relative measures of size.
>> Yeah.
>> So if you had said something like that, it would be like, okay, interesting. If he's, if he found a way to like, to navigate that, that seems to me like a staff-level engineer, right? So I think that was maybe missing. So just like a little bit of just enough more context to understand like what the stakes were. Okay. Then I would say something like, um, I think you did a good job of like coming in and talking about what you did. So, hey, we were doing like this big heavyweight scrum process where we like groomed the backlog and we had like a retrospective and then we had a like our backlog meetings, but because the, the timeline was crazy, I came in and it was like martial law. Nope, we're going to Kanban. Kanban is basically one big priority queue. We always just take from the priority queue. Another thing that we did was like, we didn't have time for randomization. So I said, Steve, you are, uh, in charge of this part. Amed, you're doing this. I'm owning this part. If any of these things are blocked or whatever, immediately escalate to me. So I like reduced randomization for our team. Then I.
went back to our stakeholders and basically said, "Hey, this cannot be the list of P zeros and must-haves." And so, what I think is, for like senior-level people, you really just have to do like basic project management stuff. You either move the date. Well, the date's not movable. You either add resources. Typically, when you add resources, there's some sort of like on-ramp period. Well, if you can't add resources in time and you can't move the date, the only thing is to cut scope, right?
So, I went back to them and I was basically like, "Hey, this date is at risk. Is this stuff really, really important? Do we actually need to ddupe, or is that a nice-to-have and we can fix it later after the date?" And so, I was able to convince the stakeholders that like three or four or five of these P 0s we could triage and we can move on to the, and we can do a fast follow. That would be a pretty good example, I think.
One last thing is, what was the project? If you could have just, at a high level, said like, "Hey, we were trying to do X," like that can maybe, uh, communicate a little bit more of the complexity. What was this project about? It was basically a migration for an old system that has been running around for lots of years. So, we had to migrate it to a new system. But the new system that we built, basically, like we built it from the ground up. So, yeah.
But what did it do? It's the ecosystem for managing large-scale events. That was the project.
Okay. Why was the deadline there? The deadline because the system has been suffering. The old system has been suffering a lot. And that was like a deadline that we came up, that the leadership, it was coming from the leadership, that you have to cut it down at this date. So, it wasn't negotiable as well because it has been pushed multiple times from other teams. One of the town's teams that has been delaying us because of multiple changes in the strategy on this side.
So, so what I would say is, we were, uh, building a new system that handled large-scale event incident reporting. Leadership was not going to move the date anymore because we had kicked the can down the road for a couple of years now, and they said, "No, no, no, it has to be done in four weeks, and no, we're not going to extend the deadline." And we were in a weird spot because we weren't evolving a system. We had to lift and shift and build in like a net-new system that had to work from day one, and we had a crazy deadline of four weeks that wasn't going to get pushed. And so, like giving enough of that context there, it would be like, "Okay, cool, like this is a real deadline."
Yeah. Like, if you didn't hit the deadline, it would have looked really bad for you and your team.
And so that also increases the stakes.
Makes sense.
Cool. And then, when it comes to delivery stuff, the results, we want to do a little bit more than just be like, "We were able to deliver on time," right? So, if you can put in like, "Hey, we were able to deliver on time." It'd be good if you were like, "Hey, we were able to deliver even before the deadline." But also something like, you know, there weren't any incidences or we were able to actually do the fast follows. As a fast follow, maybe you can add some measure of like client or partner-level satisfaction. "Hey, the 20 teams involved, like they gave us a pat on the back. They were like, 'I can't believe that you finished this in time.'" That sort of thing. I think that makes it work really well as well.
Yeah.
Cool.
Makes sense.
All right. So, you're feeling better about that story?
Yeah.
What's your best story that you have?
I would say this one.
Mhm.
Oh, this is your crowning achievement?
Yeah, I would say that because I had lots of details and it has been like a long-running project for almost two years.
Okay. So, here's a trick. It was a three-year project.
Two years.
Okay. So, this like last little bit is part of like a, like a two-year epic, like a two-year arc.
Yeah.
So, the trick here is like, we want to take like the biggest crowning achievements and we want to turn that into multiple stories if we can.
Yeah. That's what I'm trying to do.
Usually, that's why you, I think with more questions coming, you will see that I have been taking some examples from these projects. So, that's why I have been focusing on this. So, I had lots of deadlines that was really pushing and it was, I had to do lots of things to to manage. But this one, the thing I like about this project is I had to play multiple roles. So, I had to play senior engineer in the team, take lead, pushing people, and try to solve any complexity there. At the same time, working with, as a product manager, but working closely with a product manager that we have to advise them and see what are the things that we can solve better. Also, working with the technical product manager to align with other teams because there are lots of dependencies. Yep. So, that's the thing I like about this project is I had to play many hats.
Going back to this, the story that you just told, one last thing that would make this story pop a little bit is if there was one last obstacle or challenge that put the project at risk. "Hey, I went in and we moved, we took Scrum away. We're just doing Kanban. I assigned responsibilities to every single person so they weren't getting randomized. I went back to all of our stakeholders and just really poked at some of the P zeros and the P ones and all of that stuff, and everything looked like it was on track. But then, insert some sort of like challenge or obstacle at the end. There was a really big problem when..." And then what you can do is you can just take, you can take a problem that was already existing and you can basically be like, "Hey, there was an assumption that didn't hold."
Yeah.
Right? Or, uh, there was anything that's sort of like last minute to put the thing at risk. This is a good time to put it in there. You don't want to fold that into, "Was there something about it that put the project at risk?"
Yeah, actually, there was. There was, and there was like one of the things that, um, big feature that we thought it's not required, and, um, it was actually required. So, we had multiple discussions with, uh, the stakeholders.
What was it? Okay.
It was actually the one that we pushed the P 0 one, the dubbing one. So, this one wasn't required. And, um, to came up with a better solution, I had to work with a product manager to convince them that's not actually required, and we're going to build something else for you that we thought we can do it in this. It was like maybe less than four weeks at this time.
Yeah.
So, I came up with a solution to solve this issue in, um, more like, it's not a hacky way, but it's more like a manageable way. So, we can do it. And, uh, I had to push with other engineers in the team. We pushed hard to get it done before the deadline. It was a couple of days before the deadline. So, we managed to do that. We managed to came up with the idea, implement it, test it, and, yeah, move it to production.
So, yeah. So, I, the way that I would say it is, when we got, we finally got to the point where, uh, I was pushing back on some of the requirements, some of these P 0s, and we were able to eliminate like three or four of them. But then the PM came back and was basically like, "No, we, for this deduplication issue, we can't push this. This has to come back in." And so, I tried to argue with him, but then I realized like, "No, they're right. Like, if we don't ddup, like a lot of this effort is going to go to waste." And so, then you can tell a story about how you were able to pull that in, right? Even though, like initially, like you had to cut scope, but then somehow the scope increased. And so that makes the stakes a little bit higher as well. And that makes it much, much more realistic. Like, at the end of the day, like all of this stuff is happening within a month. And so, like you're trying to push it out, and then it comes back in. Like, life's a lot messier than these stories that we tell, right? So, I think we can like introduce one wrinkle there.
Yeah. I think the tricky part about this kind of situation, there are lots of details there, and it's kind of hard to pick exactly, uh, what is actually meaningful for the interviewer to listen. So, you have to like simplify. So, what it comes down to is like, I think for you, you summarize too high of a level.
Yeah.
And then you're like, "Okay, let's go into the details," and then you go all the way down to like the nitty-gritty details, and we just have to go intermediate.
Yeah.
Right? So, every senior engineer, staff-level engineer, every dev manager, they have all been in the situation where they're haggling over requirements.
Yeah.
Every single one of them. You don't have to explain like, "The product manager pushed back and he actually said it's a P 0." You don't have to go into the details on that one. Everybody that's a software developer, like in their soul, like they have been in that situation before, right? So, you can assume that they've been in that situation. I think the situation that you're trying to surface is basically, you can just say like, "Hey, there's some deduplication and unduplication that needs to occur. I realized that when I was pushing back on it, and then like we cut it out. I realized that we needed to pull it back in, and it sucked because we were already on this time crunch." And so, I had to, and this you can tell a mini-story here. I had to, like, luckily I didn't have to design it on the fly. I already kind of knew what we had to do, but even on this design, we had to cut scope on the design and then just get it down to its bare essence so that we could get it across the finish line. So, then I think putting all of those pieces together, I think that's a pretty decent delivery story. We have time for one more. So, maybe we can go this way. What's the question that you are the most scared that they would ask that you don't have a story for?
Amed just told me the question he's the most afraid of, and that's where the best coaching in this whole session happens to see how I take them all the way through it. The full conversation is in the YouTube members cut or on my Substack. And that's a good place to step back and look at what happened across the whole interview. Here's what stood out to me about Amed. He was never short on material. The experience was all there. What was missing was knowing which stories to tell and how to tell them. And that's the part almost nobody gets taught. So, here's the system that I'd leave you with. It's the spine of the first half of my book, and it comes down to three pillars. Pillar one: Build the story so it's easy to follow. Lead with the headline that gives the whole thing in about 15 seconds. Then keep your core to about 2 minutes. Pillar two: Make sure the story is strong enough for the level that you're targeting, because a mid-level story will not get you a senior offer, no matter how well you tell it. And pillar three: Match the story to what the company actually values. Because the same story can crush at a startup but fall flat at a big enterprise. Get those three right, and you'll stop hoping the interviewer connects the dots. You hand them the dots already connected. The full framework is in my book. And Amed, thank you for being willing to do this on camera. That took real guts, and you leveled up right in front of everyone watching.