Hire Rust developers

Rust gives you memory safety without a garbage collector, and hiring for it means accepting a small, strong talent pool and being clear about why you need it.

What Rust actually is

Rust is a systems programming language with a compiler that enforces memory safety at compile time rather than through a runtime garbage collector. It achieves this through ownership rules the compiler checks: every value has one owner, references are tracked, and code that could produce a dangling pointer or a data race generally does not compile. It is governed by a foundation with a stable release every six weeks.

The practical result is performance comparable to C and C++ with an entire category of bug removed. Memory corruption, use after free and data races between threads are the vulnerabilities that have dominated serious security advisories in systems software for decades, and Rust makes most of them compile errors. That argument has been strong enough to move parts of operating systems, browsers and infrastructure software.

The cost is the learning curve and the hiring pool. Rust takes longer to become productive in than any other language on this list, because the compiler enforces discipline that other languages leave to the developer. The pool is small, enthusiastic and expensive. Choosing Rust is a commitment that should follow from a requirement rather than from interest, and a good Rust developer will tell you when that requirement is absent.

The part that separates seniors from mid-levels

Ownership and borrowing are the whole language. A value has one owner; when the owner goes out of scope the value is freed. References borrow a value without taking ownership, and the compiler enforces that you may have many immutable borrows or one mutable borrow, never both. This single rule prevents data races and most memory errors, and it is also why newcomers spend their first weeks arguing with the compiler. Fluency here is the difference between productive and frustrated.

Lifetimes are the part that follows, and where candidates separate. The compiler must be able to prove that a reference does not outlive what it refers to, and sometimes it needs annotations to do so. Most code needs none, thanks to inference. Code that does need them, particularly library code holding references in structs, is where developers either understand the model or reach for cloning and reference counting to make the error go away.

Error handling is the third and it reflects the language's character. There are no exceptions. Fallible operations return a Result that the caller must handle, which makes every failure path visible in the signature. This is verbose and it is also why Rust programs tend to fail predictably. Candidates who talk about error types as part of their API design, rather than as a nuisance, are describing genuine experience.

Where Rust is used

The label “Rust developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Systems and infrastructure software

Databases, proxies, runtimes and operating system components, where performance and safety both matter.

Performance-critical services

Workloads where predictable latency without garbage collection pauses is the requirement.

Cryptography and security software

Where memory safety is a security property rather than a convenience.

WebAssembly

Compiling to run in browsers and edge runtimes, an area where Rust has strong support.

Embedded systems

Constrained devices where a garbage collector is not acceptable and safety still matters.

Command-line tooling

Developer tools distributed as single fast binaries, a popular and practical use.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Rust versions are still supported

Rust releases every six weeks with a strong stability guarantee, and editions allow language evolution without breaking existing code, which makes staying current unusually low risk.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 1 are still maintained and 7 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Rust alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Cargo

Build, dependency management and test runner. Widely regarded as one of the best in any ecosystem.

Tokio

The dominant asynchronous runtime, underneath most network services.

Axum or Actix Web

HTTP frameworks for building services.

serde

Serialisation and deserialisation, used almost universally.

sqlx or Diesel

Database access, with compile-time query checking in the first case.

Clippy and rustfmt

Linting and formatting, standard and near-universally adopted.

criterion

Benchmarking, since Rust is usually chosen for performance that should be measured.

The type system itself

Used deliberately to make invalid states unrepresentable, which is idiomatic here more than anywhere.

Related skills that frequently appear on the same specification: Go, TypeScript, AWS, DevOps, Kubernetes.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Ownership and borrowing

The foundation. Someone unclear here cannot write idiomatic Rust.

• Strong answer: Explains the rules naturally, and can describe restructuring code to satisfy the borrow checker rather than working around it.
• Warning sign: Clones everywhere or reaches for reference counting to silence errors.

When they fought the borrow checker and what it taught them

Everyone does. The response is informative.

• Strong answer: Describes a case where the compiler was pointing at a real design problem, and how the design changed.
• Warning sign: Describes the compiler as an obstacle to be circumvented.

Error handling design

Rust makes failure paths explicit and the API design around them matters.

