Granule·Labs

Open role

Senior Data Engineer

Granule Labs · Minneapolis, MN or Seattle, WA · Full-time

The basics

Out of the way up front, so the rest of this can be about the work.

Ensuring a response

Follow the criteria below and you WILL communicate with a human. :-)

Compensation

$140,000 – $165,000 base, depending on experience. Eligible for an annual performance bonus and other benefits.

Location

Minneapolis, MN or Seattle, WA. Some client travel; it varies by engagement.

Education

Bachelor's degree in computer science, engineering, or a related field, or equivalent practical experience.

About the role

The core engineering work. Engine selection, sort key and partition design, materialized views, ingestion and integration paths, and the compression work that produces the cost result.

It is a heads-down engineering role and we mean it — most of your week is schema, query plans, and pipelines, on data large enough that the decisions actually matter. It is not a hidden role. You work in the open beside the client's engineers, you explain what you are doing while you are doing it, and you are the reason their team can run the thing after we leave.

Heads-down, with a personality.

You will carry a small number of clients at a time and move between their systems rather than living inside one. Different industries, different data shapes, different environments — several times a year instead of once a decade.

About you

The last time a query got slow, your first move was the plan, not the instance size. You have also been in the room where the org chose the instance size, and you remember what that cost.

You love working with people, not managing them. We are not going to make you. The ceiling on this track is depth, not headcount.

Nearly all of your time will be on client work, building. Some engineers hear that and hear a consultancy treadmill. You hear the part of the job you actually like — in the repo, with your team and the agents, on systems you would not otherwise get near.

You have proposed a design the room disagreed with, made the case with measurements instead of seniority — and changed your own mind when the numbers went the other way.

You keep pulling the thread after the ticket is closed, because you want to know what the answer actually was.

You can tell a client bad news calmly, without softening it into something they will misread.

If this list made you nod instead of wince, then you should apply!

What you'll own

The physical design

Sort order, partitioning, index granularity, projections, and skip indexes, chosen against the real query shapes — and the compression that follows: per-column codecs, LowCardinality, Delta/DoubleDelta/Gorilla, dictionaries, and TTL tiering. Measure the ratio before and after, and defend the trade you made.

The data model

Denormalization, wide tables, dictionaries, and the specific cases where a join is still the right call.

The ingestion and integration path

Kafka into the serving tier, the right delivery semantics for the case, backfill and replay without a maintenance window, and the seams with everything else the client runs.

Precomputation that holds

Materialized views as insert triggers, aggregating and replacing merge trees, and the discipline to keep them consistent with what they summarize.

Query optimization

Read the plan, read the system tables, find what the machine is actually reading, and make it read less. Adding hardware is the answer of last resort.

Migrations at scale

Dual-write, backfill, verification, cutover, rollback plan. Decades of history and no window to hide in.

The platform as code

Terraform, matching environments, migration review, and benchmark gates in CI. If it is not reproducible it is not done.

Teaching while you build

Client engineers sit next to you. When we go, the thinking stays.

The table stakes

Skills and experience get you in the room. What is above is what gets you the job.

  • 7+ years in data engineering, on systems where scale was the actual problem — terabytes and up, billions of rows, cardinality nobody planned for. Including at least one large migration you personally delivered, off Elasticsearch, Postgres, Snowflake, Redshift, Druid, or a vendor observability platform.
  • ClickHouse in production — or something very close. Sort keys, MergeTree family, materialized views, mutations, distributed tables, and the operational reality of merges and replication. An adjacent engine (Druid, Pinot, StarRocks, Doris) can count, but you need to arrive fluent in this class of system.
  • Analytical data modeling. Dimensional and denormalized design for OLAP, slowly changing dimensions, event and telemetry schemas, and late or out-of-order data. The single most important skill in this role.
  • Expert SQL. You can read an execution plan and explain why it is bad. Strong Python; one of Go, Rust, Java, or C++ is welcome.
  • Kafka in production at real volume. Partitioning, consumer groups, backpressure, ordering, and delivery guarantees. Equivalent depth in Pulsar, Redpanda, Kinesis, or Flink counts.
  • Systems and infrastructure fundamentals. Linux, memory and I/O behavior, object storage; AWS, GCP, or Azure; Terraform, Kubernetes, CI. Enough performance instinct to know where the time is going.
  • Daily, working use of AI tooling. Coding agents and assistants in your actual workflow, with real judgment about when to trust, verify, or discard what they produce. Be ready to describe specific engineering work you completed with AI assistance and where it was wrong.
  • You write things down. Design notes, runbooks, and commit messages that explain the why.

What sets you apart

Mention any of these that apply.

  • ClickHouse contributions, issues filed with a reproduction, or a fork you had a reason to build.
  • Observability engineering — OpenTelemetry, Vector, ClickStack, Grafana, log and trace schema design at volume.
  • Semantic layer work: Cube, dbt Semantic Layer / MetricFlow, or metric definitions that agents consume.
  • Governance implementation in an OLAP store: row policies, column masking, quotas, scan and spend limits, multi-tenant isolation.
  • Engine-level work: C++ or Rust in a database, storage engine, or query executor.
  • Public work — talks, a technical blog, benchmarks you published and defended, a GitHub profile with something real in it.
  • Consulting or professional services background, and comfort with the pace it demands.
  • A performance result you are proud of, with the number attached.

Apply

careers@granulelabs.ai. Send us three things:

  • Your resume, covering the items above.
  • A note on any criteria you do not meet, and why you are worth talking to anyway.
  • A query plan you fixed, or a schema change that moved the number.

That is worth more to us than a cover letter.

How we hire

Hiring is the most important thing that we do; our product is our people, who develop our offerings and deliver for our clients.

If your resume shows you meet most of what a posting asks for, you tell us plainly why you do not meet the rest, and you can describe a system you built that resembles what we build — you will communicate immediately with a human.

Four steps after that:

  1. Human phone screen

    A real conversation about your work, not a checklist read back to you.

  2. Technical screen

    A short assignment, a live technical screen, or an online coding exercise, depending on the role.

  3. Deep dive with the CTO

    Architecture, tradeoffs, and the decisions you have had to defend.

  4. Final conversation with the CEO

    How you work with clients, and whether this is the right place for you.

Then an offer. We aim to be done quickly and to tell you where you stand at every step.

If your experience does not line up exactly with a posting, apply anyway. We would rather read your note than have you screen yourself out.