Wir haben Tausende von Codierungsinterviews analysiert. Folgendes haben wir gelernt:

Hinweis: Ich habe die meisten Wörter in diesem Beitrag geschrieben, aber der legendäre Dave Holtz hat das schwere Heben auf der Datenseite getan. Weitere seiner Arbeiten finden Sie in seinem Blog.

Wenn Sie diesen Beitrag lesen, besteht eine gute Chance, dass Sie gleich wieder in die verrückte und beängstigende Welt der technischen Interviews eintreten.

Vielleicht sind Sie ein Student oder ein frisch Absolvent, der zum ersten Mal den Interviewprozess durchläuft. Vielleicht sind Sie ein erfahrener Softwareentwickler, der seit einigen Jahren nicht mehr an Interviews gedacht hat.

In beiden Fällen besteht der erste Schritt im Interviewprozess normalerweise darin, eine Reihe von Online-Interviewleitfäden zu lesen (insbesondere, wenn sie von Unternehmen verfasst wurden, an denen Sie interessiert sind) und mit Freunden über ihre Erfahrungen mit dem Interviewprozess zu chatten (beides als ein Interviewer und ein Interviewter).

Höchstwahrscheinlich wird das, was Sie in dieser ersten „explorativen“ Phase des Interviewprozesses lesen und lernen, darüber informieren, wie Sie sich auf die weitere Entwicklung vorbereiten.

Bei diesem typischen Ansatz zur Vorbereitung von Interviews gibt es einige Probleme:

  • Die meisten Interviewleitfäden werden aus der Perspektive eines Unternehmens geschrieben. Während Unternehmen A wirklich Wert auf effizienten Code legt, legt Unternehmen B möglicherweise mehr Wert auf hochrangige Fähigkeiten zur Problemlösung. Wenn Ihr Herz nicht auf Unternehmen A gerichtet ist, möchten Sie dem, was sie wertschätzen, wahrscheinlich nicht zu viel Gewicht beimessen.
  • Menschen lügen manchmal, auch wenn sie es nicht wollen. In schriftlicher Form können Unternehmen sagen, dass sie sprachunabhängig sind oder dass es sich lohnt, Ihren Denkprozess zu erklären, auch wenn die Antwort nicht ganz richtig ist. Es ist jedoch nicht klar, ob sie sich tatsächlich so verhalten! Wir sagen nicht, dass Tech-Unternehmen schändliche Lügner sind, die versuchen, ihren Bewerberpool in die Irre zu führen. Wir sagen nur, dass sich manchmal implizite Vorurteile einschleichen und die Leute sich ihrer nicht einmal bewusst sind.
  • Ein Großteil des „Volkswissens“, das Sie von Freunden und Bekannten hören, basiert möglicherweise überhaupt nicht. Viele Leute gehen davon aus, dass kurze Interviews das Schicksal bedeuten. Ebenso kann sich jeder an ein langes Interview erinnern, nach dem er sich gedacht hat: "Ich habe mich mit diesem Interviewer wirklich gut verstanden, ich werde definitiv auf die nächste Stufe übergehen." In der Vergangenheit haben wir gesehen, dass die Leute wirklich schlecht einschätzen können, wie sie es in Interviews gemacht haben. Dieses Mal wollten wir Indikatoren wie die Länge des Interviews direkt betrachten und herausfinden, ob diese tatsächlich wichtig sind.

In meinem Unternehmen interviewing.io sind wir einzigartig positioniert, um technische Interviews und deren Ergebnisse datengesteuert anzugehen. Wir haben eine Plattform, auf der Menschen anonym technische Interviews üben können. Und wenn alles gut läuft, können sie jederzeit anonym mit Top-Unternehmen wie Uber, Lyft und Twitch interviewen.

Das Coole ist, dass sowohl Praxisinterviews als auch echte Interviews mit Unternehmen innerhalb des interviewing.io-Ökosystems stattfinden. Auf diese Weise können wir eine ganze Reihe von Interviewdaten sammeln und analysieren, um technische Interviews, das Signal, das sie tragen, was funktioniert und was nicht und welche Aspekte eines Interviews tatsächlich für das Ergebnis von Bedeutung sein können, besser zu verstehen .

