Rust Developer Interview Questions: 50 to Ask in 2026

Rust developer interview questions are prompts that test whether a candidate can manage memory safely without a garbage collector, write concurrent code that the compiler will accept, and ship working programs under the borrow checker's rules. A strong set covers ownership and lifetimes, concurrency, idiomatic error handling, the web framework your stack actually runs, and at least one short coding task scored against a fixed rubric instead of a gut feel.

The 50-plus questions below are grouped the way a hiring process is: a quick screen, a technical round, a framework round for service roles, and a final conversation about real projects. Each one carries what a strong answer covers and, where it helps, the follow-up that separates someone who has read the book from someone who has shipped.

Rust is worth the trouble of a careful interview. It is once again the most admired programming language, at 72%, in the 2025 Stack Overflow Developer Survey, so the people who know it want to keep using it, and the pool stays small relative to demand.

TL;DR

• Test three things before anything else: ownership and the borrow checker, safe concurrency, and error handling with Result and Option. Everything else is downstream of those.
• Ask about the framework the role actually uses. For a web service team that usually means Actix Web or a tokio-based stack, and framework questions expose gaps that generic language trivia hides.
• Run a short coding task. Explaining ownership out loud and satisfying the compiler under time pressure are different skills, and only one of them shows up in production.
• Score answers on a written scorecard so two interviewers grade the same response the same way. The Testlify Human-Led Decision Scorecard is the structure used through this guide.
• The business case for Rust skill is measurable now: Google reports memory safety bugs fell below 20% of Android vulnerabilities for the first time, alongside a 1000x lower memory safety vulnerability density in its Rust code than its C and C++ code.
• Hire for compiler literacy, not crate trivia. A candidate who reads an error message calmly will learn your codebase. One who memorized 30 crate names will not.

Why test Rust skills instead of trusting a resume?

Because a resume cannot show you whether someone works with the borrow checker or fights it. Rust has a steep learning curve, and the distance between "used Rust on a side project" and "shipped a concurrent service in Rust" is wide enough to sink a quarter. A skills test closes that gap by scoring real code rather than self-reported confidence.

The payoff for getting it right is now documented rather than argued. Google's security team reports that memory safety vulnerabilities fell below 20% of total Android vulnerabilities for the first time, down from more than 75% four years earlier, and that its Rust code shows a 1000x lower memory safety vulnerability density than its C and C++ code. The same report puts numbers on the productivity side: Rust changes carry a 4x lower rollback rate and spend about 25% less time in code review.

Read that as a hiring argument, not a language war. Those gains come from code that people produce when they understand ownership well enough to avoid the escape hatches. A team that hires someone who reaches for .clone() and unsafe whenever the compiler objects gets the compile times of Rust with the bug profile of C++. The screening question is not "do you know Rust" but "do you know it well enough to earn what it costs."

Scale matters too. The Rust project's own 2025 State of Rust Survey collected 7,156 responses across 30 days, its tenth annual run, which tells you this is a settled professional community with established norms, not an early-adopter crowd. Candidates can be measured against real conventions, and a good interview should check whether they follow them.

A note on where tooling fits. Testlify scores the candidate: skills tests, coding assessments, and AI interviews that grade a shortlist before anyone spends live interview time. It ships job requisitions, an application form and a hiring pipeline for teams that do not run an applicant tracking system yet, and it integrates with the one you already use as a screening layer rather than replacing your system of record. A scored Rust developer assessment and a structured interview catch different failures, which is the reason to run both.

What does a great Rust developer actually know?

Strong Rust engineers share a few habits. They reason about ownership out loud before they type. They reach for the type system before reaching for unsafe. They treat errors as values to be handled, not afterthoughts to be unwrapped. And they read a compiler error as information rather than an insult.

Those habits are gradeable, which is the point of using a scorecard. The Testlify Human-Led Decision Scorecard turns candidate evidence into a structured decision by combining assessment results, AI insights, reviewer feedback and interview data while the final judgment stays with the hiring team. Applied to a Rust role, it resolves to four weighted dimensions.

