Required Skills: Direct Wind River product experience, Aerospace, defense, telecom, industrial domain background, Kubernetes, OpenStack, DevOps, cloud, container, authoring knowledge-base articles, leading escalations
Job Description
Must have:
Look at what "reproduce customer environments" and "identify root causes" actually mean in this stack:
- VxWorks is an RTOS written in C. Its kernel, drivers, BSPs (board support packages) — all C, with some C++ in newer components. If a customer reports a kernel panic, a driver hang, or a timing bug, you're reading disassembly, stack traces, and C source to figure out what broke.
- Wind River Linux — same story at the kernel/driver level (C), though more of the userspace tooling (systemd, udev, Yocto build layers) is scriptable.
- BSPs and drivers — this is entirely C/C++. You cannot debug a device driver interacting incorrectly with hardware without reading (and often instrumenting or patching) that C/C++ code directly.
- Toolchains like Diab, GCC, Clang, Workbench — these compile C/C++. Understanding compiler behavior, optimization bugs, linker issues, or toolchain diagnostics requires fluency in what the C/C++ source is supposed to produce at the binary level.
- Simics/QEMU simulation — used to simulate hardware behavior so you can step through C/C++ code in a debugger without needing physical hardware.
What you'd actually do:
This is deep technical support, not a help desk — think tier-3/escalation engineering:
- Reproduce customer environments in internal labs
- Debug across OS, hardware, networking, virtualization, and embedded/real-time systems
- Find root causes, build workarounds, document suspected product defects
- Own customer-facing communication on critical/escalated cases
- Build knowledge-base content and mentor junior support engineers
- Act as a liaison between Support, Product Management, and Engineering