Jedes Interview, ob praktisch oder real, beginnt mit dem Treffen des Interviewers und des Interviewten in einer kollaborativen Codierungsumgebung mit Sprache, Text-Chat und einem Whiteboard. An diesem Punkt springen sie direkt in eine technische Frage.

Interviewfragen fallen in der Regel in die Kategorie, auf die Sie auf einem Telefonbildschirm für eine Back-End-Softwareentwicklungsrolle stoßen würden.

Während dieser Interviews sammeln wir alles, was passiert, einschließlich Audio-Transkripten, Daten und Metadaten, die den Code beschreiben, den der Befragte geschrieben und versucht hat, auszuführen, sowie detailliertes Feedback sowohl des Interviewers als auch des Befragten darüber, wie sie denken, dass das Interview verlaufen ist und woran sie gedacht haben gegenseitig.

Wenn Sie neugierig sind, können Sie unten sehen, wie die Feedback-Formulare für Interviewer und Interviewte aussehen. Zusätzlich zu einer direkten Ja / Nein-Frage stellen wir anhand einer Skala von 1 bis 4 einige verschiedene Aspekte der Interviewleistung.

Wir stellen den Befragten auch einige zusätzliche Fragen, die wir nicht mit ihren Interviewern teilen, und wir stellen unter anderem, ob ein Befragter die Frage, an der er gerade gearbeitet hat, zuvor gesehen hat.

Die Ergebnisse

Bevor wir uns damit befassen, sollten wir beachten, dass die folgenden Schlussfolgerungen auf Beobachtungsdaten basieren, was bedeutet, dass wir keine starken kausalen Behauptungen aufstellen können. Wir können jedoch überraschende Beziehungen, die wir beobachtet haben, teilen und erklären, was wir für Sie gefunden haben kann Ihre eigenen Schlussfolgerungen ziehen.

Nachdem ich die Interviewfrage schon einmal gesehen habe

"Wir reden über Übung!" -Allen Iverson

Das wichtigste zuerst. Es braucht keinen Raketenwissenschaftler, um zu behaupten, dass eine der besten Möglichkeiten, um in Interviews besser zu werden, darin besteht,… das Interviewen zu üben. Es gibt eine Reihe von Ressourcen, die Ihnen beim Üben helfen, darunter auch unsere. Einer der Hauptvorteile der Bearbeitung von Übungsproblemen besteht darin, dass Sie die Wahrscheinlichkeit verringern, dass Sie aufgefordert werden, etwas zu lösen, was Sie noch nie zuvor gesehen haben. Das Ausbalancieren dieses binären Suchbaums ist viel weniger einschüchternd, wenn Sie es bereits ein- oder zweimal durchgeführt haben.

Wir haben uns eine Stichprobe von ~ 3000 Interviews angesehen und das Ergebnis damit verglichen, ob der Befragte die Interviewfrage zuvor gesehen hatte. Sie können die Ergebnisse in der Darstellung unten sehen.

Es überrascht nicht, dass Befragte, die die Frage gesehen hatten, mit 16,6% höherer Wahrscheinlichkeit von ihrem Interviewer als angestellt eingestuft wurden. Dieser Unterschied ist statistisch signifikant - alle Fehlerbalken in diesem Beitrag repräsentieren ein 95% -Konfidenzintervall.

Ist es wichtig, in welcher Sprache Sie codieren?

"Wer die Sprache seiner Geburt nicht liebt, ist niedriger als ein Tier und ein übel riechender Fisch." - Jose Rizal

Sie können sich vorstellen, dass verschiedene Sprachen zu besseren Interviews führen. Vielleicht gibt Ihnen die Lesbarkeit von Python in Interviews einen Vorsprung. Oder vielleicht erleichtert die Tatsache, dass bestimmte Sprachen Datenstrukturen besonders sauber behandeln, häufig gestellte Interviewfragen. Wir wollten herausfinden, ob es statistisch signifikante Unterschiede in der Interviewleistung zwischen verschiedenen Interviewsprachen gibt oder nicht.

