Rust-Onboarding: Was Sie voraussetzen und was Sie vermitteln

Rust-Onboarding sollte Entwicklerinnen und Entwicklern zeigen, wie sie Ihre Codebasis bauen, testen, erklären und ändern – mit angemessener Prüfung ihrer Arbeit. Bevor Sie Rust-Erfahrung zur Einstellungsvoraussetzung machen, klären Sie, welche Aufgaben vom ersten Tag an Fachkenntnisse verlangen und was Ihr Team durch betreute Arbeit vermitteln kann. Halten Sie diese Unterscheidung im Stellenprofil und im Einarbeitungsplan fest.

Ein Team kann dabei in beide Richtungen falsch entscheiden. Es kann einen fähigen Entwickler ablehnen, weil ihm Sprachkenntnisse fehlen, die das Team vermitteln könnte. Es kann aber auch einen begeisterten Einsteiger für eine Stelle einstellen, auf der niemand seine Arbeit prüfen kann. Ein Einarbeitungsplan hilft Ihnen, solche Fehlentscheidungen zu erkennen, bevor jemand das Angebot annimmt.

Was bedeutet Microsofts Rust-Ankündigung für Ihr Team?

Zur Einführung einer Sprache gehört die nötige Unterstützung. Die Ankündigung eines großen Unternehmens ist ein Anlass, die eigenen Entwicklungsabläufe zu prüfen. Übernehmen Sie deshalb nicht einfach die Einstellungskriterien des Unternehmens.

In einem Gastbeitrag für die Rust Foundation vom 10. September beschrieb Microsofts Principal Engineer Victor Ciura den internen Tier-1-Status von Rust anhand von Toolchains, Entwicklungswerkzeugen, Qualitätsprüfungen, Plattformintegration und Unterstützung für den Produktivbetrieb. Er hielt auch fest, dass C++ intern weiterhin dominiert. Gemeint ist Microsofts Einstufung der eigenen Entwicklungsunterstützung, weder Rusts Einteilung der Zielplattformen noch eine Vorgabe, sämtliche Projekte neu zu schreiben. Rust Foundation: Rust ist eine Tier-1-Sprache bei Microsoft

Für ein Startup ist die nützliche Frage enger gefasst: Was muss ein Entwickler in der geplanten Komponente tun können? Einen bestehenden Dienst zu erweitern ist eine andere Aufgabe, als die erste Rust-Bibliothek Ihres Unternehmens zu entwerfen und festzulegen, wie alle späteren Mitwirkenden sie verwenden sollen.

Der folgende Plan ist ein Vorschlag für die Teamführung, kein empirischer Befund zu Einstellungsergebnissen. Er hilft Ihnen, vermittelbare Kenntnisse von Aufgaben zu trennen, die schon jetzt ein erfahrenes Urteil verlangen. Passen Sie Aufgaben und Prüfanforderungen an Ihr System an. Wer die Beispiele bearbeitet hat, ist damit noch nicht für die Verantwortung im Produktivbetrieb qualifiziert.

Welche Rust-Kenntnisse brauchen Sie vom ersten Tag an?

Richten Sie die Einstellungskriterien nach der Arbeit und der verfügbaren Prüfkapazität aus. Beginnen Sie mit einer konkreten Änderung, die die neue Person verantworten würde. Klären Sie dann, wo ein Prüfer helfen kann und wo eigenständige Fachkenntnisse unverzichtbar sind.

Halten Sie für jede Aufgabe fest, welche Folgen ein Fehler hätte. Die Fehlermeldung eines Parsers zu ändern, gemeinsam genutzte Schnittstellen zu entwerfen und eine Schnittstelle zwischen Sprachen zu betreuen, verlangt nicht dasselbe – auch wenn überall Rust zum Einsatz kommt.

Diese Unterscheidung kann als Grundlage für ein Gespräch über die Stellenbesetzung dienen:

Verstehen Sie diese Zeilen als Gesprächsgrundlage, nicht als allgemeingültige Erfahrungsstufen. Hinter derselben Stellenbezeichnung können sehr unterschiedliche Aufgaben stehen. Lassen Sie die Personalverantwortlichen und den vorgesehenen Prüfer gemeinsam festlegen, welche Zeile die Stelle beschreibt.

