Wie Sie einen Programmiertest erstellen

What you'll need

• Ein SkillCort-Workspace (oder eine Demo)
• Ein echtes Beispiel für den Code, den Ihr Team schreibt — ein Bug, ein kleines Feature, ein Refactoring
• Eine erfahrene Person aus dem Engineering, die Aufgabe und Rubrik definiert
• Eine Entscheidung darüber, welche Sprachen Sie akzeptieren

Step 1: Wählen Sie eine realistische Aufgabe statt eines Algorithmus-Rätsels

Sehen Sie sich Ihre Pull Requests des letzten Monats an und wählen Sie eine Aufgabe, die wie die wiederkehrenden geformt ist: einen Bug anhand eines fehlerhaften Verhaltens beheben, eine kleine Funktion um einen neuen Fall erweitern, einen unübersichtlichen Block refactoren oder eine Datentransformation schreiben. Solche Aufgaben sagen mehr über die tägliche Arbeitsleistung aus als das Umkehren eines Binärbaums.

Bemessen Sie sie auf 30–45 Minuten konzentrierte Arbeit für eine kompetente Neueinstellung. Ein Rätsel belohnt, wer es geübt hat; eine realistische kleine Aufgabe belohnt, wer bestehende Absichten lesen, eine tragfähige Änderung vornehmen und den Code verständlich halten kann — und genau dafür stellen Sie ein.

Streichen Sie framework- und unternehmensspezifisches Wissen, sofern die Rolle es nicht wirklich verlangt, und liefern Sie jeden nötigen Kontext im Briefing selbst mit. Eine starke Person aus dem Engineering, die Ihren Stack nie angefasst hat, sollte Ihnen trotzdem tragfähiges Urteilsvermögen zeigen können. Testen Sie die Kompetenz, nicht die Vertrautheit mit den Nebensächlichkeiten Ihrer Codebasis.

• Kommt in Ihrer echten Codebasis vor, nicht in Interview-Vorbereitungsbüchern
• Hat mehr als eine vernünftige Lösung
• Passt ohne Heldentaten in 30–45 Minuten
• In unter zehn Minuten von Prüfenden lesbar

Step 2: Legen Sie das Code-Item in der Item-Bibliothek an

Erstellen Sie einen Ordner für die Rolle — zum Beispiel Backend Engineer — mit Tags für Kompetenzbereich und Schwierigkeit, und legen Sie dann ein Item mit dem Code-Itemtyp an. Bewerbende schreiben und bearbeiten Code direkt im Antwortbereich, und Prüfende sehen ihn später an Ort und Stelle durch.

Versehen Sie das Item mit Startcode statt mit einem leeren Editor. Eine kurze Funktion mit einem beschriebenen Bug oder ein Stub mit klarem Kontrakt setzt alle Bewerbenden auf denselben Ausgangspunkt und macht ihre Änderungen unmittelbar vergleichbar. Echte Arbeit beginnt fast nie mit einer leeren Datei — der Test sollte es auch nicht.

Step 3: Schreiben Sie das Briefing neben den Editor

Nutzen Sie das nebeneinanderliegende Stimulus-Layout: Briefing, Anforderungen sowie Beispiel-Ein- und -Ausgaben auf der einen Seite, der Code-Editor daneben. Bewerbende scrollen zum Schreiben der Lösung nie von der Spezifikation weg — dieselbe Form wie die Arbeit an einem Ticket in einer IDE.

Schreiben Sie das Briefing so, wie sich ein gutes Ticket liest: aktuelles Verhalten, erwartetes Verhalten, Randbedingungen und zwei oder drei konkrete Beispiele. Sagen Sie ausdrücklich, worauf es Ihnen ankommt — „zuerst funktionierender Code; wir lesen auch auf Klarheit“ —, damit Bewerbende auf das hin optimieren, was Sie tatsächlich bewerten. Mehrdeutigkeit im Briefing wird zu Rauschen in den Ergebnissen.

Step 4: Bauen Sie eine Rubrik, die mehr als Korrektheit bewertet

Korrekte Ausgabe ist notwendig, nicht hinreichend. Bauen Sie eine stufenbasierte Matrix-Rubrik mit drei oder vier Kriterien — typischerweise Korrektheit, Lesbarkeit und Herangehensweise, optional der Umgang mit Randfällen — jeweils mit Ankerbeschreibungen dafür, wie starker, akzeptabler und schwacher Code aussieht. „Namen machen die Absicht sichtbar, kein toter Code“ ist bewertbar; „sauberer Code“ ist es nicht.

