Rust Developer Job Description Template 2026

Last updated: September 18, 2026

By Jennifer Burdick, Recruiting Manager, KORE1

A Rust developer job description should name where the compiled code runs, the toolchain and edition you build with, how much unsafe code the team maintains, how new crates get approved, and what the seat pays. Mid-level Rust engineers are getting about $135,000 to $170,000 base this year, and senior ones $165,000 to $205,000. Leave out where the code runs and a posting written for firmware fills up with web developers.

I run recruiting and delivery at KORE1. Rust reqs used to reach my desk a few times a year. Now they come in most months, usually from companies that have never hired for the language before and are writing their first posting for it.

The req had been open eleven weeks when it got to us in the spring of 2025.

The company was a battery systems supplier in Plymouth, Michigan, about 400 people, building the controller that sits inside an electric vehicle’s battery pack and decides when a cell is too hot to charge. Its firmware team had written that controller in C for a decade. A new program was starting in Rust, and they wanted a senior engineer to lead it. Nobody there had shipped Rust.

The posting had been adapted from one the company’s cloud team ran a year earlier. It asked for five years of production Rust, Actix Web, PostgreSQL, Docker, and Kubernetes, plus “experience building scalable microservices.” It drew 140 applicants. I read all of them. Most were backend developers, several of them very good, and not one had ever flashed a microcontroller.

Nothing in that posting was false. Rust really was the language. The code just ran somewhere else entirely, on an Arm Cortex-M4 with a few hundred kilobytes of memory, no operating system, and no heap, inside a product going through ISO 26262 functional safety work. The cloud team’s template had no place for any of it.

The rewrite took an afternoon. The new title read “Senior Embedded Rust Engineer, no_std Firmware for a Battery Management Controller,” and the body named the Embassy framework, the probe-rs debugger, and the qualified compiler the safety team had picked. Thirty-one people applied. The hire was a C firmware engineer from a Tier 1 supplier near Auburn Hills who had been writing Rust on weekends for two years, and she started five weeks after the repost at $168,000 base. She is still there.

Most Rust job descriptions I see read like a posting for some other language with Rust typed into the blanks. Our Rust hiring guide covers why that fails. This page is about what goes in its place, which turns out to be a handful of facts about your code that no generic template can know. Where it runs. Which compiler builds it. How much of it is unsafe. What happens before a new dependency lands. Experienced Rust engineers sort themselves on those four answers faster than on any skills list.

A disclosure before the details. KORE1 earns a fee when a Rust seat fills through our Rust developer staffing desk, and a posting this specific sometimes fills without us. I would rather lose that fee than spend six weeks sending resumes against a description of the wrong job.

Where the Binary Ends Up

A Rust developer writes and maintains software in Rust, a compiled systems language whose compiler rejects most memory errors before the program ever runs, and which needs no garbage collector. The job varies more by where the finished program runs, on a server, a microcontroller, a browser, or inside a Python package, than by the language itself.

That second sentence is the one most postings miss. Rust compiles to a lot of places, and the people who write it for each place have surprisingly little in common beyond the borrow checker. The groups barely overlap. This is how I sort a new Rust req in the first ten minutes.

People do not expect the third row. A clinical genomics lab in Madison, Wisconsin, called us early in 2026 about a posting titled “Rust Developer” that had pulled in strong systems programmers, every one of whom lost interest the moment the interview turned to Python. The job was a Python pipeline with one slow step, a variant-scoring function that ran for hours, and the plan was to rewrite that function in Rust and ship it back to the data team as a Python extension through PyO3. Most of the work was Python. The Rust was maybe a fifth of it. The interviews showed that fast.

We retitled the seat “Python Engineer, Rust Extensions (PyO3).” Applications changed overnight. The hire came from the data platform team at a Chicago insurer, where she had already written two PyO3 extensions, and she accepted $152,000. She had a competing offer. If the Python half of a seat like that is the bigger half, our Python developer job description template covers that side of the posting.

