Einleitung

Einer der VIELE LinkedIn-Aspekte, die mich nervt, ist das 'Wie man Entwickler-Posts interviewt. Es gibt eine TON von ihnen und sie sind in 3 Lagern:

1. Das »Wie würden Sie den Fuji bewegen?« Annäherung mit Logik-Puzzles und Gehirn-Teaser.
2. Der 'Lassen Sie uns sehen, wie viel Sie von Ihrem Informatik-Abschluss erinnern können' Ansatz mit algorithmischen Fragen.
3. Die 'Beobachten Sie, während Sie Code schreiben' Ansatz mit Codierung Übungen.

Im Laufe der Jahre habe ich Dutzende von Malen interviewt und Hunderte von Entwicklern für verschiedene Unternehmen von Microsoft bis Dell zu winzigen Startups angeheuert. Ich war auch seltsamerweise ein Forschungspsychologe, spezialisiert auf Psychometrie (die Wissenschaft der Messung von geistigen Kapazitäten) und ein Software-Entwickler. Also habe ich den Prozess von jeder Seite gesehen.

Das Problem

Coding ist oft keine soziale Aktivität. Sichere "soft skills" sind lebenswichtig, aber sie sind oft orthogonal für die Praxis des Schreibens von Code, um Benutzerprobleme zu lösen. Also, wie interviewen Sie jemanden für einen Job, der hauptsächlich über das Schreiben von Code ist?

Unser Beruf ist auch rife mit Impostor-Syndrom. Ich habe es in mir selbst und in vielen anderen gesehen. Das ist echt. Wie interviewst du jemanden, der sich schon wie ein Betrüger fühlt?

Unser Beruf ist mit den sozial unbequemen (und ja wie ich leicht autistisch); ein Interview, das sowohl stressig ist und soziale Interaktion erfordert, während die Lösung von Codierungsproblemen ist ein Rezept für ein Desaster. Wie interviewst du jemanden, der sozial unbequem ist?

Die Lösung

Lesen Sie zuerst ihren Lebenslauf; sprechen Sie nicht einmal mit ihnen, wenn ihr Lebenslauf nicht deutlich macht, dass sie Erfahrung genug für den Job haben, für den Sie einstellen. Dies ist nicht nur respektvoll ihrer Zeit, sondern auch Ihrer.

Zweitens sollte die Einrichtung des Interviews (oder Interviews) für die Teilnehmer so stressfrei wie möglich sein. Dies bedeutet:

1. Geben Sie ausreichend Aufmerksam keit. Spring nicht ein Interview über jemanden mit 24 Stunden Kündigung (oder schlechter am selben Tag).
2. Stellen Sie klar, was das Interview-Format sein wird, wer wird es sein und erwartete Ergebnisse (ist es das letzte, ein technischer Bildschirm etc.).
3. Lesen Sie das Resume der Person. Ich kann das nicht genug betonen. Wenn Sie jemanden interviewen, sollten Sie den Lebenslauf von innen nach außen kennen. Dies ist nicht nur respektvoll, sondern gibt Ihnen auch die Möglichkeit, Fragen zu ihrer Erfahrung zu stellen.
4. Stellen Sie sicher, dass Sie die Details im MAIL haben; wenn es Teams / Zoom ist, stellen Sie sicher, dass sie den Link haben. Wenn es persönlich ist, stellen Sie sicher, dass sie wissen, wohin.

Das Interview

BE ON TIME; nichts macht eine Person ängstlicher, als auf ein Interview zu warten, um zu beginnen. Wenn du zu spät kommst, fängst du schon am falschen Fuß an. Wenn sie zu spät kommen, geben sie ihnen ein paar Minuten; sie sind wahrscheinlich nicht in zurück zu den Back-Meetings gewesen, damit ihre Einrichtung schraubig sein könnte.

Scheinen sie wie jemand, der mit dem Team in Bezug auf Temperament passen würde; sind sie eine gute Passform für das Team? Das ist wichtig; Sie können den besten Coder der Welt haben, aber wenn sie ein Idiot sind, sind sie es nicht wert.

Ein Tipp, den ich mir ausgedacht habe (nach Jahren von Fibonacci-Sequenzfragen, Umkehrungen von Arrays, verknüpften Listen etc.) ist.

KUNDEN, DIE KENNTNISSE ÜBER CODE THEY WISSEN

