Open role · Engineering

Backend Engineer, Distributed Systems

Own the storage and query engine underneath the data lake — the part that decides whether 300 TB a day is queryable in seconds or not at all.

What you’ll work on

  • Own the storage layer of the observability data lake: ingestion pipelines, segment layout, indexing, compaction and tiering across hot and cold storage.
  • Push the query engine: distributed planning and execution, predicate pushdown, vectorised scans, and the cost model that decides between them.
  • Hold the line on cardinality. Design the encodings, sketches and rollups that keep millions of series affordable rather than merely possible.
  • Build multi-tenant isolation that holds under load — quotas, admission control and backpressure that fail predictably instead of loudly.
  • Make correctness observable: consistency guarantees, replay and repair paths, and the tests that prove them before a customer does.

What we look for

  • Deep, hands-on experience with distributed data systems — a database, stream processor, search engine, time-series store or query engine you helped build and run.
  • Fluency in the fundamentals that decide these systems: consensus, replication, partitioning, consistency models and failure semantics.
  • A performance instinct grounded in measurement — you profile, you read the flamegraph, and you know where the bytes and the cache misses went.
  • Comfort in Go or Java at production depth, and willingness to work in either.
  • Engineers who operate what they build. On-call for your own system is part of the design feedback, not a chore bolted on afterwards.

Bonus

  • Internals of Apache Pinot, Druid, ClickHouse, Kafka, Flink, Lucene or Parquet — as a contributor or as someone who has debugged them in anger.
  • Columnar and time-series storage internals: encodings, compression, zone maps, bloom and inverted indexes, cache behaviour.
  • Query language and planner work — parsing, rewriting or optimising PromQL, SQL or something like them.
  • Observability, APM or monitoring domain experience.

How we work

  • Small team, short feedback loops, real ownership from week one.
  • You’ll talk to customers, engineers debugging real incidents, and that shapes what you build.
  • We ship, then iterate; bias toward hands-on building over process.
  • Modern tooling is encouraged, including AI-assisted development.

Other open roles.

Sound like the work you want to be doing?

Send us a note with anything you’re proud of building. We read every one, and we reply.