The other rows have their own specialists. Embedded seats carry enough rules of their own that we run firmware engineer staffing as a separate desk, and a protocol seat belongs with our blockchain developer staffing team. I would not use the template on this page for a Solana program without heavy changes. The pay is different, the audit culture is different, and so is the way candidates judge an employer.

A New Compiler Every Six Weeks

Rust ships a new stable compiler every six weeks. As I write this, the current release is Rust 1.98.1, a point release published on September 3, 2026, to fix a miscompilation in 1.98.0. The Rust Project’s 2025 State of Rust survey, built from 7,156 responses, found that people develop on the stable compiler and keep up with releases. Your candidates will assume you do too.

Plenty of teams do not. Some have good reasons. A defense electronics company in Huntsville, Alabama, built its ground-station software inside an accredited environment where every toolchain change needed its own security review, so the compiler had sat at Rust 1.68 for more than two years. The posting never mentioned it. The engineer we placed there in 2025 came from a cloud infrastructure company that upgraded every release. In his first week he found out that async functions in traits were off the table, a feature stable since Rust 1.75 back in December 2023, and so were two years of library releases that would not build on the old compiler anymore. He stayed. He also told me, fairly, that he would have negotiated differently if he had known. I agreed with him.

Three facts about the toolchain belong in the posting, and your team already has all of them written down somewhere.

• The stable version you build with and how often it moves. “We track stable within one release” and “we pin Rust 1.80 in an accredited build environment” are both honest sentences, and they attract different people.
• Your edition. The 2024 edition became stable with Rust 1.85 in February 2025, so a workspace still on 2018 or 2021 has migration work ahead of it. Is that work part of this job?
• For teams that publish crates other people depend on, the minimum supported Rust version. Cargo records it in the rust-version field, and the 2024 edition’s resolver takes that field into account by default. Library maintainers care about this far more than application developers do, and one who has kept a popular crate building on old compilers will ask you about it.

If any part of the build needs the nightly compiler, name the feature and the reason. Some candidates will not take a nightly-dependent job. A few want nothing else.

The Unsafe Code Question Candidates Ask First

Rust’s guarantees stop at the keyword unsafe. Inside an unsafe block the compiler lets code dereference raw pointers and call into C, and from there it is the programmer, not the compiler, who keeps memory valid. Nearly every serious Rust codebase has some of it. Candidates know that. What matters is how much, where it lives, and who checks it.

Experienced Rust engineers ask about this early, sometimes on the first phone screen, because the answer tells them what the job really is. A service with unsafe code forbidden at the top of every crate is an application job. A workspace with hundreds of unsafe blocks wrapping a C++ library is an FFI job, and a good one for the right person. A custom allocator or a lock-free queue is systems work of the most demanding kind, and the people who want it are a small group who talk to each other. They compare notes.

Any of these would do the job in a posting.

• “No unsafe code in the services this role owns. The workspace forbids it.”
• “About 2% of the codebase is unsafe, all of it in one crate that wraps our C++ physics engine.”
• “This role writes and reviews unsafe code in our storage engine. Every unsafe block carries a SAFETY comment and a second reviewer, and Miri runs on each pull request.”

That last example describes rules a lot of mature teams already follow. Clippy even has an opt-in lint, undocumented_unsafe_blocks, that flags any unsafe block without a SAFETY comment directly above it. If your team turned it on, put that in the posting. People notice it. Candidates who have worked under the rule read it as a sign that somebody senior thought about this, and candidates who have not can see what they are signing up for. When the posting does say the job includes unsafe and FFI work, the matching section of our Rust developer interview questions gives you a way to test it.

Every Crate Is Somebody Else’s Code

A typical Rust service depends on dozens of crates from crates.io directly, and on many more through them. Each one is code your company did not write and ships anyway. Nearly all of it is well made.

In September 2025 the crates.io team removed two malicious crates, faster_log and async_println, that had been published on May 25 and spent four months searching the files of any project that used them for Ethereum and Solana private keys. They had been downloaded 7,181 and 1,243 times. Both names looked ordinary. Somebody chose them carefully.

