Die Idee hinter einem Coding-Test ist ganz einfach: Kandidaten, die nicht über die technischen Fähigkeiten für die Rolle verfügen, frühzeitig im Prozess herauszufiltern, bevor der Einstellungsleiter und der Kandidat ihre Zeit mit einem persönlichen Gespräch verschwenden.

Aber die meisten Ingenieure missbilligen heute die Idee, einen Codierungstest durchzuführen, und über 50 % lehnen es ab, Status-quo-Bewertungen durchzuführen (basierend auf unseren Untersuchungen mit über 100 Unternehmen in SEA).

Die 3 häufigsten Gründe, warum Ingenieure Status-Quo-Codierungstests hassen:

1. Sie testen eher die algorithmischen Fähigkeiten als die Fähigkeit, Code zu schreiben.

Unternehmen brauchen die Ergebnisse aus Bewertungen, um aussagekräftig zu sein, und dies erreichen Sie am einfachsten, indem Sie Trickfragen zu den Bewertungen verwenden. Um bei diesen Tests gut abzuschneiden, müssen die Kandidaten wochenlang üben, Code für eine Liste von Trickfragen zu schreiben. Nur ein Bruchteil der Entwickler kann bei diesen Tests gut abschneiden.

Als Interviewer vergisst man sehr leicht, wie stressig das Interviewsetting für den Interviewpartner ist. Ausführbaren Code für einen sehr Nischenalgorithmus schreiben zu müssen, den Sie in der Schule studiert haben (auch das nur, wenn Sie ein CS-Hauptfach waren) und in Ihrer Zeit als Ingenieur in der realen Welt mit dem tickenden Timer nie wirklich verwendet wurden, kann sehr sehr sein einschüchternd!

Es ist zwar großartig, wenn jemand gut in Algorithmen ist (auch wenn diese Fähigkeit mit Übung verbessert werden kann), dies ist jedoch kein starker Indikator dafür, wie gut jemand ein Ingenieur ist / wie gut er in der Rolle sein wird. Nur ein kleiner Bruchteil der technischen Rollen erfordert starke algorithmische Fähigkeiten. Außerdem hat diese Methode zur Messung der Entwicklerfähigkeiten eine inhärente Voreingenommenheit gegenüber erfahreneren Entwicklern.

Wie Sie sich vorstellen können, ist kein großer Entwickler begeistert von der Aussicht, überhaupt einen Test zu geben. Hinzu kommt die Tatsache, dass Fragen irrelevant sind und 50% der Kandidaten diese Tests direkt ablehnen.

2. Sie sind zu groß, um zu fragen

Es ist unfair, den Kandidaten zu bitten, mehr als 60 Minuten für einen Codierungstest zu verwenden, bevor Sie überhaupt Zeit damit verbracht haben.

Wenn Sie einen 3-stündigen Codierungstest verwenden, verfehlt er den Zweck der Automatisierung, denn während der Einstellungsmanager nichts zu verlieren hat, muss der Kandidat jetzt mehr Zeit dafür aufwenden, als er für ein Video-/persönliches Interview hätte.

Je länger Ihr Assessment ist, desto geringer ist die Testquote.

3. Es ist schwieriger, in einer unbekannten Umgebung zu programmieren

Die meisten Entwickler bevorzugen IDE (integrierte Entwicklungsumgebung), die sie so angepasst haben, dass sie nahtlos Code schreiben können. Eine Testumgebung ist ungewohnt und für einen Softwareentwickler ist es schwieriger, optimal zu funktionieren. Dies gilt insbesondere, wenn der Test nicht nur die Verwendung einer Programmiersprache in einem einfachen Code-Editor erfordert, sondern stattdessen auf die Fähigkeiten des Front-End/Back-End-Code-Frameworks getestet wird.

Entwickler stellen die Gültigkeit von Codierungstests/-bewertungen aus diesen und anderen Gründen oft und verständlicherweise in Frage.

Sollten wir also Codierungstests ganz überspringen?

Das ist keine Option. Jeder, der sich mit der Einstellung von Tech-Mitarbeitern beschäftigt hat, weiß, dass es weltweit genug Entwickler gibt, die für die Position nicht ausreichend qualifiziert sind. Daher müssen die Kandidaten eine Art Lackmustest ablegen, den die Kandidaten bestehen müssen, bevor sie zu einem Vorstellungsgespräch eingeladen werden.

Können wir nicht stattdessen einen Lebenslaufbildschirm verwenden?

