Software engineering experience hierarchy

When hiring software engineers, you can evaluate their experience and skills from several angles:

• Software domain

• Technology stack

• Business domain

Some of these are more important than others, depending on the role.

I’ve been thinking a lot about how to prioritise these factors when evaluating engineers.

Here’s how I weigh each of them.

Software domain

By software domain, I mean the part of the system an engineer specialises in: frontend, backend, infrastructure, etc.

To me, experience and skill in a specific software domain carry the most weight when hiring an engineer.

First, it takes the most time and effort to develop deep proficiency in this area compared to other aspects.

And second, because each domain has its own architecture, design patterns, and best practices. Frontend and backend development involve different tools, frameworks, and mental models.

There’s limited transferability between them.

A strong backend engineer won’t automatically be effective on the frontend, and vice versa.

Technology stack

The next layer of experience is technology.

In other words, the languages, frameworks, and platforms an engineer uses within their software domain.

For example:

• Backend: AWS, Go, PostgreSQL

• Frontend: React, Next.js, Redux

While the tech stack is important for faster onboarding and quicker time to productivity, for me, it carries less weight than software domain experience.

Most of the experience and competence gained in one tech stack is transferable to another stack.

General software engineering principles are technology-agnostic.

Business domain

Last in my list comes the industry context, such as FinTech, HealthTech, or InsurTech.

In my opinion, prior experience in a specific industry tends to have the least impact on engineering performance.

I see the ability to elicit and understand requirments as the core of a software engineer's competence.

Strong engineers excel because they are skilled in requirments gathering, not because they’ve worked in the same industry before.

That said, familiarity with compliance frameworks and regulations in highly regulated sectors (like finance or healthcare) can be valuable. However, this type of knowledge is often easier to acquire than gaining competence in the software domain or tech stack.

I don’t say that’s the best way to evaluate engineering experience.

But it helps to be aware of the weight you assign to the aspects of the engineering experience.

So you can focus on things that predict performance in the role and not over-index on factors that don’t.