So who reviews a new dependency before it merges? At a lot of companies the honest answer is nobody in particular, and a candidate from a security-conscious shop will ask. The tooling is mature. One tool, cargo-audit, checks your lockfile against the RustSec advisory database. Another, cargo-deny, adds rules about licenses and allowed sources, and Mozilla’s cargo-vet keeps a record of which dependencies a trusted person has actually audited. Name the ones you run. If you run none and this hire is expected to set them up, that is a responsibility, and it goes in the list with the others.

Dependencies also go stale. The async-std runtime, which a good number of older Rust services were built on, has been discontinued by its maintainers, who now point people to smol. A posting that lists async-std is advertising a migration, whether anybody meant it to or not.

Roadmaps, Rewrites, and Certified Compilers

A lot of the Rust reqs I see in 2026 trace back to a security decision made somewhere above the engineering team. Engineers rarely start them.

The federal guidance behind many of them is specific. CISA and the FBI put out version 2.0 of their Product Security Bad Practices guidance in January 2025. It calls starting a new product line for critical infrastructure in C or C++ dangerous whenever a memory-safe language could readily be used instead, and it asked makers of existing products to have a memory safety roadmap out before 2025 ran out. CISA and the NSA followed in June 2025 with a joint paper on adopting memory-safe languages. Neither is a law. In my conversations with engineering leaders, though, the roadmap tends to arrive as a line in a customer’s security questionnaire. Somebody has to answer it.

The results people cite come mostly from Google. In November 2025 the Android team reported that memory safety bugs had dropped below 20% of Android’s vulnerabilities for the first time. Per the same post, its Rust code carries roughly one thousandth of the memory safety vulnerability density of its C and C++. Rollbacks are rarer too, about four times rarer for medium and large Rust changes than for C++ ones, and Rust changes spend around 25% less time in code review. Numbers like that get forwarded to a CTO. My phone rings about six months after that.

What the posting needs from all this is one plain statement of which kind of work the seat is. Writing new components in Rust beside a C++ codebase that will stay put for years is one job. Rewriting something that already works is another. It is harder to staff. A roadmap program also usually needs the people who keep the old code alive, which is a separate search our C++ developer hiring guide covers, and a security partner across the table, the seat our application security engineer staffing desk fills.

Safety-certified products add one more line. Ferrocene, the Rust toolchain from Ferrous Systems, is TÜV SÜD-qualified for ISO 26262 at ASIL D, IEC 61508 at SIL 3, and IEC 62304 at Class C, with Linux, QNX, and bare-metal Arm targets. If your product goes through that kind of assessment, the qualified compiler is part of the job, and so is the paperwork around it. Say so. Engineers with safety experience look for that sentence. Engineers without it tend to leave when they meet the paperwork in month two, which is worse for everyone than never applying. The embedded software engineer job description template goes further into how to write the safety standard and level into a posting.

The Band Starts at the National Median

The federal government does not count Rust developers separately. They sit inside software developers, where the Bureau of Labor Statistics wage survey for May 2025 counts 1,687,890 jobs nationally, a median of $135,980, and a 75th percentile of $171,980. A mid-level Rust band starts almost exactly at that median and ends close to the 75th percentile. That catches finance teams off guard. Few people write Rust professionally as their first language, and the pay reflects the years that came before it.

These are the 2026 pay ranges from our Rust developer salary guide, which is where I would set a band before posting, with a note on what each level usually looks like.

Where the code runs moves the number nearly as much as level does. Blockchain seats usually pay more than a general seat at the same level and embedded seats less, even though the embedded job is often the harder one, and the salary guide breaks both out. On contract, W-2 rates run about $75 to $105 an hour at mid-level and $105 to $150 for senior systems work. Clearances push them higher. For a particular level and metro, run the numbers through our free salary benchmark assistant before anyone in finance picks a figure.

