How to assess · For hiring teams
How to Assess Rust Skills When Hiring
The test formats that actually work for Rust, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.
The short answer
Assess Rust with a task, not a conversation: ownership refactor, build a small library with an api, ai-scored assessment (e.g. cohesyve) or concurrency design conversation. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.
- Works with ownership rather than around it: borrows where possible, clones with a reason, lifetimes only when the compiler needs them
- Models errors with `Result` and a proper error type, and knows when `?`, `thiserror` or `anyhow` is appropriate
- Uses `unsafe` rarely, in small scoped blocks, with a comment stating the invariant
- Designs APIs with the type system: newtypes, builders, and traits that are small and coherent
Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.
Rust is unusual among languages in that the compiler does a lot of the assessing for you: code that compiles has already cleared a bar most languages leave to review. What the compiler cannot tell you is whether a candidate fights the borrow checker or works with it, whether they reach for `unsafe` or `clone()` to make errors go away, and whether they can design an API that is pleasant to use rather than merely correct. This page covers how to assess Rust for systems, backend and infrastructure roles: ownership, error handling, API design, concurrency and the judgement to know when Rust's guarantees are worth their cost.
Why Rust is worth testing
Rust hiring pools are small and résumés overstate. Many candidates have written a few hundred lines and hit the borrow checker; far fewer have shipped and maintained Rust in production. The difference shows in how they handle lifetimes, how much they clone, how they model errors, and whether their code is idiomatic enough for the team to review quickly. Testing separates people who can write Rust from people who can write Rust that others want to maintain.
What strong Rust looks like
- Works with ownership rather than around it: borrows where possible, clones with a reason, lifetimes only when the compiler needs them
- Models errors with `Result` and a proper error type, and knows when `?`, `thiserror` or `anyhow` is appropriate
- Uses `unsafe` rarely, in small scoped blocks, with a comment stating the invariant
- Designs APIs with the type system: newtypes, builders, and traits that are small and coherent
- Chooses between `Arc<Mutex<T>>`, channels and async with reasons, and understands `Send` and `Sync`
- Writes tests, uses `clippy`, and treats warnings as errors
- Knows what Rust is not the right tool for, and says so
Ways to assess Rust
Ownership refactor
Provide a working program that clones excessively and has a needless `Rc<RefCell<T>>`. Ask the candidate to remove unnecessary allocations and explain each ownership decision. Forty-five minutes.
Pros
Cons
Best for Mid and senior Rust roles.
Build a small library with an API
Ask for a small crate — a rate limiter, a parser for a simple format — with a public API, error type and tests. Capped take-home of two to three hours.
Pros
Cons
Best for Roles that own libraries or public interfaces.
AI-scored assessment (e.g. Cohesyve)
Generate a Rust task from the job description — an ownership review, an error-handling design, a concurrency question — with a rubric. Each candidate receives a different variant; reasoning is scored with the code.
Pros
Cons
Best for Screening a pool before engineer time.
Concurrency design conversation
Describe a service that must process messages from many connections with shared state. Ask how they would structure it and what the type system will and will not catch.
Pros
Cons
Best for Senior systems and backend engineers.
Cohesyve
Run a Rust assessment on your next opening
Cohesyve generates a unique Rust task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.
What to test
Ownership and borrowing
Whether they use the model or fight it.
Error handling
Whether failures are typed and propagated well.
API and type design
Whether the code is pleasant and hard to misuse.
Concurrency and unsafe
Whether they understand the guarantees and their limits.
Sample Rust questions
What is the difference between `String` and `&str`, and when do you use each in a function signature?
EntryLook for Owned versus borrowed; accept `&str` when reading, take `String` when storing; awareness of `impl AsRef<str>` for flexibility.
This function clones a vector three times. Which clones are necessary?
MidLook for Reads the ownership flow, identifies borrows that would work, and keeps a clone only where the data genuinely needs to outlive the borrow.
Design the error type for a crate that reads config from a file, parses it and validates it.
MidLook for An enum with variants per source, `From` impls or `thiserror`, and context preserved through the chain.
When is `unsafe` justified, and what do you write next to it?
SeniorLook for FFI, performance-critical invariants the compiler cannot see; a comment stating the invariant and why it holds; a safe wrapper around it.
A shared cache is accessed by many async tasks. How do you structure it?
SeniorLook for Considers `Arc<RwLock>` versus an actor with channels versus a concurrent map; discusses lock contention and holding locks across awaits.
Red flags
- Clones or `unwrap`s to make every error go away
- Reaches for `unsafe` without an invariant comment
- Cannot explain why a value cannot be borrowed mutably twice
- Writes Rust that reads like C++ or Java with extra syntax
- Has never run `clippy`
Scoring rubric
| Criterion | Weight | What strong looks like |
|---|---|---|
| Ownership fluency | 30% | Borrows and lifetimes are used correctly; clones have reasons. |
| Error handling | 20% | Typed errors with context; no unwraps in library code. |
| API design | 20% | Types prevent misuse; traits are small. |
| Concurrency and safety | 20% | Understands `Send`/`Sync`; `unsafe` is rare and justified. |
| Tooling and tests | 10% | Clippy-clean, tested, documented. |
Mistakes hiring teams make
- Testing algorithm puzzles where ownership does not matter
- Not asking why each clone or unwrap is there
- Accepting compiling code as sufficient
- Skipping error-type design — it is where library quality shows
- Assuming C++ experience transfers without testing the ownership model
Roles that need Rust
Common questions
How do I assess Rust if my team does not write it yet?
Use an ownership-refactor task and score the written explanation against the rubric above; the reasoning is readable even to non-Rust engineers. Bring in an external Rust reviewer for finalists.
Is compiling code enough evidence of Rust skill?
No. Code that compiles can still clone everything, unwrap everything and use `unsafe` casually. The compiler enforces memory safety, not judgement.
How long should a Rust assessment take?
Forty-five to sixty minutes for a refactor; two to three hours capped for a small crate. Rust is slower to write than most languages, so budget accordingly.
What should a junior Rust developer know?
Ownership and borrowing well enough to write functions without fighting the compiler, `Result` and `?`, basic traits and generics, and how to write a test. Async and `unsafe` are mid-level topics.
Cohesyve · Skill assessments for hiring
Test Rust before the first interview
Generate a role-specific Rust assessment from your job description and see who can do the work before you spend interview time on them.
1,500+
assessments completed
50%
faster time-to-hire
90%
completion rate
5 min
from JD to assessment
No credit card · 10 free candidates · Plans sized to your hiring volume
From the blog