We have five open roles at Serac Labs. CTO, founding platform engineer, frontend/TUI engineer, developer advocate, and a design hire that’ll be the only design hire for at least a year. The first technical screen for every one of them is the same: ship something to the public repo, or to a fork of it, that we can run.

Not a take-home assignment. Not a fake codebase we made up. A real change to actual Serac code, on the actual GitHub repository, that does something you care about. A bug fix. A connector improvement. A documentation patch that closes an issue. A failing test you turned into a passing test. Whatever shape — but it has to be runnable and it has to be in the public repo.

If you can’t do that step, the rest of the interview process doesn’t kick in. Not because we’re being cute, but because the rest of the process is calibrated on people who already cleared this bar, and inserting candidates who haven’t would make the comparison meaningless.

Why no take-homes

Take-home assignments are a tax on the candidate’s time that produces minimal signal. The candidate spends a weekend solving a problem we already solved. We read the solution. It tells us the candidate can solve the problem we already solved. We hire them and they spend six months learning the actual codebase, which looks nothing like the take-home.

The public-PR approach has the opposite shape. The candidate spends however much time they want — fifteen minutes for a typo fix, three days for a connector improvement — solving a problem we didn’t already solve. The PR tells us how they read unfamiliar code, how they make architectural decisions in a real codebase, how they write commit messages, how they respond to reviewer feedback.

A typo fix is a real signal, by the way. It tells us the candidate read the docs carefully enough to spot the typo. It tells us they were willing to file the smallest possible PR rather than waiting for something “worth our time.” That’s culturally useful. Most of the people who file a typo PR also have a bigger PR queued up; the typo was the warm-up.

Why no whiteboard algorithms

Most of the work at Serac Labs in 2026 is not algorithmic. It’s:

  • Reading the ServiceNow sys_dictionary table and figuring out which fields actually matter for a specific operation
  • Writing a connector that handles the seventeenth edge case of how update sets serialize a scoped artifact
  • Designing a tool contract that the LLM will reliably call correctly without 600 lines of prompt engineering
  • Debugging an async business rule that fires after the transaction commits and breaks the agent’s predicted state
  • Writing CSS that respects the design tokens and doesn’t introduce a fourth border-radius value

A candidate’s ability to invert a binary tree on a whiteboard tells us roughly nothing about their ability to do this work. We’ve worked with senior engineers who can reverse a linked list in their sleep and cannot read an unfamiliar codebase to save their lives, and we’ve worked with engineers who can’t tell you the time complexity of quicksort but who can land a fix to a 14,000-line file in 90 minutes.

We optimize for the second group.

What we actually look for

Three concrete things, in order of how much they matter:

One: You’ve debugged a P1 in production at 11pm and you have opinions about idempotency. This sounds glib but it’s not. The candidates we hire have a specific posture toward production: cautious, methodical, biased toward reversibility, allergic to “let’s try it and see.” That posture is hard to fake and impossible to teach. It comes from having been the person responsible for fixing the thing, not just shipping it.

Two: You read code before writing code. When we send candidates a real bug from the issue tracker, we watch what they do. The strongest ones spend 45 minutes reading before they touch a line. They follow the call chain through three or four files. They check git blame. They read the PR that introduced the bug. They understand the historical reasoning before they propose a fix. The weakest ones start typing in the first five minutes.

Three: You have opinions, and you can defend them, but you change them when shown new information. ServiceNow has a culture of “the way it’s always been done.” We’re trying to build a different one — but the way to build it isn’t to dismiss the existing one. The strongest engineers we’ve worked with hold strong views loosely. They’ll tell you their design is wrong faster than you can.

What the roles are

Five roles, each owns a domain, none of them is “general engineer”:

CTO. Co-leads engineering with me. Owns the runtime architecture long-term, the technical hiring bar, and the relationship with the open-source community. Probably someone who’s run a 10-50 person engineering org before, or who’s been the principal engineer at a place where the principal was actually responsible for decisions. Has to be in Amsterdam at least 50% of the time in the first year.

Founding platform engineer. Owns the agent runtime, ServiceNow connectors, deterministic-trace pipeline. Lives in TypeScript end-to-end. Strong Postgres, strong understanding of async systems, strong opinions on idempotency. Will be the second-most-senior engineer in the room for the first year.