Der schwierigste Gegenfall ist ein Team ohne qualifizierten Rust-Prüfer. Einen Kurs zuzuweisen schafft keine Prüfkapazität. Vielleicht brauchen Sie eine erfahrene Neueinstellung, einen qualifizierten externen Prüfer mit klar umrissenem Auftrag oder die Entscheidung, die Komponente vorerst zurückzustellen. „Wir lernen gemeinsam“ lässt offen, wer die erste folgenreiche Änderung freigibt.

Formulieren Sie anschließend eine ehrliche Stellenbeschreibung. Wenn Rust in der Stelle erlernt werden kann, sagen Sie das und beschreiben Sie die Unterstützung. Soll die Person von Anfang an andere anleiten, nennen Sie die Entscheidungen, die sie verantworten wird. Kits Leitfaden zum Erstellen idealer Kandidatenprofile zeigt, wie Sie solche Aufgaben vor dem ersten Interview in beobachtbare Kriterien übersetzen.

Schaffen Sie einen funktionierenden Ausgangspunkt

Eine brauchbare Einrichtungsanleitung endet mit einer nachweislich funktionierenden Aufgabe und einer Ansprechperson. Dokumentieren Sie die Umgebung, die Ihr Repository tatsächlich voraussetzt. Lassen Sie die Anleitung dann von jemandem durcharbeiten, der das Projekt noch nicht kennt.

Die rustup-Dokumentation beschreibt Toolchain-Dateien und die Prüfung der aktiven Toolchain mit rustup show. Andere Einstellungen können Vorrang haben. Eine Datei im Repository allein belegt daher noch nicht, welche Toolchain jemand verwendet. Vergleichen Sie die aktive Umgebung mit der für Ihr Projekt vorgesehenen. rustup-Handbuch: Überschreibungen

Das Abhängigkeitsmanifest und die Lockdatei von Cargo erfüllen unterschiedliche Zwecke. Das Manifest beschreibt die Abhängigkeiten; die Lockdatei hält deren aufgelöste Versionen fest. So lässt sich dieselbe Auswahl von Abhängigkeiten wiederverwenden. Identische Systembibliotheken, sichere Abhängigkeiten oder ein bitgenau reproduzierbarer Build sind damit nicht garantiert. Cargo-Handbuch: Cargo.toml und Cargo.lock

Verbinden Sie diese Grundlagen in Ihrer Einarbeitungsanleitung mit dem Repository. Nennen Sie die Toolchain-Konfiguration, erforderliche Werkzeuge auf dem Entwicklungsrechner, benötigte Zugänge, das Arbeitsverzeichnis und den genauen Befehl für einen kleinen bestehenden Test. Nennen Sie auch die lokale Konfiguration, die über Ihren üblichen Zugangsprozess bereitgestellt werden muss. Setzen Sie nicht voraus, dass neue Kollegen bereits wissen, wer ihnen den fehlenden Zusammenhang erklären kann.

Beschreiben Sie das erwartete Ergebnis, ohne sich auf einen Screenshot einer alten Terminalausgabe zu verlassen. Nennen Sie den Test oder das Verhalten, das der Entwickler beobachten soll. Falls der Befehl fehlschlägt, verweisen Sie auf die Diagnoseausgabe, mit der sich eine fehlende Abhängigkeit von einem Anwendungsfehler unterscheiden lässt.

Bestimmen Sie jemanden, der diese Anleitung bei geänderten Abläufen pflegt. Wenn die Einrichtung scheitert, kann das an der Dokumentation liegen und muss nicht auf fehlende Fähigkeiten der neuen Person hindeuten. Notieren Sie den fehlenden Schritt, solange er noch präsent ist, und korrigieren Sie die Anleitung vor der nächsten Einarbeitung.

Zeigen Sie schließlich, wo dieselbe Prüfung in CI läuft. Lassen Sie den Entwickler ein aktuelles Ergebnis finden und erklären, was geprüft wird. So verbinden Sie einen lokalen Befehl mit dem Prüfprozess des Teams. Das nächste Gespräch hat damit einen konkreten Ausgangspunkt: Welche Nachweise erwartet ein Prüfer zu einer vorgeschlagenen Änderung?

