Embedded Linux Engineer — Platform & Integration İş İlanı

We are looking for a senior Embedded Linux Engineer who is at their best ranging across a platform rather than guarding one corner of it. As the Q12 fleet grows, so does everything between the specialisms: platform services that bridge the OS and the product, software that needs integrating cleanly onto the aircraft, and a steady stream of promising prototypes waiting to become production software. This role owns that space — the connective tissue of the platform, and the projects that don’t exist yet. This is a role with real ownership rather than a specification to implement — the ownership is simply broader than a single subsystem. We are hiring two Embedded Linux Engineers with deliberately different centres of gravity: your counterpart owns connectivity and routing, while you range across the platform around it. The deep specialisms are already in good hands — one senior engineer owns boot, BSP, and board bring-up; another owns releases, fleet provisioning, and the firmware-update pipeline; a third owns the drone management system and configuration management — so this role is not about re-owning their domains. It is about multiplying the team: closing the gaps between the lanes and giving every new idea a first owner. And you will not be alone in it — you pair with another platform engineer, who ranges just as widely from the applications side; the two of you are the team’s generalist core. There is plenty of room to shape what the role becomes. About SiFly Aviation At SiFly, we’re building a new category of aircraft: vertical-takeoff, long-endurance drones that deliver helicopter-level performance at drone economics. After thousands of flight tests and years of engineering, our NDAA-compliant platform flies more than 2 hours in hover or 3 hours in forward flight on a single charge — matching the capability of traditional helicopters at a fraction of their cost and operational burden. We merge aerial robotics, perception, and onboard intelligence to cut complexity and minimize human intervention, and our unique approach to communications and networking unlocks remote operations from day one. It’s an ambitious mission, and we’re a small team that moves fast. The role You will work across the Linux platform that every other software team builds on. Your home ground is the space between the lanes: the platform services — telemetry, logging, health, and diagnostics — that bridge the OS and the product; the integration and packaging work that turns software, yours and other teams’, into containerized or systemd-managed services that actually ship in the image; and the pipeline of prototypes waiting to become supported features, starting with an internally-proven offline cellular diagnostics tool. Day to day that means writing services in C, C++, and Python on a Yocto-based platform, and picking up whatever the week actually needs — a bench debug, a bitbake recipe, a test rig that should exist. You will collaborate closely with the engineer who owns our drone management system and configuration management — your generalist counterpart on the applications side — the platform engineers who own the BSP and the release-and-update pipeline, the Embedded Linux Engineer who owns networking and the Dynamic Routing Engine, the firmware engineers who own the supervisory MCUs, the applications and autonomy teams building on your work, and our hardware engineers in Santa Clara. What you’ll do Turn prototypes into product. Take internally-proven concepts — an offline cellular diagnostics tool is first in the queue — from “works on one bench” to tested, packaged, documented platform features running on the fleet, and own them once they ship. Build the platform services. The daemons and utilities that bridge the OS and product logic: telemetry and logging, watchdogs, health and recovery paths, and power-on-self-test and run-time diagnostics. Integrate software onto the aircraft. Package your own and other teams’ services into our Yocto-based image as containerized or systemd-managed services with proper configuration, resource isolation, and lifecycle management — the difference between “it runs” and “it ships”. Take the projects that have no owner yet. Be the default first assignee for the new, the ambiguous, and the cross-cutting: scope it, build it, prove it, document it — then keep it or hand it over clean. Back up the specialists. Take the overflow from the BSP and release-and-update owners — recipe updates, image tweaks, driver integration support — debug alongside them at the bench, and keep the platform moving when they are heads-down elsewhere. Pair with our other generalist. Work side by side with the engineer who owns the drone management system and configuration management — two generalists, one from the applications side, one from the platform side — swarming the same problems from both ends and picking up the OS-side work around his systems when that is what the week needs. Leave every corner better than you found it. Tooling, bench-test infrastructure, CI checks, and documentation that make the next engineer faster in whatever subsystem you just passed through. Required experience Minimum 5+ years of professional experience in embedded Linux development, spanning more than one problem domain — platform, system services, networking, or applications. A bachelor’s degree or higher in a related program — Electrical Engineering, Computer Engineering, Computer Science, or similar. Breadth and self-direction. Shipped work in several unrelated corners of a Linux system, comfort ramping up fast on subsystems you have never touched, and a track record of taking a loosely-specified project to done without waiting for a detailed spec. Embedded development. Strong C and C++ and Python, building resource-efficient services with systemd, D-Bus, Docker, namespaces, and cgroups — and comfortable working inside a Yocto-based image even if you do not maintain it. Prototype-to-production instincts. You have taken rough proof-of-concept code and made it shippable — tests, packaging, failure handling, documentation — and you can judge what to keep, what to rewrite, and when. Low-level literacy. You do not need to own a BSP, but you can read a device tree, follow a kernel log to a suspect driver, hold your own on a serial console, and debug productively alongside the engineers who do. Debugging and workflow. Skilled in multi-layer troubleshooting with gdb, strace, and perf across processes, containers, and services, in a Git-driven CI/CD environment, and comfortable with instrumented bench work on real hardware. Advanced English language skills and strong written and verbal communication — able to coordinate clearly across a distributed team in Turkey and Santa Clara. Nice to have Yocto recipe and layer authoring · kernel configuration, device trees, or small driver patches · U-Boot or OTA update systems (Mender, RAUC, SWUpdate) from the integration side · cellular modems and diagnostics (ModemManager, QMI, or AT) · fleet, device-management, or IoT platforms (AWS IoT, Azure IoT, Balena, or in-house) · MQTT and cloud-connected device services · digital-twin or device-shadow frameworks (Eclipse Ditto or similar) · MediaTek SoC platforms · CAN and MAVLink or comparable robotics/autopilot interfaces · test automation and hardware-in-the-loop rigs · camera and multimedia pipelines (V4L2, GStreamer) · UAV, robotics, automotive, or other safety-relevant embedded experience. What success looks like Prototypes stop dying in the lab: a proof-of-concept becomes a tested, documented feature on the fleet in weeks — the offline cellular diagnostics tool is the first proof. The platform services that bridge the OS and the product — telemetry, logging, health, diagnostics — are owned, tested, and documented rather than accreted. The generalist pair works: between you and the drone-management owner, the space between the specialists’ lanes is simply covered — no category of work belongs to nobody. The specialists stay specialists: the BSP, update, and connectivity owners spend their time in their own lanes because the work between the lanes reliably lands with you. When something new lands on the team’s plate, “who takes this?” has a default answer — and what you hand back comes with tests and documentation. Every subsystem you pass through is easier to work on when you leave it than when you found it. Compensation & logistics Job type: Remote contract-based employment. Location: On-site position in Ankara, Turkey — working closely with our Santa Clara team.