How do you remain employable in the new agentic coding world? You may have heard that your job is essentially to become like an engineering manager, managing all of your agents, your team of agents, and that now you're sitting up and you're a manager, but you don't have manager skills. What you've learned to do of your career, it's not even really what you want to do. You want to be a tech lead or a senior engineer. As it turns out, most of the people who are saying that you're like a manager really probably mean something more like you're like an architect or you're like a tech lead. And that's what we're going to talk about today. Specifically, I want to talk about interviewing skills for senior engineers, interviewing skills for a tech lead level role. And we're going to talk about this probably in upcoming episodes as well. This isn't really a series necessarily, but it's something that's going to come up over and over and over because as we continue moving forward into this kind of new world of coding, the likelihood that you're going to get a job where you are dedicating all of your time or even most of your time to kind of junior level coding tasks, the likelihood of that is very low. And so. The skills that you need in order to succeed are changing very rapidly. And it's important to recognize that this is true regardless of your level. This is true whether you are applying for a senior role or not. Some of the senior skills and things that have been kind of left up to the seniors, which are learnable by more junior people. All right. Some of those skills are what you're going to have to call a senior. Cultivate some of that mindset is what you're going to have to come to the table with early. Right. Early on. So regardless of where you are in your career, we're going to talk about a specific interviewing skill, a skill. And it's not just an interviewing skill. It's actually how you think about and how you talk about problems that you face in the course of project development, in the course of your career, in the course of your job. How do you do that? How do you think about these projects? And specifically, I want to zoom kind of zoom in on most of the time we do these interviews that we do something like a star story. Right. And we're not going to dig into this too deeply. But, you know, the situation, the task, you know, I can't remember what all of these letters stand for. I've used star stories before. They're great. They're a cool tool. And, you know, the goal of this episode is not to say that star stories are great. Star stories are bad. But sometimes, sometimes what the interviewer is really looking for is not just the times that you stood out in a positive way. The interviewer wants to know more also about how you behave when the pressure's on. What do you do when things fall apart? What do you do when things fall apart? If you walk into an interview and all you have, all you're armed with is. Stories of how you succeeded or how you overcame, how you proved your value. If that's the only story that you know how to tell, then it's likely that. And if you were to think about this just from the human perspective, if you do that at a party, right, if you do that with your friends, if all you ever talk about is how good you are or how cool you are, there's kind of the inverse assumption that there's something that you're hiding. Right. That this is kind of the value. Visceral kind of social thing that we, we can pick up on as humans. We know, uh, based off the way that somebody is talking about a situation, oh, they might be hiding something. They may be just telling me what I want to hear. Right. And so it's important for us to develop the skill of identifying mistakes and how we dealt with them. This is crucially important, crucially important. And, um, so, so I want to talk a little bit about kind of. Identifying the mistakes and recognizing what the, what the real mistake was. Right. And, and that's, so part of the skill is, uh, being able to recognize where the mistake is actually happening. Right. And, and there's some diagnostics here that we're going to talk about, and then your attitude going into mistakes, both now and into the future. And hopefully in the past, if you can, uh, recognize times when you've engaged in this, we're going to talk about in the second part of this episode. So first. I want to talk about it. So, so, uh, you know, don't delete your star stories. Those things are good things to hold on to. And in fact, you can still use star stories in failure mode. Right. You can still talk about, uh, uh, the failure as the situation that you had a task in and, uh, and talk about how you dealt with that failure. So the important thing, uh, the, the first skill I want to talk about here is identifying where the problem really is. Right. I. Identifying where the real problem is. So for example, very often I hear these, these stories in interviews. I conduct a lot of interviews and, and very often the stories that I hear tends to have some component of a knowledge transfer, right? And a knowledge transfer from, let's say, uh, a product manager to an engineer. That's one transfer from one team to another team or from a engineering manager to an engineer. Or from a previous engineer on a team to a new engineer on a team, senior to junior. All of these are translations of some kind. Right. And a lot of times, um, the, the, the most common failure modes are when that translation or, or one of the most common failure modes is when that translation, when that transition has not gone well, that, you know, you, you hand off the project, you hand off the task, or whatever it is, and, uh, you move forward on it. And something about the knowledge that was transferred is wrong or insufficient. Something has not translated well enough for you to be successful. Right. And so the answer is, you know, very often when I say what went wrong, the most common answer is, well, the knowledge transfer wasn't good. We didn't have good documentation is, is another common variant. Of this. Right. And, uh, so with this specific kind of answer and with other answers that are kind of like this, right. It could also be, for example, that, uh, well, they didn't document, they didn't, uh, document their code very well. Right. Or they didn't manage their versions really well. The people who came before me have done something wrong or the people who are giving me this thing, they've done something wrong. And therefore I was kind of up a Creek to begin with. And therefore, you know, the problem occurred. And usually this is, this answer is kind of this first level. And what I really want to hear as an interviewer is what is the systematic problem? And this is the senior mindset and the mindset that's going to help you stay employable. Right. As you move forward into the future. And, uh, the senior mindset is not something that you have to have a ton of, of experience to start adopting. And so what you really should be thinking about is, yeah, well, why did that? Why did that context transfer fail? Why were we set up for failure in the first place? Why did we not have better documentation? What is it about our system or about our incentives or about our structure or about our organizational, you know, setup? What causes that to happen? Right. So the diagnosis that you're doing here is not just what is this kind of a pro you know, the proximal thing, the thing that's close by that I can point to and say, yep, uh, it had that been better than the rest of this would have gone better. That makes sense. It's not wrong, but it's usually incomplete. It's not the whole picture and fixing that proximate or proximal cause is not going to fix the root cause. And so what I want to hear as an interviewer, what I want to hear as a hiring manager is, well, the root cause here is fill in the blank. Often the root cause of a knowledge transfer problem is that the organization. Okay. is moving too fast. And so they haven't taken the time to stop and put documentation into place. All right. So, well, why is the organization moving fast? There could be more answers to that that are even further down the root cause path. Wherever you find the most kind of salient point, because eventually you're too abstract for it to be useful. So you don't want to keep going down that chain necessarily. There is a point where it starts to become so abstract that it's not actionable. But if you can find the place that if I were to fix it at that juncture, right, if I were to, for example, be able to talk with my product manager and my manager about how our velocity is actually causing us to go slow in the long run and maybe short, you know, fast in the short run, but our velocity or ambition here is very high. But we're going to have a bunch of failures and we're going to have to roll back or we're going to have, you know, issues in production. We're going to have a bunch of on-call work, whatever the reason is systematically downstream from going fast upstream. That if you were to change the fast upstream, then you could, you know, improve those downstream outcomes, right? Okay. So the whole idea here is that if we're focused on just the most obvious, thing that went wrong, if we can't look at root causes, then we're unlikely to improve a situation, right? We can try to fix all of those immediate, immediately salient and obvious things, but it's more likely that we're going to improve a lot more outcomes if we go upstream, if we can fix something that is causing those bad outcomes. Right. We fix knowledge transfer, the system that is creating bad knowledge transfer, rather than the specific knowledge transfer in this instance. Okay. So that's the first behavior is to recognize that if you are, if you're trying to look at how can I make things better? What would I do next time? You're probably going to get this question. What did you learn? Right. What, what kind of improvement, what kind of adjustment, what kind, you know, how did you change as a result of this experience? What did the organization learn? What did others learn? You know, how, how did you grow? Because I, as a hiring manager, I want to see not only how did you behave in the past, but especially if I'm asking you about mistakes, what happened as a result of that? What adjustment, what did, what did the mistake do to you? Right. We learned from our mistakes. And so what did you learn? And if you can recognize that the learning, right, as you're telling these stories, try to connect that learning to, to something more systematic, that's a leveled up answer. That's going to get you a much better, uh, you know, interview review, right? Because you're showing that not only do you understand what happened in this case, but you also understand how to improve not just for you, but for others as well, this system so that it, uh, the outcomes that are generated from the system are improved, not just fixed for this particular project. Okay. Uh, so why does this, why does this matter in the first place? Why are we talking about, you know, uh, kind of learning from our mistakes? Uh, this is all about ownership and I want to talk to you more about ownership and why that's important, especially right now in the industry. I want to talk to you about that right after we talk about today's sponsor. Today's episode is sponsored. By cert API, no matter what you're building, cert API is the web search API for your needs. If you're building an application that needs real time search data, that's live on the web right now, whether it's an AI agent, an SEO tool, a price tracker, anything else that needs to know what's happening on the web, cert API is the web search API that handles it for you. And it does it in a clean, uh, uh, you know, kind of easy to access way that this is a true developers API. You make an API call and you get back clean. You get back to the actual application. You get back to the clean JSON. You can ignore all of the difficulty of having to parse, you know, or, or try to, uh, deal with captchas deal with, uh, you know, uh, uh, the search engines trying to shut you down. Uh, you're not going to have to deal with that because cert API is dealing with all that for you. All the scraping headaches. You don't want to deal with that. Um, they support dozens of search engines and platforms. They're fast. They've been doing it for a very long time. Uh, long enough that companies like Nvidia, Adobe, and Shopify all rely on them. And there's a free tier to get started. So you can build, and test your application before you commit to anything. And by the way, if you're building with API with, with AI, which, uh, probably if you're listening to this show at this point, you probably are, uh, SERP has an official MCP to get make getting up and running a simple task. So if your app needs to search the web in real time, check out SERP API.com that's S E R P A P I.com. So we're talking about ownership. And when we say ownership in this sense, I'm curious what everyone's kind of first thought of what ownership really means. Uh, I'm curious what that thought is. Uh, if we were to take, you know, a metaphor from home ownership, for example, home ownership implies the, uh, it implies that whatever the outcome is, is up to you. That's what the implication of home ownership is. And so if there is a, uh, you know, a leak, uh, a pipe leaking, then you could deal with it yourself. You could call a plumber to come and deal with it, or you could ignore it. Whatever happens though, you are the one who's going to take the next step. And you can delegate these things. You can, uh, you know, hire people to take help, take care of your home for you. But at the end of the day, it's your actions. It's your choices that determine what happens in the home that you own. You don't have a landlord. You don't have somebody who's going to check in on your utilities, right? Nobody's going to wash your house for you. Nobody's going to clean, uh, uh, your driveway off as a homeowner. The implication is that the outcomes, the environment of your home is going to be essentially directly connected to your choices about what you do with that home. And when we talk about mistakes and owning the mistake or owning a project, this skill is so critical because our scope of ownership, our scope of ownership has shifted dramatically. Assuming again, if you're listening to this, if you're listening to this, if you're listening to this, I I'm making kind of broad assumptions. Um, and maybe we've gone very early on this. I don't really know because things move so quickly in the industry right now. I'm making broad assumptions that most of you are either already or will soon be, uh, you know, using or adapting to some kind of agentic coding patterns for a huge part of your work, at least your professional work. Um, and so in assuming that's true, then it's very likely, it's very likely that you are owning code that maybe you haven't even read, that you are responsible for the outcomes of code that you haven't read. You're responsible for outcomes on your team that are larger than they were a few months ago, that are larger in scope. And so when we talk about ownership in this sense, as a, uh, as an engineer, regardless of your level, there's another word that I want you to, to associate with ownership. The concept of ownership is because it's tied to outcomes. Uh, I want you to think of the word relentlessness. Now this might trigger, some kind of anxiety that you're going to be tired. And that's not really what I mean by this. You can do this sustainably. You can do this in a way that is, um, that is not urgent. That doesn't drain you. Okay. But when I say relentlessness, I mean, following the trail until it ends until it terminates. That is what ownership is ultimately about following some kind of trail, some trail of thought, some trail of development until it gets to its natural end. So what this might look like is, uh, if there's ambiguity about whether something is working, right? The you've, you've created an MR or PR, and you don't know if it's succeeding. If it does it actually work? I don't know. Your ownership level will, will drive you relentlessly to find out. Uh, another totally different example at coming out of coding and more into kind of interpersonal relationships, relentlessly owning the outcomes of the relationships that you have with your team or the relationships you have with other teams, cross-functional partners, being a relentless owner of that means that when you see something, for example, your team is over allocated. Right? You don't have enough time to accomplish the tasks that are assigned to the team. That you take the next step to figure out what to do about that. Do I go and talk to my manager? Do I talk to the team? Do we need to get headcount? Do I have approval to ask for headcount? If I don't have approval to ask for headcount? Who does? Who would I go and talk to? Who can I escalate to? And the relentlessness in your mind. here is about avoiding the I'm going to let someone else do it syndrome. It's not a very catchy name, but ultimately if you are responsible for the outcomes of your team, if you're responsible for the outcomes of your work and you're recognizing, wait a second, I don't have everything that I need. You are relentlessly following a path of escalation. You're relentlessly figuring out who is responsible. How can I get this solved? This is the kind of key differentiator, the key differentiator between a senior thinking engineer and a more junior engineer who's just kind of working through specific assigned tasks, right? The senior engineer, this is directly related to your reliability and people's perception of your reliability. Because if you're relentless in, now notice, I want to be super clear about something here because most people have this built-in assumption that what this means is that you have to learn everything or that you have to do everything, that you have to own something all the way over the finish line, that you have to accomplish it yourself. And if you're relentless in that, you're going to be able to do it. And because you're not senior yet, because you don't have enough experience, that you can't do that, that you're blocked by your own inexperience. But the truth is very different. Because if you recognize that you are incapable of doing something, look at the homeowner example, right? There's some things that I can do that I can take care of in my own home and there's other things that I'm just not qualified for. I don't have the experience. If I tried to do it, the outcome would be bad. I don't have the experience. If I tried to do it, the outcome would be bad. It would be a bad idea. It would be a bad choice for me to try to own the specific implementation of that, right? For me to try to get into plumbing. I have very little confidence in my own ability as a plumber. Well, why would I believe that I have to carry that particular task all the way through? The correct thing for me to do is to own the outcome, not the task itself, but the outcome of the task. And so if you recognize that you're in over your head, if you recognize that a task is not well suited for you, the ownership mindset, the relentless ownership mindset is to try to find the person that it is good for. And if you don't know to ask and escalate until you do, and at some point you might find out that, well, you actually do need to learn this skill. Okay. Well, then you're, you're relentless about communicating what the risks are, right? You're relentless about communicating that, well, I, I, I recognize that now I have a responsibility and I'm not well suited for this. So what am I going to do? I'm going to learn, but there's risk associated with that. I'm going to communicate that risk so that the people who care about that, my stakeholders, they know what the risk is, right? And so what you're, what we're really trying to push here and, and what will make you a better senior, what will make you a better engineer, regardless of how many years you're in this, what will help you stay employable in the agentic coding era is relentless ownership. And that's not some magical term. All it really means is continuing to follow up on things until they come to their natural end point until there's nothing else to do. There's no other place to escalate. There's no one else to check in with. This doesn't mean doing this to an annoying degree. It also doesn't mean doing it until 10 PM every night. It means that you're choosing to spend your work times following on and staying with something and sticking with something until it is resolved. That is the key, the key skill. So how does this tie back? I want to tie this back to our previous discussion, the first part of the episode in discussing failures. Very often, very often failure, especially personal failure, something that you failed at. If that makes you uncomfortable, I encourage you go write a list of five things that you failed at. We're very easy. We can very easily find what other people have failed at. Other people could very easily find things that you have failed at. It's part of being a human. If everyone else around you has failed, then almost certainly statistically you have too. So, uh, get comfortable with recognizing these failures, but very often, very often our failures are, are a direct result of our lack of ownership, lack of relentlessness in our ownership. I stopped escalating, right? I didn't follow through with my responsibility. I, uh, chose to try to push through, even though I knew that