Veröffentlicht am 12-03-2019

Lassen Sie uns mit den Whiteboard-Interviews aufhören

Nein nein Nein Nein…

Die Einstellung ist kaputt.

Whiteboarding saugt.

Immer wieder hören wir das, aber nichts ändert sich. Unternehmen wenden diese Praxis weiterhin an, und Ingenieure / Entwickler beschweren sich weiterhin, bis sie einen Job bekommen, an dem sie sie als einen beschissenen, aber notwendigen Prozess betrachten, ähnlich wie ein trügerisches Ritual in einer Gemeinschaft. Ich bin nicht der erste, der es sagt, und ich werde nicht der letzte sein, der es sagt. Es gibt Unmengen von Artikeln, die den Tech-Interview-Prozess kritisieren.

Um klar zu sein - Whiteboarding ist nicht das einzige Problem. Wir streiten uns immer noch darüber, wie man die Leistung eines Ingenieurs am besten messen kann, und bitten die Ingenieure, die B-Trees umzukehren, anstatt ihr Verständnis des DOM zu bewerten. Dies ist wahrscheinlich keine gute Strategie, aber es funktioniert bis zu einem gewissen Grad. Sie filtern nach Menschen, die bereit sind, den langwierigen Prozess der Vorbereitung auf diese Fragen zu durchlaufen, der indirekt ihr Engagement und ihre Leidenschaft misst, um einen Job zu bekommen, der in gewisser Weise mit ihrer Effektivität bei ihrem eigentlichen Job zusammenhängt. Es ist nicht ideal, aber es ist etwas.

Aber ich möchte mich in diesem Artikel auf Whiteboards konzentrieren, weil ich glaube, dass dies die niedrig hängende Frucht ist, die wir leicht loswerden können, ohne die traditionellen Heuristiken zu beeinträchtigen, die wir verwenden, um zu viel einzustellen.

Ich hatte kürzlich eines der besten technischen Interviews meines Lebens. Es war ein Telefonbildschirm und wir verwendeten Coderpad, ein allgemeines Online-Editor-Tool, das von Tech-Unternehmen für diesen Prozess verwendet wird. Ich hatte zuvor mit dieser Firma ein Interview geführt (es ist eine große Tech-Firma, die Sie vielleicht kennen werden) und zu diesem Zeitpunkt zu kurz gekommen.

Aber als wir dieses Interview begannen und uns mit den Fragen beschäftigten, geschah etwas Erstaunliches. Ich habe meinen Code durchgearbeitet, als das Interview vorschlug: "Warum versuchen Sie nicht, es auszuführen und zu sehen, was wir bekommen?"

Ummmm ... was?

Ich kann meinen Code ausführen ?! Sie meinen, ich kann dieses Problem so angehen, wie ich normalerweise ein Problem angehe

Ich hatte zuvor schon mehrere Coderpad-Interviews durchgeführt und hatte nie diese Fähigkeit, oder um genauer zu sein: Unternehmen haben sich niemals für diese Fähigkeit entschieden. Google macht sich nicht einmal die Mühe, Ihnen eine förderliche Kodierungsumgebung zu bieten, und lässt Sie zum Schreiben von Code ein hässliches weißes Google Doc Word-Dokument verwenden. WTF.

Ich würde mich immer in Zwischenstufen eines Problems festsetzen und nicht sicher sein, wie ich vorgehen soll. Mein Codieransatz besteht immer darin, etwas zu schreiben, auszuführen, zwangsläufig einen Fehler zu finden und ihn zu beheben. Ich behaupte nicht, dass dies die richtige Vorgehensweise ist. Ich weiß gar nicht, ob es jemand anders so macht. Aber so codiere ich. Und zumindest für mich führt mich die Tatsache, dass ich so triggerfreundlich bin, viel schneller zur richtigen Lösung.

Schnelles Beispiel: Angenommen, ich möchte die Anzahl der Kunden in jedem Land ermitteln, wobei nur Länder mit mindestens 5 Kunden berücksichtigt werden sollen.

Iteration 1

OK Cool. Hmmm… wie bekomme ich die Zählung wieder?