Then put the range on the posting. More states require a posted range every year. Rust people talk. Many of them know each other from the same open-source projects and conference hallways, and a posting with no number on it gets compared, in private, against one that has a number.

Rust Developer Job Description Template

Fill the brackets in from your repository, not from memory. Most of the answers sit in three files, Cargo.toml, rust-toolchain.toml, and your CI configuration, and the rest are decisions your engineering lead has probably made already. Brackets that begin with “Note” are for you. Delete them before posting.

Job Title

[Senior Embedded Rust Engineer, no_std Firmware / Rust Engineer, Backend Services / Python Engineer, Rust Extensions (PyO3) / Staff Systems Engineer, Rust] [Note: Put where the code runs into the title. “Rust Developer” on its own reads as a services job to most of the people searching for one.]

About the Role

[Company] builds [product], and this Rust engineer will [build / maintain / port] [component], which runs on [Linux services in AWS / an Arm Cortex-M[x] controller with no operating system / a Python package our data team installs / the browser, as WebAssembly]. [One or two sentences on what the software does for the business and what breaks when it fails.] You will join a team of [N] engineers, [N] of whom write Rust today, and report to [title].

What You Will Work On

• Design, build, and test Rust code for [component], from design review through production
• Review pull requests, including any change that touches unsafe code [Note: Say who else reviews unsafe changes. A second reviewer is common.]
• Own [the FFI boundary with our C++ [library] / the PyO3 bindings / the async service layer / the hardware abstraction layer for [chip family]]
• Add and review third-party crates under our dependency policy, using [cargo-audit / cargo-deny / cargo-vet]
• [Move the workspace to the 2024 edition / migrate [service] from async-std to Tokio / replace [C module] with a Rust implementation]
• Take part in [the on-call rotation for [service], [frequency] / hardware bring-up and lab testing / safety analysis reviews]

Toolchain and Codebase

[We build on stable Rust [version], updated [every release / quarterly / when the accredited environment is re-reviewed]. The workspace uses the [2021 / 2024] edition and holds [N] crates and about [N] lines of Rust. Unsafe code is [forbidden in this workspace / limited to [crate], which wraps [library] / part of the job, with SAFETY comments and a second reviewer on every block]. We [do / do not] use the nightly compiler [for [feature]]. [If you publish crates: our minimum supported Rust version is [version].]] [Note: Rust candidates read this paragraph before the responsibilities. Copy the versions from Cargo.toml and rust-toolchain.toml.]

Experience We Are Looking For

• Production Rust on [async services / no_std firmware / Python extensions / WebAssembly], shipped and maintained [Note: Ask for shipped work, not a count of Rust years. Rust 1.0 came out in 2015, and strong candidates usually have fewer Rust years than total years.]
• [N] or more years of [systems / embedded / backend] engineering in any language, including [C / C++ / Go]
• Working knowledge of [Tokio and Axum / Embassy or RTIC with probe-rs / PyO3 and maturin / wasm-bindgen]
• [Comfort reading and reviewing unsafe code, including FFI]
• [Domain experience: ISO 26262 or IEC 62304 projects / low-latency networking / storage engines / scientific Python]

Nice to Have

• A crate you maintain or a merged pull request into a project we would recognize [Note: Preferred, never required. Plenty of excellent engineers have only ever written proprietary code.]
• [Experience with a qualified toolchain such as Ferrocene]
• [Miri, fuzzing, or property-based testing]
• [The other language in the codebase: C++ / Python / TypeScript]

Compensation

[$135,000 to $170,000 / $165,000 to $205,000] base, plus [bonus], [equity], and [benefits]. [Note: Embedded, blockchain, and staff seats price differently. Check the salary guide before copying a row from the table above.]

Where and How We Work

[Remote within the United States / hybrid in [city] for [N] days a week / on site at our [city] lab for hardware access]. [If the role needs lab time or a security clearance, say so here, and say how often.]

Pushback From the Engineers on the Interview Panel

Is it fair to ask for open-source Rust contributions?

