Embedded Linux Engineer — Networking & Connectivity İş İlanı

We are looking for a senior Embedded Linux Engineer to own connectivity on the aircraft: how a Q12 stays reachable over 5G, Wi-Fi 6, and Wi-Fi HaLow simultaneously, how traffic is routed and prioritized across those links as they degrade, and how video, telemetry, and command-and-control survive a handover mid-flight. Remote beyond-visual-line-of-sight operation is the product, and the network is what makes it possible. The picture is also wider than the aircraft alone: the same links and routing decisions span the DroneFi ground station and the pilot application, and you will own how they behave as one system. This is a role with real ownership rather than a specification to implement. You will own our Dynamic Routing Engine — the service that decides, in flight, which link carries what — along with the link-management daemons, the secure overlay back to our cloud, and the test rigs that prove any of it works. The engine is led part-time today; ownership of it transfers to you as you onboard — and with it, the role of primary technical guide for DroneFi development, supported by the senior architect who owns our low-level networking foundations. We are hiring two Embedded Linux Engineers with deliberately different centres of gravity: you own connectivity and routing, while a counterpart works broadly across the platform — platform services, integration, and new platform capabilities — alongside the senior engineers who already cover BSP, boot, and the update pipeline. You will work closely together. 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 own the networking stack on the aircraft and the software that manages it: multi-link connectivity across cellular, Wi-Fi 6, and Wi-Fi HaLow, the Dynamic Routing Engine that selects and blends those links, traffic policy and QoS that keeps command-and-control alive when video wants all the bandwidth, the Tailscale mesh and TLS-secured paths back to our AWS backend, and the behaviour of MQTT, WebRTC video, and the MAVLink router under real loss and latency. Day to day that means writing services in C, C++, and Python on a Yocto-based platform, living in packet captures, and building the emulation and field-test setups that turn “it felt better” into a number. You own the connectivity picture in its totality: not just the Linux side, but partnering with the applications team so the software riding on these links is as resilient to degradation and handover as the network beneath it. You will collaborate closely with the rest of the embedded platform team — your generalist counterpart and the engineers who cover BSP, boot, updates, and the low-level networking foundations — the firmware engineers who own the radios and supervisory MCUs, the part-time engineer who leads the Dynamic Routing Engine today and will hand it over to you, the applications and autonomy teams whose traffic you carry and whose resilience you help design, the cloud team on the other end of every link, and our hardware and RF engineers in Santa Clara — including on antenna placement and integration on the airframe. What you’ll do Own the Dynamic Routing Engine. Design, implement, and harden the service that chooses and blends links in flight — link metrics and scoring, switching policy and hysteresis, failover timing, and behaviour at the edge of coverage — and close out the open risks against it. Make multi-link connectivity dependable. Own the cellular, Wi-Fi 6, and Wi-Fi HaLow links end-to-end on the Linux side: modem management, association and roaming, bonding and make-before-break handover, and graceful degradation rather than a cliff edge. Own routing and traffic policy. Policy routing across multiple tables and interfaces, nftables, tc-based QoS and shaping, VLANs, bridges, and network namespaces — so command-and-control, video, and bulk transfer each get what they need on a link that is shrinking. Keep video and telemetry alive under degradation. Tune WebRTC (WHIP/WHEP) and RTP video, adaptive bitrate and congestion control, MQTT keepalive and reconnect behaviour, and MAVLink routing on lossy, high-latency links — and make reconnection invisible to the operator. Make the applications resilient with you. Own the contract between the network and everything riding on it: expose link state, quality, and bandwidth signals that applications can act on, and work with the applications team so onboard and ground-side software handles degradation, handover, and offline periods by design rather than by surprise. Own the secure overlay. The Tailscale/WireGuard mesh, TLS, per-aircraft identity and certificate provisioning, NAT traversal, and an addressing plan that still works when the fleet is an order of magnitude larger. Instrument the network. Per-link metrics for signal quality, latency, loss, jitter, and throughput; structured connectivity logging that makes a post-flight “why did the link drop” answerable from data rather than guesswork. Build the test rigs. Network emulation with netem and programmable attenuators, shielded and bench setups, and structured field and drive testing — quantify handover time, packet loss, and throughput versus range, and reproduce field failures on the bench. Integrate on the platform. Package your services into our Yocto-based image as containerized or systemd-managed services with proper configuration and device management, and work with the platform team and firmware owners on modem, Wi-Fi, and radio drivers. Support the connected subsystems. Provide the network-side integration and debugging for Remote ID, ADS-B-In, and the ground-side apps — Pilot, Crew, HQ, and mobile — working with the owners of each. Required experience Minimum 5+ years of professional experience in embedded Linux development with a networking or connectivity focus. A bachelor’s degree or higher in a related program — Electrical Engineering, Computer Engineering, Computer Science, or similar. Linux networking depth. Expert with the Linux network stack — netlink and iproute2, policy routing and multiple routing tables, nftables/iptables, tc and QoS, bridges, VLANs, and namespaces — and fluent in packet-level debugging with tcpdump and Wireshark. Wireless and cellular. Hands-on with cellular modems (5G/LTE via QMI, MBIM, ModemManager, or AT) and Wi-Fi (wpa_supplicant, hostapd, roaming behaviour), plus a working understanding of RF realities: link budget, interference, and range versus throughput. Multipath and failover. Real experience making a device stay connected across more than one link — bonding, multipath (MPTCP or equivalent), VPN overlays (WireGuard, Tailscale, or IPsec), or mesh routing protocols — including the failure modes that only show up in the field. Real-time transport. Comfortable reasoning about UDP-based streaming and control traffic — RTP or WebRTC, MQTT, congestion control, and how latency, jitter, and loss actually affect a video feed and a control loop. 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. Debugging and workflow. Skilled in multi-layer troubleshooting with gdb, strace, and perf across processes, containers, and networks, in a Git-driven CI/CD environment, and comfortable with serial consoles and 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 Wi-Fi HaLow (802.11ah) or other sub-GHz links · mesh radios (Silvus, Rajant, Doodle Labs) or SDR-based custom links · MAVLink and autopilot link management, including telemetry radio failover · GStreamer or WebRTC pipeline tuning under constrained bandwidth · eSIM and carrier provisioning, multi-carrier SIM strategies, private 5G, or roaming agreements · BVLOS regulatory context — C2 link requirements, link redundancy, and Remote ID · DDS or XRCE-DDS middleware · antenna placement and RF integration on airframes or vehicles · Yocto recipe authoring · MediaTek SoC platforms · contributing upstream to Linux networking or open-source networking projects · UAV, robotics, automotive, or other mobile-connectivity experience. What success looks like The Dynamic Routing Engine is owned, understood, and documented — its decisions are explainable after the fact, and its open risks are closed. Link handovers happen without the operator noticing: video keeps playing and command-and-control never gaps. Connectivity is a measured property of the aircraft, not an anecdote — we can state expected range, throughput, and failover time, and hold ourselves to it. Field connectivity failures are reproducible on the bench within days and land in an automated test. The network stack degrades predictably as links are lost, and the aircraft always has a trustworthy path home. The applications, autonomy, and cloud teams treat the link as something they can rely on rather than design around — and when a link does degrade, their software hears it from your link-state signals first, not from timeouts. Compensation & logistics Job type: Remote contract-based employment. Location: On-site position in Ankara, Turkey — working closely with our Santa Clara team.