Zur Untersuchung haben wir die Interviews auf unserer Plattform nach Interviewsprachen gruppiert und alle Sprachen herausgefiltert, die in weniger als 5 Interviews verwendet wurden (dies warf nur eine Handvoll Interviews aus). Danach konnten wir das Interviewergebnis und dessen Variation in Abhängigkeit von der Interviewsprache untersuchen.

Die Ergebnisse dieser Analyse sind in der folgenden Tabelle aufgeführt. Alle nicht überlappenden Konfidenzintervalle stellen einen statistisch signifikanten Unterschied dar, wie wahrscheinlich es ist, dass ein Befragter ein Interview in Abhängigkeit von der Interviewsprache „besteht“.

Obwohl wir nicht für jedes mögliche Sprachpaar einen paarweisen Vergleich durchführen, deuten die folgenden Daten darauf hin, dass es im Allgemeinen keine statistisch signifikanten Unterschiede zwischen der Erfolgsrate gibt, wenn Interviews in verschiedenen Sprachen durchgeführt werden. (Es gab mehr Sprachen als diese auf unserer Plattform, aber je dunkler die Sprache, desto weniger Datenpunkte haben wir. Zum Beispiel waren alle Interviews in Brainf *** eindeutig erfolgreich. Scherz.)

Einer der häufigsten Fehler, den wir qualitativ beobachtet haben, ist jedoch, dass Leute Sprachen auswählen, in denen sie sich nicht wohl fühlen, und dann grundlegende Dinge wie die Suche nach der Array-Länge durcheinander bringen, über ein Array iterieren, eine Hash-Tabelle instanziieren und so weiter.

Dies ist besonders beschämend, wenn die Befragten absichtlich eine ausgefallene Sprache wählen, um ihren Interviewer zu beeindrucken. Vertrauen Sie uns, wenn Sie die Sprache Ihrer Wahl verwenden, können Sie sich jedes Mal in einer Sprache präsentieren, die Sie nicht gut kennen.

Auch wenn die Sprache keine Rolle spielt ... ist es vorteilhaft, in der Sprache des Unternehmens zu codieren?

"Gott hilf mir, ich bin einheimisch geworden." - Margaret Blaine

Es ist schön und gut, dass die Interviewsprache im Allgemeinen nicht besonders mit der Leistung korreliert. Sie können sich jedoch vorstellen, dass es abhängig von der Sprache, die ein bestimmtes Unternehmen verwendet, zu einem Effekt kommen kann. Sie können sich einen Ruby-Shop vorstellen, in dem steht: "Wir stellen nur Ruby-Entwickler ein. Wenn Sie in Python interviewen, stellen wir Sie mit geringerer Wahrscheinlichkeit ein."

Auf der anderen Seite könnten Sie sich vorstellen, dass ein Unternehmen, das seinen gesamten Code in Python schreibt, einem Befragten in Python viel kritischer gegenübersteht - sie kennen die Vor- und Nachteile der Sprache und beurteilen den Kandidaten möglicherweise für alles Arten von "nicht-pythonischen" Dingen während ihres Interviews.

Die folgende Tabelle ähnelt der Tabelle, in der Unterschiede in der Erfolgsquote von Interviews (gemessen an der Bereitschaft der Interviewer, den Befragten einzustellen) für C ++, Java und Python dargestellt wurden. In diesem Diagramm wird die Leistung jedoch auch danach aufgeschlüsselt, ob sich die Interviewsprache im Stapel des Unternehmens befindet oder nicht.

Wir beschränken diese Analyse auf C ++, Java und Python, da dies die drei Sprachen sind, in denen wir eine gute Mischung von Interviews hatten, in denen das Unternehmen diese Sprache verwendet hat und nicht. Die Ergebnisse hier sind gemischt. Wenn die Interviewsprache Python oder C ++ ist, gibt es keinen statistisch signifikanten Unterschied zwischen den Erfolgsraten für Interviews, bei denen die Interviewsprache eine Sprache im Stapel des Unternehmens ist oder nicht. Interviewer, die in Java interviewt haben, hatten jedoch eher Erfolg, wenn sie mit einem Java-Shop interviewten (p = 0,037).

