In der IT-Branche werden Kandidaten nach einem Muster bewertet, das seiner Aufgabe nicht gerecht wird: Skill-Listen. Framework A, drei Jahre. Technologie B, nachgewiesen. Zertifikat C, vorhanden. Was sich als objektive Bewertung tarnt, ist in Wahrheit ein Filtermechanismus, der systematisch die falschen Signale priorisiert.

Das Muster

Die Situation tritt regelmäßig auf: Erfahrene Entwickler mit 10 oder mehr Jahren Projekterfahrung, die nachweislich Systeme gerettet, Teams verbessert und Kunden überzeugt haben, werden aufgrund einer Skill-Liste abgelehnt. Framework XY nur zwei statt drei Jahre Erfahrung. Branche X nicht „offiziell“ gemacht. Tool Y nicht im Lebenslauf aufgeführt.

Als würde Erfahrung nur zählen, wenn sie exakt in der richtigen Zeile steht.

Und dann die Gegenerfahrung: Sobald diese Entwickler im Projekt arbeiten, ist das Feedback durchweg positiv. „Tolle Arbeit.“ „Die beiden bitte bis zum Schluss behalten.“ Die Diskrepanz zwischen Filterergebnis und tatsächlicher Leistung ist frappierend.

Warum der Filter versagt

Das Problem hat eine nachvollziehbare Ursache: Skill-Listen sind einfach zu bewerten. Ein Häkchen setzen kann jeder. Einen Menschen einzuschätzen erfordert Urteilsvermögen, Erfahrung und Zeit.

In größeren Unternehmen entscheidet oft nicht die Fachabteilung über die Besetzung, sondern ein Einkaufsprozess. Profile werden gegen Anforderungslisten geprüft, teilweise automatisiert, teilweise durch Personen, die den technischen Kontext nicht beurteilen können. In diesem System fällt ein Java-Entwickler mit 15 Jahren Erfahrung durchs Raster, weil er ein bestimmtes Framework nicht im Lebenslauf stehen hat, obwohl er es innerhalb von zwei Wochen produktiv einsetzen würde.

Das ist kein Einzelfall, sondern ein strukturelles Problem. Und es wird durch KI im Recruiting nicht besser. Automatisierte Vorfilterung auf Basis von Keywords verschärft den Effekt: Wer die richtigen Buzzwords nicht im CV hat, kommt nicht durch die erste Filterstufe. Unabhängig von der tatsächlichen Qualifikation.

Was dabei verloren geht

Ein Senior-Entwickler lernt eine neue Technologie nicht in Monaten, sondern in Wochen. Das liegt nicht an besonderer Begabung, sondern an akkumulierter Erfahrung: Wer drei verschiedene Frontend-Frameworks gelernt hat, erkennt die gemeinsamen Patterns und braucht für das vierte einen Bruchteil der Einarbeitungszeit. Wer in unterschiedlichen Branchen gearbeitet hat, versteht neue Domänen schneller, weil er Parallelen erkennt.

Diese Art von Erfahrung lässt sich in keiner Skill-Matrix abbilden. Genauso wenig wie Kommunikationsfähigkeit, Eigenverantwortung oder die Fähigkeit, ein Problem zu durchdringen, bevor eine Lösung vorgeschlagen wird. Es sind aber genau diese Eigenschaften, die in komplexen Softwareprojekten den Unterschied machen.

Die Kosten dieses Filterproblems sind real, wenn auch indirekt. Stellen bleiben länger unbesetzt. Projekte verzögern sich. Am Ende wird jemand besetzt, der alle Häkchen hat, aber weniger Projekterfahrung und weniger Wirkung mitbringt. Sechs Monate später fragt sich das Team, warum das Projekt nicht vorankommt.

Alternative Bewertungsansätze

Die Alternative zum Skill-Listen-Ansatz besteht nicht darin, keine Anforderungen zu formulieren. Sie besteht darin, die richtigen Anforderungen zu formulieren.

Wirkung statt Werkzeuge bewerten: Nicht fragen „Kennt er React?“, sondern „Hat er komplexe Frontends gebaut, die in Produktion laufen?“ Ein Entwickler, der nachweislich komplexe Systeme erfolgreich umgesetzt hat, wird die spezifische Technologie lernen. Umgekehrt garantiert eine Technologie im Lebenslauf noch keine erfolgreiche Projektarbeit.

Muster statt Keywords suchen: Erfahrene Entwickler bringen Muster mit, die sich über Technologien hinweg anwenden lassen: Architekturmuster, Kommunikationsmuster, Problemlösungsmuster. Diese Muster stehen in keinem Lebenslauf, aber sie sind der Grund, warum erfahrene Entwickler in neuen Kontexten schnell produktiv werden.

Fachgespräch statt Checkliste: 30 Minuten Fachgespräch liefern mehr Informationen als jede Skill-Matrix. Wie denkt jemand? Wie geht er an ein Problem heran? Welche Fragen stellt er? Wie kommuniziert er über technische Sachverhalte? Diese Dimensionen lassen sich nicht automatisieren, und genau deshalb sind sie so aussagekräftig.

Referenzen aus realen Projekten: Was sagen ehemalige Projektleiter, Teamkollegen oder Kunden? Wie wurde die Person in konkreten Projektsituationen erlebt? Diese Informationen sind schwerer zu beschaffen als eine Skill-Liste, aber sie bilden die tatsächliche Leistungsfähigkeit deutlich besser ab.

Die Perspektive beider Seiten

Aus Sicht der Unternehmen ist der Skill-Listen-Ansatz nachvollziehbar: Er ist effizient, vergleichbar und skaliert. Bei 200 Bewerbungen auf eine Stelle ist ein automatisierter Filter verständlich. Das Problem ist nicht der Filter an sich, sondern die Kriterien, nach denen gefiltert wird.

Aus Sicht der Kandidaten ist die Frustration ebenso nachvollziehbar: Jahrelange Erfahrung wird nicht anerkannt, weil ein bestimmtes Keyword fehlt. Die Reaktion vieler erfahrener Entwickler ist, ihre Lebensläufe mit Keywords zu optimieren statt mit Substanz. Das verstärkt das Problem, weil die Skill-Listen noch weniger mit der Realität korrelieren.

Die Lösung liegt nicht in einem der beiden Extreme. Sie liegt in Bewertungsmethoden, die sowohl skalierbar als auch aussagekräftig sind. Das erfordert mehr Aufwand als eine automatisierte Keyword-Suche. Aber es liefert auch bessere Ergebnisse.

Fazit

Skill-Listen sind bequem, aber sie filtern nach den falschen Kriterien. Die tatsächliche Wirksamkeit eines Entwicklers zeigt sich in der Fähigkeit, Probleme zu verstehen und zu lösen, nicht in der Anzahl der Keywords im Lebenslauf. Unternehmen, die bereit sind, über die Skill-Liste hinauszuschauen, finden die besseren Kandidaten. Es erfordert mehr Aufwand bei der Bewertung. Aber es spart den deutlich höheren Aufwand, der entsteht, wenn die falsche Person im Projekt sitzt.