Viele Unternehmen möchten Entwicklungsqualität prüfen, ohne Bewerbenden unbezahlte Probearbeit oder standardisierte Coding-Tests abzuverlangen. Gleichzeitig brauchen sie belastbare Signale für technisches Können, Sorgfalt und Verantwortung, während Kandidatinnen und Kandidaten einen fairen, respektvollen Prozess erwarten. Welche Alternativen gibt es, wenn man echte Arbeit besser verstehen will als über Lebenslauf, Selbstdarstellung oder künstliche Aufgaben? Dieser Beitrag ordnet gängige Wege ein, beschreibt ihre Grenzen und stellt mit Repo-Audits auf Basis realer Entwicklungsarbeit einen Ansatz vor. Mehr Kontext bieten auch Zweifel an KI-Bewerbungen und warum Entwickler-Lebensläufe an Aussagekraft verlieren.
Warum Coding-Tests und Probeaufgaben oft an Akzeptanz verlieren
Klassische Coding-Tests zeigen oft nur einen kleinen Ausschnitt dessen, was Entwicklerarbeit im Alltag ausmacht. Meist geht es um Aufgaben unter künstlichen Bedingungen: begrenzte Zeit, isolierte Probleme, wenig Kontext. Geprüft wird dann vor allem, ob jemand eine Aufgabe lösen kann – nicht unbedingt, wie jemand mit bestehendem Code arbeitet, Entscheidungen begründet, mit anderen zusammenarbeitet oder Software wartbar weiterentwickelt.
Unbezahlte Probeaufgaben stoßen zusätzlich häufig auf Skepsis. Für Bewerbende bedeuten sie Aufwand neben Beruf, Familie oder laufenden Gesprächen. Nicht selten wirken sie wie kostenlose Vorarbeit. Gerade gefragte Entwickler springen an dieser Stelle eher ab, wenn der Prozess viel verlangt, bevor überhaupt ein ernsthaftes Gespräch über die tatsächliche Rolle entstanden ist.
Standardisierte Aufgaben versprechen zwar Vergleichbarkeit. Das ist für Unternehmen nachvollziehbar, weil Auswahlprozesse Unsicherheit reduzieren sollen. Trotzdem folgt daraus noch nicht, dass die Ergebnisse viel über den späteren Arbeitsalltag sagen. Wer in einem Test sauber abschneidet, zeigt damit nicht automatisch, wie sorgfältig mit Abhängigkeiten, Tests, Sicherheitsfragen oder kontinuierlichen Beiträgen in echten Projekten umgegangen wird.
Gerade bei Entwicklern zählt oft mehr als die Endlösung:
- wie Änderungen in einen bestehenden Kontext passen
- wie mit Testabdeckung umgegangen wird
- ob Sicherheitsbewusstsein erkennbar ist
- wie kontinuierlich und nachvollziehbar Beiträge entstehen
Deshalb suchen viele Teams nach Verfahren, die näher an realer Arbeit liegen – etwa über kostenlose Repo-Audits für Entwickler, verifizierbare Nachweise für Unternehmen und ein Modell mit Pay-per-Verify statt Abo.
Welche faireren Alternativen Unternehmen heute nutzen können
Wer auf klassische Coding-Tests verzichten will, hat heute mehrere praktikable Wege, technisches Können fairer einzuordnen. Dazu gehören vor allem:
- strukturierte Fachgespräche
- gemeinsame Code-Reviews
- Diskussionen realer Architekturentscheidungen
- Portfolios und Arbeitsproben aus der bisherigen Praxis, soweit sie vorhanden und teilbar sind
Besonders Gespräche über echte Entscheidungen können aussagekräftiger sein als Whiteboard-Aufgaben oder Rätsel. Sie machen sichtbar, wie jemand Prioritäten setzt, zwischen Geschwindigkeit, Wartbarkeit und Risiko abwägt und technische Überlegungen verständlich erklärt. Gerade diese Trade-offs prägen den Alltag in Entwicklungsteams oft stärker als das Lösen künstlich isolierter Probleme.
Auch Reviews vorhandener Arbeiten liegen in vielen Fällen näher an der späteren Tätigkeit. Statt unter Testbedingungen neuen Code zu produzieren, wird besprochen, was bereits entstanden ist: Wie wurde ein Problem gelöst? Wie sorgfältig wurde mit Struktur, Tests oder Abhängigkeiten umgegangen? Das schafft häufig mehr Kontext als eine einzelne Probeaufgabe.
Ganz ohne Grenzen sind diese Ansätze jedoch nicht. Nicht jeder Entwickler darf frühere Arbeiten teilen. Open-Source-Beiträge sind ungleich verteilt und sagen nicht bei allen Rollen gleich viel aus. Dazu kommt, dass Interviews immer auch von Selbstdarstellung, Gesprächsdynamik und Tagesform beeinflusst werden können.
Darum wird ein Ansatz interessant, der weniger auf Behauptungen setzt, sondern auf nachvollziehbare Evidenz aus realer Entwicklungsarbeit. Acquispect ist ein Beispiel dafür: Statt den Lebenslauf in den Mittelpunkt zu stellen, wird das Git-Repository eines Entwicklers auditiert. Unternehmen erhalten dabei keine rohen Repository-Daten, sondern eine überprüfbare Zusammenfassung des Ergebnisses; das Audit-Log zeigt, wie dieses Ergebnis zustande kam. So entsteht ein zusätzlicher Nachweis, der an echter Arbeit ansetzt, ohne frühere Projektdaten breit zu verteilen.
Repo-Audit statt Probeaufgabe: Wie ein evidenzbasierter Nachweis entsteht
Bei einem Repo-Audit wird keine neue Testaufgabe gestellt. Ausgangspunkt ist stattdessen ein reales Git-Repository. Der Nachweis entsteht also nicht aus einer künstlichen Prüfungssituation, sondern aus bereits geleisteter Entwicklungsarbeit, die im Projektkontext entstanden ist.
Der Ablauf umfasst drei Stufen.
Stage A: Ghostwriter Detector
Zuerst wird die .git-Historie forensisch analysiert. Dabei geht es um drei Fragen:
- wer die Commits verfasst hat
- ob Code in größeren Blöcken eingespielt wurde
- wie ein Impact Score ausfällt
Solche Signale sind im Hiring-Kontext deshalb relevant, weil sie Beiträge und Arbeitsmuster aus realen Abläufen greifbarer machen können. Sie ersetzen keine fachliche Einordnung, helfen aber dabei, Behauptungen aus dem Bewerbungsprozess mit nachvollziehbarer Evidenz aus echter Arbeit zu ergänzen.
Stage B: Safety Check
In der zweiten Stufe wird das Repository auf sicherheits- und qualitätsrelevante Punkte geprüft. Der Safety Check scannt auf:
- geleakte Secrets
- bekannte Schwachstellen in Abhängigkeiten
- Test Coverage
- den Tech Stack
Damit rückt nicht nur in den Blick, dass Code entstanden ist, sondern auch, wie sorgfältig mit typischen Risiken und Qualitätsfragen umgegangen wurde. Gerade bei Entwicklerrollen ist das wichtig, weil technische Arbeit selten nur aus einer funktionierenden Endlösung besteht. Ebenso relevant ist, ob Sicherheitsbewusstsein, Wartbarkeit und ein strukturierter Umgang mit Abhängigkeiten und Tests erkennbar werden.
Stage C: KI-Panel mit Konsensurteil
In der dritten Stufe bewertet ein Panel aus fünf KI-Expert-Personas die vorliegenden Signale:
- Tech Lead
- Security
- Performance
- Architect
- Craftsman
Diese fünf Perspektiven kommen zu einem Konsensurteil. Das Ergebnis ist bewusst kein sicherer Wahrheitsanspruch. Es handelt sich um ein Verdict mit Confidence Score.
Genau darin liegt der Unterschied zu vielen klassischen Probeaufgaben: Statt eine einmalige Testsituation zu bewerten, wird reale Entwicklungsarbeit in mehreren Schritten eingeordnet. Unternehmen erhalten so einen evidenzbasierten Nachweis, der technische Beiträge, Sicherheitsaspekte und Qualitätsmuster zusammenführt, ohne daraus absolute Gewissheit abzuleiten.
Was Unternehmen damit im Auswahlprozess konkret anders machen können
Ein Repo-Audit lässt sich im Hiring nicht nur an einer Stelle einsetzen. Es kann vor einem Interview als zusätzlicher Nachweis vorliegen oder nach einem Gespräch helfen, offene technische Fragen gezielter einzuordnen. Damit ersetzt es nicht zwingend jedes Gespräch. Es ergänzt den Prozess dort, wo Unternehmen mehr Substanz wollen als Selbstdarstellung, Lebenslaufpunkte oder das Ergebnis einer abstrakten Testaufgabe.
Der praktische Unterschied liegt oft in der Gesprächsgrundlage. Statt vor allem über behauptete Erfahrung zu sprechen, kann sich der Austausch stärker auf nachweisbare Entwicklungsarbeit beziehen. Das verschiebt den Fokus von allgemeinen Aussagen hin zu konkreteren Fragen, etwa:
- welche Beiträge tatsächlich erkennbar sind
- wie mit Sicherheitsaspekten umgegangen wurde
- wie Testabdeckung im Repository sichtbar wird
- welche technischen Entscheidungen im realen Kontext nachvollziehbar werden
Wichtig ist dabei auch die Form der Verifikation. Unternehmen sehen das Verdict und nicht automatisch die zugrunde liegenden Rohdaten des Repositorys. Diese selektive Verifikation lenkt den Blick auf das relevante Ergebnis, ohne frühere Arbeit unnötig breit offenzulegen.
Zusätzlich hilft das Audit-Log. Es liefert Kontext dazu, wie das Ergebnis zustande gekommen ist, statt nur ein Etikett zu vergeben. So lassen sich technische Gespräche oft konkreter und näher an realer Arbeit führen.
Gleichzeitig bleibt die Einordnung bewusst vorsichtig. Das Verdict kommt mit einem Confidence Score. Es ist damit eine zusätzliche Entscheidungsgrundlage im Auswahlprozess, aber kein Anspruch auf absolute Gewissheit.
Kostenmodell und Einführung ohne Abo-Logik
Auch beim Modell unterscheidet sich dieser Ansatz von vielen klassischen Hiring-Werkzeugen.
- Entwickler werden kostenlos auditiert.
- Unternehmen zahlen pro Verifikation.
- Ein Abonnement ist dafür nicht nötig.
Das passt vor allem dann, wenn Verifikation nicht als Dauerprozess, sondern als Bedarfslösung genutzt werden soll. Geprüft wird also genau dann, wenn ein bereits ausgestelltes Credential in einem konkreten Hiring-Kontext verifiziert werden soll. Dadurch lässt sich der Nachweis punktuell in den Auswahlprozess einbinden, ohne ihn an eine laufende Vertragslogik zu koppeln.
Für Teams, die nur in bestimmten Situationen verifizieren möchten, ist das ein klar umrissenes Nutzungsmodell: bezahlt wird die Prüfung des Nachweises, nicht die bloße Möglichkeit dazu.
Daneben ist ein Enterprise-Angebot auf Anfrage verfügbar. Mehr dazu steht auf der Preisseite.
Häufige Fragen zu Alternativen zu Coding-Tests
Sind Coding-Tests grundsätzlich ungeeignet, wenn man Entwickler einstellen will?
Nein. Sie sind nicht grundsätzlich ungeeignet, aber oft nur ein begrenztes Signal. Sie zeigen, wie jemand eine gestellte Aufgabe unter Testbedingungen löst. Weniger sichtbar wird dabei häufig, wie im laufenden Projekt gearbeitet wird: mit bestehendem Code, mit Abhängigkeiten, mit Tests und mit Verantwortung für Änderungen über Zeit.
Darum lohnt es sich, Coding-Tests eher als einen möglichen Baustein zu sehen als als alleinige Grundlage.
Wie lässt sich technisches Können prüfen, ohne Bewerbende mit unbezahlter Probearbeit zu belasten?
Sinnvoll sind Verfahren, die an vorhandener Arbeit ansetzen statt neue Aufgaben zu erzeugen. Dazu gehören zum Beispiel:
- strukturierte Fachgespräche
- gemeinsame Reviews bestehender Arbeiten, wenn sie teilbar sind
- Gespräche über reale Architektur- und Implementierungsentscheidungen
- Repo-Audits auf Basis eines Git-Repositorys
Bei Acquispect wird dafür nicht der Lebenslauf auditiert, sondern das Repository eines Entwicklers. Die Prüfung umfasst drei Stufen: forensische Analyse der .git-Historie, Safety Check und ein Panel aus fünf AI-Expert-Personas, das zu einem Konsensurteil mit Confidence Score kommt.
Was sieht ein Unternehmen bei einer Verifikation eigentlich genau – das Repository oder nur das Ergebnis?
Ein Unternehmen sieht bei der Verifikation das Verdict, nicht die rohen Repository-Daten. Das Credential ist als W3C Verifiable Credential (did:web) im Wallet des Entwicklers abgelegt; der Entwickler besitzt es. Die Verifikation ist selektiv. Zusätzlich kann das vollständige Audit-Log gelesen werden, das erklärt, wie das Ergebnis zustande kam.
Warum ist ein Audit echter Git-Arbeit oft näher am Berufsalltag als eine künstliche Testaufgabe?
Weil es Signale aus tatsächlicher Entwicklungsarbeit aufgreift. Ein Git-Repository zeigt eher, wie Beiträge entstanden sind, ob Code gesammelt eingespielt wurde, wie mit Test Coverage umgegangen wird, welche Abhängigkeiten vorhanden sind und ob bekannte Schwachstellen oder geleakte Secrets auffallen. Das liegt näher an dem, was Teams später im Alltag beurteilen müssen, als eine isolierte Aufgabe ohne echten Projektkontext.
Fazit: Weniger Probearbeit, mehr Evidenz
Wenn Unternehmen weniger unbezahlte Probeaufgaben verlangen wollen, brauchen sie Verfahren, die näher an echter Entwicklungsarbeit liegen als künstliche Testsituationen.
Hilfreich sind dabei zum Beispiel:
- strukturierte Fachgespräche
- Reviews vorhandener Arbeit
- Portfolios, soweit sie teilbar sind
Noch direkter wird der Nachweis, wenn ein Repository selbst geprüft wird. Bei Acquispect geschieht das in mehreren Stufen: forensische Analyse der .git-Historie, Safety Check und ein Panel aus fünf KI-Expert-Personas mit Konsensurteil und Confidence Score.
Das Ergebnis wird als W3C Verifiable Credential (did:web) im Wallet des Entwicklers abgelegt und bei Bedarf von Unternehmen verifiziert. Für Teams, die Fairness und technische Aussagekraft verbinden möchten, ist das ein Ansatz, den man im Hiring-Prozess prüfen kann.