Warum scheint die Codierung in der Unternehmenssprache hilfreich zu sein, wenn es sich um Java handelt, nicht jedoch um Python oder C ++? Eine mögliche Erklärung ist, dass die Communitys, die um bestimmte Programmiersprachen (wie Java) herum existieren, eine höhere Prämie auf frühere Erfahrungen mit der Sprache legen. In diesem Sinne ist es auch möglich, dass Interviewer von Unternehmen, die Java verwenden, eher Fragen stellen, die diejenigen bevorzugen, die bereits über Kenntnisse der Eigenheiten von Java verfügen.

Was ist mit der Beziehung zwischen der Sprache, in der Sie programmieren, und der Qualität eines Kommunikators, als den Sie wahrgenommen werden?

"Mit einer Sprache geschickt umzugehen bedeutet, eine Art evokative Zauberei zu üben." - Charles Baudelaire

Auch wenn die Wahl der Sprache für die Gesamtleistung nicht so wichtig ist (trotz Java-Unternehmen), waren wir gespannt, ob unterschiedliche Sprachwahlen in anderen Interviewdimensionen zu unterschiedlichen Ergebnissen führten.

Beispielsweise kann eine extrem lesbare Sprache wie Python dazu führen, dass Kandidaten interviewt werden, die als besser kommuniziert eingestuft werden. Auf der anderen Seite kann eine einfache Sprache wie C ++ zu höheren Punktzahlen für technische Fähigkeiten führen.

Darüber hinaus können sehr lesbare oder einfache Sprachen zu Korrelationen zwischen diesen beiden Ergebnissen führen (z. B. sind sie möglicherweise ein C ++ - Interviewkandidat, der überhaupt nicht erklären kann, was er oder sie tut, aber sehr effizienten Code schreibt). Die folgende Tabelle zeigt, dass es keinen wirklich erkennbaren Unterschied zwischen der Wahrnehmung der technischen und Kommunikationsfähigkeiten der Kandidaten in einer Vielzahl von Programmiersprachen gibt.

Unabhängig davon scheinen schlechte technische Fähigkeiten in hohem Maße mit schlechten Kommunikationsfähigkeiten zu korrelieren - unabhängig von der Sprache ist es relativ selten, dass Kandidaten technisch gute Leistungen erbringen, aber nicht effektiv kommunizieren (oder umgekehrt) , größtenteils (und zum Glück) den Mythos des inkohärenten, schnell sprechenden, ungeschickten Ingenieurs zu entlarven.

(Die besten Ingenieure, die ich getroffen habe, waren auch legendär gut darin, komplexe Konzepte aufzubrechen und sie Laien zu erklären. Warum der wütende Mythos des sozial ungeschickten, inkohärenten Tech-Nerds weiterhin existiert, weiß ich absolut nicht.)

Interviewdauer

„Es ist in Ordnung, wenn man sich um Katastrophen kümmert und schrecklich schlechte Kritiken und Ablehnung und all das Zeug, wenn man jung ist. Ihre Belastbarkeit ist einfach großartig. “ - Harold Prince

Wir haben alle die Erfahrung gemacht, ein Interview zu verlassen und das Gefühl zu haben, dass es schlecht gelaufen ist. Oft wird dieses Gefühl einer gewissen Underperformance durch Faustregeln motiviert, die wir uns entweder ausgedacht oder immer wieder wiederholt haben. Sie denken vielleicht: „Das Interview hat nicht lange gedauert? Das ist wahrscheinlich ein schlechtes Zeichen… “oder„ Ich habe in diesem Interview kaum etwas geschrieben! Ich werde definitiv nicht bestehen. “ Anhand unserer Daten wollten wir herausfinden, ob diese Faustregeln für die Bewertung Ihrer Interviewleistung von Nutzen sind.

Zuerst haben wir uns die Länge des Interviews angesehen. Bedeutet ein kürzerer Interviewer, dass Sie so ein Zugunglück waren, dass der Interviewer das Interview nur vorzeitig beenden musste? Oder war es vielleicht so, dass der Interviewer weniger Zeit als normal hatte oder in kurzer Zeit gesehen hatte, dass Sie ein großartiger Kandidat waren? Die folgende Darstellung zeigt die Verteilung der Interviewlänge (gemessen in Minuten) für erfolgreiche und erfolglose Kandidaten.