• Strong answer: Designs error types deliberately, uses the appropriate crates, and distinguishes recoverable from unrecoverable.
• Warning sign: Unwraps routinely in code that is not a prototype.

Async Rust

Genuinely harder than async in most languages and where much service work lives.

• Strong answer: Understands the runtime, knows what blocking inside async does, and can explain a pinning or lifetime problem they hit.
• Warning sign: Has used async without any model of the runtime underneath.

Unsafe code

Rust allows escaping its guarantees, and how someone treats that is revealing.

• Strong answer: Avoids it, and where it is necessary, isolates it behind a safe interface with documented invariants.
• Warning sign: Uses unsafe to resolve borrow checker complaints.

Why Rust for this problem

The most important question, because Rust is frequently chosen for the wrong reasons.

• Strong answer: Names the specific requirement: latency predictability, memory safety in a security context, or embedded constraints.
• Warning sign: Advocates Rust generally without reference to a requirement.

Compile times and how they manage them

A genuine practical cost of the language.

• Strong answer: Uses workspaces, watches dependency weight, and has improved a slow build.
• Warning sign: Has never worked on a codebase large enough for it to matter.

Warning signs in a Rust codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Cloning to satisfy the compiler

• What you see: Clone calls scattered wherever a borrow error appeared.
• What it costs: Allocation and copying that removes the performance advantage Rust was chosen for.
• The fix: Restructure ownership. The borrow checker is usually indicating a design problem rather than being obstinate.

Unwrap in production code

• What you see: Results and options unwrapped without handling the failure case.
• What it costs: A panic, which terminates the thread or the process, for a condition the type system had already flagged.
• The fix: Handle the error or propagate it. Reserve unwrap for cases where the invariant is genuinely guaranteed and say why.

Unsafe as an escape hatch

• What you see: Unsafe blocks used to bypass borrow checking rather than for a genuine need.
• What it costs: The language's central guarantee discarded, reintroducing exactly the bugs it was chosen to prevent.
• The fix: Treat unsafe as requiring justification and review. Isolate it behind a safe interface with its invariants documented.

Blocking inside async

• What you see: Synchronous file or network operations inside an async function.
• What it costs: The runtime's worker thread is blocked, so unrelated tasks stall under load.
• The fix: Use async-aware libraries, or move blocking work to a dedicated thread pool explicitly.

Over-engineering with the type system

• What you see: Elaborate generic and trait structures for straightforward application code.
• What it costs: Compile times rise, error messages become unreadable, and nobody else can modify it.
• The fix: Use the type system to prevent real errors. Keep application code simple and reserve sophistication for library boundaries.

Choosing Rust without a reason

• What you see: A standard web service in Rust because the team wanted to use it.
• What it costs: Slower delivery, a smaller hiring pool, and no benefit over a more productive language.
• The fix: Choose it for latency predictability, safety requirements or resource constraints. Otherwise choose productivity.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Rust developer.

Junior

Writes code within an established structure. Expect a longer ramp here than in any other language on this list.

Mid-level

Owns a module including its error types and tests. Works with the borrow checker rather than against it.

Senior

Owns architecture, the async model, public API and error design, and can justify unsafe where it appears.

Staff

Owns the case for Rust in the organisation, the shared library surface, and the boundaries with services in other languages.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

Performance-critical component

• Usual team: One to two senior developers.
• What governs it: The usual justified case. Rewriting a hot path rather than a whole system.

New service in Rust

• Usual team: Two developers, at least one experienced in Rust.
• What governs it: Slower to deliver than an equivalent service elsewhere. Justified by a stated requirement.

Command-line tooling

• Usual team: One developer.
• What governs it: A good first Rust project. Single-binary distribution is a real advantage.

WebAssembly component

• Usual team: One developer with both Rust and web experience.
• What governs it: Scoped by the boundary between Rust and JavaScript, which is where the work concentrates.

Team upskilling

• Usual team: An experienced Rust developer alongside existing engineers.
• What governs it: Budget months rather than weeks. The ramp is genuinely longer than for other languages.

Migration work you may actually be hiring for

A large share of Rust work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

C or C++ to Rust

