Finding Docker and platform-engineering roles

We don't run our own job board. The container ecosystem is small enough that broad, well-known boards already aggregate the relevant openings, and a curated job board adds little value. What does add value is honest guidance on where to look, what the titles actually mean, and how to translate the skills you have into what employers are searching for.

Where these jobs are posted

Job titles, decoded

Container-adjacent titles overlap heavily and the mapping is inconsistent across companies. The shorthand below is what they tend to mean in practice:

• DevOps engineer — historically broad: CI/CD, deployment, monitoring, infrastructure-as-code. At smaller companies, often "the person who keeps things running."
• Site reliability engineer (SRE) — operations with a software-engineering toolkit. Heavy on observability, incident response, capacity planning, and reliability targets.
• Platform engineer — building internal developer platforms: shared CI, shared base images, shared deployment tooling. Often the team that decides what your FROM line should be.
• Cloud engineer / cloud infrastructure engineer — usually anchored to a specific cloud (AWS/GCP/Azure). Networks, IAM, and managed services more than container internals.
• Build / release engineer — focused specifically on the build pipeline, artefact management, and release process. The closest fit if your strongest interest is what this site covers.

What the job ad really wants

Most ads list more tools than any one person actually needs to know. Reading the description carefully tells you which two or three things are real:

• Tools repeated across multiple sections are usually the ones the team is actively using. A tool mentioned once may just be a "nice to have."
• The "responsibilities" section describes the day job. The "requirements" section often describes the team's wish list.
• Specific version numbers, named open-source projects, or architectural patterns ("multi-arch builds with buildx", "ECR with cache-mounts") signal genuine technical depth in the team.
• Vague phrases ("DevOps culture", "modern CI/CD") without concrete tools usually mean the team itself is not certain what stack it wants.

What to lead with on your CV

For roles where the work touches Docker image building specifically, the things that move recruiters and hiring managers are:

• A measurable improvement: image size cut from X to Y, build time reduced from N minutes to M minutes, CI cost reduced.
• A concrete tool or pattern you applied: multi-stage builds, BuildKit cache mounts, distroless images, image scanning in CI, signed images.
• A failure mode you debugged: layer-cache busting, container not running as non-root, builds that work locally but break in CI.
• A small public artefact: a Dockerfile in a personal repo, a pull request to a project you use, a short write-up of a build problem you solved.

If you want to fill in any of those gaps before applying, the on-site learning paths are organised by goal — beginner, optimisation, security — and the microservices worked example gives a vocabulary for talking about pipeline optimisation in interviews.

Hiring? Where to post

If you are on the other side and looking to hire, the same boards listed above tend to perform well. Be specific about what's actually in your stack. Ads that name your registry, your CI system, your image-build approach, and one or two real problems the role will own consistently outperform generic "DevOps engineer wanted" listings.