Pro Tip: Set the weights before you meet anyone. A high-throughput service role should push concurrency to 35% and let memory safety and idiomatic style share what is left. An embedded role should do the opposite. A scorecard tuned to the role beats a generic checklist, and fixing the weights in advance kills the halo effect where one clever answer carries an otherwise weak interview.

One tell shows up again and again in technical screens: candidates who pass cleanly describe the borrow checker as a helper. The ones who describe it as "fighting the compiler" tend to struggle once a codebase grows past a few thousand lines, because the fight gets worse, not better. It is a small signal that predicts a lot, and it costs nothing to listen for.

When should you ask these questions?

Spread them across three stages so live interview time goes only to candidates worth it. A short screen filters obvious mismatches. A technical round tests depth. A final round checks how someone works with other people, which is where senior hires actually fail.

• Screen, 20 to 30 minutes: three or four general questions plus one small coding task. You are checking that ownership and error handling are real knowledge, not memorized definitions.
• Technical round, 60 minutes: the advanced questions below, live or async, plus framework questions if the role is a service. Watch how the candidate reads a compiler error.
• Final round, 15 to 20 minutes: the experience questions, plus soft-skills and collaboration signals. A brilliant engineer who cannot review a teammate's pull request calmly is still a risk to the team.

Running a scored assessment before the screen changes the math on all of this. If a pre-interview coding assessment has already graded 40 applicants, the screen exists to confirm the score and check communication, not to discover basic ability. Teams under 200 people feel this most, because the interviewers are the same engineers who have to ship the roadmap.

What general Rust interview questions should you ask?

These 25 questions check whether a candidate understands what makes Rust different from the language they used before it. For each one, the italic line is what a strong answer covers, so any interviewer on the panel can grade consistently. Several carry a follow-up, which is usually where the real signal lives.

1. Explain Rust's ownership model. How is it different from the last language you used?

What a strong answer covers: Ownership, borrowing and lifetimes manage memory with no garbage collector and no manual free. Every value has one owner, the value is dropped when the owner goes out of scope, and references borrow access without taking ownership. The Rust documentation defines it plainly: ownership is a set of rules that govern how a Rust program manages memory. A strong answer contrasts this with manual management in C++ and collection pauses in Java or Go. Follow-up: ask what ownership costs them, because a candidate who says "nothing" has not written enough Rust to hit a self-referential structure.

2. What are lifetimes, and how do they help with memory safety?

What a strong answer covers: Lifetimes are annotations that tell the compiler how long a reference stays valid, which stops dangling references and use-after-free bugs before the program runs. Listen for the clarification that lifetimes describe existing relationships rather than changing how long data lives. A candidate who says a lifetime annotation "makes the data live longer" has the mental model backwards, and that misunderstanding produces some very strange code.

3. How do you handle errors in Rust?

What a strong answer covers: Result for recoverable failure, Option for absence, handled by pattern matching or the ? operator, with no exceptions anywhere. A senior answer distinguishes library code from application code: libraries return concrete or boxed error types so callers can decide, while applications can collapse everything into one error type near the top. Red flag: heavy unwrap() outside tests and prototypes.

4. What is a trait, and how do you use one?

What a strong answer covers: Traits define shared behavior, roughly like interfaces, but they can carry default methods and be implemented for types you did not define. A good candidate defines one, implements it, and mentions trait bounds. Follow-up: ask about the orphan rule, which stops you implementing a foreign trait for a foreign type. Anyone who has published a crate has met it.

5. Explain Rust's concurrency model.

What a strong answer covers: Safe concurrency falls out of ownership. The type system prevents data races at compile time through Send and Sync, so shared mutable state has to be made explicit with Mutex, RwLock or atomics. Expect threads, channels, and an honest note that Rust prevents data races but not deadlocks or logic races.

6. What are smart pointers? Give examples.

What a strong answer covers: Box for heap allocation and recursive types, Rc for shared ownership on one thread, Arc for thread-safe shared ownership, and RefCell for interior mutability with borrow checking moved to runtime. Each should come with a use case rather than a definition. Follow-up: ask what happens when two Rc values point at each other, which is the reference-cycle leak that Weak exists to solve.