Land auswählen, zählen (Kunden-ID)
vom Kunden

Fehler 1: Anweisung konnte nicht erstellt werden (1 keine solche Tabelle: Kunde)

Iteration 2

Woops der Tabellenname ist Kunden und nicht Kunde. Beheben wir das.

Land auswählen, zählen (Kunden-ID)
von Kunden
Gruppe nach Land

Ja, ich habe etwas Output bekommen!

Oh cool, das gab mir die Zählung jedes Kunden nach Land. Großartig - ich glaube, ich bin nah dran.

Iteration 3

Hmm - ok, ich muss jetzt nur nach Ländern filtern, in denen mindestens 5 Kunden sind. Wie wäre es damit?

Land auswählen, zählen (Kunden-ID)
von Kunden
wo zählen (customerid)> 5
Gruppe nach Land

Fehler 1: Anweisung konnte nicht erstellt werden (1 Missbrauch des Aggregats: COUNT ())

Iteration 3

Ah! Etwas ist schief gelaufen… warte ich erinnere mich, dass ich nicht verwenden kann, wo ich zählen muss.

Land auswählen, zählen (Kunden-ID)
von Kunden
zählen (customerid)> 5
Gruppe nach Land

Fehler 1: Anweisung konnte nicht vorbereitet werden (1 bei "GROUP": Syntaxfehler)

Iteration 4

Was jetzt? Oh dumm, natürlich kommt die Gruppe nicht vorher vorbei. Was sinnvoll ist, weil wir haben, um Funktionen zu aggregieren, die nicht zur Gruppe gehören, von…

Land auswählen, zählen (Kunden-ID)
von Kunden
Gruppe nach Land
zählen (customerid)> 5

Yay! Ich habe wieder etwas ausgegeben! Dadurch fühle ich mich besser. Lassen Sie uns eine letzte Prüfung durchführen.

Iteration 5

Hmm - jetzt, wo ich mir die Ausgabe anschaue, sehe ich keine Länder mit 5 Kunden. Und wir wollten alle Länder mit mindestens 5 Kunden finden. Oh ich sehe jetzt! Ich muss nur die Filterbedingung anpassen.

Land auswählen, zählen (Kunden-ID)
von Kunden
Gruppe nach Land
zählen (customerid)> = 5

Woo hoo! Ich denke das löst es! :)

Siehe W3 Schools für diesen Code: https://www.w3schools.com/sql/sql_having.asp

Jetzt… hier ist das Ding.

  1. Ich sage nicht, dass ich jeden Fehler jedes Mal in diesem Beispiel aufgeführt habe. Aber ich mache einige von ihnen. Die Chancen stehen gut, dass ich sie eher mache, wenn Sie oder jemand mich anstarren und nachprüfen wollen, was ich tue, während ich codiere.
  2. Ich sage nicht, dass Sie diese Fehler machen. Hey - vielleicht bin ich es nur. Ich bin nicht so schlau und wurde nicht von den Kodiergöttern wie dir gesegnet. Ich muss kämpfen und wackeln und weinen und schwitze und das alles, um eine grundlegende Zählung zu erhalten. Ich kenne. Traurig.
  3. Sie könnten denken, "das sieht schmerzhaft aus". Wenn ich jedoch mit der Option programmiere, zu sehen, wie mein Code abläuft, dauert der gesamte Vorgang von Iteration 1 bis 5 ungefähr 30 Sekunden. Ich habe meinen mittelmäßigen Kodierungsprozess im Griff. Wenn ich mich auf eine andere Person verlassen muss, um meinen Code in jeder dieser Stufen zu überprüfen und mir diese ausgetrockneten Ölzweige anzubieten? Sind Sie sicher, dass wir mit dieser Abfrage alle Ergebnisse erhalten, die wir wollten? “ Ganz zu schweigen von der psychischen Belastung, so dass Sie Ihren Code so oft „korrigieren“ müssen, dass Sie mehr Stress haben und mehr Fehler machen.

