Die meisten gescheiterten Tech-Suchen scheitern, bevor die erste Kandidatin überhaupt kontaktiert wird, und zwar in einem Dokument, das kaum jemand ernst nimmt: dem Anforderungsprofil. Ist es eine zusammenkopierte Liste aller Tools, die das Team je angefasst hat, zielt das Sourcing auf die falschen Leute, Interviewer:innen bewerten gegen unterschiedliche imaginäre Rollen, und das Angebot geht an die Person, die das Rauschen zufällig überstanden hat. Ein gutes Anforderungsprofil ist kurz, gnadenlos priorisiert und in Ergebnissen statt Tool-Namen formuliert. Dieser Artikel liefert die exakte Struktur, Abschnitt für Abschnitt, plus ein ausgefülltes Miniaturbeispiel zum Anpassen.
Was ohne echtes Anforderungsprofil schiefgeht
Das Anforderungsprofil zu überspringen spart keine Zeit, es verschiebt die Kosten nach hinten, wo sie deutlich höher sind. Die typischen Fehlerbilder sind vorhersehbar genug für eine Tabelle.
| Fehlerbild | Wie es aussieht | Was es kostet |
|---|---|---|
| Wollmilchsau-Profil | Fünfzehn „zwingende“ Skills über drei echte Jobs verteilt | Fast leere Pipeline; starke Kandidat:innen sortieren sich selbst aus |
| Interviewer-Drift | Jede:r Interviewer:in prüft die eigene gedachte Version der Rolle | Widersprüchliches Feedback, Entscheidungen aus dem Bauch |
| Stichwort-Sourcing | Sourcing matcht Tool-Namen statt Fähigkeit | Eloquente Redner:innen kommen durch, Praktiker:innen fallen raus |
| Level-Mismatch | Senior-Titel, Mid-Level-Verantwortung und -Gehaltsband | Absagen in der Angebotsphase nach Wochen im Prozess |
| Scope-Creep | Rolle wird mitten in der Suche umdefiniert, weil Stakeholder nachlegen | Suche startet neu; Kandidat:innen im Prozess gehen verloren |
Die Vorlage: acht Abschnitte, ein bis zwei Seiten
Ein Anforderungsprofil sollte auf ein bis zwei Seiten passen. Längere Dokumente sind nicht gründlicher, sondern schlechter priorisiert. Diese Struktur können Sie direkt übernehmen.
- 1Rollenkontext (3-4 Sätze): warum es diese Rolle jetzt gibt, was sich im Unternehmen ändert, wenn sie gut besetzt ist, an wen sie berichtet.
- 2Mission der Rolle (1 Satz): das eine Ergebnis, das diese Person verantwortet, z. B. „verantwortet den Weg vom ML-Prototyp zum zuverlässigen Produktionsservice“.
- 3Top-3-Ergebnisse der ersten 12 Monate: konkrete, überprüfbare Resultate, jedes mit einem groben Erfolgssignal.
- 4Muss-Kriterien (max. 7): ergebnisformulierte Fähigkeiten, die echte K.-o.-Kriterien sind, jeweils mit Nachweis-Hinweis (wie ein Beleg aussehen würde).
- 5Kann-Kriterien (max. 5): ausdrücklich als Zünglein an der Waage markiert, nie als Ablehnungsgrund.
- 6Senioritäts-Kalibrierung: was die Person allein entscheidet, gemeinsam entscheidet und eskaliert, plus das Ambiguitätsniveau, das sie aushalten muss.
- 7Arbeitskontext: Team-Setup, Stack (als Kontext, nicht als Anforderung), Remote-/Vor-Ort-Realität, Bereitschafts- oder Reiseerwartungen.
- 8Explizite Nicht-Anforderungen: Dinge, die als Pflicht vermutet werden, aber keine sind (z. B. Promotion, ein bestimmtes Framework), um den Pool bewusst zu weiten.
Muss vs. Kann, und Ergebnisse statt Tool-Listen
Zwei Disziplinen trennen ein funktionierendes Profil von einer Wunschliste: Jede Anforderung verdient sich ihren Platz als echtes K.-o.-Kriterium, und jede Anforderung beschreibt, was die Person kann, nicht was sie benutzt hat. Ein Tool lernt man in Wochen; das Ergebnis dahinter braucht Jahre. Die Tabelle zeigt das Umschreiben.
| Tool-Listen-Version (schwach) | Ergebnis-Version (stark) | Nachweis, den man erfragt |
|---|---|---|
| 5+ Jahre Python, pandas, scikit-learn | Kann eine unscharfe Geschäftsfrage als Modellierungsaufgabe fassen und in Wochen ein erstes nützliches Modell liefern | Walkthrough eines Projekts von der Frage bis zum ausgelieferten Ergebnis |
| Kubernetes, Docker, Terraform, MLflow | Kann ein Modell vom Notebook in einen überwachten, rollback-sicheren Produktionsservice bringen | Architektur-Diskussion eines Systems, das sie in Produktion betrieben hat |
| Erfahrung mit LLMs, RAG, LangChain | Kann ein LLM-Feature gegen Qualitäts-, Kosten- und Latenz-Budgets entwerfen und evaluieren | Ein konkretes Eval-Setup, das sie gebaut hat, inklusive seiner Schwachstellen |
| Ausgeprägte Kommunikationsstärke | Bringt skeptische Fachexpert:innen dazu, dem Output eines Modells zu vertrauen und ihn zu nutzen | Eine Geschichte über Adoptionswiderstand und wie er gelöst wurde |
Seniorität kalibrieren und die Anti-Wollmilchsau-Regel
Berufsjahre sind das schwächste Senioritätssignal in Tech. Kalibrieren Sie stattdessen über Verantwortung und Ambiguität: Was entscheidet diese Person, ohne zu fragen, und wie unterspezifiziert darf ein Problem sein, bevor sie stehen bleibt? Danach der harte Check des fertigen Entwurfs.
- 1Muss-Kriterien zählen. Mehr als sieben: Rolle aufteilen oder Anforderungen zu Kann-Kriterien herabstufen.
- 2Auf Rollenvermischung prüfen: Spannen die Muss-Kriterien zwei unterschiedliche Jobs auf (z. B. forschungsnahe Modellierung UND Plattform-Engineering), beschreiben Sie zwei Einstellungen.
- 3Für jedes Muss-Kriterium fragen: „Würden wir eine ansonsten exzellente Kandidatin wirklich deshalb ablehnen?“ Lautet die ehrliche Antwort nein, ist es ein Kann-Kriterium.
- 4Level an Entscheidungen koppeln: Ein Senior-Profil benennt Entscheidungen, die die Person allein trägt; läuft jede Entscheidung über einen Lead, ist die Rolle Mid-Level, egal was der Titel sagt.
- 5Markt-Plausibilität prüfen: Passen in Ihrer Hiring-Region plausibel weniger als ein paar hundert Menschen auf das Profil, muss sich entweder das Gehaltsband oder das Profil ändern.
Ein ausgefülltes Miniaturbeispiel
Ein illustrativer Auszug für ein fiktives mittelständisches Unternehmen, das seinen ersten ML Engineer einstellt, verdichtet auf die Kernabschnitte. Bewusst kurz; ein echtes Profil ergänzt Arbeitskontext und Nicht-Anforderungen.
| Abschnitt | Inhalt (verdichtet) |
|---|---|
| Mission | Unsere zwei validierten ML-Prototypen zuverlässig in Produktion bringen und etablieren, wie wir künftig Modelle ausliefern |
| Top-Ergebnis Jahr 1 | Absatzprognose-Modell live im Bestellprozess, mit Monitoring und dokumentiertem Retraining-Pfad |
| Muss-Kriterium 1 | Hat mindestens ein Modell vom Prototyp in Produktion gebracht und betrieben (Nachweis: System-Walkthrough) |
| Muss-Kriterium 2 | Kann pragmatische Datenpipelines auf einem Cloud-Stack bauen, ohne Plattform-Team im Rücken |
| Muss-Kriterium 3 | Kann Modellgrenzen für nicht-technische Planer:innen erklären und den Workflow darum herum gestalten |
| Kann-Kriterium | Handels- oder Supply-Chain-Erfahrung; Erfahrung mit Build-vs-Buy-Entscheidungen bei ML-Tooling |
| Seniorität | Entscheidet Architektur und Tooling allein im Budgetrahmen; eskaliert Scope-Änderungen an Head of Data |
Typische Fehler, die Sie vermeiden sollten
- 1Anforderungen aus fremden Stellenanzeigen kopieren, das importiert die Organisationsstruktur und die Fehler anderer Unternehmen in Ihr Profil.
- 2Jeden Stakeholder Anforderungen ergänzen lassen, ohne einen Tausch zu erzwingen: Ergänzungen kosten die Beteiligten nichts und die Pipeline alles.
- 3Das Profil nur für die Anzeige nutzen und dann aus dem Gedächtnis interviewen: Aus dem Profil sollte die Scorecard entstehen, mit der alle Interviewer:innen bewerten.
- 4Das Profil erst schreiben, wenn das Sourcing läuft, dann rechtfertigt es die bereits gefundenen Kandidat:innen, statt zu definieren, wen man sucht.
- 5Den Stack-Abschnitt als Anforderungen behandeln: Der Stack ist Kontext; Tool-für-Tool-Matches zu erzwingen filtert genau die anpassungsfähigen Seniors heraus, die Sie wollen.
