Mit technische Bewertung suchen viele Unternehmen nach einer verlässlicheren Grundlage, um Entwicklerarbeit einzuordnen als reine Selbstaussagen im CV oder im Gespräch. Gemeint ist eine technische Bewertung, die zeigt, was jemand tatsächlich in realer Softwarearbeit beigetragen hat, statt nur Aufgaben unter künstlichen Testbedingungen zu bewerten.
Gerade beim Hiring ist das wichtig, wenn Bewerbern weniger unbezahlte Probearbeit zugemutet werden soll und trotzdem eine nachvollziehbare technische Einschätzung gebraucht wird. Dieser Artikel erklärt, was darunter sinnvollerweise zu verstehen ist, welche Bestandteile dazugehören und wie ein repo-basierter Audit mit Acquispect funktioniert, von der Methodik der Proof Engine bis zur Verifikation von Credentials für Unternehmen.
Was eine technische Bewertung leisten sollte
Wer nach technische Bewertung sucht, meint meist keine bloße Momentaufnahme aus einem Gespräch. Gemeint ist eine nachvollziehbare Einordnung technischer Arbeit: auf welcher Grundlage jemand entwickelt, wie sorgfältig Änderungen umgesetzt werden und welche Signale sich aus echter Praxis ableiten lassen.
CV, Projektliste und Selbstauskünfte helfen dabei nur begrenzt. Sie fassen Stationen und Technologien zusammen, zeigen aber oft nicht, wie die konkrete Arbeit zustande kam. Auch Live-Coding, Whiteboard-Aufgaben oder kurze Tests haben Grenzen: Sie bilden meist nur einen Ausschnitt ab und stehen unter Bedingungen, die mit realer Entwicklungsarbeit nicht immer viel gemeinsam haben.
Eine nützliche technische Bewertung sollte deshalb möglichst nah an der tatsächlichen Arbeit ansetzen, etwa bei:
- Commits und Änderungsverläufen
- Tests und Testabdeckung
- Abhängigkeiten und ihrem Zustand
- der technischen Entwicklung eines Projekts über Zeit
Für Einstellungsentscheidungen brauchen Unternehmen vor allem nachvollziehbare Signale, nicht nur Eindrücke. Dazu gehören Fragen wie: Wie hoch ist der erkennbare Eigenanteil? Wie sorgfältig wird gearbeitet? Gibt es Hinweise auf Sicherheitsbewusstsein? Welche technische Breite ist sichtbar? Und wie wirkt das Vorgehen insgesamt?
Auch für Bewerber ist das relevant. Wenn vorhandene Arbeit bewertet wird, muss nicht jedes Unternehmen erneut zusätzliche unbezahlte Aufgaben verlangen. Wer sehen möchte, wie ein kostenloses Repo-Audit für Entwickler beschrieben ist, findet dort den Ansatz aus Entwicklersicht.
Wichtig ist dabei: Eine technische Bewertung ist kein absoluter Wahrheitsbeweis. Sie ist eine fundierte Entscheidungsgrundlage mit dokumentierten Kriterien. Genau hier setzt Acquispect an: nicht beim CV, sondern beim Audit des Git-Repositories eines Entwicklers. Organisatorisch ist das Modell klar über die Preisstruktur ohne Abo eingeordnet.
Warum ein Git-Repository oft mehr zeigt als der Lebenslauf
In der Softwareentwicklung liegen die aussagekräftigsten Spuren der Arbeit oft nicht im Lebenslauf, sondern im Repository. Dort finden sich Commits, Autorenhinweise, Änderungen über Zeit, Tests und die verwendeten Technologien. Für eine technische Bewertung sind das keine Nebendetails, sondern konkrete Hinweise darauf, wie Entwicklung tatsächlich stattgefunden hat.
Der wichtige Unterschied zum CV: Ein Lebenslauf verdichtet Projekte zu Stationen und Schlagworten. Ein Repository zeigt Beiträge auf Code-Ebene. Sichtbar werden nicht nur Ergebnisse, sondern auch Verlauf und Arbeitsweise: wie Änderungen eingebracht wurden, ob Tests Teil der Arbeit sind und welche technische Umgebung dabei eine Rolle spielt.
Gerade deshalb sind Arbeitsproben aus einem bestehenden Projekt oft aussagekräftiger als einmalige Testaufgaben unter Zeitdruck. Sie entstehen in realen Zusammenhängen und lassen eher erkennen, wie jemand im Entwicklungsalltag arbeitet, statt nur, wie jemand in einer künstlichen Prüfungssituation reagiert.
Natürlich ersetzt ein Repository kein Gespräch über Teamarbeit, Produktverständnis oder Kommunikation. Diese Themen bleiben wichtig. Aber eine repo-basierte Bewertung ergänzt sie um technische Evidenz, die über Selbstaussagen hinausgeht.
Für Unternehmen mit vielen Bewerbungen ist das zusätzlich organisatorisch relevant: Eine standardisierte technische Bewertung auf Basis von Repositories kann Vergleichbarkeit schaffen, ohne jede Einschätzung nur auf Intervieweindrücke zu stützen.
Bei Acquispect können Entwickler ihr Repository kostenlos auditieren lassen. Wer sehen möchte, wie dieses kostenlose Repo-Audit für Entwickler beschrieben ist, findet dort die Darstellung aus Entwicklersicht.
Wie die technische Bewertung bei Acquispect aufgebaut ist
Die technische Bewertung bei Acquispect folgt einem dreistufigen Audit-Rahmen: der Proof Engine. Sie wertet nicht Aussagen über Arbeit aus, sondern Spuren realer Entwicklerarbeit im Git-Repository. Ziel ist eine belastbare technische Einordnung auf Basis dokumentierter Artefakte aus dem Entwicklungsverlauf.
Die erste Stufe ist Stage A: der Ghostwriter Detector. Hier wird die .git-Historie forensisch analysiert. Im Mittelpunkt stehen dabei drei Signalarten:
- wer die Commits verfasst hat
- ob Code in größeren Blöcken in das Repository hineingekippt wurde
- ein Impact Score
Diese Stufe ist für die technische Bewertung wichtig, weil sie hilft, den erkennbaren Eigenbeitrag besser einzuordnen. Sie liefert keine absolute Gewissheit, aber sie schafft eine fundiertere Grundlage, um die Plausibilität einer Arbeitshistorie zu verstehen. Für Hiring-Teams ist das relevant, wenn nicht nur das Endergebnis betrachtet werden soll, sondern auch, wie Beiträge im Projektverlauf entstanden sind.
Darauf folgt Stage B: der Safety Check. Diese Stufe scannt das Repository auf:
- geleakte Secrets
- bekannte Schwachstellen in Abhängigkeiten
- Test Coverage
- den Tech Stack
Damit schaut die technische Bewertung nicht nur darauf, ob Software irgendwie funktioniert. Sie bezieht auch Punkte ein, die im Entwicklungsalltag für Wartbarkeit und Sicherheitsrelevanz zählen. Ein Repository kann fachlich interessant wirken und trotzdem Risiken enthalten, etwa durch offengelegte Zugangsdaten, anfällige Dependencies oder fehlende Testabdeckung. Stage B ergänzt die Bewertung daher um praktische Qualitäts- und Sicherheitsaspekte.
Die dritte Stufe ist Stage C. Hier bewertet ein Panel aus fünf AI-Expert-Personas die Ergebnisse aus den vorherigen Stufen aus unterschiedlichen Blickwinkeln. Diese Perspektiven sind:
- Tech Lead
- Security
- Performance
- Architect
- Craftsman
Statt nur ein einzelnes Signal zu betrachten, entsteht so eine zusammengesetzte technische Einschätzung. Die fünf Perspektiven arbeiten auf ein gemeinsames Verdict hin, das mit einem Confidence Score ausgegeben wird. Genau dadurch wird aus einzelnen Repository-Signalen eine nachvollziehbare technische Bewertung, die mehrere relevante Dimensionen von Entwicklerarbeit zusammenführt.
Wie Verifikation funktioniert, ohne Rohdaten offenzulegen
Nach dem Audit wird das Verdict nicht einfach als internes Ergebnis gespeichert, sondern als W3C Verifiable Credential mit did:web ausgestellt. Damit liegt die technische Bewertung in einem standardisierten, verifizierbaren Format vor.
Wichtig dabei: Dieses Credential liegt im Wallet des Entwicklers. Es gehört also dem Entwickler selbst, nicht dauerhaft der prüfenden oder verifizierenden Seite. Für Hiring-Prozesse ist das ein anderer Ansatz als der direkte Zugriff auf Repository-Daten oder auf vollständige Projektunterlagen.
Ein Unternehmen verifiziert die Bewertung dann bei Bedarf. Es muss dafür nicht laufend auf das Repository zugreifen und erhält auch nicht pauschal Einsicht in sämtliche Rohdaten aus dem Audit. Die Verifikation ist selektiv aufgebaut:
- sichtbar ist das Verdict
- ausgegeben wird ein Confidence Score
- die Rohdaten des Repository-Audits werden nicht offengelegt
Das ist für eine technische Bewertung relevant, weil damit nicht der gesamte Entwicklungsverlauf geteilt werden muss, nur um eine Einschätzung nachzuweisen. Gleichzeitig bleibt die Bewertung erklärbar: Der vollständige Audit-Log zeigt, wie das Ergebnis zustande gekommen ist, ohne den Grundgedanken selektiver Einsicht aufzugeben.
Für Einstellungsprozesse schafft das eine praktikable Balance. Unternehmen erhalten eine nachvollziehbare technische Einschätzung, Entwickler behalten die Kontrolle über ihre Nachweise und müssen nicht jedes Mal ihre komplette Arbeitshistorie offenlegen.
Wie die Verifikation solcher Credentials aus Unternehmenssicht beschrieben ist, wird auf der Unternehmensseite näher dargestellt.
Was das für Hiring-Prozesse praktisch verändert
Eine technische Bewertung auf Basis realer Repository-Arbeit kann den Hiring-Prozess anders ordnen. Statt früh mit abstrakten Aufgaben zu starten, lässt sich das Gespräch zunächst auf dokumentierte technische Evidenz stützen. Danach können Interviews gezielter werden: mit Rückfragen zu Entscheidungen, Prioritäten, Sicherheitsaspekten oder zum Umgang mit Änderungen im Projektverlauf.
Das verändert auch den Umgang mit unbezahlter Probearbeit. Wenn vorhandene Arbeit zuerst ausgewertet wird, müssen zusätzliche Aufgaben nicht mehr automatisch der Standard sein. Sie können zur Ausnahme werden, wenn nach der bestehenden Evidenz noch etwas offen bleibt.
Wichtig ist dabei: Die Bewertung ist ein Baustein, nicht der einzige Maßstab. Sie ergänzt andere Teile des Prozesses, zum Beispiel:
- Interviews
- Referenzen
- Teamfit
Auch organisatorisch bleibt das Modell klar. Entwickler werden kostenlos auditiert. Unternehmen zahlen pro Verifikation und brauchen kein Abonnement. Wie dieses Modell eingeordnet ist, zeigt die Preisübersicht.
Häufige Fragen zur technischen Bewertung
Was ist mit "technische Bewertung" bei Entwicklerarbeit genau gemeint?
Mit technische Bewertung ist hier eine nachvollziehbare Einordnung realer Entwicklerarbeit gemeint. Es geht nicht nur darum, was jemand über seine Arbeit sagt, sondern welche technischen Spuren diese Arbeit hinterlässt. Eine solche Bewertung soll helfen, Beiträge, Sorgfalt und technische Praxis besser einzuordnen. Sie ist keine absolute Gewissheit, sondern eine dokumentierte Einschätzung.
Warum ist ein Git-Repository für eine technische Bewertung oft aussagekräftiger als ein CV?
Ein CV fasst zusammen. Ein Repository zeigt, wie Arbeit tatsächlich entstanden ist. Für eine technische Bewertung ist das wichtig, weil dort unter anderem sichtbar wird:
- wie sich Änderungen über Zeit entwickeln
- wer Commits verfasst hat
- ob Tests Teil der Arbeit sind
- welche Technologien und Abhängigkeiten genutzt werden
Damit entsteht ein Bild aus realer Projektarbeit statt nur aus Selbstdarstellung. Das ersetzt kein Gespräch, liefert aber eine andere Art von Evidenz.
Welche Punkte prüft Acquispect in der technischen Bewertung eines Repositories?
Acquispect prüft ein Repository in drei Stufen. Zuerst analysiert der Ghostwriter Detector die .git-Historie forensisch: Autorenschaft von Commits, mögliches Code-Dumping und einen Impact Score. Danach folgt der Safety Check mit Scans auf geleakte Secrets, bekannte Schwachstellen in Dependencies, Test Coverage und den Tech Stack. Anschließend bewertet ein Panel aus fünf AI-Expert-Personas — Tech Lead, Security, Performance, Architect und Craftsman — die Ergebnisse gemeinsam und erstellt ein Verdict mit Confidence Score.
Was sieht ein Unternehmen bei der Verifikation – und was nicht?
Bei der Verifikation sieht ein Unternehmen das Verdict und den Confidence Score. Es sieht nicht die Rohdaten des Repository-Audits. Das Ergebnis liegt als W3C Verifiable Credential mit did:web im Wallet des Entwicklers. So bleibt die Verifikation selektiv, während der Audit-Log nachvollziehbar macht, wie die Einschätzung zustande kam.
Wie passt eine technische Bewertung in einen Hiring-Prozess, ohne Interviews zu ersetzen?
Sie eignet sich als zusätzlicher Baustein vor oder zwischen Interviews. Unternehmen können zuerst technische Evidenz einordnen und danach gezielter nachfragen. Gespräche zu Zusammenarbeit, Kommunikation, Verantwortung oder Produktverständnis bleiben weiterhin wichtig. Die technische Bewertung ersetzt diese Punkte nicht, sondern ergänzt sie um eine strukturierte Sicht auf reale Entwicklungsarbeit.
Fazit: technische Bewertung näher an echter Arbeit
Eine technische Bewertung wird vor allem dann sinnvoll, wenn sie sich auf reale Entwicklerarbeit stützt und nicht nur auf Behauptungen, Schlagworte oder Intervieweindrücke. Für Unternehmen schafft das eine nachvollziehbarere Grundlage, um technische Beiträge einzuordnen.
Acquispect setzt dafür auf ein Git-basiertes Audit in drei Stufen:
- Ghostwriter Detector
- Safety Check
- Panel aus fünf AI-Expert-Personas
Das Ergebnis wird als verifizierbares Credential ausgegeben. Das Verdict kommt mit einem Confidence Score und ist als fundierte Einschätzung zu verstehen, nicht als absolute Gewissheit. So entsteht mehr technische Evidenz für Unternehmen und weniger zusätzliche unbezahlte Probearbeit für Bewerber.