Rust Onboarding: Decide What to Hire For and What to Teach

Rust onboarding should show an engineer how to build, test, explain, and change your codebase with appropriate review. Before making Rust experience a hiring requirement, decide which responsibilities need expertise on day one and which your team can teach through supervised work. Write that distinction into the role and the learning plan.

A team can get this decision wrong in either direction. It can reject a capable engineer for lacking syntax the team could teach. It can also hire an enthusiastic learner into a role where nobody is available to review their work. An onboarding plan helps you see which situation you are creating before someone accepts the offer.

What does Microsoft’s Rust announcement mean for your team?

Language adoption includes the support around the language. A major company’s announcement is a reason to examine your own engineering workflow, not a reason to copy its hiring requirements.

In a September 10 guest post for the Rust Foundation, Microsoft principal engineer Victor Ciura described Rust’s internal Tier-1 status through toolchains, developer tooling, quality workflows, platform integration, and production support. He also noted that C++ still dominates internally. This is Microsoft’s engineering support classification, not Rust’s target-platform tier system or a mandate to rewrite every project. Rust Foundation: Rust Is Tier-1 Language at Microsoft

For a startup, the useful question is smaller: what must an engineer be able to do in the component you intend to build? Someone extending an established service faces a different job from someone designing your first Rust library and deciding how every later contributor should use it.

The plan below is a suggested management approach, not a measured finding about hiring outcomes. It gives you a way to separate teachable gaps from responsibilities that need experienced judgment now. Adapt the tasks and review requirements to your system; completing the examples does not establish production readiness.

Decide which Rust skills you need on day one

Set the hiring bar from the work and the review capacity available. Start with an actual change the new person would own, then identify where a reviewer could help and where independent expertise is essential.

For each responsibility, write down the consequence of getting it wrong. Changing a parser’s error message, designing shared interfaces, and maintaining a boundary between languages should not inherit the same requirements simply because all involve Rust.

Here is a suggested distinction for a hiring discussion:

Treat these as discussion prompts, not universal job levels. A familiar title can hide very different responsibilities. Ask the hiring manager and the engineer expected to review the work to agree on the row that describes the job.

The hardest counterexample is a team with no qualified Rust reviewer. Assigning a course does not create review capacity. You may need an experienced hire, a qualified external reviewer with a defined remit, or a decision to postpone the component. “We will learn together” needs an answer to who approves the first consequential change.

Then make the job description honest. If Rust can be learned in the role, state that and explain the support. If the person must guide others from the start, say which decisions they will own. Kit’s guide to building ideal candidate profiles offers a way to turn these responsibilities into observable criteria before interviews begin.

Give every engineer a working starting point

A useful setup guide ends with a working task and a person to contact. Document the environment your repository actually expects, then ask someone unfamiliar with the project to follow it.

The rustup documentation describes toolchain files and how to inspect the active toolchain with rustup show. Overrides can take precedence, so the presence of a repository file is not enough to establish which toolchain someone is using. Compare the active environment with the one your project expects. rustup book: Overrides

Cargo’s dependency manifest and lockfile serve different purposes. The manifest describes dependencies; the lockfile records their resolved versions. That helps repeat dependency selection, but it does not establish identical system libraries, secure dependencies, or a bit-for-bit reproducible build. Cargo Book: Cargo.toml vs Cargo.lock

Your onboarding instructions should connect those facts to the repository. Identify the toolchain configuration, required host tools, access needed, working directory, and exact command for a small existing test. Include any local configuration that must be supplied through your normal access process. Avoid a setup guide that assumes the newcomer knows which colleague holds the missing context.

Describe what success looks like without relying on a screenshot of an old terminal. Name the test or behavior the engineer should observe. If the command fails, point to the diagnostic output that helps distinguish a missing dependency from an application failure.

Assign someone to maintain these instructions when the workflow changes. A setup failure can be a documentation defect rather than evidence that a new hire lacks ability. Record the missing step while it is visible and repair the guide before the next person arrives.

Finally, show where the same check runs in CI. Ask the engineer to locate a recent result and explain what it checks. This connects a local command to the team’s review process and gives the next conversation a concrete starting point: which evidence would a reviewer expect alongside a proposed change?

Assess a small change you can actually review

Use a bounded task with stated criteria to discuss how an engineer reasons. If the role accepts Rust learners, provide enough context to separate unfamiliar language details from the capabilities you intended to assess.

Consider this fictional exercise: a supplied Rust component reads an input record and returns a parsed result. A malformed field currently produces an unhelpful error. Ask the engineer to change that behavior, add a regression test, and explain the choice. Supply a repository that builds and a description of the intended caller experience.

The task is an example you can adapt, not a validated predictor of job performance. Choose a small piece of work that your reviewers understand well enough to discuss alternatives. Do not use a candidate exercise to obtain unpaid production work.

Write the task brief before inviting anyone

Explain the requested behavior, what falls outside the task, and how much effort you expect. State whether documentation, search, AI assistance, and discussion with a reviewer are allowed. Ask candidates to describe material help they used, so the follow-up conversation matches the conditions you offered.

For a learner-friendly role, provide the relevant entry points and allow questions. Tell the candidate whether you care about a finished implementation, a reasoned partial attempt, or both. Those choices affect how someone allocates effort, so they belong in the brief rather than in hidden reviewer expectations.