7. How does pattern matching work?

What a strong answer covers: match destructures and inspects values including enums, tuples, structs and slices, with guards for extra conditions. The key property is exhaustiveness: the compiler forces every case to be handled, so adding a variant to an enum turns into a list of compile errors instead of a silent runtime bug. That property is why experienced Rust developers model state as enums.

8. What is the purpose of Cargo?

What a strong answer covers: Cargo is the build tool and package manager. It resolves dependencies, builds, tests, generates docs, and runs benchmarks, all driven from Cargo.toml. The tooling is a real part of Rust's appeal, and the 2025 Stack Overflow survey found Cargo the most admired cloud development and infrastructure tool at 71%, so a candidate who shrugs at it is unusual.

9. What is the difference between &str and String?

What a strong answer covers: &str is a borrowed view into UTF-8 bytes; String is owned, growable and heap-allocated. The practical rule follows: take &str in function arguments so callers can pass either, and return String when you have to own the result. A candidate who writes fn f(s: String) for a read-only argument is forcing an allocation at every call site.

10. How do you ensure thread safety?

What a strong answer covers: Ownership plus Arc for shared data and Mutex or atomics for mutation, with the compiler rejecting most races before they run. The better answer adds that a Mutex in Rust wraps the data rather than sitting beside it, so you cannot forget to take the lock. That design detail is the part people who have only read about Rust tend to miss.

11. How would you make a Rust program faster?

What a strong answer covers: Profile first with perf or a flamegraph, then cut allocations, pick the right data structure, and use iterators that compile down to the same code as a hand-written loop. Listen for release mode: a surprising number of "Rust is slow" reports are benchmarks run in debug. Red flag: optimizing before measuring.

12. How does Rust manage allocation and deallocation?

What a strong answer covers: Deterministically, through ownership and scope. When a value goes out of scope, Drop runs and memory is released at a predictable point, so there is no collector pause. This is the property that makes Rust workable for audio, games and embedded targets where a 10 millisecond pause is a defect.

13. What are macros, and when do you write one?

What a strong answer covers: Declarative macros written with macro_rules! and procedural macros including custom derives generate code at compile time. Expect a real example such as vec! or a derive for serialization. The judgment part matters more than the syntax: a good candidate says macros are a last resort after functions and generics, because they are harder to read and debug.

14. Explain how iterators work.

What a strong answer covers: Iterators are lazy. Adaptors like map and filter build a chain that does nothing until a consumer such as collect or sum drives it. Strong candidates mention that the chain usually compiles to the same machine code as the equivalent loop, which is what "zero-cost abstraction" means in practice rather than as a slogan.

15. What is unsafe, and when would you use it?

What a strong answer covers: unsafe unlocks raw pointer dereferences, foreign function calls and a few other operations the compiler cannot verify. A mature answer treats it as rare, small, wrapped in a safe API, and documented with the invariant the caller must uphold. It also corrects the common myth: unsafe does not turn off the borrow checker, it adds five specific powers.

16. How do you write and run tests?

What a strong answer covers: test functions marked with the test attribute and run by cargo test, unit tests in a test-only module beside the code, integration tests in the tests directory, and doc tests that keep examples in the documentation honest. Doc tests are a good signal, because they show someone who has maintained a crate other people depend on.

17. Which crates do you reach for, and why?

What a strong answer covers: Common picks are serde for serialization, tokio for async, reqwest for HTTP clients, thiserror or anyhow for errors, and tracing for instrumentation. Listen for reasons, not a list. Follow-up: ask how they evaluate a new dependency, because a candidate who checks maintenance history and audit status before adding a crate is someone you can trust with your supply chain.

18. How do you handle asynchronous code?

What a strong answer covers: async and await on a runtime, usually tokio, with futures that do nothing until polled. A strong answer names the classic mistake of blocking inside an async function, which stalls the executor thread and silently destroys throughput. The fix is a blocking-task pool, and someone who has debugged this in production will say so without prompting.

19. What is Arc, and when is it the wrong tool?