Frontend/TUI engineer. Owns the dashboard and the terminal UI. Astro, SolidJS, plus the TUI work in our serac CLI. Reads pixel diffs. Will be the only person who reliably notices when a focus ring is two pixels off. Has to actually care about CSS, not just tolerate it.

Developer advocate. Lives in the public repo. Writes the changelog. Runs the Discord. Ships docs that don’t lie. Has shipped on ServiceNow before — this is non-negotiable. The DevRel role at a ServiceNow tools company is impossible to do well if you’ve never built a Flow Designer integration that broke in production.

Design. Owns the visual system, the marketing site, and the product UI’s principles. Will work closely with the frontend engineer but is responsible for the design language, not just the screens. We have a starting visual system in place. The first big project is to extend it to the agent conversation surface, which is where the real product UX work lives.

What we offer

Founding-team equity, real numbers, transparent vesting. Salary that’s competitive with the senior end of the Amsterdam market for the role, but not with the FAANG sticker rate — we’re not playing that game and we don’t want candidates who are.

Full ownership of a domain. The platform engineer is the platform engineer. There’s no second one waiting for them to leave. There’s no shadow architect grading their PRs without commenting. You own the thing.

A small team — five to eight engineers in year one, ten to fifteen by end of year two. Everyone is in the public repo. Every commit you ship has your name on it, in public, forever.

Amsterdam-based with a flexible remote arrangement. We have a small office in Amsterdam Centrum. Most of the team comes in two or three days a week. The CTO role specifically benefits from being in the room with me regularly; the engineering roles are more flexible.

A working environment that values shipping, not theater. We don’t have ceremonies. We don’t have OKR cycles. We have a roadmap, an issue tracker, a Discord, and a weekly Friday review where someone walks the team through what they just shipped. That’s the shape of the org for the first year.

What we don’t offer

This is the part most companies leave out and we’ll put it up front:

  • No free lunch, no snacks, no espresso machine. We have water and coffee. The office is good. The chairs are good. There is no perks budget because perks budgets are a tax on people who don’t want them and a recruiting prop for people who don’t actually use them.
  • No ping pong, no foosball, no in-office gym. If you need to work in an office that feels like an undergraduate dorm with a stipend, this isn’t it.
  • No 30-person engineering org by 2027. We’re aiming for the team to stay small for a long time. If your career goal is to manage 12 people in two years, we’re the wrong company.
  • No US presence. Not in 2026. Probably not in 2027. The company is in Amsterdam, the product is targeted at the ServiceNow developer community globally, but the team is European-headquartered and that won’t change soon.
  • No equity refresh culture. The founding grants are real and meaningful. After that, we’ll do small refreshes tied to specific achievements, not annual escalators. If you’re optimizing for repeated equity grants, you’ll be happier elsewhere.

We mention this stuff because the wrong candidate will figure it out three months in and resent it. The right candidate is already nodding at point three.

How to apply

The public-PR step is the actual first step. There’s no recruiter screen ahead of it. There’s no application form. You send an email to [email protected] with:

  1. The PR or fork link
  2. A short paragraph (genuinely short — three sentences is fine) on what role you’re interested in
  3. A pointer to two or three pieces of your work we can look at, public or private (private is fine if you describe what they are)

That’s the entire application surface. If your PR is good, you’ll hear from me in two or three days for a 45-minute call. If the call goes well, you’ll do a paid two-day work session with the team — real work, real codebase, paid at the role’s day rate. After that, we make a decision and tell you in five business days.

The whole process is meant to take three weeks. If it takes longer, that’s a signal we’re not ready to hire, and we’ll tell you.

The pattern

Hiring is the most consequential thing a small company does. We’ve watched founders hire people they couldn’t really evaluate and then spend a year learning that the new hire was the wrong fit. We’ve also watched founders run six-month interview gauntlets and lose every good candidate to companies that decided in two weeks.

The middle path is to find a signal that’s cheap for the candidate, expensive to fake, and predictive of the work. Public PRs are that signal for the kind of company we are. The rest of the process is calibration around it.

If you’ve read this far and the shape of it sounds right — open a PR. We’ll see it.