Der Punkt, den ich zu sagen versuche, ist: Der Unterschied zwischen der Option, Ihren Code auszuführen, ist nicht viel größer, als Sie vielleicht denken. Es gibt alle möglichen Mini-Handicaps, die Sie auf sich ziehen, wenn Sie diese Option nicht haben, und es ist eine unnötige selbst auferlegte Einschränkung, mit der Sie in der Realität fast nie arbeiten müssen.

Und so habe ich mich in meinem Interview gefühlt. Sobald ich wusste, dass ich meinen Code ausführen konnte, wechselte ich zu meiner "normalen" Art, Probleme zu lösen. Ich habe meinen Code wahnsinnig in Zwischenstufen ausgeführt und den Kurs entsprechend der Ausgabe auf der rechten Seite des Bildschirms angepasst.

Manchmal - zum Beispiel bei komplexen SQL-Abfragen - möchte ich Code nur für eine Tabelle ausführen und die Ausgabe sehen. Wenn ich nur die Ausgabe sehe, fühle ich mich wärmer und näher an der Lösung. Es ist komisch, aber es funktioniert für mich. In Python - ich liebe es, meine geliebten print-Anweisungen an verschiedenen Stellen im Code zu verwenden, um Probleme zu debuggen, indem ich sehe, wie der Codefluss für bestimmte Randfälle funktioniert ('oh, ich verstehe, warum dieser Fall fehlschlägt, weil wir diese if-Anweisung nie treffen… ').

Am Ende war es wunderschön. Ich habe alle Fragen durchgegangen. Ich war so stolz auf mich.

Aber bevor ich feiern konnte, wurde ich vor Ort eingeladen.

„Ja - du hast großartig gearbeitet. Also bringen wir Sie zu uns ins Büro und lassen Sie alles, was Sie in einem Editor geschrieben haben, nieder, bevor Sie es auf eine weiße Tafel schreiben. “

Nun, das ging nicht so gut. Und nein, es waren nicht nur die weißen Bretter schuld. Ich stolperte an Orten, an denen ich kein Yada Yada hätte. Es war jedoch ein komischer Versuch, Code auf eine Tafel zu schreiben, ständig Sachen zu löschen und Pfeile zu verwenden, um an Orten, an denen ich vergessen hatte, Code einzufügen. Aus irgendeinem Grund kann ich nicht direkt schreiben. Alle meine Linien waren furchtbar zur oberen rechten Ecke geneigt. Seltsam.

Ich verstand einfach nicht, warum ich diesen Prozess des Schreibens auf eine weiße Tafel durchlaufen musste. Warum können wir Coderpad nicht beim Interview vor Ort verwenden? Wir könnten Bildschirme teilen und das Problem durchgehen. Hey - wir könnten sogar schicker werden und meinen Coderpad-Bildschirm auf das Whiteboard projizieren? Wir haben die Technologie. Warum nicht benutzen?

Und hier ist mein Appell an alle, die Einfluss auf diese Tech-Interviews haben. Bitte - das nächste Mal, wenn Sie einen Kandidaten mitbringen, geben Sie ihm einen Laptop und stellen ihm Fragen zur Kodierung. Sie können das Board verwenden, um visuelle Elemente wie Diagramme, Sternschemata usw. zu zeichnen. Lassen Sie sie jedoch auf Coderpad codieren. Am Ende - anstatt ein Foto der weißen Tafel von Ihrem Telefon zu machen, können Sie einfach die Datei speichern, an der Sie später gearbeitet haben, um sie zu überprüfen. Sie können sogar die gesamte Sitzung aufzeichnen, die das Einstellungskomitee später durchläuft, wenn Sie dazu neigen. Dieser Prozess erleichtert Ihnen und dem Kandidaten das Leben.

Es ist höchste Zeit, dass wir uns von dieser dummen Praxis entfernen, von der jeder zu hassen scheint, aber niemand tut etwas dagegen.

Siehe auch

Mit Workflow für JotFormKapitel 7: Relevanz und TargetingIch brauche Ihre Hilfe, um Software zu entwickeln, die das Leben verändert, in der BlockchainGedanken zur Verwendung eines iPad Pro für die ArbeitTaxi und Uber werden verschwinden?Kosteneinsparungsstrategien mit Cloud Hosting - Teil 2