What Do Future Engineers Look Like?

This article was originally published on the Voze Engineering Blog and is republished here for posterity.

What do you look for in an engineer when that engineer is not the one writing most of the code? That question sent us back to our hiring rubric¹ early, as we reshaped our engineering process and organization around the agentic production of software. Two of the four criteria we used no longer have a score of their own. Because the rubric drives your hiring decisions, it is core to the future of your engineering organization.

Here is the rubric that we landed on and some commentary around what it means, and why we think it is important to the future of engineering at Voze. The six criteria below are the ones we use for all of our engineering hires now.

The New Rubric

System Thinking

Understands how their work fits into the bigger picture across teams, codebases, and the product. Can zoom from the 1000-mile view down to a single block of code. Architects for broad requirements, not just the immediate ticket, and considers second-order effects as well as observability, testability, and failure modes.

As we move farther up the ladder of abstraction as engineers, being able to think about systems as a whole becomes more important. It is also critical that engineers be able to reason through the complex interactions both inside a system, and inside the system that produced it. As the speed of code production increases, we have to deal with technical design issues next week that might not have appeared for months or years in the past.

Pragmatic Conductor

Knows the difference between ideal and reality and is comfortable with "good enough" to keep things moving. Sees ideas through to the end rather than throwing them over the wall. Builds simple, repeatable tools over one-off solutions. Considers how to de-risk changes, and plans for maintainability and long-term ownership.

Some of this bears echoes of Google's "The Standard of Code Review", in which they remind us all, "In general, reviewers should favor approving a CL² once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect." We function as conductors now, helping get code from initial authoring all the way out the door and into customers' hands. That is a broader mandate than just writing code, and core to our engineering process as we work with agents.

Culture Add

Do they have a bias toward action? Are they a dedicated learner? Do they enjoy tackling challenging problems? Are they collaborative?

This criterion is often fraught, often overemphasized, and often the source of toxic homogeneity within engineering teams. The name is deliberate. Culture add, not culture fit. Fit selects for the people you already have. "Add" asks what this person brings that the team is missing.

We also try to make clear that the attributes we are looking for are as measurable as possible by providing some guiding questions to answer. Each question is tied to an attribute that we believe is crucial both to an engineer's success here and to the success of the company.

Communicates & Shares Knowledge

Articulates problems and solutions clearly in writing, in code, and in conversation at any level of abstraction. Actively shares what they learn, listens as readily as they speak, and openly names their knowledge gaps.

Now that so much of our work happens alongside agents, and in pairs, clear communication becomes even more critical. This is one of four criteria we added in the rewrite. The ability of an engineer to communicate and collaborate with other departments to solve problems, as well as their ability to listen and share, is critical in our minds. So much more of the job happens in human-shaped communication than it used to.

Ownership

Takes end-to-end responsibility for the solutions they produce. Understands how to balance desired outcomes effectively, making speed, debt, and quality tradeoffs well. Is comfortable owning the quality of what they produce.

Ownership has always been a core element of what we look for in engineers, but it changes shape in a world where you didn't author the code. Do they take responsibility for what they ship? Do they track down issues willingly? Are they comfortable being responsible for the positive, and negative, outcomes of their decisions? Do they stick with the issue until find the solution?

Leadership / Bar Raiser

What aspect of the engineering team’s work would this person be the “go-to person” for?

When you are hiring, you are hiring to fill a gap in your organization. This criterion is a final check on whether this person will fill that gap. Is there something they bring to the organization that we are missing? It's not about whether they will be a manager of people. It is about whether they can be an informal owner, a peer leader within the team.

What We Dropped

What hides behind a new rubric is what stopped being scored. Some of the criteria we used to weigh heavily no longer stand on their own, and have been folded into others. That is because the scope of what we look for in an engineer changed.

For instance, Technical Ability and Problem Solving. Together these two were half of our rubric, and I often spent more than half of my interview time evaluating them. They focused on the ability to solve problems in code, and produce good-quality code, key skills of the software engineer of the past. Now they are folded into the System Thinking and Pragmatic Conductor criteria.

The initial response to seeing this change could easily be "They believe writing code isn't an important skill for a software engineer to have!" and I could have written a great clickbait title. But that overstates it a bit. We still believe it is an important skill. We just no longer believe it is important enough to warrant 50% of the rubric. Technical excellence alone is not enough in this evolving landscape.

Where This Leaves Us

No rubric can measure the totality of an individual, but for our interviewing team, this rubric keeps us focused on the attributes that we believe are important for our engineers. It pushes out some of the subjectivity, producing relative consistency over time as we onboard new interviewers, and as we interview more people.

It also shows us where engineers in our organization need to grow, so we can coach them, and where they are already doing exceptionally well.

Go look at your own rubric. If it still scores what it scored before agents started writing your code, it is describing a job your engineers no longer have.

If you enjoyed this article please share it! I also have a newsletter that you might enjoy as well. Thanks! -Daniel