What a strong answer covers: Atomic reference counting for thread-safe shared ownership, usually paired with Mutex when the data also needs mutation. The "wrong tool" half is the interesting half: Arc<Mutex<T>> around a hot data structure turns a parallel program into a queue. Channels, sharding, or giving each worker its own copy often beat it.

20. How do you manage dependencies and reproducible builds?

What a strong answer covers: Cargo.toml for declaring crates and version requirements, Cargo.lock committed for binaries so builds reproduce, and feature flags to keep compile times and binary size under control. Follow-up: ask what they do about a transitive dependency with a security advisory, which separates people who have run a real service from people who have not.

21. Describe a hard problem you hit in Rust and how you solved it.

What a strong answer covers: A concrete story, often the borrow checker, async lifetimes or foreign function interfaces, with a real fix and a lesson. This question rewards specifics. "The borrow checker was annoying until it clicked" is a tutorial answer; "we had an Arc<Mutex<HashMap>> under contention and moved to sharded locks" is a practitioner answer.

22. How do you keep code idiomatic?

What a strong answer covers: rustfmt for formatting, Clippy for lints, and a preference for the standard library over reinvention. Expect concrete idioms: returning iterators instead of collecting into vectors, using impl Trait in argument position, deriving traits rather than hand-writing them. Clippy in continuous integration is a good sign of a team habit rather than a personal one.

23. Explain the module system.

What a strong answer covers: Crates are compilation units, modules organize code inside them, and pub, pub(crate) and use control visibility and paths. A clear answer covers the difference between a binary crate and a library crate, and mentions that privacy in Rust is module-based rather than class-based.

24. How do you debug Rust code?

What a strong answer covers: Read the compiler error first, because it usually contains the fix. Then dbg!, structured logging with tracing, and rust-gdb or lldb for real debugging. Look for a workflow, not a tool list. A candidate who mentions reaching for a debugger on async code has been somewhere painful and come back.

25. How does type inference work, and where does it stop?

What a strong answer covers: The compiler infers most types inside function bodies from usage, while function signatures always require explicit types. Strong candidates mention the cases where inference needs help, such as collect() needing a target type, which is the error every Rust developer has seen and can explain in one sentence if they have written real code.

Which Actix interview questions should you ask?

If the role builds HTTP services, language questions alone will not tell you whether someone can ship. Actix Web is one of the two frameworks most Rust service teams standardize on, and it has enough sharp edges that framework questions expose experience quickly. Ask these when the job description mentions APIs, and swap in the equivalents if your team runs a different framework on the same tokio runtime.

26. What does HttpServer::new actually do with the closure you pass it?

What a strong answer covers: It calls that closure once per worker thread to build a separate application instance, so anything constructed inside the closure exists once per worker rather than once per process. This is the single most common Actix bug in interviews and in production: a counter or cache created inside the closure silently becomes several independent counters. The fix is to build shared state outside, wrap it in web::Data, and clone the handle into each worker.

27. How does state sharing work, and what does web::Data wrap?

What a strong answer covers: web::Data<T> is an Arc around your state, registered with app_data and extracted by type in handlers. Two details separate real users: cloning web::Data clones the Arc rather than the data, and extracting a type you never registered compiles fine but fails at runtime with an internal server error. A candidate who has hit that second one will mention it unprompted.

28. Explain extractors. How would you write your own?

What a strong answer covers: Extractors turn parts of a request into typed arguments: web::Json for a deserialized body, web::Path for route segments, web::Query for the query string, web::Data for shared state. A custom one implements FromRequest, which is how teams build an AuthenticatedUser extractor that pulls and validates a token once instead of in every handler. That pattern is a good architecture signal.

29. What happens if you call a blocking function inside a handler?

What a strong answer covers: You block a worker thread, and since each worker serves many connections, throughput collapses under load while the service still looks healthy in a single-request test. The answer is web::block for synchronous work like file access or a blocking database driver, or an async driver instead. Listen for the diagnosis as much as the fix: "requests queue behind each other under concurrency" shows someone who has profiled a real service.

30. How do you write middleware, and when would you not?

