> ## Content Index > Fetch the complete content index at: https://blog.jesusguerra.io/llms.txt > Use this file to discover other available public pages before exploring further. # What Interviewing Engineers Changed About How I Think About Seniority - URL: https://blog.jesusguerra.io/what-interviewing-engineers-changed-about-how-i-think-about-seniority/ - Published: 2026-10-12T15:50:15.000Z - Updated: 2026-10-12T15:50:15.000Z - Description: Interviewing experienced engineers forced me to make some distinctions about seniority more explicit. Technical depth mattered, but the clearer signals often came from scope, ambiguity, ownership, influence, and how someone operated when the answer was not obvious. - Author: Jesus Guerra - Tags: Engineering Leadership, Software Engineering, Technical Leadership, Career Lessons Over the past few months, I have had the opportunity to interview several experienced engineers for roles at different levels of seniority. Going into those conversations, I thought I had a reasonably clear idea of what separated a strong Senior engineer from someone operating at Lead or Staff level. I had worked with people at those levels, had my own experiences with increasing responsibility, and had seen enough engineering organizations to have developed some intuition around it. What I did not realize was how much of that understanding was still intuitive. It is relatively easy to recognize an engineer who seems experienced. It is harder to explain exactly what you are recognizing, especially when two people can both be technically strong, communicate well, and have spent years working on complicated systems. Interviewing forced me to make distinctions that I had previously felt more than articulated. I am also careful about treating those distinctions as universal. Titles vary significantly between organizations. A Staff engineer at one company might have responsibilities closer to a Senior engineer somewhere else, while another organization might expect Staff engineers to operate across multiple teams. I did not come out of these interviews with a leveling framework that I think everyone should use. What changed was mostly the set of things I pay attention to. ## Technical depth stopped being enough One thing became clear surprisingly quickly: technical strength alone did not separate levels as cleanly as I expected. Some of the strongest Senior engineers I spoke with could go very deep technically. They had dealt with difficult architecture, concurrency, testing, CI/CD, migrations, legacy systems, and production constraints. In a conversation focused entirely on code, I am not sure there would always be a meaningful way to distinguish them from someone operating at Staff level. That made me reconsider what I was actually trying to understand. I found myself becoming less interested in whether someone had encountered technically complicated problems and more interested in what happened around those problems. How did the problem reach them? Was the direction already established? Who recognized that something needed to change? Who figured out which other teams or systems were involved? Who made the decisions when there were several reasonable options? Those questions started revealing distinctions that technical depth alone did not. There is a meaningful difference between working inside a complex system and owning an important problem within that system. Someone might implement a difficult migration, redesign a complicated subsystem, or deliver a feature with significant technical challenges while operating within a direction that someone else established. That can still be excellent engineering work. In fact, a highly effective Senior engineer who can reliably execute difficult work is enormously valuable. The distinction I started noticing was not about the difficulty of the implementation. It was about the scope of responsibility surrounding it. When candidates described projects, they naturally used "we" a lot. That makes sense because almost everything meaningful in software is built by teams. I do not want someone artificially turning every team accomplishment into a personal achievement. But eventually I found myself needing to understand what existed before that person became involved and what changed specifically because they were there. What did they notice? What did they propose? Which decisions were theirs? What would probably not have happened without their involvement? The answers were sometimes very different even when the projects themselves sounded equally impressive. ## Ambiguity changed how I think about autonomy Before these interviews, I think I associated autonomy a little too closely with independence. Someone receives a problem, asks relatively few questions, and gets it done. That still has value, but I no longer think the number of questions someone asks tells me very much about their autonomy. In fact, some of the conversations that gave me the strongest sense of autonomy involved engineers asking a lot of questions. The difference was what those questions were doing. An engineer might receive something vague like "this part of the system is becoming unreliable" or "we need to improve how this works." There may not be a clear implementation yet. The boundaries might cross teams. Nobody may know whether the real problem is architectural, operational, or simply a process that has accumulated too many exceptions. In that situation, asking questions is part of the work. Who owns this system? What assumptions are we making? What depends on it? What happens if we change this behavior? How do we know the change actually improved anything? The interviews made me more precise about the distinction between needing information and needing direction. Someone can need a lot of information while still being highly autonomous. What matters more is whether another person has to continuously assemble the problem for them. If someone else needs to identify every dependency, define every next step, determine what should be validated, and keep returning to provide the next piece of structure, the engineer may be executing independently without really owning the problem independently. That distinction matters because difficult, well-defined work and ambiguous work demand different things from an engineer. A technically challenging problem can still have a clear boundary: this is the component, this is the expected behavior, these are the constraints, and this is roughly what success looks like. The implementation may be extremely difficult, but much of the problem has already been shaped. Ambiguous work starts earlier. Part of the job is figuring out what the problem actually is and turning it into something that other people can reason about and eventually execute. I used to think of that mostly as a leadership skill. I now see it more as a form of engineering ownership. ## Disagreement revealed more than alignment Another thing I started listening for was what happened when capable people disagreed. Many project stories eventually reach some version of "we discussed the options and aligned on an approach." That is useful context, but after hearing it several times I realized that the interesting part was often missing. Real engineering decisions are not always resolved because one option is obviously better. Sometimes several experienced engineers understand the problem and still prefer different trade-offs. Those situations told me much more. I became interested in what happened when consensus did not arrive naturally. How did the engineer explain their position? What evidence changed the conversation? Which constraints mattered most? Was the decision theirs to make, someone else's, or genuinely shared? If the team chose a different direction, what did they do afterward? This also changed how I thought about influence. It is easy to associate leadership with being the person assigning work or coordinating people, particularly when someone has formally led a team. But those stories did not always tell me who was responsible for moving an uncertain technical problem toward a decision. Conversely, some engineers described situations where they had no formal authority but still changed the direction of a project. They found a problem, gathered enough evidence to make it visible, involved the right people, proposed a direction, responded to disagreement, and helped the team converge on something they could execute. That kind of influence became more interesting to me than the title attached to the person doing it. Delegation became more nuanced for the same reason. Saying "I delegated these pieces to other engineers" tells me how work was distributed, but it does not necessarily tell me how responsibility was distributed. I started wondering what decisions those engineers could make independently, which decisions still came back to the lead, and who was ultimately responsible for recognizing when the overall initiative was drifting. This is where leadership and delivery ownership started separating in my mind. They overlap, but they are not the same thing. Someone can mentor people well, coordinate a team, and create space for others without necessarily being the person shaping or carrying an initiative through ambiguity. Someone else might own a difficult outcome across several people without being their manager or even the most senior person in the room. ## The stories with imperfections were often more convincing One of the things that surprised me most was how much confidence I gained from candidates who were precise about the limits of their own contribution. There is a natural temptation in an interview to make every story as strong as possible. A team solved a difficult problem, and the candidate describes the part they played. Sometimes, though, the boundaries become suspiciously clean: they identified the problem, designed the solution, convinced everyone, led the implementation, and the decision turned out to be correct. Real projects are rarely that cooperative. The conversations I found more convincing often contained boundaries. Someone would explain that another engineer made a particular architectural decision, or that the overall initiative came from their lead while they owned one part of it. They could describe where their responsibility started and stopped without making their contribution sound smaller. That precision made the parts they did claim easier to trust. The same was true when people talked about mistakes. I found myself paying particular attention when someone could say, in effect, "This was my decision, and it turned out to be wrong." Not because making mistakes is evidence of seniority, but because explaining one clearly requires a different kind of reflection than presenting a sequence of successful decisions. What assumption turned out to be wrong? When did they realize it? What was the cost of changing direction? Did they defend the original decision longer than they should have? What did they change afterward? Those stories gave me a better view of engineering judgment because judgment is not really tested when the correct answer is obvious. It becomes visible when information is incomplete, trade-offs are uncomfortable, or a reasonable decision produces an unexpected result. It also made me more comfortable preserving uncertainty in my own evaluation. There were conversations where I came away thinking someone had very strong technical judgment but I still did not have enough evidence about delivery ownership. In others, I saw clear initiative but wanted to understand how far that influence extended beyond their immediate work. Earlier, I might have felt pressure to resolve those signals into a simple conclusion too quickly. Now I think keeping the uncertainty is sometimes more useful. "I have strong evidence here, but I still need evidence there" is a much more accurate assessment than forcing every conversation into a clean yes or no. ## A different question about seniority I still care deeply about technical ability. None of this replaces it. The higher the level of responsibility, the more important it becomes to have enough technical judgment to understand the consequences of a decision, recognize risk, and earn the trust of other engineers. But interviewing experienced engineers changed the question I find myself asking. Instead of only wondering how difficult a problem someone can solve, I think more about what kind of problem I could hand them before it has been fully shaped. If the requirements are incomplete, several systems are involved, ownership is unclear, and reasonable engineers may disagree about the direction, what happens next? Does someone else still need to turn that uncertainty into a plan for them, or can they progressively create enough clarity for themselves and for the people around them? That does not make one kind of engineer more valuable as a person or even more useful in every organization. Teams need engineers who can execute difficult work extremely well, and not every problem benefits from expanding its scope or involving more people. Sometimes the most valuable thing an experienced engineer can do is take a well-understood problem and solve it reliably without creating unnecessary complexity. What became clearer to me is that increasing seniority often changes the shape of the responsibility more than the difficulty of the code. The code may still be hard, but more of the work happens before and around it: identifying what actually needs attention, discovering constraints, deciding what not to solve, bringing the right people into the conversation, making decisions without complete information, and creating enough clarity that other engineers can move independently. I do not think these interviews gave me a perfect definition of seniority. If anything, they made me more skeptical of simple definitions, especially when titles themselves vary so much between organizations. They did make me more precise about what I am trying to recognize. The question I keep coming back to now is less "How much does this person know?" and more "What kind of uncertainty can I hand them, and what happens next?" I suspect my answer to that will continue changing as I work with and interview more engineers. For now, that feels more useful than trying to draw a clean line between Senior, Lead, and Staff.