Das bedeutet, dass die Person, die das Interview durchführt, in der Lage sein muss, über den Code zu sprechen, den sie sehen. Wenn es ein Rahmen ist, den du nicht kennst (wie ich Angular devs interviewe), mach dir keine Sorgen.

Also vor dem Interview mit genügend Mitteilung (5 Tage ist in der Regel gut) sagen Sie ihnen, dass Sie sie bitten, über ein Stück Code sie geschrieben haben zu sprechen. Ich frage nicht GENERAL nach einem GitHub Link (viele Leute auf sogar höheren Ebenen haben das vielleicht nicht; ich habe an vielen Projekten gearbeitet, die proprietär sind und nicht geteilt werden können).

Machen Sie es klar, dass Sie nicht für ein großes Projekt / einige erstaunliche innovative Code fragen. Es ist nur ein Code, über den sie reden können. VIELE Menschen haben diese "Familien" Dinge, Wahrscheinlichkeit sind sie nicht ein 365 Tage Streifen Beitrag zu einem großen Open-Source-Projekt gewesen.

Sie stellen nicht ein, basierend auf, wie viel Freizeit jemand hat

Warum?

Warum bevorzuge ich diesen Ansatz? Warum denke ich, dass dies ein besserer Weg ist, um Entwickler zu interviewen?

1. Es ist weniger stressig. Die Person, die interviewt wird, spricht über etwas, das sie wissen. Sie versuchen nicht, ein Problem zu lösen, das sie noch nie zuvor gesehen haben; wirklich die meiste Zeit, wenn Sie sich Sorgen darüber machen, wie sie Code schreiben, wenn ihnen Zeit gegeben wird, es zu schreiben. Die meisten von uns peitschen nicht verrückte Algorithmen, um Dinge zu tun, die unser Rahmen der Wahl bereits für uns tut.
2. Man kann erkennen, ob sie über ihre Erfahrung lügen. Wenn sie nicht über einen Code reden können, den sie geschrieben haben, dann haben sie ihn wahrscheinlich nicht geschrieben.
3. Sie können in den Code auf natürlichere Weise graben; warum sie diesen Ansatz gegen einen anderen gewählt haben, warum sie keine Bibliothek usw. benutzt haben.
4. Du siehst den Code, den sie dir zeigen wollen. Das ist eine große. Wenn Sie sie bitten, Code an Ort und Stelle zu schreiben, sehen Sie Code, den sie unter Druck schreiben. Wenn Sie sie bitten, über Code zu sprechen, den sie geschrieben haben, sehen Sie Code, den sie geschrieben haben, wenn sie nicht unter Druck stehen. Wieder, es sei denn, Ihr Arbeitsplatz ist ein Korb Fall die meiste Zeit Sie nicht schreiben Code unter Druck.

Ausnahmen von der Regel

Also gibt es Ausnahmen hier, Super-Junior-Coder brauchen manchmal ein wenig Codierung Übung, aber nehmen Sie es langsam. Sie zu bitten, zu parsen und refactor / beheben einige riesige Codebase ist einfach grausam. Für sie können Sie nach grundlegenden Konzepten wie Loops, Conditions etc. fragen (behalten Sie es konzentriert auf den Job, für den Sie einstellen). Muster? Nun, ich habe viele Leute gesehen, die kein Muster nennen können, aber Ihnen sagen können, wann sie es benutzt haben. Also leg dich nicht zu sehr damit an.

Logik-Puzzle? Ich habe noch nie den Sinn davon gesehen. Ich habe noch nie einen Job gesehen, wo du den Fuji umziehen musst. Ich habe noch nie einen Job gesehen, bei dem du wissen musst, wie viele Golfbälle in eine 747 passen. Ich habe noch nie einen Job gesehen, wo du wissen musst, wie viele Klavier-Tuner es in New York gibt.

Nach oben

Nach dem Interview stellen Sie sicher, dass Sie mit dem Kandidaten folgen. Wenn sie den Job nicht bekommen haben, sagen sie ihnen warum (Sie haben mir nicht genug von Ihrer Erfahrung gezeigt, Sie waren nicht klar, wenn Sie Ihren Code usw. erklären). Das ist nicht nur respektvoll, sondern hilft ihnen auch beim nächsten Interview. Wenn sie den Job bekommen haben, stellen Sie sicher, dass sie wissen, was als nächstes zu erwarten ist.