Bewerten Sie eine kleine Änderung, die Sie tatsächlich prüfen können

Besprechen Sie die Denkweise eines Entwicklers anhand einer begrenzten Aufgabe mit offengelegten Kriterien. Wenn die Stelle Rust-Einsteiger zulässt, geben Sie genügend Kontext. So können Sie ungewohnte Sprachdetails von den Fähigkeiten unterscheiden, die Sie eigentlich beurteilen wollten.

Ein fiktives Beispiel: Eine bereitgestellte Rust-Komponente liest einen Eingabedatensatz und gibt das Ergebnis der Verarbeitung zurück. Ein fehlerhaftes Feld führt bislang zu einer wenig hilfreichen Fehlermeldung. Bitten Sie den Entwickler, dieses Verhalten zu ändern, einen Regressionstest hinzuzufügen und seine Entscheidung zu erläutern. Stellen Sie ein Repository bereit, das sich bauen lässt, und beschreiben Sie das gewünschte Verhalten aus Sicht des aufrufenden Codes.

Diese Aufgabe ist ein anpassbares Beispiel, kein validiertes Verfahren zur Vorhersage beruflicher Leistung. Wählen Sie einen kleinen Arbeitsumfang, den Ihre Prüfer gut genug kennen, um Alternativen zu besprechen. Nutzen Sie eine Bewerbungsaufgabe nicht, um unbezahlte Arbeit für Ihr Produkt zu erhalten.

Schreiben Sie die Aufgabenbeschreibung vor der Einladung

Erläutern Sie das gewünschte Verhalten, die Grenzen der Aufgabe und den erwarteten Aufwand. Geben Sie an, ob Dokumentation, Recherche, KI-Unterstützung und Gespräche mit einem Prüfer erlaubt sind. Bitten Sie Kandidatinnen und Kandidaten, wesentliche Hilfen zu benennen. So passt das anschließende Gespräch zu den Bedingungen, die Sie angeboten haben.

Bei einer Stelle, die Einsteigern offensteht, sollten Sie die relevanten Einstiegspunkte im Code nennen und Fragen zulassen. Sagen Sie dem Kandidaten, ob Sie eine fertige Implementierung, einen nachvollziehbar begründeten Teilversuch oder beides bewerten. Davon hängt ab, wie jemand seinen Aufwand verteilt. Diese Erwartungen gehören deshalb in die Aufgabenbeschreibung und dürfen nicht nur den Prüfern bekannt sein.

Die Cargo-Dokumentation erläutert, dass cargo test Tests kompiliert und ausführt, darunter Unit-, Integrations- und Dokumentationstests. Optionen und Projekteinstellungen beeinflussen das Verhalten. Bitten Sie den Kandidaten, die ausgeführten Prüfungen und deren Umfang zu benennen. Ein erfolgreiches Ergebnis sagt nur etwas über das Verhalten aus, das diese Prüfungen abdecken. Cargo-Handbuch: cargo test

Besprechen Sie Entscheidungen anhand derselben Kriterien

Eine Scorecard für Prüferinnen und Prüfer kann kurz bleiben:

• Verhalten: Erfüllt die Änderung die vorgegebene Anforderung, einschließlich der fehlerhaften Eingabe?
• Tests: Deckt der Regressionstest den Fehler ab und macht er das erwartete Verhalten deutlich?
• Erklärung: Kann der Kandidat den Datenfluss und die Gründe für die Fehlerbehandlung beschreiben?
• Umfang: Benennt er Annahmen und Arbeiten, die bewusst nicht Teil der Aufgabe waren?
• Prüfung: Kann er einen konkreten Einwand abwägen und erklären, ob er deshalb anders vorgehen würde?

Notieren Sie zu jedem Kriterium eine Beobachtung. „Hat erklärt, warum der aufrufende Code den Feldnamen benötigt“ hilft bei der Entscheidung mehr als „kommuniziert gut“. Will ein Prüfer fortgeschrittenen Rust-Entwurf bewerten, klären Sie, ob das tatsächlich zur ausgeschriebenen Stelle gehörte.