What a strong answer covers: Middleware wraps the service chain, either with the Transform trait for full control or with a lighter wrapper function for simple cases, and is registered with wrap. Strong candidates note that middleware runs in reverse registration order for responses, and that per-route concerns like input validation usually belong in an extractor rather than in middleware that runs for every request.

31. How do you turn an application error into an HTTP response?

What a strong answer covers: Implement ResponseError for your error type so handlers can return Result and the framework maps failures to status codes in one place. The mature version of this answer distinguishes what the client sees from what gets logged: a database failure becomes a 500 with a generic body and a full internal log line, never a leaked error string. Candidates who have handled a security review bring this up themselves.

32. Do futures in Actix handlers need to be Send?

What a strong answer covers: Actix Web runs a single-threaded runtime per worker, so handler futures do not have to be Send, which is a genuine difference from frameworks that spawn onto a multi-threaded scheduler. It matters because it lets you hold non-Send types across an await point, and because it changes how work is moved between threads. Very few candidates get this one, so treat it as a bonus signal rather than a filter.

33. How do you test an Actix service?

What a strong answer covers: The test utilities let you build an app in-process and send requests to it without binding a socket, so handler tests run fast in continuous integration. A good answer separates handler tests from integration tests that use a real database, and mentions how test state is isolated between cases. Someone who says "we test with curl against a running server" has not automated this yet.

34. How do you structure routes as a service grows?

What a strong answer covers: Scopes group related routes under a shared path prefix and shared middleware, and route configuration can be split into separate modules with a configuration function per domain area. Look for a candidate who has split a monolithic route table before, because the answer usually comes with an opinion about where to draw the module boundaries.

Pro Tip: Framework questions are also the fastest way to check honesty. A candidate who says "I used Actix on one service two years ago and would need to re-read the extractor docs" is telling you something accurate and useful. One who claims deep familiarity but cannot describe the per-worker closure has rehearsed a keyword. Score the accuracy of self-assessment as its own signal.

Should you test for Rust, C++, or Go instead?

Most systems roles could reasonably run in Rust, C++ or Go, and a candidate who chose Rust should be able to defend the choice past "it is memory safe." Use the table to frame the question, then listen for whether the answer matches the row rather than the marketing.

35. Why would you choose Rust over C++ for a new systems project?

What a strong answer covers: Compile-time memory safety with no collector, a package manager and build tool that C++ still lacks natively, and refactoring confidence because the compiler catches what a C++ reviewer would have to catch by eye. A balanced answer also names what C++ still wins on: mature libraries in some domains, a deeper hiring pool, and decades of existing code you may have to live with.

36. Why would you choose Rust over Go for a networked service?

What a strong answer covers: No collector pauses, finer control over memory layout and tail latency, and abstractions that cost nothing at runtime, traded against a longer ramp-up and a smaller hiring pool. The honest version of this answer says Go is often the right call for a standard service, and Rust earns its cost when latency targets are tight or the binary runs somewhere constrained. A candidate who claims Rust is always correct is selling, not engineering.

What advanced questions test ownership and concurrency?

These push past the basics. They separate a candidate who has read the documentation from one who has fought these exact problems in a codebase with other people in it, including where Rust is being used now: WebAssembly, embedded targets, large workspaces, and AI-assisted development.

37. When would you reach for interior mutability, and what does it cost?

What a strong answer covers: RefCell or Cell let you mutate through a shared reference when the static borrow rules are too strict for a pattern that is actually valid, at the cost of moving borrow checking to runtime, where a violation panics instead of failing to compile. Strong candidates name the threaded equivalent, Mutex or RwLock, and flag that RefCell in a multi-threaded context will not compile at all.

38. Explain lifetime elision.

What a strong answer covers: The compiler applies a fixed set of rules to infer lifetimes in common signatures, so annotations are only required when there are multiple reference inputs and an ambiguous output. Ask them to state one of the rules. A candidate who can say "a method with &self gives the output the lifetime of self" has read the reference rather than absorbed folklore.

39. What is a self-referential struct, and why is it hard in safe Rust?

