Bewerbungen, Whitelist und Menschen, die Formulare ausfüllen

Das Bewerbungssystem war der Teil von Los Santos County, an dem ich am längsten gesessen habe. Nicht wegen des Codes — ein Formular mit Freitextfeldern, ein Datensatz, ein Status, eine Entscheidung. Sondern weil jede scheinbar kleine Entscheidung eine Wirkung auf echte Leute hatte.

Der technische Kern

CREATE TABLE bewerbungen (
  id           INTEGER PRIMARY KEY,
  nutzer_id    INTEGER NOT NULL,
  status       VARCHAR(20) NOT NULL DEFAULT 'eingereicht',
  eingereicht  DATETIME NOT NULL,
  bearbeiter   INTEGER NULL,
  entschieden  DATETIME NULL,
  begruendung  TEXT NULL
);
 
CREATE TABLE bewerbung_antworten (
  bewerbung_id INTEGER NOT NULL,
  frage_id     INTEGER NOT NULL,
  antwort      TEXT NOT NULL
);

Die Trennung von Bewerbung und Antworten war wichtiger, als sie aussieht: Fragen ändern sich. Wenn die Antworten als Spalten in der Bewerbungstabelle stünden, wäre jede geänderte Frage eine Schemaänderung — und alte Bewerbungen würden plötzlich zu Fragen gehören, die es nicht mehr gibt.

Stattdessen gibt es einen Fragenkatalog mit Versionen. Jede Bewerbung hängt an der Fassung, die zum Zeitpunkt des Absendens galt. Damit bleibt eine zwei Jahre alte Bewerbung lesbar, auch wenn die Fragen längst andere sind.

Die Details, die über Menschen entscheiden

Ein Entwurf, der nicht verloren geht. Die erste Fassung hatte keinen Zwischenspeicher. Jemand hat vierzig Minuten an einer Charakterbeschreibung geschrieben, ist versehentlich zurückgegangen, und alles war weg. Die Person hat sich nie wieder beworben. Seitdem speichert das Formular alle paar Sekunden lokal — technisch fünfzehn Zeilen, menschlich der Unterschied zwischen einem neuen Mitglied und keinem.

Eine Ablehnung mit Begründung. Der Wunsch des Teams war zunächst, Ablehnungen ohne Begründung zu verschicken, weil Begründungen Diskussionen auslösen. Ich habe dagegen argumentiert und mich durchgesetzt, was rückblickend richtig war: Eine Ablehnung ohne Grund führt zu genau derselben Diskussion, nur dass sie im Discord stattfindet statt im System.

Eine Sperrfrist statt einer Sperre. Wer abgelehnt wird, darf sich nach zwei Wochen erneut bewerben. Das war das Ergebnis einer langen Diskussion — die Alternative war, Abgelehnte dauerhaft auszuschließen. Zwei Wochen sind lang genug, um Spontanwiederholungen zu verhindern, und kurz genug, um jemandem eine zweite Chance zu lassen.

Sichtbarkeit nur für Zuständige. Bewerbungen enthalten teilweise persönliche Dinge — Alter, Erfahrungen, manchmal mehr. Sie gehen nur an die, die entscheiden. Kein „das ganze Team kann alles sehen".

Infobox

Der wichtigste Satz aus dieser Zeit: Jedes Feld, das man abfragt, muss man begründen können. Wir hatten zunächst eine Abfrage des Geburtsdatums. Auf die Frage, wofür genau, kam als Antwort: „damit man das Alter sieht". Für ein Mindestalter reicht eine Ja/Nein-Angabe. Das Feld ist geflogen, und die Seite wurde dadurch besser.

Was ich über Formulare gelernt habe

Freitext ist teuer. Jede offene Frage bedeutet Lesearbeit für das Team. Zehn Fragen mit Freitext ergeben bei dreißig Bewerbungen pro Woche eine Menge Arbeit, die niemand macht. Wir haben den Katalog auf vier offene Fragen gekürzt und den Rest zu Auswahlfragen gemacht.

Regelwerksfragen sind keine Wissensabfrage. Anfangs gab es einen Test mit Fragen zum Regelwerk. Nach zwei Wochen kursierte ein Dokument mit allen Antworten. Das ist bei jedem solchen Test der Fall, und es ist kein Grund, ihn abzuschaffen — man muss nur wissen, dass er Bereitschaft misst, nicht Verständnis.