Unser Leitfaden zum Gestalten von Code-Aufgaben behandelt den Ablauf aus Sicht der Kandidaten. Trennen Sie diese Aufgabe von der Einarbeitung nach der Einstellung: Kandidaten sollten wissen, welcher Bewertung sie zustimmen. Beschäftigte brauchen dagegen Zeit und Unterstützung, um das System des Teams kennenzulernen.

Vermitteln Sie Rust anhand Ihrer eigenen Codebasis

Verbinden Sie Lernmaterial mit einem kleinen Codeabschnitt, den der Entwickler einem Prüfer erklären kann. Wählen Sie die Konzepte für den nächsten betreuten Beitrag aus. Ein Kursplan eignet sich nicht als Checkliste für die Release-Freigabe.

Das Rust-Buch beschreibt Ownership als Regeln für die Speicherverwaltung, die der Compiler prüft. Es erläutert Moves, Borrowing und was geschieht, wenn ein Owner seinen Gültigkeitsbereich verlässt. Anhand dieser Konzepte können Sie konkret besprechen, wie Daten Ihre Komponente durchlaufen. Das Rust-Buch: Was ist Ownership?

Wählen Sie beispielsweise eine kurze Funktion, die Daten an ihren Aufrufer zurückgibt. Lassen Sie den Entwickler nachverfolgen, woher die Daten stammen, wer sie an jedem Schritt besitzt und warum die Schnittstelle geliehene oder eigene Daten zurückgibt. Besprechen Sie, ob eine Kopie beabsichtigt ist und was sich bei einer Alternative ändern würde. Halten Sie die Übung so klein, dass ein Prüfer die Überlegungen nachvollziehen kann, statt lediglich einen Diff freizugeben.

Googles Android-Team veröffentlicht Comprehensive Rust, einen kostenlosen Kurs, der keine Rust-Vorkenntnisse voraussetzt. Sie können passende Lektionen zur Vorbereitung auf dieses Gespräch auswählen. Der Abschluss eines Kurses oder das Einhalten seines Zeitplans belegt nicht, dass jemand Ihre Komponente im Produktivbetrieb verantworten kann.

Ein möglicher Einarbeitungsablauf:

1. Bauen: Die Einrichtungsanleitung befolgen und das erwartete Testergebnis finden. Alles notieren, was die Anleitung nicht erklärt hat.
2. Erklären: Gemeinsam mit einem Prüfer einen bestehenden Datenfluss, einen Fehlerpfad und eine Ownership-Grenze durchgehen.
3. Ändern: Eine begrenzte Verhaltensänderung einreichen, die Tests erklären und auf die Prüfung eingehen.
4. Betreiben: Diagnose, Release und Rollback für die tatsächliche Komponente durchgehen, soweit es die Stelle erfordert.

Richten Sie das Tempo nach der Arbeit und der verfügbaren Unterstützung aus. Ein fester Zeitplan hilft bei der Terminplanung. Ein Datum belegt aber nicht, dass jemand eine Verantwortung sicher übernehmen kann.

Halten Sie an jedem Kontrollpunkt kurz fest, was beobachtet wurde und welche Unterstützung weiterhin nötig ist. „Kann diesen Parser unter Prüfung ändern; hat noch kein Release durchgeführt“ gibt dem nächsten Prüfer nützlichen Kontext. Eine einzelne Kennzeichnung wie „Rust geschult“ lässt diese Unterscheidung verschwinden.

Geben Sie dem Entwickler auch Raum, das Material zu hinterfragen. Wenn eine Übung eine undokumentierte Konvention voraussetzt, ergänzen Sie die Lektion. Braucht die nächste Aufgabe ein Konzept, das im Kurs nicht vorkam, erklären Sie es gezielt, bevor Sie die Aufgabe vergeben.

Legen Sie fest, welche Änderungen Rust-Fachkenntnisse erfordern

Benennen Sie Änderungen, die Fachkenntnisse verlangen, bevor neue Kollegen damit konfrontiert werden. Der Prüfplan sollte festhalten, wer solche Änderungen freigeben kann und was bei Abwesenheit dieser Person geschieht.

