Rust Systems Engineer

Rust Systems Engineer — Firmware & Enterprise C/C++ Migration

Role Type: Full-Time | Contract-to-Hire available
Level: Senior / Staff Engineer
Location: Remote-first | US or Brazil timezone preferred
Compensation: $140K–$190K base | $85–$120/hr contract

The Mission

This is legacy C/C++ work being moved while the business keeps running. Some of it is backend infrastructure. Some of it is firmware. None of it is a clean-room Rust rewrite.

The person in this seat owns the transition architecture. Not just tickets. Not just “convert this file to Rust.” You will be deciding what moves first, what stays in C++ for now, where the FFI boundary belongs, and how the team avoids turning a migration into a long, expensive mess.

If your Rust experience is mostly side projects, this is not the right job. If you have shipped Rust into production where failure had real consequences, keep reading.

Where the Rust work is

Firmware

– Rewrite embedded C/C++ components in no_std Rust.
– Target bare-metal and RTOS environments. ARM Cortex-M, RISC-V, or equivalent.
– Maintain hardware abstraction layers (HAL). You should be comfortable around peripheral registers, DMA, interrupts, and low-power modes.
– Work with embedded Rust tools and frameworks such as probe-rs, defmt, embassy, or whatever combination actually fits the target hardware.
– Replace unsafe C memory patterns with Rust ownership models without casually adding latency or blowing up binary size.

Enterprise

– Move performance-critical C++ services into safe, idiomatic Rust. Networking, parsing, IPC, data pipelines.
– Design FFI bridges for incremental migration. Rust calling C. C calling Rust. Zero-copy where it is worth the complexity.
– Integrate with existing build systems across polyglot codebases: CMake, Bazel, Cargo workspaces.
– Profile and optimize with the tool that fits the failure mode: perf, valgrind, cargo-flamegraph, heaptrack.

Both

– Write the migration plan people will actually follow: which pieces move first, which ones wait, and where the sharp edges are.
– Define memory safety policies the engineering team can live with and enforce.
– Read C/C++ code closely enough to spot the high-leverage Rust migration targets.
– Mentor engineers who are coming from C++ to Rust and will not become fluent overnight.

Requirements

• 3+ years of production Rust — not adjacent to Rust, but in Rust
• Real C or C++ experience. Enough that you understand what you are replacing and why it was written that way in the first place.
• Deep understanding of Rust ownership, lifetimes, trait system, and unsafe. Including when unsafe is correct.
• At least one of these: embedded Rust (no_std, HAL, RTOS) or enterprise Rust (high-throughput services, FFI, systems programming).
• Experience with cross-compilation toolchains and target-specific builds.
• Can write architecture documents, not just code.
• Has operated in codebases they did not write — and improved them without burning them down
• Can explain tradeoffs clearly to non-Rust engineers and to stakeholders.
• Knows that porting code line-for-line is usually how migrations get expensive and weird.

Star candidates:

• Have debugged a production issue that required reading disassembly.
• Have written a custom allocator or worked with #[global_allocator].
• Understand the difference between safe abstraction and safe theater.
• Have used bindgen or cbindgen in production.
• Have pushed back on a migration timeline with data — and won.

Please do not apply if

• Your resume lists Rust as “learning” or “exploring.” We need production proof.
• You cannot explain a lifetime error in plain English to a non-Rust engineer.
• You have a history of abandoning migrations halfway without documented rationale.
• You treat unsafe as a shortcut instead of a contract.

Interview process

The interview is deliberately practical. We are not trying to trick you with Rust trivia. We are trying to find out whether you have done this kind of migration work when the codebase, schedule, and failure modes were all real.

1. Signal screen: 30-minute conversation focused on one real migration you led or meaningfully contributed to.
2. Technical review: We provide a 100-line C function. You rewrite it in Rust and explain your decisions. No time pressure. No gotchas.
3. Systems interview: How would you approach migrating a 200K-line C++ codebase? This is an architecture conversation: order of operations, risk, rollback, and what you refuse to migrate first.

We care most about whether your reasoning is honest, specific, and grounded in how systems actually fail.

This position is sourced and managed exclusively by SherlockTalent.com.