Ein kurzer Blick auf diese Tabelle zeigt, dass es keinen Unterschied in der Verteilung der Interviewlängen zwischen gut verlaufenden und nicht gut verlaufenden Interviews gibt. Die durchschnittliche Länge der Interviews, in denen der Interviewer den Kandidaten einstellen wollte, betrug 51,00 Minuten, während der Durchschnitt Die Länge der Interviews, in denen der Interviewer nicht war, betrug 49,95 Minuten. Dieser Unterschied ist statistisch nicht signifikant .

(Für jeden Verteilungsvergleich in diesem Beitrag verwenden wir beide einen Fisher-Pitman-Permutationstest, um den Unterschied in den Mittelwerten der Verteilungen zu vergleichen.)

Menge des geschriebenen Codes

"In der Kürze liegt die Würze." -William Shakespeare

Möglicherweise haben Sie ein Interview erlebt, in dem Sie völlig ratlos waren. Der Interviewer stellt Ihnen eine Frage, die Sie kaum verstehen, Sie wiederholen zu ihm oder ihr "binäre Suche was?" Und Sie schreiben während Ihres Interviews im Grunde keinen Code. Sie könnten hoffen, dass Sie ein solches Interview noch mit bloßem Witz, Charme und hochrangigen Fähigkeiten zur Problemlösung bestehen können. Um zu beurteilen, ob dies zutrifft oder nicht, haben wir uns die endgültige Zeichenlänge des vom Befragten geschriebenen Codes angesehen. Das folgende Diagramm zeigt die Verteilungen der Zeichenlänge für erfolgreich und nicht erfolgreich. Ein kurzer Blick auf diese Tabelle zeigt, dass es einen Unterschied zwischen den beiden gibt - Interviews, die nicht gut laufen, haben tendenziell weniger Code. Es gibt zwei Phänomene, die dazu beitragen können. Erstens schreiben erfolglose Interviewer möglicherweise zunächst weniger Code. Zusätzlich,Sie sind möglicherweise anfälliger dafür, große Teile des von ihnen geschriebenen Codes zu löschen, die entweder nicht ausgeführt werden oder das erwartete Ergebnis nicht zurückgeben.

Im Durchschnitt hatten erfolgreiche Interviews einen endgültigen Interviewcode, der durchschnittlich 2045 Zeichen lang war, während erfolglose im Durchschnitt 1760 Zeichen lang waren. Das ist ein großer Unterschied! Dieser Befund ist statistisch signifikant und wahrscheinlich nicht sehr überraschend.

Codemodularität

"Das Kennzeichen eines ausgereiften Programmierers ist die Bereitschaft, Code wegzuwerfen, für den Sie Zeit aufgewendet haben, wenn Sie feststellen, dass er sinnlos ist." - Bram Cohen

Neben nur schauen, wie vielCode, den Sie schreiben, wir können auch über die Art des Codes nachdenken, den Sie schreiben. Konventionelle Erkenntnisse legen nahe, dass gute Programmierer keinen Code recyceln - sie schreiben modularen Code, der immer wieder verwendet werden kann. Wir wollten wissen, ob diese Art von Verhalten während des Interviewprozesses tatsächlich belohnt wurde. Zu diesem Zweck haben wir uns die in Python5 durchgeführten Interviews angesehen und gezählt, wie viele Funktionsdefinitionen in der endgültigen Version des Interviews enthalten waren. Wir wollten wissen, ob erfolgreiche Befragte mehr Funktionen definiert haben - obwohl mehr Funktionshandler nicht die Definition von Modularität sind, ist dies unserer Erfahrung nach ein ziemlich starkes Signal dafür. Wie immer,Es ist unmöglich, starke kausale Behauptungen darüber aufzustellen - es kann vorkommen, dass bestimmte Interviewer (die mehr oder weniger nachsichtig sind) Interviewfragen stellen, die sich für mehr oder weniger Funktionen eignen. Trotzdem ist es ein interessanter Trend zu untersuchen!

