[Hiring] Embedded Linux Build & Release Engineer @L4B Software

Role Description

This is a fully remote role — anyone based anywhere in the EU is welcome to apply.

• Build infrastructure, CI/CD, release automation, SBOM generation, and supply-chain security for Android and Linux platform development.
• Hands-on builder. Not cloud DevOps.
• If your instinct when a pipeline goes red is to SSH into the build box and find out why — not file a ticket for someone else to look at — keep reading.
• This isn't a Kubernetes-and-Terraform seat. It's the person who keeps Android and Linux builds actually building, and who can prove exactly what shipped inside them.

Before you go further: this role requires hands-on experience with at least one of AOSP, Android BSP, Yocto, firmware, or embedded Linux. If your background is primarily cloud infrastructure or identity administration — AWS, Azure, or GCP, Kubernetes administration, or Infrastructure-as-Code for enterprise or web applications — this genuinely isn't the right role.

• Not a fit for a Kubernetes administrator, a Terraform engineer, an AWS migration specialist, a cloud-only DevOps engineer, or someone whose CI/CD experience begins and ends with web apps.
• This role lives in build farms, toolchains, and native compilation, not cloud consoles.

This role sits across L4B's product platforms — spanning medical, automotive, and space-grade embedded systems, all built on a shared core platform layer. Every one of them depends on Android and Linux builds that just work, releases that can be reproduced and trusted, and a clear, provable record of what's actually inside what ships.

• This role owns: the infrastructure and automation that turns engineering work into something releasable, with the evidence to back it up.
• This enables engineering velocity and release confidence — not as a slogan, as the actual job.

This work also carries real regulatory weight in Europe: the EU Cyber Resilience Act now requires a machine-readable SBOM and continuous vulnerability monitoring for any product with digital elements sold into the EU market, with reporting obligations already active and full compliance due by December 2027.

• For our EU-facing products, the SBOM and CVE work this role owns isn't just good practice — it's becoming a legal requirement.

What you'll own

• Build Infrastructure
  • Own Ubuntu build systems, build agents, build runners, and build farm health.
  • Debug builds across Android, AOSP, Yocto, and embedded Linux.
• CI/CD
  • Set up and maintain GitLab CI, Jenkins, GitHub Actions, and Azure DevOps.
  • Be comfortable building everything from scratch — no inherited pipeline is sacred.
• Build Failure Analysis
  • Diagnose toolchain, disk, memory, dependency, permission, and environment issues.
  • Independently recover broken pipelines — that's the job description, not an escalation.
• Release Engineering
  • Own release packaging, artifact publishing, release versioning, and release notes.
  • Guarantee build reproducibility and generate real release evidence.
• SBOM & Supply Chain
  • Implement Syft, SPDX, and CycloneDX.
  • Maintain the software bill of materials and open-source visibility across products.
• Security Pipeline
  • Integrate Trivy, Grype, Snyk, Black Duck, Dependency-Track, and Yocto CVE checks into the build itself.
• Automation
  • Build it yourself: Bash automation, Python tooling, validation automation, release automation.

What you bring

• A Linux-first engineer — not someone who happens to touch Linux occasionally.
• Real Jenkins/GitLab CI experience.
• Build server administration.
• Bash scripting.
• Python scripting.
• Experience with large native builds.
• At least one of: AOSP, Android BSP, Yocto, firmware, or embedded Linux.

Strong plus

• Artifactory, Nexus, or JFrog.
• SBOM generation.
• CVE pipelines.
• Release evidence generation.

What success looks like after year one

• Linux and Android builds are fully automated.
• The release process is reproducible, not tribal knowledge.
• SBOM generation is automated.
• CVE monitoring is automated.
• Every release comes with a real evidence package.
• Manual release activity is the exception, not the routine.

How we hire

• Two rounds. Both hands-on, both with people who'll ask you to actually debug a broken build, not describe one in the abstract.