Cloud Intelligence™
Unsere Recruiter liefern jetzt Software
Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.
About Vadim Solovey
Founded DoiT in 2011 and have been here ever since — in every flavor of CTO, co-CEO, and now CEO. I started my career in 1999 building data centers before anyone called it "the cloud," and I've spent the two decades since trying to deliver on what the cloud was actually supposed to be. I still write code most weeks.
My personal pageVor einem Jahr war careers.doit.com eine HubSpot-Seite mit Filtern, die nicht funktionierten. Wer auf die Kategorie "Customer Experience" klickte, sah vielleicht ein Drittel der offenen Stellen – weil Jobs in Greenhouse mit Unterabteilungen getaggt werden und die Seite die Hierarchie nie durchlaufen hat. Kandidaten bewarben sich über ein eingebettetes iframe, das aussah, als wäre es 2014 gestaltet worden. Weil es das war.
Heute betreibt dasselbe Team, das früher Tickets zu dieser Seite eingereicht hat, eine Next.js-Anwendung, die produktiv auf Google Cloud Run läuft. Sie liefert die öffentliche Karriereseite aus – und hinter einem Login laufen ein KI-gestützter Job-Description-Builder, ein Tool fürs Candidate Sourcing, ein Bewerbungs-Screener, ein Vergütungs-Review-Workflow mit Freigaben, ein Blog-Editor für Mitarbeitergeschichten und ein Slack-Bot, der neue Stellen ankündigt. Das Talent-Acquisition-Team hat keine Agentur beauftragt. Es hat nicht im Engineering-Backlog gewartet. Es hat das Ganze selbst gebaut – mit einem Engineer und einer Menge Claude.
Ich möchte zeigen, wie das funktioniert. Denn ich glaube, das Modell ist wiederholbar – und die meisten Unternehmen machen es sich unnötig kompliziert.
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
Der Applied AI Engineer
Im Kern steht eine Rolle, die wir Applied AI Engineer nennen. Ein Softwareentwickler, dessen Vollzeitjob es ist, in ein einzelnes Business-Team eingebettet zu sein. Kein Berater, der Anforderungen aufnimmt und für ein Quartal verschwindet, und kein Plattform-Team, das "AI Enablement" für alle und niemanden baut. Ein Engineer, ein Team (in diesem Fall unser People-Ops-Team) – jemand, der in deren Meetings sitzt und deren Ärgernisse am eigenen Leib erlebt.
Unser Talent-Acquisition-Team, das zur People-Organisation gehört, bekam einen. Der Auftrag des Engineers war simpel: automatisieren, was langweilig ist, bauen, was fehlt, und dem Team beibringen, mit der Zeit mehr davon selbst zu erledigen.
Der letzte Punkt ist der wichtigste. Wir messen den Engineer daran, wie viel das Team ohne ihn liefern kann – nicht an seinem eigenen Output.
Die eigentliche Arbeit waren die Specs
Der Neubau der Karriereseite begann mit einem Dokument, nicht mit Code. Wir schrieben eine lange Markdown-Spezifikation, die alles beschrieb: die Abteilungshierarchie in Greenhouse und wie genau die Filter sie durchlaufen müssen, die Felder des Bewerbungsformulars, die Redirects von alten URLs, die Anforderungen an Barrierefreiheit – sogar die Fehler der alten Seite, die sich nicht wiederholen durften. Diese Datei landete als CLAUDE.md im Repo, und Claude Code baute die Seite danach.
Womit ich nicht gerechnet hatte: Die Recruiter konnten die Spec lesen. Und sie korrigierten sie. "Das Recruiter-Screening dauert 30 Minuten, nicht 45." "Jobs werden mit der Unterabteilung getaggt, deshalb funktionieren die Filter nicht." Domänenwissen, das normalerweise im Stille-Post-Spiel zwischen PM und Dienstleister verloren geht, floss direkt in die Single Source of Truth ein.
Heute schreiben wir für jedes interne Tool eine solche Spec. Die Spec für den JD Builder umfasst rund zehn Seiten und enthält die exakten Prompts, das Bewertungsraster und offene Fragen an die Stakeholder. Das Schreiben dauerte Tage. Das fertige Tool brauchte weniger Zeit als die Spec. Dieses Verhältnis fühlt sich für mich immer noch seltsam an – und ich habe aufgehört zu erwarten, dass es sich wieder umkehrt.
Was das Team tatsächlich gebaut hat
Die öffentliche Seite ist der sichtbare Teil: ein eigenes Bewerbungsformular, das direkt mit der Greenhouse-API spricht, eine Hiring-Map, Job-Alerts, sauberes SEO und AEO sowie eine gebrandete Bestätigungs-E-Mail direkt nach der Bewerbung. Schön – aber das ist Pflichtprogramm.
Die internen Tools sind das, was die Arbeitswoche des Teams wirklich verändert hat:
JD Builder. Jeder bei DoiT kann eine Stellenbeschreibung generieren oder umschreiben lassen. Die KI schreibt sie in unserer Tonalität – und bewertet den Entwurf während des Editierens etwa im Sekundentakt neu, entlang von fünf Dimensionen: Inklusion, Tonalität, Vollständigkeit, Lesbarkeit und die Frage, ob ein starker Kandidat beim Scrollen tatsächlich hängen bleiben würde. Offene Stelle aus Greenhouse importieren, überarbeiten, zurückspielen. Unser Zielwert: von "Ich brauche eine JD" bis zur Veröffentlichung in unter 15 Minuten, mit einem Inklusions-Score von 85 oder besser. Hiring Manager schicken keine Entwürfe mehr zur Überarbeitung an TA. Sie erledigen es selbst.
Unser internes System zum Erstellen von Stellenbeschreibungen
Candidate Sourcing. Ein Recruiter wählt eine offene Stelle, das Tool liest die Stellenbeschreibung, lässt die KI eine Suchanfrage samt Verifizierungskriterien formulieren und übergibt beides an eine Web-Research-API, die rund 250 passende Personen findet und deren berufliche E-Mail-Adressen ermittelt. Die Kriterien kodieren, was wir darüber gelernt haben, wer bei uns erfolgreich ist – etwa Kandidaten aus Unternehmen, die an Plattform- und DevOps-Teams verkaufen. Die Ansprache erfolgt direkt aus demselben Screen, über LinkedIn und E-Mail, mit markierten Leads, Notizen und Kontakt-Tracking. Sourcer jonglieren nicht länger mit Browser-Tabs und Tabellen.
Die Oberfläche für das Candidate Sourcing
Candidate Screener. An der schieren Masse scheitern Menschen im Hiring – deshalb ist dieses Tool das wichtigste. Auf eine kürzlich ausgeschriebene Stelle gingen rund 2.200 Bewerbungen ein; die Greenhouse-eigenen Filter reduzierten das auf etwa 1.100 aktive Kandidaten. Der Screener zog für jeden Einzelnen Lebenslauf, Screening-Antworten und Profil aus Greenhouse und ließ die KI alle gegen acht universelle Eigenschaften plus die spezifischen Anforderungen der Rolle bewerten. Jeder Kandidat erhält eine schriftliche Einschätzung – und ich meine wirklich jeder: eine Zusammenfassung, Stärken mit Belegen als Zitat aus dem Lebenslauf, Punkte, die man im Interview vertiefen sollte, und Eigenschafts-Scores, mit Link zurück zum Greenhouse-Profil. Wir setzten den Schwellenwert auf 96 und landeten bei 61 starken Kandidaten. Das ist eine Shortlist, die ein Hiring-Team tatsächlich gemeinsam durchgehen kann – und bei Bedarf als CSV exportiert. Die Rolle, für die wir das Tool eingesetzt haben? Unser nächster Applied AI Engineer. Das passte irgendwie.
Kandidaten-Screening mit KI-Classifier
Comp Review. Bewirbt sich ein Doer in Greenhouse auf eine interne Stelle, erstellt ein Webhook den Entwurf des Vergütungs-Reviews, bevor überhaupt jemand danach fragt: aktuelles Gehalt, Bonus, Equity und Beförderungshistorie aus der Rippling-API (unserem HR-System), plus ein Gehaltsband, berechnet aus Peers in derselben Rolle und Region. Anschließend benachrichtigt er den Recruiter, die Führungskraft, deren Vorgesetzte, den HRBP und die Abteilungsleitung auf Slack. Was früher eine Woche Tabellen-Archäologie und E-Mail-Nachfassen war, ist heute ein Freigabe-Workflow mit Erinnerungen.
Das System für Vergütungs-Reviews
Slack-Ankündigungen. Neue Stellen werden auf Slack gepostet, sobald sie ausgeschrieben sind – mit getaggtem Recruiter und Hiring Manager sowie der Deadline für interne Bewerbungen. Doers erfahren sofort von neuen Rollen und können einen internen Wechsel in Betracht ziehen, wenn er zu ihren Karrierezielen passt.
Interne Slack-Benachrichtigungen
Keines dieser Tools hätte es für sich genommen je auf die Engineering-Roadmap geschafft. Zusammen haben sie verändert, wie das Team arbeitet.
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
Der Teil, der Vorsicht verdient
Das Screening ist der folgenreichste Bereich, in dem wir KI einsetzen – und ich möchte beide Seiten ehrlich benennen.
Vieles spricht dafür. Der Screener liest Kandidat Nummer 1.100 mit derselben Aufmerksamkeit und denselben Kriterien wie Kandidat Nummer 1. Menschen können das nicht. Wir werden müde, wir orientieren uns am zuletzt gelesenen Lebenslauf, und am späten Nachmittag achten wir auf die falschen Muster. Wer auf Position 900 im Stapel liegt, bekommt von der Maschine eine faire Bewertung, die er von einem erschöpften Menschen nie bekommen hätte. Genau an dieser Stelle bin ich ein überzeugter Befürworter von KI.
Aber KI bringt ihre eigenen Verzerrungen mit – und eine konsistente Verzerrung, die auf 1.100 Menschen gleichzeitig wirkt, ist ein anderes Problem als eine inkonsistente menschliche. Deshalb liefert der Screener eine Shortlist und eine Liste von Punkten zum Nachhaken; jede Entscheidung danach treffen Menschen. Und bevor das vom Experiment zum etablierten internen Tooling wird, sind wir uns selbst ein offenes Gespräch über Fairness, Transparenz und Leitplanken schuldig. Wir führen dieses Gespräch gerade – laut und offen. Und ich rate jedem Unternehmen, das so etwas baut, dieses Gespräch zu führen, bevor das Tool so gut funktioniert, dass niemand mehr darüber sprechen will.
Was ich einem anderen CEO sagen würde
Starten Sie mit etwas Kaputtem, nicht mit einer KI-Strategie. Wir wollten nicht "KI im HR-Bereich einführen". Wir wollten eine Karriereseite mit kaputten Filtern reparieren. Der Rest hat sich von dort aus aufgebaut – ein Ärgernis nach dem anderen.
Ein Repo, gemeinsame Basis. Jedes Tool lebt im Careers-Repo und nutzt dieselbe Greenhouse- und Rippling-Integration und dieselbe Authentifizierung. Das zweite Tool kostete einen Bruchteil des Aufwands des ersten. Das fünfte war fast geschenkt.
Nicht-Engineers reviewen Ergebnisse, nicht Code. Unsere Recruiter können kein TypeScript lesen – und müssen es auch nicht. Sie erkennen in Sekunden, ob eine generierte JD nach uns klingt, und das Qualitäts-Dashboard gibt ihnen eine gemeinsame Sprache dafür, was nicht stimmt. Vertrauen Sie den Fachleuten bei der Beurteilung des Outputs – und überlassen Sie den Diff dem Agenten und dem Engineer.
Die Kosten sind unspektakulär. Ein schnelles, günstiges Modell für das Echtzeit-Scoring, ein starkes Modell für die Generierung, ein Container, der auf null skaliert, wenn um 3 Uhr nachts niemand einstellt. Das ist kein großer Kostenblock. Teuer ist das Gehalt des Engineers – und genau das ist die Idee: ein Engineer pro Team.
Die unglamouröse Wahrheit: Der Großteil des Werts kam von einem Menschen, dem die Sache wichtig war, nah dran an der Arbeit – mit einem Coding-Agenten, der die Ausrede "Wir haben keine Engineering-Kapazität" aus der Welt geschafft hat. Diese Kombination steht heute fast jedem Unternehmen offen.
Und wenn ein Unternehmen, in dem Recruiter produktionsreife Software liefern und der CEO Specs schreibt, nach Ihrem Geschmack klingt: Die Karriereseite, die das Team gebaut hat, finden Sie unter careers.doit.com. Die Filter funktionieren jetzt – ich habe es überprüft.