Die folgende Darstellung zeigt die Verteilung der Anzahl der Python-Funktionen, die sowohl für Kandidaten definiert wurden, die der Interviewer eingestellt hat, als auch für Kandidaten, die der Interviewer nicht eingestellt hat. Ein kurzer Blick auf diesem Diagramm legt nahe , dass es ist ein Unterschied in der Verteilung der Funktionsdefinitionen zwischen Interviews , die gut und Interviews gehen , die dies nicht tun. Erfolgreiche Befragte scheinen mehr Funktionen zu definieren .

Im Durchschnitt definieren erfolgreiche Kandidaten, die in Python interviewt werden, 3,29 Funktionen, während erfolglose Kandidaten 2,71 Funktionen definieren. Dieser Befund ist statistisch signifikant. Das Ergebnis hier ist, dass Interviewer wirklich die Art von Code belohnen, von dem sie sagen, dass sie möchten, dass Sie schreiben.

Ist es wichtig, ob Ihr Code ausgeführt wird?

„Bewege dich schnell und zerbreche Dinge. Wenn du nichts kaputt machst, bewegst du dich nicht schnell genug. “ - Mark Zuckerberg „Das effektivste Debugging-Tool ist immer noch sorgfältiges Überlegen, gepaart mit vernünftig platzierten Druckanweisungen.“ - Brian Kernighan

Ein häufiger Hinweis bei technischen Interviews ist, dass es Interviewern eigentlich egal ist, ob Ihr Code ausgeführt wird - was sie interessiert, sind Fähigkeiten zur Problemlösung. Da wir Daten über den Code sammeln, den die Befragten ausführen, und ob dieser Code kompiliert wird oder nicht, wollten wir sehen, ob unsere Daten Beweise dafür enthalten. Gibt es einen Unterschied zwischen dem Prozentsatz an Code, der in erfolgreichen Interviews fehlerfrei kompiliert wird, und nicht erfolgreichen Interviews? Können die Befragten tatsächlich noch eingestellt werden, selbst wenn sie Unmengen von Syntaxfehlern machen?

Um auf diese Frage zu kommen, haben wir uns die Daten angesehen. Wir haben unseren Datensatz auf Interviews beschränkt, die länger als 10 Minuten dauern und in denen mehr als 5 eindeutige Codeinstanzen ausgeführt werden. Dies half dabei, Interviews herauszufiltern, bei denen die Interviewer nicht wollten, dass der Befragte Code ausführt, oder bei denen das Interview aus irgendeinem Grund abgebrochen wurde. Wir haben dann den Prozentsatz der Codeläufe gemessen, die zu Fehlern geführt haben.5 Natürlich gibt es einige Einschränkungen bei diesem Ansatz - zum Beispiel könnten Kandidaten Code ausführen, der zwar kompiliert, aber eine leicht falsche Antwort gibt. Sie könnten auch die richtige Antwort bekommen und sie an stderr schreiben! Dies sollte uns jedoch ein direktionales Gefühl dafür geben, ob es einen Unterschied gibt oder nicht.

Die folgende Tabelle enthält eine Zusammenfassung dieser Daten. Die x-Achse zeigt den Prozentsatz der Code-Ausführungen, die in einem bestimmten Interview fehlerfrei waren. Ein Interview mit 3 Codeausführungen und 1 Fehlermeldung würde also für den Bucket "30% -40%" zählen. Die y-Achse gibt den Prozentsatz aller Interviews an, die in diesen Bereich fallen, sowohl für erfolgreiche als auch für erfolglose Interviews. Wenn man nur die Tabelle unten betrachtet, bekommt man das Gefühl, dass erfolgreiche Kandidaten im Durchschnitt mehr Code ausführen, der fehlerfrei abläuft. Aber ist dieser Unterschied statistisch signifikant?

