Skip to content

people.md

Latest commit

 

History

History
73 lines (45 loc) · 4.27 KB

people.md

File metadata and controls

73 lines (45 loc) · 4.27 KB

People

We're a small team and we intend to stay that way. Every person we add either raises the bar or lowers it. There's no neutral.

What We Look For

Engineers Who Ship

The single most important trait is the ability to take a problem and turn it into working software in production. Not in a sandbox. Not in a PR that sits for two weeks. In production, where users interact with it.

This means you can:

  • Read a codebase you've never seen before and contribute within days
  • Make technical decisions without waiting for someone to tell you what to do
  • Write code that other people can understand and maintain
  • Debug production issues under pressure
  • Know when something is good enough and when it needs more work

Systems Thinking

You understand that software doesn't exist in isolation. A function call becomes a network request becomes a database query becomes a disk write. You think about failure modes, latency, data consistency, and what happens when the thing you depend on goes down.

This doesn't mean you need to have built a distributed database. It means you understand why your choices matter beyond the scope of the file you're editing.

Ownership

You don't wait to be assigned work. You see what needs to be done and you do it. If something is broken, you fix it. If the documentation is wrong, you update it. If the deploy is failing, you investigate.

Ownership also means knowing your limits. Asking for help isn't weakness — it's efficiency. Silently struggling for two days on something a teammate could have unblocked in ten minutes is not ownership. It's pride.

Clear Communication

Remote, async work only functions if people can communicate in writing. This means:

  • Your PR descriptions explain why, not just what
  • Your messages are specific enough that someone can act on them without a follow-up call
  • You surface problems early instead of hoping they resolve themselves
  • You can explain a technical decision to a non-technical person when needed

How We Evaluate

We don't do whiteboard interviews. We don't ask you to invert a binary tree. We don't care about your degree.

Our process:

  1. Conversation. We talk about what you've built, what you're interested in, and how you think about problems. This is mutual — you're evaluating us too.
  2. Code review. We look at code you've written. Open source contributions, personal projects, anything public. If you don't have public code, we'll give you a small take-home problem that's relevant to real work we do. Not a trick question. Not a time-boxed pressure test.
  3. Paid trial. For roles beyond freelance, we do a short paid engagement on a real project. This is the best signal for both sides. You see how we actually work. We see how you actually work. No amount of interviewing replicates this.

We value depth over breadth. We'd rather hire someone who deeply understands one language and one problem domain than someone who has surface-level experience with ten frameworks.

Growth

We don't have career ladders with ten levels. We have two expectations:

  1. Get better at your craft. Read code. Write code. Study systems. Contribute to open source. Go deeper on the things you're good at. Get competent at the things adjacent to your work.
  2. Share what you learn. Write about it. Review someone else's PR thoughtfully. Mentor when you can. The best way to solidify your own understanding is to explain it to someone else.

We support growth through:

  • Paid time for open source contributions
  • Conference attendance
  • Book and course budgets
  • Real projects that stretch your abilities (not busywork)

There's no forced growth plan or quarterly performance review. If your work is good, you'll know. If it's not, we'll tell you directly and help you get there.

What We Don't Tolerate

  • Ego over outcome. We don't care whose idea it was. We care whether it works.
  • Gatekeeping. Knowledge hoarding, dismissive code reviews, or making people feel stupid for asking questions. We're a team, not a hierarchy.
  • Excuses over accountability. Everyone makes mistakes. Own them, fix them, learn from them. Don't blame the tooling, the requirements, or someone else.
  • Mediocrity by choice. It's fine to not know something. It's not fine to not care about learning it when it's part of your job.