What a strong answer covers: A struct holding a reference into its own data is hard because moving the struct invalidates that internal reference, and Rust moves values freely. Strong candidates mention Pin and connect it to async, where the compiler generates exactly this shape for a state machine that holds a borrow across an await point. That connection is the mark of someone who has debugged async lifetimes.

40. How do you choose an async runtime, and what breaks if you mix them?

What a strong answer covers: tokio is the de facto standard with the largest ecosystem, and most libraries assume it. Mixing runtimes in one binary causes runtime-specific types to panic when polled outside their own executor, usually with a confusing "no reactor running" style error at runtime rather than a compile failure. Anyone who has pulled in a library with a hidden runtime dependency will recognize this immediately.

41. When would you implement Send or Sync by hand?

What a strong answer covers: Almost never. Both are derived automatically when every field qualifies, and implementing either by hand is an unsafe assertion that you have upheld a guarantee the compiler could not verify, typically for a type holding raw pointers in a foreign function interface wrapper. The correct answer includes "and I would document why" rather than a mechanism.

42. How do you cancel an in-flight async task cleanly?

What a strong answer covers: Dropping a future cancels it at its next await point, so cleanup has to live in Drop or behind a cancellation token rather than in code after the await that may never run. Follow-up: ask what happens to a half-finished database transaction when the client disconnects. This is where cancellation stops being trivia and starts being a data-integrity question.

43. What changes when you compile to WebAssembly?

What a strong answer covers: No operating system threads or filesystem access by default, a different allocator story, and a binding layer to cross into JavaScript. Binary size and load time become first-class concerns, so build flags and size profiling matter in a way they do not for a server binary. Ask this only if the role touches the browser or edge runtimes.

44. What is no_std, and when do you need it?

What a strong answer covers: no_std drops the standard library in favor of core, which is required on microcontrollers and other targets with no operating system underneath. A strong candidate explains what they lose, mainly heap allocation and collections unless they add an allocator, and how that changes ordinary code such as error handling and string building.

45. How do you use AI coding assistants with Rust, and where do you stop trusting them?

What a strong answer covers: Comfortable delegating boilerplate, test scaffolding and first-pass implementations, while treating anything touching unsafe, lifetimes or concurrency as a draft to verify line by line. The best answers name the specific failure mode: generated Rust often compiles but over-clones or over-annotates to satisfy the borrow checker, which is exactly the habit you are screening against. This question is worth asking every candidate now.

46. A teammate's pull request adds clones and lifetime annotations to satisfy the compiler. How do you review it?

What a strong answer covers: Treats it as teaching rather than gatekeeping: explains the simpler ownership pattern that removes the need for the clone, points to the relevant documentation, and re-reviews rather than rejecting with a one-line comment. You are testing temperament here as much as skill, and this is the question that most often changes a hiring decision for a senior role.

47. When do you prefer trait objects over generics?

What a strong answer covers: Trait objects give runtime polymorphism at the cost of a pointer indirection and a vtable lookup; generics monomorphize at compile time for direct calls but grow compile time and binary size. A strong answer picks generics when the call site is hot and known, and trait objects when the set of types varies at runtime, such as a plugin registry or a heterogeneous collection.

48. How do you manage a multi-crate workspace?

What a strong answer covers: A workspace shares one lock file and one target directory across member crates, so a shared library compiles once rather than per consumer, and dependency versions stay unified. Look for experience splitting a monolith into members to cut incremental build times, plus an honest note that workspaces do not fix a bad dependency graph, they only make it visible.

49. What is a minimum supported Rust version, and how do you manage one?

What a strong answer covers: It is the oldest compiler version a crate promises to build with, pinned in Cargo.toml, tested in continuous integration on that exact toolchain, and raised deliberately. Teams that publish crates care about this a lot; teams shipping a container image often do not need one at all. A candidate who asks which situation applies to you is thinking about context, which is a good sign.

50. Where do you draw the line between panic! and returning a Result?

What a strong answer covers: Panic for bugs and broken invariants a caller could never legally trigger; Result for expected failure the caller should handle, such as bad input or a missing file. A library that panics on user input is a library that takes down its callers. Someone who reaches for unwrap() in library code by default has not internalized the distinction yet.

51. How would you review an unsafe block added for a foreign function call?