Gewichten Sie Korrektheit am stärksten, aber halten Sie die anderen Kriterien real: Eine gerade so funktionierende Lösung, die niemand warten kann, ist kein starkes Signal für eine Einstellung. Beim Anhängen wird die Rubrik als Momentaufnahme eingefroren, sodass alle Bewerbenden im Durchlauf am identischen Maßstab geprüft werden, selbst wenn sich die Version in der Bank später weiterentwickelt.

Step 5: Zusammenstellen und Zeit begrenzen im Builder

Erstellen Sie das Assessment aus Abschnitten, Seiten und Blöcken und importieren Sie das Code-Item über die Auswahl. Viele Teams stellen einen kurzen ersten Abschnitt mit schnellen Urteilsfragen voran — einen Diff lesen, den Bug in einem Snippet finden, per Quick-Paste als Multiple Choice eingefügt — und geben der Programmieraufgabe einen eigenen Abschnitt.

Setzen Sie das Gesamtzeitlimit mit Puffer für Lesen und Nachdenken und nutzen Sie ein Limit pro Seite auf der Programmierseite, damit die Aufgabe nicht den ganzen Versuch verschlingt. Gewichten Sie den Programmierabschnitt am stärksten (zum Beispiel ×3), damit die Rollenpassung im Decision Board die eigentliche Arbeit abbildet und nicht das Aufwärmen. Schreiben Sie Anweisungen, die die erlaubten Sprachen benennen und sagen, was beim Ablauf der Zeit passiert.

Step 6: Vorschau, Checkliste abarbeiten und veröffentlichen

Nutzen Sie „Preview as candidate“ und bearbeiten Sie die Aufgabe selbst — besser noch: Lassen Sie sie von einer Person aus dem Engineering ohne Vorbereitung bearbeiten, die sie nicht geschrieben hat. Ist sie in zehn Minuten fertig, ist die Aufgabe zu leicht; schafft sie es im Limit nicht, lockern Sie den Umfang oder die Uhr. Bessern Sie das Briefing überall dort nach, wo sie gezögert hat.

Erfüllen Sie danach die Checkliste zur Veröffentlichung — sie blockiert „Publish“, bis Bewertung, Zeitsteuerung und Anweisungen vollständig sind. Ein Programmiertest mit fehlender Rubrik oder ungetestetem Zeitlimit sollte nie bei Bewerbenden ankommen, und die Checkliste sorgt dafür, dass er es nicht kann.

Step 7: Setzen Sie Integritätskontrollen im Verhältnis zur Tragweite

Legen Sie die Durchführung mit Namen und Zeitfenster an und wählen Sie die Sicherheitsschalter dann bewusst. Für ein normales Einstellungs-Screening genügen in der Regel das Blockieren von Kopieren/Einfügen und der Vollbild-Lockdown mit einem sinnvollen Verstoßlimit. Webcam-Aufzeichnung, Bildschirmaufzeichnung, Zweitbildschirm-Erkennung und Ausweisprüfungen gibt es für Durchläufe mit wirklich hoher Tragweite — Zertifizierung, finale Runden — nicht als Standardeinstellung.

Alles, was Sie aktivieren, wird an der Einwilligungs- und Preflight-Stufe offengelegt, bevor Bewerbende starten. Integritätssignale sind Hinweise, die ein Mensch im Kontext prüft, niemals ein Grund für eine automatische Ablehnung — das Verlassen des Vollbilds kann eine Benachrichtigung sein, kein Betrug. Verhältnismäßigkeit verhindert, dass starke Bewerbende vor einem Überwachungsnetz zurückschrecken.

Step 8: Prüfen Sie Code mit der Rubrik, KI als Unterstützung

Prüfende sehen jede Einreichung anhand der gemeinsamen Rubrik durch und klicken bei jedem Kriterium — Korrektheit, Lesbarkeit, Herangehensweise — die Stufenkarte an, die zum Code passt. Zwei prüfende Personen bei Grenzfällen oder bei hoher Tragweite halten den Maßstab ehrlich, und weil alle gegen dieselbe eingefrorene Rubrik-Momentaufnahme bewerten, zeigen sich Meinungsverschiedenheiten als konkrete Lücken bei einzelnen Kriterien statt als vages Bauchgefühl.

KI kann eine Zusammenfassung der Einreichung entwerfen und Punktwerte auf Kriteriumsebene vorschlagen — bei Code ein wirklich nützlicher erster Durchgang, mit Modell und Version für die Akte protokolliert. Aber eine namentlich benannte Person aus dem Engineering bestätigt oder überschreibt jeden Punktwert. KI ist hier Entscheidungsunterstützung, niemals die entscheidende Instanz: Das verantwortete Urteil über den Code einer bewerbenden Person ist immer menschlich.