T-shaped full-stack product problem solvers
Historically, we’ve always hired “full-stack” engineers. But it would be more accurate to say we are looking for “T-shaped full-stack product problem solvers”.
Let’s define all of this and see why and how we apply it to Alan.
Note: In the rest of this article I will use the word “engineer”, but you can use it interchangeably with “developer”, “coder”, “SRE”, etc.
Problem solver — and not executant
We are looking for people who want to solve problems. For us, being an engineer means more than “just” coding. It’s about taking a problem and finding the best solution considering the context. Most of the time the solution involves programming and developing. But we expect our engineers to be able to take a step back and think of other solutions as well. Sometimes an excel spreadsheet is a simpler solution than a custom admin tool, or not coding is better than adding a new feature.
Product — and not software
We are looking for engineers that want to solve problems for our members by providing them the best experience with our products. We think being a “product” engineer encompasses more than “just” software. A product engineer thinks first and foremost about the value they will add to the company and the members. We do work on complex technical topics, but only if they solve actual problems and bring value for Alan.
Full-stack
A full stack engineer is an engineer who can introduce a bug to every layer of the software stack.
This is very true. I confess, I myself have broken all of our backends, frontends, and mobile apps. Multiple times.
And we want engineers who are willing to do the same! We think it brings a better end value to think of problems and solutions holistically. In other words, this implies considering our stack as an entire system rather than breaking it down into individual systems. As an engineer at Alan, you are encouraged to work on the whole stack: mobile, front-end, backend, infrastructure, etc.
This doesn’t imply you need to be an expert on every part of it, only that you are willing and able to work on any of it. This mindset pushes us to help engineers achieve what they need without bothering them with the technical details. You can read more on this part in our “pit of success” article.
T-Shaped
In reality, we value “specialists that masquerade as generalists”, which Valve, in its famous handbook, calls “T-Shaped” people. They are people who are both generalists and also specialists. They are proficient at a broad range of skills — the horizontal bar of the T — and they also are specialists in a field — the vertical leg of the T. For example, I do front-end development, backend, and infrastructure. And I can also lead a team, run interviews, etc. I know I’m far from the best on most of those topics, and my specialisation is more on coding.
Why? I think Valve sums it up very nicely:
An expert who is too narrow has difficulty collaborating. A generalist who doesn’t go deep enough in a single area ends up on the margins, not really contributing as an individual.
Conclusion
To sum it up, we are more interested in a mindset and less in hard technical skills. Most of our engineers had never used Python nor React before joining Alan. Does this interest you? Come join us!