What a strong answer covers: Check that a safety comment documents exactly which invariant the caller must uphold, confirm the block is as small as it can be, and verify the safe wrapper cannot be called in a way that violates that invariant. No safety comment means the review stops there. This question doubles as a check on whether the candidate will raise the standard of your codebase or quietly lower it.

52. How do you benchmark a performance change?

What a strong answer covers: A benchmarking harness that runs enough iterations to control for noise, warms the cache, and reports a confidence interval rather than one wall-clock number. Candidates who have done this mention variance, outliers or warm-up without being asked, and they know that a 3% improvement measured once is usually nothing.

Which coding questions test real Rust skills?

Short tasks, five to seven minutes each. The goal is not trick puzzles. It is whether someone writes compiling, idiomatic Rust under mild time pressure, and whether they can explain what the compiler is telling them. Run these as a scored assessment before the interview so live time goes to the judgment questions instead.

53. Reverse a string.

Write a function that takes a &str and returns a new String with the characters reversed. Look for chars().rev().collect() rather than byte indexing, and for the candidate to mention that reversing bytes breaks multi-byte characters. The best answers go further and note that reversing by character still mangles emoji built from several code points, which is a correctness detail most people miss.

54. Compute a factorial.

Write a function that takes a u32 and returns its factorial. Look for a base case and clean recursion or a fold, plus an unprompted note that this overflows fast and that debug builds panic while release builds wrap. A candidate who reaches for checked_mul or a wider integer type is showing you how they will handle arithmetic in your codebase.

55. Check whether a number is prime.

Write a function that takes a u32 and returns true if it is prime. Look for an early return, a square-root bound on the loop, and correct handling of 0 and 1. This one is mostly a warm-up, but it does catch the candidate who writes a loop to n and never questions it.

56. Sum a vector without a manual loop.

Write a function that takes a Vec<i32> and returns the sum. Look for iter().sum(), and ask why the argument might be better as a slice. A candidate who says "take a slice of i32 so callers can pass an array or part of a larger vector" understands borrowing at the API level, not just inside a function body.

57. Merge two sorted vectors.

Write a function that takes two sorted vectors and returns one sorted vector containing all elements. Look for a working answer first. Extending and sorting is fine and honest; a candidate who mentions that a linear merge beats a re-sort for already-sorted input, and then says it is not worth the complexity at this size, is demonstrating exactly the judgment you want in code review.

58. Fix code that does not compile.

Give them a function that takes ownership of two strings and returns the longer one, plus a caller that uses one of those strings afterward. Look for the diagnosis before the fix: the value was moved into the call, so it is no longer available to the caller. A strong fix changes the signature to borrow. A weak fix sprinkles .clone() until the red underline disappears. Both compile. Only one of them scales.

Pro Tip: Grade question 58 on reasoning, not speed. The candidate who talks through why the move happened before typing understands ownership. The one who pastes .clone() everywhere does not, and the resulting code will look fine in review and allocate on every request in production.

How do you score answers across a panel?

Two interviewers hearing the same answer will grade it differently unless you give them a shared instrument. That is the whole job of a scorecard: it converts opinions into evidence that can be compared across candidates and defended later.

Fill it in during the interview, not afterward from memory. Reconstructed scores drift toward whoever spoke most confidently, which is a known way to hire a good talker over a good engineer. Each dimension gets a 1 to 5 rating and one line of evidence, and the line of evidence is the part that matters: "explained why Arc<Mutex> serialized their workers, proposed sharding" is a usable note. "Strong on concurrency" is not.

Aggregate with the weights you set before the process started. A candidate who scores 5 on idiomatic style and 2 on concurrency is not a 3.5 for a high-throughput service role; they are a no for that role and possibly a yes for a different one. Testlify's multiple-reviewer scoring, skill-level breakdowns and candidate comparison exist to keep that arithmetic honest, with the decision staying where it belongs, in the hiring team's hands.

