# Stressfreies Interview von Softwareentwicklern ## Einleitung Eines der VIELE Dinge, die mich auf LinkedIn nerven ist das "Wie man Entwickler interviewt" Post. Es gibt Tonnen von ihnen, und sie fast alle fallen in drei Lager: 1. Der klassische Gehirn-Teaser **"Wie würden Sie den Fuji bewegen?"** Stil. 2. Das **"Was können Sie sich von Ihrem CS-Abschluss erinnern?"** Annähern. 3. Das **"Schreiben Sie Code, während wir Sie beobachten"** Annähern. Im Laufe der Jahre habe ich Dutzende von Malen interviewt und angeheuert **Hunderte** von Entwicklern für verschiedene Unternehmen - von Microsoft und Dell zu winzigen Startups. Ich hatte auch ein früheres Leben als **Forschungspsychologe, spezialisiert auf Psychometrie** (die Wissenschaft der Messung der geistigen Fähigkeiten). So habe ich den Prozess aus gesehen *jedes* Seite. [TOC] --- ## Das Problem Schreiben Code ist oft keine soziale Aktivität. Sicher - Soft Skills Materie. Aber sie sind oft orthogonal zu der tatsächlichen Praxis des Schreibens Code, um echte Benutzerprobleme zu lösen. Wie interviewt man jemanden für einen Job, der *meist* Über das Schreiben von Code? Unser Beruf ist auch rife mit **Impostorsyndrom** - Ich habe es in mir und unzähligen anderen gesehen. *schon* Fühlst du dich wie ein Betrüger? Und wir sind oft ein **sozial unbeholfene Gruppe** Ein Interview, das sowohl stressig als auch stressig ist. *und* erfordert Live-Problemlösung ist ein Rezept für Katastrophe. Wie interviewst du jemanden, der nervös, peinlich oder schon an sich selbst zweifelt? --- ## Die Lösung ### Zuerst: Lesen Sie den Lebenslauf Nicht mal *Anfang* Es sei denn, ihre Erfahrung reiht sich zusammen. Das respektiert ihre Zeit *und* Deine. ### Zweitens: Ein stressfreies Interview einrichten Machen Sie den Prozess klar und menschlich. 1. Keine Interviews am selben Tag. 2. Machen Sie das Format, die Teilnehmer und die erwarteten Ergebnisse klar. 3. **LESEN SIE IHRE RESUME.** Wenn du sie interviewst, solltest du es besser wissen als sie. 4. Fügen Sie alle verbindenden Details klar. Zoom/Teams Link, oder Richtungen, wenn in-Person. --- ## Das Interview Sei **rechtzeitig**Wenn sie zu spät sind, geben Sie ihnen ein paar Minuten - Wahrscheinlich sind sie nicht in Back-to-Back-Meetings wie Sie. Fragen Sie sich: **Würden sie dem Team temperamentvoll passen?** Ein brillanter Programmierer, der ein Idiot ist, ist ein Nettoverlust. Nach Jahren von Fibonacci-Fragen und verknüpften Listen-Marathons lernte ich eine Kernwahrheit: > ## **Coder lieben es, über Code zu reden, den sie kennen.** Das ist das Geheimnis. Und es funktioniert nur, wenn der Interviewer wirklich versteht, was gezeigt wird. Wenn Sie den Rahmen nicht kennen (Angular, React, was auch immer) - immer noch in Ordnung. Konzentrieren Sie sich auf Struktur, Klarheit, Benennung, Absicht. Also - sagen Sie es ihnen **im Voraus** (5 Tage sind fair), dass Sie Code, den sie geschrieben haben, diskutieren wollen. Kein Druck. Kein Trick. Nur: *Zeig mir etwas, worüber du reden kannst.* Sie haben vielleicht nicht GitHub – das ist ok. Ein persönliches oder Arbeitssnippet ist in Ordnung. Das Ziel ist es nicht, Genie zu finden. **Eigentümer**. > Sie stellen nicht ein, basierend darauf, wie viel Freizeit jemand hat. --- ## Warum das funktioniert **I. ENTWICKLUNG DER RECHTSVORSCHRIFTEN** Lassen Sie persönlich Kodierung Interviews in diesen Tagen. Es macht mich MASSIVE ängstlich - obwohl ich Hunderte von Systemen gebaut habe. Es ist UNNECESSARY. Hier ist, warum dieser Ansatz besser ist: 1. **Es ist weniger stressig.** Sie reden über vertrauten Code, nicht über Panik, etwas unter Druck zu schreiben. 2. **Es enthüllt die Wahrheit.** Wenn sie den Code nicht erklären können, dann haben sie ihn wahrscheinlich nicht geschrieben. 3. **Es führt zu natürlichen Erkundungen:** * Warum dieser Ansatz? * Warum nicht eine Bibliothek benutzen? * Was waren die Einschränkungen? 4. **Sie sehen Code, den sie mit der Zeit geschrieben haben - nicht beim Schwitzen.** Es sei denn, Ihr Arbeitsplatz ist Chaos, Menschen normalerweise nicht unter Panikbedingungen codieren. --- ## Ausnahmen von der Regel Junior-Kandidaten *kann* brauchen einen kleinen praktischen Test - aber halten Sie es humane. Machen Sie sie nicht refaktor eine 4.000-Zeilen-Vermächtnis-Datei. Fragen Sie nach Schleifen, Bedingungen, Real-Welt-Grundlagen. Halten Sie es an den Job gebunden. Design-Muster? Viele Menschen verwenden sie täglich, ohne den Namen zu kennen. Lassen Sie sich nicht auf Etiketten aufhängen. Logik-Rätsel? Nie einmal brauchte sie in der realen Arbeit. Nie sah eine echte Verwendung für das Wissen, wie viele Klavier-Tuner gibt es in New York. --- ## Nach oben Ob der Kandidat die Rolle bekommt oder nicht - **Folgemaßnahmen**. Wenn sie es nicht bekommen haben: Erklären Sie, warum. Geben Sie ihnen etwas Nützliches, um sie wegzunehmen. Wenn sie es bekommen haben: Sag ihnen, was sie als nächstes erwarten sollen. Lassen Sie sie atmen. Denn letztendlich: > **Ein Interview sollte die Fähigkeit offenbaren - nicht das Ego schützen.** > **Es sollte Wert hinzufügen - auch wenn die Antwort nein ist.** --- ## Unterm Strich: **Das genaueste Interview, das ich je gefunden habe, ist einfach:** Lass Kandidaten über Code reden, auf den sie stolz sind. Denn im Code zeigt sich Ehrlichkeit. Druck versteckt es. Wenn Leute Ihr Interview verlassen fühlen sich respektiert — Selbst wenn sie abgelehnt werden — Du hast schon etwas gebaut, das es wert ist, mitzumachen.