Automatische Vorprüfungen sind Gold wert. Nicht als Entscheidung, sondern als Vorsortierung: Ist das Discord-Konto verknüpft, hat die Person die nötige Spielzeit, gibt es eine frühere Ablehnung? Diese drei Prüfungen laufen automatisch und stehen als Hinweise über der Bewerbung. Das Team entscheidet weiterhin selbst, sieht aber sofort, worauf es achten sollte.

Der Teil, den ich unterschätzt habe: die Warteschlange

Nach dem Start kamen deutlich mehr Bewerbungen als erwartet. Innerhalb von zwei Wochen lagen über hundert unbearbeitet da, und die Leute fragten im Discord nach.

Ich habe daraufhin drei Sachen gebaut, die nichts mit dem Formular zu tun haben und trotzdem den größten Unterschied gemacht haben:

Eine sichtbare Position. Der Bewerber sieht, wie viele vor ihm liegen. Das ersetzt jede Nachfrage.
Eine Zuweisung. Ein Teammitglied übernimmt eine Bewerbung, damit nicht drei dieselbe lesen und siebzig gar keiner.
Eine Alterswarnung. Bewerbungen, die älter als sieben Tage sind, werden hervorgehoben. Nicht als Vorwurf, sondern damit niemand hinten runterfällt.

Die Zahlen, die das Team überrascht haben

Nach ein paar Monaten hatte das System genug Daten für Auswertungen, und zwei Ergebnisse haben die Diskussion im Team verändert.

Die Abbruchquote im Formular lag bei über der Hälfte. Mehr als die Hälfte derer, die anfingen, haben nie abgeschickt. Das war die Zahl, die zur Kürzung des Fragenkatalogs geführt hat — vorher hatte niemand ein Gefühl dafür, wie viele wir unterwegs verlieren.

Die durchschnittliche Bearbeitungszeit lag bei mehreren Tagen, der schlechteste Fall bei über zwei Wochen. Das Team hätte auf Nachfrage „ein bis zwei Tage" geschätzt. Die Wahrnehmung derer, die entscheiden, unterscheidet sich systematisch von der Wartezeit derer, die warten.

Beide Zahlen waren unangenehm und beide haben zu konkreten Änderungen geführt. Das ist der Punkt, an dem Messung mehr wert ist als jede Meinung — inklusive meiner eigenen.

Was ich beim Datenschutz gelernt habe

Ein Bewerbungssystem sammelt personenbezogene Daten, und das ist keine Formalie, sondern eine Verantwortung mit praktischen Folgen.

Aufbewahrungsfristen brauchen eine Entscheidung. Wie lange bleibt eine abgelehnte Bewerbung? Bei uns: sechs Monate, damit man bei einer erneuten Bewerbung den Zusammenhang kennt, danach automatische Löschung.

Löschung muss möglich sein, ohne die Datenbank anzufassen. Wenn jemand die Löschung seiner Daten verlangt, darf das keine Handarbeit an der Konsole sein. Es braucht einen Weg in der Oberfläche.

Zugriff protokollieren. Wer hat welche Bewerbung geöffnet? Das klingt nach Überwachung des eigenen Teams und ist vor allem Schutz: Wenn jemand behauptet, Informationen seien weitergegeben worden, kann man nachsehen.

Diese drei Punkte habe ich damals halb umgesetzt und in späteren Projekten vollständig. Sie kosten zusammen vielleicht einen Tag Arbeit — und sie sind der Unterschied zwischen einem System, das man erklären kann, und einem, bei dem man hofft, dass niemand fragt.

Was davon übrig geblieben ist

Das Projekt selbst gibt es in dieser Form nicht mehr. Was geblieben ist, ist eine Haltung zu Formularen, die ich seitdem überall anwende — auch bei Ticket-Kategorien in Yurna oder bei den Bewerbungen, die auf meinen eigenen Servern anfallen.

Ein Formular ist nie nur ein Formular. Es ist der erste Kontakt mit einer Organisation, und es sagt mehr über sie aus als jede Regelseite. Wer zwölf Pflichtfelder abfragt und ohne Begründung ablehnt, hat eine bestimmte Haltung. Wer vier Fragen stellt, den Entwurf speichert und begründet, hat eine andere. Beides ist derselbe Aufwand in Code.