Im Durchschnitt lief der Code erfolgreicher Kandidaten 64% der Zeit erfolgreich (führte nicht zu Fehlern), während die Versuche erfolgloser Kandidaten, Code zu kompilieren, 60% der Zeit erfolgreich liefen, und dieser Unterschied war in der Tat signifikant. Auch wenn wir keine kausalen Behauptungen aufstellen können, ist der wichtigste Aspekt, dass erfolgreiche Kandidaten normalerweise Code schreiben, der besser läuft, ungeachtet dessen, was Interviewer Ihnen zu Beginn eines Interviews sagen.

Sollten Sie warten und Ihre Gedanken sammeln, bevor Sie Code schreiben?

"Vergessen Sie niemals die Kraft der Stille, diese massiv beunruhigende Pause, die immer weiter geht und einen Gegner schließlich dazu bringen kann, nervös zu plappern und sich zurückzuziehen." - Lance Morrow

Wir waren auch neugierig, ob erfolgreiche Befragte dazu neigten, sich Zeit für das Interview zu nehmen. Interviewfragen sind oft komplex! Nachdem eine Frage gestellt wurde, kann es von Vorteil sein, einen Schritt zurückzutreten und einen Plan auszuarbeiten, anstatt direkt in die Dinge zu springen. Um ein Gefühl dafür zu bekommen, ob dies wahr ist oder nicht, haben wir gemessen, wie weit in einem bestimmten Interview Kandidaten zuerst Code ausgeführt haben. Unten sehen Sie ein Histogramm, das zeigt, wie weit in Interviews sowohl erfolgreiche als auch erfolglose Befragte zuerst Code ausgeführt haben. Wenn Sie sich das Histogramm schnell ansehen, können Sie feststellen, dass erfolgreiche Kandidaten tatsächlich etwas länger warten, bis Code ausgeführt wird, obwohl das Ausmaß des Effekts nicht sehr groß ist.

Im Durchschnitt führen Kandidaten mit erfolgreichen Interviews im Durchschnitt 27% des gesamten Interviews Code aus, während Kandidaten mit erfolglosen Interviews 23,9% des ersten Codes im Interview ausführen, und dieser Unterschied ist signifikant . Natürlich gibt es alternative Erklärungen dafür, was hier passiert. Zum Beispiel können sich erfolgreiche Kandidaten besser die Zeit nehmen, um ihren Interviewer zu unterhalten. Darüber hinaus gilt die übliche Einschränkung, dass wir keine kausalen Ansprüche geltend machen können. Wenn Sie nur weitere 5 Minuten in völliger Stille in einem Interview sitzen, hilft dies Ihren Chancen nicht. Dennoch scheint es einen Unterschied zwischen den beiden Kohorten zu geben.

Schlussfolgerungen

Alles in allem war dieser Beitrag unser erster Versuch zu verstehen, was normalerweise dazu führt, dass ein Interviewer sagt: "Weißt du was? Ich würde diese Person wirklich gerne einstellen." Da alle unsere Daten Beobachtungsdaten sind, ist es schwierig, kausale Aussagen über das zu machen, was wir sehen.

Während erfolgreiche Befragte bestimmte Verhaltensweisen aufweisen können, garantiert die Übernahme dieser Verhaltensweisen keinen Erfolg. Trotzdem können wir viele der Ratschläge, die Sie im Internet lesen, um ein erfolgreicher Interviewpartner zu sein, unterstützen (oder BS anrufen).

Trotzdem bleibt noch viel zu tun. Dies war eine erste quantitative Übergabe unserer Daten (die in vielerlei Hinsicht eine Fundgrube an Interviewgeheimnissen darstellt), aber wir freuen uns darauf, einen tieferen, qualitativen Tauchgang durchzuführen und tatsächlich verschiedene Fragen zu kategorisieren, um zu sehen, welche die Daten enthalten Die meisten Signale sowie Verhaltensweisen, die Sie nicht einfach messen können, indem Sie einen regulären Ausdruck über ein Codebeispiel laufen lassen oder messen, wie lange ein Interview gedauert hat.

Wenn Sie uns dabei helfen möchten und sich über eine Reihe technischer Interviews freuen, schreiben Sie mir eine Nachricht!

Möchten Sie bei technischen Interviews großartig werden und Ihren nächsten Job in diesem Prozess bekommen? Mach mit bei interviewing.io!