Software-Ingenieure neigen dazu, sich nicht gut zu verkaufen, und großartige Kandidaten unterbieten sich auf dem Papier oft massiv. Bestenfalls hilft Ihnen ein Lebenslauf-Bildschirm dabei, einige Kandidaten zu eliminieren, die ganz eindeutig nicht für die Stelle qualifiziert sind, und Lebensläufe nach Priorität zu sortieren. Darüber hinaus hat die Verwendung eines Lebenslauffilters eine inhärente Tendenz zu Kandidaten mit guten Zeugnissen (Bildung und beruflicher Werdegang). Gute Programmierer können von überall herkommen, und die Verwendung von Keyword-Matching bedeutet, dass Sie wahrscheinlich viele großartige Kandidaten verpassen. Wenn Unternehmen jedoch beginnen, alle Bewerber zu interviewen, würde es die gesamte Zeit des Ingenieurteams in Anspruch nehmen, nur die Kandidaten zu interviewen.

Wie beurteilen wir, ob eine Bewertungslösung gut ist?

Hier ist eine Liste der wichtigsten Dinge, die Sie überprüfen möchten. Sie sind in guten Händen, wenn:

  1. Ihre Testteilnahmequote > 70 %.
  2. Die durchschnittliche Bearbeitungszeit beträgt zwischen 45 und 75 Minuten.
  3. Wenn Sie Kandidaten in persönlichen Vorstellungsgesprächen um ihr Feedback bitten, haben sie Gutes über ihre Erfahrungen mit der Bewertung zu sagen.
  4. Einstellungsmanager sind mit der Qualität der Kandidaten zufrieden, die zu persönlichen Runden weitergeleitet werden.

Wenn Ihre aktuelle Lösung diese Kriterien nicht erfüllt, verpassen Sie möglicherweise starke Kandidaten für Ihr Team. Als Software-Ingenieure und Hiring Manager haben mein Mitgründer und ich bisher einen Großteil der Status-Quo-Lösungen genutzt und die Ergebnisse als unbefriedigend empfunden. Darauf haben wir in den letzten Jahren hingearbeitet und erste Erfolge erzielt.

Bei Adaface bauen wir eine Möglichkeit für Unternehmen, die erste Runde von Tech-Interviews mit einer dialogorientierten KI, Ada, zu automatisieren.

Ist dies also nur ein Codierungstest, aber im Chatbot-Format?

Nein. Folgendes machen wir anders als beim Status Quo:

  • Kürzere Assessments (45-60 Minuten), um sicherzustellen, dass die Ingenieure dies so schnell wie möglich tun können. Sie investieren so wenig Zeit wie möglich, aber immer noch genug, um ihr Fachwissen zu präsentieren.
  • Maßgeschneiderte Assessments, die auf die Anforderungen der Rolle zugeschnitten sind (KEINE Fangfragen).
  • Fragen am einfacheren Ende des Spektrums (es ist ein Screening-Interview) mit einem großzügigen Zeitaufwand (3x so viel wie unser Team braucht, um Code dafür zu schreiben).
  • Extrem granulares Scoring, das falsch positive und falsch negative Ergebnisse eliminiert.
  • Freundliche Kandidatenerfahrung (Hinweise zu jeder Frage, freundliches Messaging und Chatbot; durchschnittlicher NPS für Kandidaten beträgt 4,4/5). ️

Wie schneidet Adaface bei unseren Kriterien für eine Bewertungslösung ab?

  1. Wir haben eine durchschnittliche Prüfungsquote von 86 % im Vergleich zum Industriestandard von 50 %.
  2. Die durchschnittliche Bearbeitungszeit beträgt 62 Minuten.
  3. Wir sind am stolzesten auf das Feedback, das die Kandidaten nach dem Assessment teilen. Die durchschnittliche Bewertung beträgt 4,4/5.
  4. Wir konzentrieren uns darauf, für jede Rolle die Fähigkeiten am Arbeitsplatz zu testen. Ada kann Kandidaten auf über 700 Fähigkeiten in Software Engineering, Data Science, DevOps, Analytics, Aptitude usw. prüfen. Dies hilft unseren Kunden, die am besten qualifizierten Kandidaten zu finden. Mehrere unserer Kunden sind von der Verwendung von Status-Quo-Lösungen zu Adaface gewechselt und können bis zu 75 % Zeit beim Screening-Prozess einsparen.

Hier ist eine Beispielbewertung von einem der Kandidaten, der ein Erstrunden-Interview mit einem unserer Kunden absolviert hat:

Beispielbewertung von einem von Tausenden von Kandidaten, die ein Erstrundeninterview auf Adaface abgeschlossen haben

Auf die Frage, was sie von der Verwendung von Adaface überzeugt hat, sagte Brandon Lee, Head of People & Culture, Love, Bonito:

Von außen erhielten wir von den Kandidaten positives Feedback zur Benutzerfreundlichkeit und Bequemlichkeit von Adaface. Intern, nachdem wir es mit unseren Teammitgliedern getestet hatten, waren wir auch von der Gültigkeit und Strenge der Aufgaben überrascht.

Wenn Sie derzeit einstellen, würde ich gerne mit Ihnen chatten. Bitte wenden Sie sich an [email protected] oder finden Sie mich hier auf LinkedIn .