Senior DevOps Engineer

Part 2

• Tech Lab

Senior DevOps Engineer

Build a company's entire delivery platform from the first commit, own it outright, and never carry a pager. Both halves of that sentence are deliberate.

• Barcelona
• on site
• Open
• 1 seat

What you own

• 01 Infrastructure-as-code, from zero
• 02 CI/CD and the release path
• 03 Secrets management, including for agents
• 04 Observability, backup and a tested restore

In Your First Few Months You Will

• Build the platform from code. Hosts, networking, ingress, access, environments — committed, parameterised, reviewable. It is the cheapest moment this will ever be done, and you get to do it properly instead of retrofitting it.
• Make deployment self-serve. Today, shipping an existing app is a git push; standing up a new one needs admin rights and two undocumented footguns. That gap is yours to close, down to one command, so a developer never holds a platform credential.
• Own secrets properly. A real machine secrets manager, and — because we run a lot of AI agents — credentials brokered so an agent process only ever holds a placeholder, never a key. If you have opinions about how you stop a prompt-injected agent leaking a production credential, you will enjoy this part; almost nobody gets to design it from scratch.
• Prove the restore. We have a written standard that says "someone deploys it" is not "someone has proven the restore works." You will run the drill and write the report.
• Build the release path. Commit to production, an automated test gate, per-branch preview URLs a stakeholder can open from their phone, and a rollback that everyone on the team has rehearsed before they need it.
• Then keep it all running — and keep making it duller. Observability, cost caps, dependency hygiene, the unglamorous work that decides whether a small team can own a lot of products.

And you will have the authority to match.

You are not inheriting a platform. You are writing one.

There is no infrastructure-as-code in our estate today — not a line. Your first job is to make that permanently untrue: every environment we run reproducible from a committed repo, from your first week, before the habit sets.

No rota, no pager, no phone number, no "just keep an eye on it this weekend". We are telling you this up front because it is not a perk we are quietly hoping you will waive.

Here is the honest other half, and it is the actual job:

We can only make that promise because we protect ourselves with engineering instead of with people's evenings — and that engineering is what we are hiring you to build. Infrastructure as code, so a lost machine is rebuilt rather than resurrected. Backups with a restore we have actually tested. A rollback that is one click and that everyone has already practised. Alerting that queues instead of paging, because nothing on the other end of it is expected to answer at night.

So the trade is explicit:

You are never woken up, and in exchange the systems have to be genuinely recoverable. If you have spent a career being paged for things that should have been engineered away, this is the version of the job where you get to do the engineering instead.

During working hours it is the opposite of hands-off.

The PO, the developers and the DevOps engineer assigned to a product own that product's incidents — support is not shipped off to a separate team, it is part of owning the thing, and it is what keeps everyone honest about quality.

How we build — deliberately boring, and you get a say in it

We have a settled stack and it is the same in most repos on purpose: one scaffold, shared packages, push-to-deploy. The payoff is that a two-person team can pick up a product they have never seen and be useful the same day, which is the only reason a team this size can own this many products.

We build the simplest platform that meets the requirement, and we are strict about what the requirement actually is.

Complexity here has to earn its place: every capability we run is one more thing one team has to understand, patch and be able to rebuild.

A concrete example, because it tells you a lot about us: we do not run Kubernetes, and that was a decision rather than an omission.

We looked at it properly, twice — most recently because we were worried we had got it wrong — and both times the answer was that a small portfolio on predictable traffic does not need multi-node scheduling and autoscaling badly enough to pay for them with the only infrastructure engineer we have. We wrote down the specific conditions under which we would change our minds, and when one of them is met, we will.

Which is why we are asking for someone who has run Kubernetes in production and can tell us when it is not the answer.

If your idea of a good week is tuning a cluster, this is the wrong job and we would rather you knew now. If your idea of a good platform is one a small team can fully understand, rebuild from a repo and hand to a new joiner in an afternoon — and you have enough scar tissue to know where that stops being enough — that judgement is most of what we are hiring.

It is a default, not a straitjacket.

Some things genuinely need something else, and when they do we adapt deliberately, with the reasoning written down. What we do not do is re-decide the same five questions on every new repo out of habit.

And you get a say in what the standard is.

Anyone can propose a change — something new that is genuinely better, something we should upgrade to, something we got wrong. A proposal gets researched properly against the alternatives, it gets an answer, and if the answer is no you get the reasoning. On infrastructure, you are not one voice among many — you are the one who decides, within a budget you help set.

You will get seriously good at building with AI agents

We are an AI-native engineering team, genuinely — not a team that added a Copilot licence. Every engineer gets their own Claude Max subscription and a desktop orchestrator that runs several coding agents in parallel, each in its own branch. That is true of you too: a great deal of infrastructure work is now specified rather than typed, and you will get very good at driving that — where it works, where it fails, and how to read a diff and decide whether it is actually right.