The Cargo documentation explains that cargo test compiles and runs tests, including unit, integration, and documentation tests, with behavior affected by options and project settings. Ask the candidate to name the checks they ran and explain their scope. A green result only speaks to the behavior those checks cover. Cargo Book: cargo test

Discuss decisions against the same criteria

A suggested reviewer rubric can stay short:

• Behavior: Does the change meet the supplied requirement, including the malformed input?
• Testing: Does the regression test exercise the failure and make its expected behavior clear?
• Explanation: Can the candidate describe the data flow and the reason for the error handling?
• Scope: Do they identify assumptions and work deliberately left outside the exercise?
• Review: Can they consider a concrete objection and explain whether it changes their approach?

Write an observation beside each criterion. “Explained why the caller needs the field name” is more useful for the decision than “good communicator.” If a reviewer wants to grade advanced Rust design, check whether that was actually part of the advertised role.

Our guide to structuring code assignments covers the surrounding candidate experience. Keep this exercise and employee onboarding distinct: a candidate should understand the assessment they are accepting, while an employee needs time and support to learn the team’s system.

Teach Rust through your own codebase

Pair learning material with a small piece of code the engineer can explain to a reviewer. Choose the concepts required for the next supervised contribution instead of treating a course syllabus as a release checklist.

The Rust Book describes ownership as rules governing memory management that the compiler checks. It explains moves, borrowing, and what happens when an owner leaves scope. Those concepts give you a precise discussion to have about data passing through your component. The Rust Book: What Is Ownership?

For example, select a short function that returns data to its caller. Ask the engineer to trace where the data originates, who owns it at each step, and why the interface returns borrowed or owned data. Discuss whether a copy is intentional and what an alternative would change. Keep the exercise small enough that a reviewer can examine the reasoning rather than merely approve a diff.

Google’s Android team publishes Comprehensive Rust, a free course that welcomes learners without prior Rust knowledge. You can select relevant lessons as preparation for that discussion. Finishing a course, or following its published schedule, does not demonstrate readiness to own your production component.

A suggested onboarding sequence is:

1. Build: Follow the setup guide and locate the expected test result. Record anything the instructions failed to explain.
2. Explain: Walk through an existing data flow, error path, and ownership boundary with a reviewer.
3. Change: Submit a bounded behavior change, explain the tests, and respond to review.
4. Operate: Walk through diagnosis, release, and rollback for the actual component, at the scope the role requires.

Set the pace from the work and the support available. A fixed calendar can help schedule conversations, but a date is not evidence that a person can safely take on a responsibility.

At each checkpoint, keep a short note of what was observed and what support remains necessary. “Can change this parser with review; has not yet handled a release” gives the next reviewer useful context. A single label such as “Rust trained” loses that distinction.

Give the engineer room to challenge the material too. If the exercise depends on an undocumented convention, update the lesson. If the next task needs a concept the course did not cover, arrange a focused explanation before assigning it.

Define what needs experienced Rust review

Name the changes that require specialist judgment before a newcomer encounters them. The review plan should describe who can approve those changes and what to do when that person is unavailable.

The Rust Book explains that unsafe operations carry obligations the programmer must uphold. An unsafe block does not switch off the borrow checker, and the book recommends keeping such blocks small and exposing safe abstractions. Compilation alone does not discharge those obligations. The Rust Book: Unsafe Rust

For your component, identify any unsafe code and interfaces with other languages. Document the assumptions a reviewer needs to inspect. Do not make a first contribution quietly depend on a learner certifying an unfamiliar abstraction without help.

Keep the review questions broader than memory management. The engineer still needs to reason about the requested behavior, error paths, access rules where relevant, and how a change reaches users. Language checks do not answer whether the implementation matches the product requirement.

Make the readiness decision specific. You might approve supervised changes within a familiar module while keeping interface design or releases with an experienced owner. Record that scope and revisit it after further observed work. Avoid converting a quiz result into blanket permission to maintain every part of the system.

If the required reviewer is consistently unavailable, change the workload or the staffing plan. A backlog of reviews is a capacity problem the manager needs to solve. Sending the learner another course does not answer who will examine their next change.

Keep hiring and onboarding evidence usable in Kit

Keep assessment criteria, learning records, and engineering review decisions clear enough for the next person to use. They answer different questions, even when they concern the same language.

Kit’s hiring stages support scoring criteria with names, descriptions, weights, and scales. Reviewers can record scores and comments, and code assignments support GitHub templates and written instructions. These features can organize the hiring process around the criteria you chose. They do not establish that a submitted implementation is correct without appropriate review.

For employee learning, Kit Training supports authored courses with slides, quizzes, and attestations, plus invitations, progress records, and reminders. Checklist programs support editable checkpoints, platform-specific instructions, and evidence submissions. You supply the Rust material and decide what a setup confirmation should document; Kit does not include a Rust curriculum or automatically verify code competence.

A completion record tells you that the configured learning steps were completed. Keep the engineering judgment explicit: who reviewed the work, what they observed, and which responsibility the engineer can take next. Do not treat finishing a course as a substitute for that conversation.

Before making Rust mandatory in a job post, agree on the first contribution, its reviewer, and the expertise the role truly needs. Then make the hiring brief and onboarding material support that decision. You will have a concrete plan to discuss with a candidate and a new colleague.