Das Rust-Buch erklärt, dass Unsafe-Operationen Anforderungen mit sich bringen, die der Programmierer erfüllen muss. Ein unsafe-Block schaltet den Borrow Checker nicht ab. Das Buch empfiehlt, solche Blöcke klein zu halten und sichere Abstraktionen bereitzustellen. Dass Code kompiliert, belegt noch nicht, dass diese Anforderungen erfüllt sind. Das Rust-Buch: Unsafe Rust

Ermitteln Sie für Ihre Komponente vorhandenen Unsafe-Code und Schnittstellen zu anderen Sprachen. Dokumentieren Sie die Annahmen, die ein Prüfer untersuchen muss. Ein erster Beitrag sollte nicht stillschweigend voraussetzen, dass ein Einsteiger ohne Hilfe die Sicherheit einer unbekannten Abstraktion bestätigt.

Beschränken Sie die Prüfung nicht auf die Speicherverwaltung. Der Entwickler muss weiterhin das gewünschte Verhalten, Fehlerpfade, gegebenenfalls Zugriffsregeln und die Bereitstellung für Nutzer durchdenken. Die Prüfungen der Sprache beantworten nicht, ob eine Implementierung zur Produktanforderung passt.

Entscheiden Sie konkret, welche Verantwortung die Person übernehmen kann. Sie könnten betreute Änderungen innerhalb eines vertrauten Moduls zulassen, während Schnittstellenentwurf oder Releases bei einer erfahrenen Person bleiben. Halten Sie diesen Umfang fest und überprüfen Sie ihn anhand weiterer beobachteter Arbeit. Ein Quizergebnis sollte nicht zur pauschalen Erlaubnis werden, jeden Teil des Systems zu warten.

Ist der erforderliche Prüfer regelmäßig nicht verfügbar, ändern Sie die Arbeitsverteilung oder die Personalplanung. Aufgestaute Prüfungen sind ein Kapazitätsproblem, das die Führungskraft lösen muss. Ein weiterer Kurs für den Einsteiger beantwortet nicht, wer seine nächste Änderung prüfen wird.

Halten Sie Nachweise zu Einstellung und Einarbeitung in Kit nutzbar

Dokumentieren Sie Bewertungskriterien, Lernnachweise und fachliche Prüfentscheidungen so klar, dass die nächste Person damit arbeiten kann. Sie beantworten unterschiedliche Fragen, auch wenn es um dieselbe Sprache geht.

Kits Einstellungsphasen unterstützen Bewertungskriterien mit Namen, Beschreibungen, Gewichtungen und Skalen. Prüfer können Bewertungen und Kommentare erfassen; Code-Aufgaben unterstützen GitHub-Vorlagen und schriftliche Anweisungen. Damit lässt sich der Einstellungsprozess an den gewählten Kriterien ausrichten. Ohne angemessene Prüfung belegen diese Funktionen jedoch nicht, dass eine eingereichte Implementierung korrekt ist.

Für die Weiterbildung unterstützt Kit Training selbst erstellte Kurse mit Folien, Quizfragen und Bestätigungen sowie Einladungen, Fortschrittsaufzeichnungen und Erinnerungen. Checklistenprogramme bieten bearbeitbare Kontrollpunkte, plattformspezifische Anweisungen und das Einreichen von Nachweisen. Sie stellen das Rust-Material bereit und entscheiden, was eine Bestätigung der Einrichtung dokumentieren soll. Kit enthält keinen Rust-Lehrplan und überprüft Programmierkompetenz nicht automatisch.

Ein Abschlussnachweis zeigt, dass die konfigurierten Lernschritte abgeschlossen wurden. Halten Sie das fachliche Urteil ausdrücklich fest: Wer hat die Arbeit geprüft, was wurde beobachtet und welche Verantwortung kann der Entwickler als Nächstes übernehmen? Ersetzen Sie dieses Gespräch nicht durch einen Kursabschluss.

Bevor Sie Rust in einer Stellenanzeige voraussetzen, einigen Sie sich auf den ersten Beitrag, den zuständigen Prüfer und die Kenntnisse, die die Stelle tatsächlich erfordert. Richten Sie dann die Aufgabenbeschreibung und das Einarbeitungsmaterial an dieser Entscheidung aus. So haben Sie einen konkreten Plan, den Sie mit einem Kandidaten und einem neuen Kollegen besprechen können.