Key Takeaway: An interview only measures what the scorecard asks about, and most Rust interviews ask the wrong things because trivia is easy to grade. Language definitions can be recited by anyone who read the documentation on the train, so they separate almost nobody. The two dimensions that actually predict whether a hire ships in their first month are compiler literacy, meaning how they behave when the build fails, and fluency in the framework the team runs every day. Both take longer to grade and both are worth the time. The practical move is to fix your four dimensions and their weights before the role is posted, then delete any question that does not map to one of them. A shorter interview that grades the right things beats a longer one that grades what was convenient to ask, and it gives every candidate the same bar to clear.

How do you gauge a candidate's experience?

These five open questions separate someone who has shipped Rust from someone who has studied it. There are no clean reference answers. You are listening for specifics, scars and judgment, and the follow-up matters more than the first response.

• Describe a project where you used Rust for a specific module. What broke, and how did you fix it?
• Where has Rust measurably improved performance for you? Give real numbers if you have them, including how you measured.
• Have you connected Rust to another language across a foreign function interface? What made it hard?
• Which open-source Rust projects have you contributed to, and what was your actual change?
• Which pattern from another language did you try in Rust and have to abandon?

That last question is the most useful one on this page. Everyone who has learned Rust properly has abandoned something: inheritance hierarchies, shared mutable state passed around freely, or a linked list built the way they would build it in C. A candidate who cannot name one has either not written enough Rust or is not reflecting on how they write it.

What should you pay a Rust developer?

Rust pay is set by scarcity rather than by the job title. The people who know it well tend to be senior engineers who chose it deliberately, often moving from C++ or Go, and they know what the skill is worth. Budget for the specialization, not for a generic backend band, or expect your offers to be declined late in the process.

Three variables move the number more than anything else.

The practical move is to decide the band before the first interview and tie it to scorecard outcomes rather than to negotiation stamina. Teams that skip this step end up paying senior rates for a candidate who interviewed well and scored a 3 on every dimension that mattered.

What mistakes do hiring managers make?

Good questions inside a broken process still produce bad hires. These five mistakes show up most often, and each has a cheap fix.

Testing trivia instead of compiler literacy. Asking "what is a lifetime" gets a memorized definition that a candidate could have read on the train. Asking someone to fix a lifetime error in five lines of broken code, like question 58 above, produces a real signal, because a wrong mental model and a right one look identical until the compiler runs.

Skipping the coding round because the panel feels unqualified to grade it. This is common on small teams where the hiring manager is not a Rust developer. A scored coding assessment with a fixed rubric removes the dependency: the panel reads a scored breakdown instead of raw code. Testlify's coding questions run in an embedded editor with up to 20 test cases per question, visible or hidden, scored per test case, so the output is a graded result rather than a snippet someone has to interpret.

Treating "knows Rust" as one skill. A candidate strong in embedded no_std work and a candidate strong in async web services share the language and almost nothing else day to day. Score the dimensions the role needs rather than issuing a general pass or fail, and be explicit in the job description about which one you are hiring.

Letting one clever answer carry a weak interview. A candidate who nails the ownership question but cannot explain a Result chain is average, not exceptional. The halo effect is strongest in technical interviews where the interviewer is impressed by an answer they would not have given themselves. A weighted scorecard filled in live is the defense.

Comparing candidates on resume keywords instead of comparable evidence. Two people who both list "Rust, 3 years" can be at opposite ends of the skill range, because one spent those years in a codebase with review standards and the other did not. Run the same coding test and the same scorecard for everyone in a role, and the comparison becomes real instead of rhetorical.

One more, less obvious than the rest: interviewing for Rust when the job does not need it. If the service is a standard web API with modest latency requirements, a strong Go or Java team will ship it sooner. Rust earns its hiring difficulty when memory safety, tail latency or a constrained target genuinely matters. Hiring for it out of preference rather than need makes an already thin pool thinner and slows the roadmap.

Hire Rust developers with confidence

Set your scorecard weights, send a short Rust developer test to every applicant, and interview only the people who clear the bar. Build the rest of the pipeline from the assessment question library and pair it with broader technical screening when the role spans more than one language.

Start free with Testlify and assemble a Rust screening round in under an hour, or book a demo to see how scored assessments slot into the pipeline you already run.

Frequently asked questions