What We Look for When Hiring Engineers

What we do not filter on

We do not require a specific degree. We do not require a minimum number of years of experience. We do not require experience with a specific tech stack. We do not require you to have worked at a brand-name company.

This is not a philosophical stance. It is a practical one. In our experience, none of these things reliably predict whether someone will be good at the kind of work we do.

What we actually look for

Three things.

Evidence of building

Show us something you built. It does not need to be a startup or an open source project with thousands of stars. It could be a side project, a tool you made for your team, a contribution to someone else’s codebase, or a system you designed at a previous job.

What we care about is the gap between “I had a problem” and “I shipped a solution.” If you can walk us through that journey clearly, that tells us more than any resume.

How you think about problems

We will ask you to describe a hard technical problem you faced and how you approached it. We are not looking for the “right” answer. We are looking for the reasoning:

• How did you figure out what the real problem was?
• What options did you consider?
• What tradeoffs did you make?
• What would you do differently now?

People who have actually solved hard problems can answer these questions in specific, concrete terms. People who have not tend to speak in generalities.

Ownership instinct

We are a small team. There is no layer of project managers between you and the work. When something breaks, you fix it. When something is unclear, you figure it out. When something needs to be built, you build it.

This is not about working long hours or being “always on.” It is about caring whether the thing you shipped actually works for the people using it. Some people find this energizing. Some people find it exhausting. We are looking for the first group.

How the process works

1. You send us an email at [email protected] with your name, links to your work, and a short writeup about a hard problem you solved.
2. We review it. If it is interesting, we schedule a conversation.
3. The conversation is not a whiteboard interview or a leetcode session. We talk about what you have built, what you want to build, and whether working together makes sense.
4. If we both want to move forward, we may do a short paid trial project to see what working together actually feels like.

The entire process is designed around one question: can this person build real things that work?

Current openings

We are currently hiring for three roles: Core Systems Architect, Product Engineer, and Technical Generalist. Details are on our careers page.

If you are not sure which role fits, apply anyway and tell us what you are good at. We are small enough that roles flex around the people in them.