As a preference, it is fine, but as a requirement it quietly screens out strong engineers whose Rust has all been written for employers that do not publish code.

Many of the best embedded and fintech Rust engineers I know have no public crates at all. Their work sits in firmware images and private repositories. Nobody outside will see it. A merged pull request into Tokio or a widely used crate tells you a lot when it exists, and its absence tells you almost nothing. Ask for a code sample, or for a walkthrough of something they built at work with the proprietary parts described out loud, and you will learn most of what a GitHub link would have shown.

We do not have any unsafe code. Does the posting still need to mention it?

One sentence is enough, because “no unsafe code in this workspace” tells application developers they are welcome and tells systems engineers, correctly, that this is not their job.

Both outcomes save everyone time. It is the shortest line in the posting.

Our team has not picked an async runtime yet. Should the posting name Tokio anyway?

Tokio is the safe assumption for server work, since so much of the async ecosystem is built on it, but a posting should admit when the decision is still open.

An undecided runtime is useful information. Candidates like hearing it. It signals that the person you hire will probably make that call, and senior engineers tend to like making it. Embedded work is different. There the choice is usually between Embassy and RTIC, and it depends on the chip and on how much the team wants async code running on the device at all. If the codebase still runs on async-std, say that too, since a candidate will read it as a migration.

The security team is the reason we are moving to Rust. Should the posting say so?

Say it in one sentence, because candidates will ask why the company is adopting Rust, and a memory safety roadmap is a more convincing answer than a benchmark someone read.

It also tells them what kind of work to expect. Security-driven adoption usually means new Rust components beside a large C or C++ codebase that is not going anywhere, plenty of FFI, and meetings with people who have never written Rust and need convincing. Some engineers love that job. Others want a greenfield Rust service and nothing else, and the sentence sorts them before anyone has to schedule an interview.

Should a contract Rust posting read differently from a full-time one?

$105 to $150 an hour on W-2 is the usual rate for senior systems work, and a contract posting should also state the end date, the deliverable, and whether the seat can convert to full time.

Rust suits bounded work unusually well. A service rewrite has an end. So does a firmware milestone or an audit of the unsafe code in one crate. We fill more Rust seats through contract staffing than as direct hires, which is unusual for a software language, and our Rust contract searches average 28 days to the first submitted candidate. If the seat might convert, write that into the posting and read how a contract-to-hire arrangement would work before promising it, because candidates hold you to that line more than to any other.

Will C++ engineers apply to a posting with Rust in the title?

Many will, as long as the posting says in plain words that serious C or C++ systems experience counts and that the Rust can be recent, and a lot of good ones will skip the posting without that sentence.

Some of the best Rust hires I have seen were C and C++ engineers with a year or two of Rust on top. The Plymouth hire was one of them. They read “five years of production Rust” as a closed door. One line opens it. “We will consider strong C or C++ systems engineers who have written Rust in the last two years, at work or on their own.” If the seat is permanent, our direct hire staffing team recruits from exactly that crossover pool.

Let the Compiler Settings Do the Screening

The Huntsville engineer is still on that team, for what it is worth. The toolchain moved to a newer pinned version this summer after its security review, and he wrote the migration plan. When his team opened a second Rust seat, the posting named the pinned version in its first paragraph and explained the review cycle behind it. Nobody who applied was surprised by anything in week one. It filled in a month.

Your Cargo.toml already knows the edition. The rust-toolchain.toml file knows the compiler version. Your CI configuration knows whether Miri runs and whether a new crate can fail the build. The facts that sort the Rust market sit in files your team edits every week, and most postings never quote them. Open those three files before writing a single responsibility, and the posting that comes out reads like it was written by someone who works on the code. That is exactly what Rust candidates are checking for.

When the seat is ready, talk with a Rust recruiter at KORE1. We place Rust engineers on contract, on contract-to-hire terms, and as direct hires across the U.S., and our twelve-month retention runs at 92%. Rust hires tend to stay when the first week looks like the posting did.