We’re hiring engineers who are excited to build the next class of engineering primitives, starting with queues, background tasks and durable execution. We started in early 2024 after launching our distributed task queue on Hacker News; since then we’ve raised a $5.7M seed round and launched our durable execution platform in mid-2025.
Hatchet is currently used by thousands of engineers for all kinds of workloads: log ingestion pipelines, code review agents, video encoding, GPU scheduling, the list goes on. Our target customer is fast-growing startups (which may or may not be AI companies) who have a strong need for background jobs system.
Who we’re looking for
We’re looking to work with engineers who are humble, ambitious, curious and kind. Some things that we’re looking for in particular are:
-
Motivated by difficult problems. Our day-to-day is working on distributed systems, high-throughput workloads, and scaling infrastructure to keep up with demand.
-
Eager to learn about new technologies, frameworks, and stacks; this doesn't mean that we go crazy in using new technology in our stack (we're quite practical), but we're always learning.
-
Excited to help others. Particularly other engineers on the team and users (who also tend to be engineers!)
-
Passionate about open source, developer experience, best-in-class developer tools, or reliable + fast infrastructure.
-
Enjoy communicating or writing about engineering.
TL;DR - we’re a team of software engineers building and writing for other software engineers.
What you’ll build
There are two priorities at Hatchet: reliability and incredible developer experience. Everything that we build feeds into these two focuses; we’ll often spend weeks optimizing part of our infrastructure to allow it to serve users more reliably. We’ll also spend weeks rewriting or rebuilding our SDKs to make them a better fit for developer workloads.
We obviously also build a ton of new features, some things that we have planned for 2026 are:
- Vastly improved observability, allowing for full tracing and log support across every workflow and task that’s run in Hatchet.
- (Re-)launching our managed worker runtime, which allows users who are onboarding or deploying a small application to host workers on Hatchet. We have a current version of this deployed across a set of users and running on Fly.io, but we have lots more to do before we expand usage on this product.
- A Hatchet CLI for easy local development, and eventually allowing users to set up automations like listing and replaying failed tasks.
Working at Hatchet
Our founding team is comprised of two second-time YC founders and two founding engineers. We’re remote-first but have an office in NYC if you’d prefer to be in-person.
We tend to avoid symbolic or arbitrary process and we intentionally want to keep the team as small as possible.
Working hours
Our philosophy is to maximize productive working hours. To accomplish this, we want everyone showing up each day feeling rested and motivated. This means that we care deeply about health and well-being of everyone on the team, and we don’t expect you to work weekends or late into the night. For most team members, this usually means 8-9 hours of highly productive working hours, Monday-Friday.
Support and on-call
Everyone in the company shares in support and helping our users (engineers) wherever we can. As an infrastructure company, we do 2-week on-call rotations. Part of the reason we focus on reliability as part of our core product work is that we can avoid getting paged constantly or overnight because systems are down, but it does happen occasionally.
Do I need to know Go, Postgres or Kubernetes?
No. If you’ve read this far, please share a personalized message explaining why you’d be a great fit for Hatchet! If it seems like a good fit, we’d love to chat with you.
Note: due to the large volume of AI-generated messages, we can’t guarantee that we’ll respond to every message. We apologize for this, and we’ll do our best to respond to all personalized messages.
Hatchet
