Hiring Philosophy
Hiring engineers based purely on technical skills never felt sufficient to us.
Of course, an engineer needs to be good at engineering. But when we started thinking more deeply about the people we wanted to work with, we realized that knowing a programming language, framework, or even having strong system-design knowledge was only one dimension.
So we started looking at companies we admire and asking a broader question:
What characteristics do great technology companies actually value in their people?
We looked at companies including Apple, SpaceX, Airbnb, Stripe and others. We weren't interested in copying another company's culture. These companies have different products, organizational structures, histories, and ways of working.
Instead, we wanted to understand the patterns behind them and then decide what mattered for the kind of engineering organization we wanted to build.
Engineering Excellence
Technical excellence remains the foundation.
We value engineers who can understand difficult problems, design appropriate solutions, reason about trade-offs, and build software that remains understandable and maintainable as it grows.
But we don't define engineering excellence by knowledge of a particular technology.
Frameworks change. Languages change. Infrastructure changes. The way software itself is created is changing rapidly with AI.
Strong fundamentals and engineering judgment have a much longer lifespan than knowledge of the tool that happens to be popular today.
Product Builder Mindset
We also realized that we value engineers who think like builders.
There is an important difference between implementing requirements and understanding why something should exist in the first place.
A product-oriented engineer is curious about the problem behind the feature. They notice opportunities. They experiment. They think about what could be built, not only what has already been specified.
This doesn't mean every engineer needs to be an entrepreneur.
It means we value the instinct to connect engineering with creating something useful.
Customer Orientation
That naturally connects to another principle: customer orientation.
Software doesn't exist in isolation. Someone eventually needs to use what we build.
We therefore value engineers who are interested in understanding the actual problem behind a customer's request.
Sometimes good customer orientation means challenging what has been requested because there is a better solution.
Sometimes it means recognizing that the technically most elegant solution isn't necessarily the right business decision.
And sometimes it means realizing that the customer knows something we don't.
Strong engineering judgment and customer orientation shouldn't compete with each other. The best decisions usually require both.
Future-Oriented Thinking
We also want people who are interested in where the industry is going.
This has become particularly visible with AI.
Software engineering today already looks different from software engineering a few years ago, and we expect that pace of change to continue.
We value engineers who experiment with new tools, observe changes in the industry, develop opinions about where things are going, and continuously reconsider which skills will matter next.
The goal isn't to predict the future correctly.
It's to avoid becoming intellectually anchored to the present.
Team Stewardship
Individual engineering ability matters, but companies aren't collections of independent programmers.
They're teams.
We value people who make the people around them more effective: engineers who share knowledge, support colleagues, communicate clearly, give useful feedback, and are equally comfortable asking for help themselves.
This is why we use the word stewardship rather than simply teamwork.
It implies some responsibility for the environment around you.
A strong engineer shouldn't only leave the codebase better than they found it. Ideally, they leave the team better too.
Intellectual Flexibility
As we developed our framework, one characteristic became increasingly important to us: intellectual flexibility.
Technology is full of strong opinions.
Monoliths versus microservices. SQL versus NoSQL. One framework versus another. Build versus buy. Move quickly versus invest in architecture.
Having opinions isn't a problem. In fact, good engineers should develop strong opinions through experience.
The problem appears when opinions become identities.
We value people who can defend an idea strongly while remaining capable of changing their position when better evidence appears.
For us, this characteristic became more than another desirable quality.
It is foundational.
A person can be extremely knowledgeable today, but if they cannot update their thinking, the value of that knowledge gradually decreases as the world changes around them.
That's why intellectual flexibility carries particular importance in how we think about hiring.
Continuous Improvement
The final characteristic is a continuous improvement mindset.
Some people naturally notice things that could work better.
A piece of architecture is unnecessarily complicated. A deployment process is repetitive. Documentation is missing. Onboarding takes too long. A development workflow creates unnecessary friction.
We value engineers who don't automatically accept these things as permanent.
Not every improvement needs to become a large initiative. Often the most valuable improvements are small changes made consistently over time.
What matters is the instinct to leave things better than you found them.
Where We Ended Up
Eventually, these discussions converged into seven dimensions:
Engineering Excellence — strong technical fundamentals and engineering judgment.
Product Builder Mindset — thinking beyond implementation toward what should be built and why.
Customer Orientation — understanding the people and businesses behind the software.
Future-Oriented Thinking — remaining curious about where technology is heading.
Team Stewardship — contributing to the growth and effectiveness of the people around you.
Intellectual Flexibility — having strong opinions without becoming trapped by them.
Continuous Improvement — consistently looking for ways to make products, systems, teams, and yourself better.
None of these ideas is particularly revolutionary on its own.
What became useful for us was making them explicit.
Instead of saying that we want "great engineers," we had to define what great actually means for us.
And that definition extends considerably beyond writing good code.
Our Hiring Philosophy Will Keep Changing
This isn't intended to be a permanent manifesto.
The industry will change. Our company will change. The kinds of problems we work on will change.
Our definition of a great engineer will probably evolve with them.
That is actually consistent with the philosophy itself.
If we value continuous improvement, future-oriented thinking, and intellectual flexibility in the people we work with, we should expect exactly the same qualities from the company we're building.