• Why teams do it: Eliminating memory-safety vulnerabilities without giving up performance.
• What to watch: Incremental through the C interface is the realistic path. Rewrite the components where safety matters most rather than attempting the whole codebase, and expect the interface boundary to need careful design.

A garbage-collected service to Rust

• Why teams do it: Predictable latency where collection pauses are the constraint.
• What to watch: Only justified when pauses are genuinely the problem, which should be measured first. Rewrite one service and compare before committing further.

Synchronous Rust to async with Tokio

• Why teams do it: Concurrency for network-bound services.
• What to watch: Async Rust is substantially harder than synchronous Rust, with lifetime and pinning complications that do not arise otherwise. Only adopt it where concurrency is genuinely the requirement.

An older Rust edition to a current one

• Why teams do it: Language improvements and ecosystem alignment.
• What to watch: Editions are designed to be adopted incrementally and the tooling automates most of it. This is one of the smoother upgrade stories in any ecosystem.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Rust developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Why Rust was chosen, because the answer determines whether the requirement is real.
• Whether the work is systems programming, a network service, WebAssembly or embedded, since these differ considerably.
• Whether async is involved, which is a meaningfully harder skill.
• Whether any unsafe code exists and who is responsible for reviewing it.
• Whether existing team members are learning Rust, since that changes the mentoring expectation.
• Whether interoperability with another language is part of the work.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Rust work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Rust developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Rust developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Rust frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

A small and expensive hiring pool. The main practical constraint. Consider training strong systems developers rather than waiting for Rust experience.

Enthusiasm driving the choice. Ask when they would not use Rust. Someone with no answer may steer you toward it unnecessarily.

Learning-project depth. Ask about async and about a real borrow checker fight. Tutorial Rust and production Rust differ considerably.

Underestimating the ramp for existing staff. Competent developers in other languages take months, not weeks, to be productive here.

Hiring Rust developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Rust developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Should we use Rust for our web back end?

Usually not, unless you have a specific requirement it answers. For ordinary web services, more productive languages will deliver faster with a much larger hiring pool. Rust earns its place where predictable latency without garbage collection pauses matters, where memory safety is a security requirement, or where resource constraints are tight.

How long does it take to become productive in Rust?

Longer than any other language here. A competent developer writes working Rust within a few weeks and spends a few months becoming genuinely comfortable with ownership, lifetimes and async. Teams that budget the usual two-week ramp are surprised. The upside is that once past it, developers report fewer runtime surprises than in any other language.

Is the hiring pool a real problem?

Yes, and it is the main practical objection. Rust developers are fewer and more expensive than developers in comparable languages. The mitigation most organisations use is training strong systems developers rather than recruiting for existing Rust experience, since the language attracts people who want to learn it.

Rust or Go?

Go for services where development speed, a simple language and a larger pool matter, which covers most network services. Rust where you need maximum performance, predictable latency without collection pauses, or memory safety as a security property. Go is the more productive choice for typical back-end work; Rust is the better one when those specific requirements are genuine.

Does Rust really prevent security bugs?

It prevents a specific and historically dominant category: memory corruption, use after free and data races. That category has accounted for a very large share of serious vulnerabilities in systems software. It does not prevent logic errors, injection, or bad authorisation. The claim is narrower than the enthusiasm suggests and it is genuinely significant.

Are Rust compile times a real problem?

They are slower than most alternatives and it is a genuine daily cost, particularly on large codebases with heavy generic code. It is manageable with workspace structure, attention to dependency weight and incremental compilation. It is worth knowing about rather than being surprised by, and it is the complaint experienced Rust developers raise most often.

Can we mix Rust with our existing services?

Yes, and this is usually the sensible adoption path. Rust interoperates well with C interfaces, which most languages can call, and a Rust component behind a network boundary is just another service. Rewriting a hot path or a single component is a far lower-risk way to evaluate the language than committing a whole system.

What does a Rust developer need from us?

A clear reason for the choice, because Rust asks more of everyone and the team should know why. Beyond that, the usual: a working build, a reviewer, and patience during the ramp if other team members are learning. Fast build hardware is a genuine productivity investment here in a way it is not elsewhere.