It Also Makes Your Job More Interesting Than The Same Title Elsewhere, Because Agentic Engineering Creates Infrastructure Problems Most Teams Do Not Have Yet

• Agents install packages into code that sits next to client data. Supply-chain hygiene stops being a compliance checkbox and becomes a live control you own.
• Agents hold credentials — or rather, they must not. Brokering machine identity so the agent never touches the real key is a design problem, and it is yours.
• Agents cost money in a way that is invisible until the invoice. Per-project budgets, hard caps and an alert that fires before the cap, not after it.
• Agents can deploy. Which means the guardrails between "an agent proposed this" and "this is in production" are infrastructure, not policy.

If you have been running agents seriously and have opinions about where they break, we want to hear them. If you are curious but not yet deep in it, that is fine — teaching this well is something we intend to be known for.

Things worth knowing up front

• This is an on-site role in Barcelona. More than the other seats here, and for a real reason: you are standing up physical-ish infrastructure and access for a team being assembled around you, in its first year, and most of that goes faster in a room.
• You are the only DevOps engineer for a while. That is authority, and it is also a bus factor — which is why "nothing exists only in one person's head" is written into the role rather than hoped for. Everything you build gets documented and reproducible as you go, not afterwards.

If you would be moving to Barcelona for this

• We pay to get you here. Flights, your first month's accommodation while you find somewhere of your own, the visa and paperwork costs, and an agent to handle the bureaucracy — the NIE, the TIE appointment, the apostilles — instead of leaving you to meet the administrative system alone. Spanish lessons if you want them.
• A relocation bonus, paid on arrival rather than dripped out. It is repayable only if you leave within the first eighteen months, and that condition is the reason we can pay it up front — moving countries costs money at the start, not in year two.

Three things here are worth more than they look on an offer comparison, particularly against a US one:

• Nobody is on call. Ever. It has its own section above and we mean it literally. If you are coming from a market where infrastructure work and a pager are assumed to travel together, read that section twice — it is the single largest difference between this job and the same title elsewhere, and it is not a perk we are quietly hoping you will waive.
• Healthcare with no premium, no deductible and no network — from day one, and not tied to staying in this job.
• Thirty calendar days of holiday — that is 22 working days — plus fourteen public holidays, roughly seven weeks in total. That is the statutory floor in Spain, not a benefit we are being generous with.

And the on-site line reads differently depending on where you are standing. For someone already in Barcelona it is a constraint and we have said why. For someone moving here it is most of the point: this is a job in Barcelona, not a job you do from Barcelona — a team that sits together, in a city worth being physically present in.

What we are looking for

Read this as a description of the engineer you will be here, not a checklist you have to arrive with. Almost nobody ticks all of it on day one, and we would rather hire someone with the instinct and train the rest — that is a large part of what the certificate is for.

• You have built infrastructure from nothing before, and it survived other people using it. A platform you were handed and maintained is fine; a platform you created is what we are asking for. This is the one non-negotiable, and it is why the role is senior: there is nobody here to check your work, and the platform you put in place is the one everyone else builds on for years.
• Infrastructure-as-code is how you work, not a tool you have used. You can talk about what you do when reality and the repo disagree, because it always eventually does.
• You have owned backups and actually restored from them — under time pressure, ideally when it mattered. Everyone has backups. Far fewer have restored.
• You are comfortable running things on your own servers, not only on a managed cloud console. We own our infrastructure deliberately, and that is a different skill from configuring somebody else's.
• You have run Kubernetes in production — and you are equally comfortable saying when it is not the right answer. We do not run it today. Whether and when we do is one of the decisions this job owns, and we would rather that call were made by someone who has lived with the thing than by someone reasoning about it from the outside.
• You automate yourself out of the loop, and you write things down. The measure of this job is how little of it requires you specifically.
• You can say no to complexity. The best engineer for this seat is the one who builds the boring thing that works and resists the interesting thing that does not need to exist.
• Security is instinct, not a stage. Secrets, access, least privilege, patching — the boring disciplines, held consistently.
• English, fluently. It is our working language — we work across roughly fifteen countries. Spanish is genuinely useful day to day. Catalan is not required.
• Barcelona. This is a team that sits together, especially in its first year.

We do not care what you studied.

We care what you have built and run, and whether you can talk us through the decisions in it.

How we hire — the two rounds built for this seat

• A thirty-minute conversation. What you have built, how you work, and how you think about it. We will ask you to walk us through something you built and then to justify a specific decision inside it. There is no way to prepare for that and it is not meant to catch you out; it is how we tell understanding from familiarity.
• A project. We give you a brief and a working environment to build it in, with Claude Code already set up and wired to a key, so you are building the way we actually build rather than talking about it at a whiteboard. It is real work, not a puzzle, you do it on your own schedule — no week off, no flights, nothing that requires you to already be free — and we go through what you built together afterwards.

Mainloop

• Barcelona.