Careers
Build the tooling other engineers have to trust.
A build tool is judged on the day it is wrong. That constraint makes the work unusually concrete: cache correctness, exit codes, log classification, manifest integrity. There is very little room here for something that only works in the demo.
The work
What the surface actually is.
We are a small product team building Horu CLI and Horu CI. That means the interesting problems are not spread across twenty services; they are concentrated in a handful of places where being subtly wrong is expensive for someone else.
- CLI internals
- Go command surface design, flag ergonomics, configuration resolution, profile selection, and help output treated as a public interface.
- build engine
- Shared build modules used by both the CLI and the runner, target matrix resolution, and host compatibility filtering.
- cache correctness
- Key derivation, path-split entries, warm-workspace no-op detection, invalidation reasons, and hybrid behaviour alongside an Accelerator endpoint.
- log classification
- Turning Unity and Unreal output into collapse rules, failure anchors and remediation hints without hard-coding one studio's habits.
- runner operations
- Registration, leases, heartbeats, log streaming and artifact upload on machines with licensed engine installs that cannot simply be recreated.
- artifact integrity
- Sanitation rules, manifest generation, checksums, and the packaging boundary between a build output and a shippable package.
- evidence surfaces
- Build records, stage timelines, release candidates and gate evaluation in a Go service backed by PostgreSQL and S3-compatible storage.
How we work
Three things we actually enforce.
Documentation before implementation
Architecture and product decisions are written down and diagrammed before the expensive parts get built. It is why we can publish a status split at all: the gap between what is documented and what is implemented is something we already track internally.
Ownership with a boundary
You own an area end to end, including the decision to say no to a feature that would blur the product boundary. Autonomy without a stated boundary is just churn.
Direct, unpadded communication
Short reviews, specific objections, no ceremony around bad news. If something in the roadmap is wrong, the useful move is to say which part and why, early.
Fit
Who this suits, and who it does not.
Written plainly so nobody spends three interviews discovering a mismatch.
A good fit if
- You have opinions about exit codes, and can defend them
- You have debugged a build that only fails on one machine
- You would rather read a log format specification than a framework changelog
- You are comfortable shipping something honest and unfinished, with the status stated
- You want your work used by a small number of teams who will tell you exactly what is wrong with it
Probably not if
- You want a large, specialised team and a narrow slice of it
- You want product decisions handed to you as tickets
- You prefer greenfield rewrites to correctness work on something already in use
- You need a stable, mature codebase from day one; we are pre-1.0 and it shows in places
Terms
What we provide.
Stated as specifics rather than adjectives, because a benefits list of adjectives tells you nothing.
| Provision | Detail |
|---|---|
| Remote-ready setup | The tools and equipment to set up a productive home office, so working effectively from anywhere is the default rather than an exception. |
| Paid vacation | 25 paid vacation days per year, plus an extra day for your birthday, and flexible time off around key life moments. |
| Medical insurance | Comprehensive medical insurance plans covering you and your family. |
| Food allowance | A practical daily food allowance. |
| Training budget | Support for courses, workshops, conferences, certifications and practical skill development as your career changes shape. |
Applying
How to reach us.
Open positions are listed on our LinkedIn page when we have them. If nothing is listed, that means nothing is open right now: not that a good speculative message is unwelcome.
If you are writing speculatively, the most useful thing you can send is a short description of a build, packaging or CI problem you fixed properly, and what you would have done differently. That is more informative than a list of technologies.
Where we are
The team is set up to work remotely. Applications are read by the people you would work with, not by a filter.
Small team, unusually concrete problems.
Cache keys, exit codes, log taxonomies and manifests, for people whose deadline is a launch date.