Umgang mit Stress bei der Kodierung von Interviews

Question

view on stackexchange narkive permalink

Ich schneide beim Codieren von Interviews sehr schlecht ab. Ich glaube, dass viele Leute in diesen Interviews unterdurchschnittlich abschneiden, aber ich habe das Gefühl, dass ich 20% von dem zeige, was ich bekommen habe. In meinem letzten Interview war die Frage so einfach, dass ich dachte, es müsse ein Fehler oder ein heikler Punkt sein. Ich verbrachte gut 10 Minuten mit einer Frage, die ich in einer Minute beantworten würde, wenn es kein Interview wäre.

Ich habe dies den Interviewern nie erklärt und ich habe keine Alternativen. Der typische Rat, den ich höre, ist, zu Github-Projekten beizutragen, die ich täglich verwende, aber es gibt keine Softwareprojekte, die ich täglich verwende.

Die Bewältigung des Stresses ist Teil des Interviews oder sollte ich erklären im Voraus, dass ich mit Interviews schrecklich bin? Wie kann ich beweisen, dass ich ein guter Kandidat bin?

Answer 1

view on stackexchange narkive permalink

Ich habe ein bisschen Erfahrung mit dieser Frage. Ich habe in zwei Vorstellungsgesprächen als Kandidat und zehn als Interviewer teilgenommen, daher kenne ich beide Seiten der Geschichte.

Als Interviewer ist es mir egal, ob Sie denken, dass Sie es nicht sind gut in Interviews. Sie müssen es nur einen glühenden Riss geben. Um allen Kandidaten gegenüber fair zu sein, muss es einen systematischen und einheitlichen Ansatz geben.

Es geht nie um die tatsächliche Antwort oder die tatsächliche Lösung, es geht um den Denkprozess, der in einem Interview zählt. Wenn Sie die Frage nicht bekommen, sprechen Sie den Denkprozess aus. Fragen stellen. Testen Sie das Szenario.

Bezüglich des Beitrags zu Projekten auf Github. Ich denke, es ist ein schlechter Rat, zu Projekten beizutragen, die Sie täglich nutzen. Mein Rat wäre, etwas auszuwählen, das Sie interessiert. Kleinere Projekte sind einfacher zu starten.

Auch wenn Sie bei Interviews hervorragend waren, sollten Sie dennoch versuchen, ein Portfolio an Arbeiten aufzubauen, das Sie vorführen können. Sie wissen an dem Tag nie, wie Sie vorgehen werden und gegen wen Sie antreten. Und denken Sie daran, es geht nicht nur um den Code, den Sie an Projekte senden, sondern auch darum, wie Sie bei Pull-Anfragen interagieren, wenn Sie Feedback erhalten.

Als Interviewter hatte ich nicht erwartet, dass das erste Interview landen würde Also ging ich sehr beiläufig hinein und suchte mehr nach Erfahrung als nach irgendetwas. Ich habe es sehr gut gemacht. Ich habe den Job bekommen. Im zweiten Interview war ich sehr nervös. Ich wollte wirklich die Rolle in dieser Firma. Ich geriet völlig in Panik und hatte wirklich Mühe, die Aufgaben zu erledigen. Ich verließ das Interview und fühlte mich sehr niedergeschlagen. Ich habe den Job bekommen.

Unabhängig davon, wie Sie in einem Interview vorgehen, ist es normalerweise nicht so schlimm, wie Sie denken.

Answer 2

view on stackexchange narkive permalink

Natürlich kann ich nicht für alle sprechen (und ich bin sicher, dass es einige Interviewer gibt, die nicht zustimmen würden), aber ich habe nie ein Problem damit, dass die Befragten mir von vornherein sagen, dass sie nervös sind.

Es wird die Standards des Interviewers nicht senken, ob Ihre Antwort "gut" ist oder nicht. Meiner Meinung nach kann es jedoch ein gutes Zeichen sein, wenn jemand anerkennen kann, dass er sich in einer stressigen Situation befindet und Strategien anwenden muss, um mit dem Stress umzugehen. Zumindest zeigt es ein gewisses Maß an Selbstbewusstsein.

Versuchen Sie, dem Interviewer anzuzeigen, was Ihr Denkprozess ist. Bei Codierungsfragen geht es im Allgemeinen um mehr als "Kann diese Person dieses Problem lösen?". Es geht darum, den gesamten Problemlösungsprozess einer Person zu verstehen.

Wenn Sie also doppelt so lange brauchen, um tatsächlich zum Problem zu gelangen Antwort, aber Sie teilen dem Interviewer die Schritte mit, die Sie in Ihrem Kopf durchlaufen, um zu einer Lösung zu gelangen, die genauso positiv sein kann wie die Antwort in der Hälfte der Zeit. Außerdem finde ich, dass das tatsächliche Durchsprechen eines Problems bei den Nerven hilfreich sein kann.

Answer 3

view on stackexchange narkive permalink

Ja, der Umgang mit Stress ist Teil des Interviews. Ich habe die folgenden 3 Schritte gefunden, die mir helfen, keinen Interviewstress zu haben:

1. Stellen Sie für jedes gestellte Problem aussagekräftige Fragen - denken Sie laut nach - ein Großteil der Diskussion würde dazu beitragen, die Erwartungen des Interviewers zu klären

2. Springen Sie niemals direkt zum Schreiben von Code. Selbst wenn Sie das Problem kennen, besprechen Sie mit dem Interviewer Ihren Ansatz. Dies hilft Ihnen, die Lösung in Ihrem Kopf zu stärken und gegebenenfalls Korrekturen vorzunehmen

3. Versuchen Sie nicht, die Absichten des Interviewers anhand des Problems zu erraten, sondern konzentrieren Sie sich nur auf das vorliegende Problem und versuchen Sie, es zu lösen. Alles andere wird auf das Problem passen eigene

ol>

Was

betrifft, wie kann ich zeigen, dass ich ein guter Codierer bin?

Während Guter StackOverflow, Github-Profile, persönliche Projekte und Blogs tragen dazu bei, die Wahrnehmung zu Ihren Gunsten zu verbessern. Nach meiner Erfahrung als Interview-Diskussionsteilnehmer habe ich nicht einmal jemanden gesehen, der eingestellt wurde, wenn er diese Profile hatte, aber in Interviews nicht gut abgeschnitten hat. Das Gegenteil passiert jedoch ziemlich häufig und ist fast die Norm. Daher würde ich vorschlagen, die Vorbereitung des Interviews und die Problemlösung über diese Profile zu priorisieren.

Answer 4

view on stackexchange narkive permalink

Es gibt einen Unterschied zwischen "ein guter Programmierer sein" und "ein Programmierer sein". Programmierer wissen, wie sie ein Problem mit den logischen Konstrukten einer Programmiersprache / -umgebung lösen können. Ein Codierer ist jemand, der diese Lösung nehmen und dem Computer tatsächlich sagen kann, wie es geht. Die meisten Programmierer sind Programmierer, nicht alle Codierer sind Programmierer.

Was zu tun ist, um den Eindruck zu verbessern, hängt wirklich von der Art des Codierungstests ab. Einige allgemeine Dinge, nach denen meine Gruppe auf diesen sucht -

Fragen stellen - über die Spezifikation des Tests, die betroffene Infrastruktur usw. Wenn wir Sie bitten, eine SQL-Anweisung auszuführen (zeigen Sie die Kategorie für alle Elemente an Das kostet weniger als 2 US-Dollar und hat eine Produktnummer, die mit 3 beginnt. Wir erwarten Fragen zum DB-Layout, zu den verfügbaren Schlüsseln usw. Wenn wir Sie bitten, einen Beispielcode zu schreiben, der diese Abfrage ausführt und das Ergebnis konvertiert Datensatz auf eine JSON-Zeichenfolge gesetzt. Wir erwarten Fragen zu verfügbaren Bibliotheken (Gson usw.), zu internen Dienstprogrammen (Verbindung zur Datenbank herstellen und Abfrage ausführen) usw.

Zeigen Sie Ihre Arbeit oder zeigen Sie Verständnis der Arbeit - Wenn Sie Code schreiben müssen, tun Sie dies zuerst als Kommentare im Pseudocode und gehen Sie dann zurück und füllen Sie ihn aus. Erstellen Sie Stub-Methoden mit Kommentaren darüber, was sie verbrauchen und tun / zurückgeben usw. Zeigen Sie uns, dass Sie geplant haben und schreibe das Programm in deinen Kopf / auf dein Papier, dann mache die eigentliche Codierung dafür. Zeigen Sie gute Codierungsgewohnheiten. Wenn Sie sich in einer unbekannten Umgebung befinden (Netbeans und Sie sind an Eclipse gewöhnt oder umgekehrt usw.), haben Sie keine Angst zu fragen, wo sich Tools befinden oder ähnliche Fragen zur Verwendung der Umgebung, es sei denn, Sie haben Kenntnisse beansprucht in diesem speziellen Setup.

Überdenken Sie dies nicht und erschweren Sie es nicht. Dieses Beispiel für eine SQL-Anweisung war der Codierungstest für meinen letzten Job - und ich hatte eine Stunde Zeit dafür, zwei angespitzte Stifte und drei Blatt Druckerpapier. Wenn Sie sich fragen - der Schlüssel wurde ich nach der DB-Struktur, Primär- / Fremdschlüsseln usw. gefragt, und es scheint, dass es einige Produktnummern gibt, die alphanumerisch sind, also String-Vergleich für den Gewinn :)

Answer 5

view on stackexchange narkive permalink

Gelegentliche Notwendigkeit, ein Problem unter Stress zu lösen, ist in vielen (wenn nicht allen) Programmierjobs Realität. Vielleicht möchten Sie herausfinden, wie Sie im Nicht-Interview-Kontext damit umgehen, und dies auf Interviews anwenden.

Ein weiterer wichtiger Schritt ist die Vorbereitung und das Training - jeder Beruf, bei dem Stress einen wesentlichen Teil des Prozesses ausmacht, erfordert immer viel Training. Sie werden nicht F-18 in einer Diamantformation für Blaue Engel fliegen, nachdem Sie "Fliegen in 24 Stunden" gelesen haben - Sie brauchen Hunderte von Flugstunden und mehrmals so viele Stunden, um jede Bewegung richtig oder falsch für eine einzelne Show zu besprechen ... Behandeln Sie Interviews gleich - überprüfen / lernen Sie die Grundlagen und üben Sie Interviews auf beiden Seiten.

• Lernen und üben Sie grundlegende Datenstrukturen. Lassen Sie Ihren Freund jemanden bitten, auf dem Whiteboard zu codieren - "Erweiterbare Liste mit Arrays fester Größe schreiben", "Element in BST suchen".
• Wissen über die O-Notation auffrischen ... Die Behauptung, dass das Entfernen eines Elements aus dem Array O (1) ist, weil es sich um einen einzelnen Methodenaufruf handelt (ich kann keine andere Erklärung für this a finden >) Ich werde dir nicht viel helfen.
• Erfahren Sie, welche Art von Fragen / Interview-Unternehmen Sie beantragen.
• Gehen Sie einfach zu Interviews mit dem einzigen Ziel, Ihre Interviewfähigkeiten zu üben.
• Überprüfen Sie die Grundlagen des Testens. Sie sollten in der Lage sein, grundlegende Testfälle für die meisten Datenstrukturen sofort auszuspucken. Das heißt, Alles, was an Arrays arbeitet, benötigt mindestens 3 Fälle - 0, 1, 10000 Elemente, unabhängig davon, was die Frage war.

Ziel ist es, sicherzustellen, dass grundlegende Dinge, die Sie für ein Interview benötigen, nicht beeinflusst werden Ihr Stresslevel.

Randnotiz: Eine meiner Interviewfragen steht auf der ersten Seite eines Leitfadens zum Thema "Vorbereitung auf das Codieren von Interviews". Dies lässt mich glauben, dass wenn Sie nach Auf der ersten Seite sind Sie vielen Leuten voraus :)

Answer 6

view on stackexchange narkive permalink

Zusätzlich zu den anderen Antworten gibt es manchmal eine "unmögliche" Frage in einem Codierungsinterview.

In solchen Fällen geht es nicht darum, sie richtig zu beantworten (dies ist nahezu unmöglich). , aber um einen logischen Denkprozess und ein logisches Verständnis zu demonstrieren.

Wenn Sie diesen Ansatz wählen, können Sie die Frage möglicherweise nicht wirklich lösen, aber Sie können ein gutes Verständnis demonstrieren, die Frage untersuchen und wie andere sagte - denken Sie laut nach, dann können Sie Ihren eigenen Stress reduzieren und manchmal sogar "erfolgreich" Codierungsfragen beantworten, die Sie sonst nicht hätten!

Versuchen Sie diese Einstellung, es kann viel helfen: )

Answer 7

view on stackexchange narkive permalink

"In meinem letzten Interview war die Frage so einfach, dass ich dachte, es müsste ein Fehler oder ein kniffliger Punkt sein. Ich verbrachte gut 10 Minuten mit einer Frage, die ich in einer Minute erledigen würde, wenn es so wäre war kein Interview. "

Setzen Sie einen Fuß vor den anderen.

Mit anderen Worten: Machen Sie Schritt für Schritt. Lösen Sie das Problem Stück für Stück und vokalisieren Sie Ihren Denkprozess.

Die Vokalisierung ist hier sehr wichtig, da sie dem Interviewer die Möglichkeit gibt, großzügig zu sein. In Ihrem Beispiel klingt es so, als wären Sie übermäßig vorsichtig. Dies ist nicht perfekt, aber auch nicht problematisch (in einigen Fällen kann es sehr wertvolles Verhalten sein!). Wenn Sie Ihre Bedenken äußern, kann der Interviewer genau sehen, was Sie tun. Wenn Sie jedoch still auf eine leere Seite starren, werden sie wahrscheinlich falsch verstanden und davon ausgehen, dass Sie Schwierigkeiten mit der Frage haben.

Wenn Das ist für Sie nicht selbstverständlich, dann wäre es eine gute Idee, es zu üben.

Answer 8

view on stackexchange narkive permalink

Ich habe diese beiden erlebt und mich insbesondere gefragt, ob es sich um eine Trickfrage handelt oder nicht. Normalerweise habe ich einfach so viel gesagt, so etwas wie "das sieht einfach aus, also frage ich mich jetzt, ob es eine Trickfrage ist." Das gibt normalerweise die Gewissheit, dass dies nicht der Fall ist.

Ich hatte auch einige Erfolge damit, zu erklären, warum ich solche Tests nicht mag. Die Art und Weise, wie ich Code schreibe, ist methodischer und führt tendenziell zu einem robusteren, korrekten Code, der fehlerfrei ist, anstatt unter Druck zu einer Lösung zu eilen. Ich schätze die Fähigkeit, auch bei Zeitdruck methodisch und sorgfältig weiterzuarbeiten, da dies letztendlich zu einem besseren Ergebnis führt. Im Allgemeinen scheinen die Interviewer positiv zu reagieren, und wenn dies nicht der Fall ist, möchten Sie möglicherweise überlegen, welche Art von Arbeitsumgebung sie bieten. Sie möchten nicht ständig gegen Feuer kämpfen und Code von geringer Qualität ausgeben.

Leider haben Sie sich damit abgefunden, bis Sie das höhere Niveau erreicht haben. An diesem Punkt sind alberne Tests normalerweise ein gutes Zeichen, dass Sie woanders nach einer Beschäftigung suchen sollten.

Answer 9

view on stackexchange narkive permalink

Ich sehe, dass es bereits eine ausgewählte Antwort gibt, aber hier sind einige relativ konkrete Dinge, die mir bei meinem Interview in jeder Hinsicht geholfen haben , einschließlich meiner Nerven:

• Angenommen, Sie sind qualifiziert, bis etwas anderes nachgewiesen wird. Sie sind es wahrscheinlich.
• Angenommen, Ihre Interviewer glauben, dass Sie qualifiziert sind. Das tun sie wahrscheinlich.

• Angenommen, die technischen Fragen sind nur Überprüfungen der Vernunft und / oder des Levels. Sie sind kein Make-or-Break für Sie , weil Sie ein erfahrener Programmierer sind.
• Geben Sie Ihre Wissenslücken sofort zu. Fragen Sie nach Technologien oder Praktiken, von denen Sie noch nichts gehört haben. Seien Sie daran interessiert, etwas über das zu erfahren, was Sie nicht wissen, weil Sie es sind. Ob Sie ALLES wissen, ist normalerweise irrelevant, weil Sie es nicht wissen.
• Bereiten Sie sich mit ein paar Fragen an Ihren Interviewer über das Unternehmen, den Job und seine Erfahrung bei der Arbeit vor. Die Fragen sollten Daten zu Dingen sammeln, die Sie wirklich interessieren. Einige meiner Favoriten:
  • Wenn ich eingestellt werde, was mache ich dann in den nächsten 3 Monaten?
  • Wie wird mein Alltag aussehen?
  • Wie definieren, priorisieren und verwalten Sie die Arbeit in diesem Entwicklerteam?
  • Kann ich von zu Hause aus arbeiten, wenn ich mich nicht gut fühle?
  • Was gefällt Ihnen am besten? Ihr Job?
  • Was gefällt Ihnen an Ihrem Job am wenigsten ?
• Stellen Sie während des gesamten Interviews Folgefragen eher großzügig , besonders wenn ...
  • Sie die Frage nicht ganz verstehen
  • Sie brauchen mehr Zeit, um über die Antwort nachzudenken
  • Sie möchten wissen, nach welchen Daten sie wirklich suchen.
  • Sie sind wirklich interessiert und / oder neugierig auf das Thema / die Frage. ZB fragen sie nach TDD, man könnte sagen: "Oh, ich hatte in meiner Karriere nicht viel Erfahrung. Keiner meiner Mentoren macht das wirklich. Aber ich bin super interessiert! Betont Ihr Team das wirklich? Tun Sie das?" Finden Sie, dass es so effektiv ist, wie Onkel Bob es sagt? "
  • Sie erhalten Fragen zum Thema "Codierung" oder "Systemdesign" , mit denen normalerweise zwei Dinge bewertet werden sollen: Grundlegende Codierungsfähigkeit und Fähigkeit zum Dialog und Fleisch Anforderungen.
• Üben. viel interviewen - insbesondere , wenn Sie keinen neuen Job benötigen .

Und schließlich ist die definierende Änderung der Denkweise, aus der ich die meisten dieser Verhaltensweisen "extrahiert" habe, folgende:

Sie sollten sie genauso oft interviewen, wie sie Sie interviewen.

Ein Interview ist eine Chance, ein Unternehmen kennenzulernen und ihre Mitarbeiter , um festzustellen, ob Sie alle zusammenarbeiten möchten. Es ist kein Test. Es ist ein Gespräch, und sollte fun sein.

Answer 10

view on stackexchange narkive permalink

Sie haben mehr Erfahrung mit Codierungsproblemen als Sie denken. Der Interviewer möchte wissen, ob Sie ein guter Kollege sind. Behandeln Sie ihn also wie einen. Behandeln Sie ein Interviewproblem genauso, wie Sie es tun würden, wenn ein Kollege um Ihre Hilfe bitten würde. Erklären Sie die Teile, die Sie kennen, und stellen Sie klärende Fragen. Das hilft sehr bei der Entspannung, vorausgesetzt, Sie geraten nicht jedes Mal in Panik, wenn Ihnen jemand bei der Arbeit eine Frage stellt.

Sie haben auch mehr Erfahrung mit dem Codieren unter Stress als Sie denken. Was machst du bei der Arbeit, wenn du müde bist, Kopfschmerzen hast oder überfordert bist? Machen Sie die gleichen Dinge in einer Interviewfrage. In solchen Situationen verlangsame ich mich ein wenig und bin methodischer. Ich benutze Notizen, um meinen Platz zu behalten. Ich spreche durch meinen Ansatz mit Kollegen. Ich bitte um häufigeres Feedback.

Answer 11

view on stackexchange narkive permalink

Interviewer berücksichtigen den Stress des Kandidaten mehr als Sie denken. (Die meisten Interviewer waren natürlich Interviewpartner - einige davon oft!) Und als Interviewer betrachten Sie die gesamte Sitzung und nicht nur die Antwort auf ein Problem. In diesem Zusammenhang ist es ziemlich einfach, den Unterschied zwischen Leistungsmängeln aufgrund von Stress und dem Unwissen, wie man ein Problem angeht, zu erkennen. Und auch gegen ahnungsloses Herumflattern. Und auch gegen einfaches (und vor allem aufwändiges) Bullshitting.

Der beste Weg, um Ihren stressbedingten Leistungsfehler (z. B. wenn Sie nicht im laufenden Betrieb die "richtige" Datenstruktur finden) von ahnungslosem Hin und Her zu unterscheiden, besteht darin, zu zeigen, dass Sie Dinge denken : Randfälle berücksichtigen, Alternativen in Betracht ziehen und nach Informationen suchen.

Die beste Taktik, die Sie anwenden können, wenn Sie verloren gehen, besteht darin, anzukündigen, dass Sie sich zuerst für eine einfache, korrekte Lösung entscheiden und dann werden Sie Verbesserungen in Betracht ziehen, z. B. um die Leistungsanforderungen zu erfüllen. Dann machen Sie genau das: Lösen Sie das Problem einfach und richtig und beginnen Sie dann damit, über Verbesserungen zu diskutieren.

Der beste Weg Eine einfache richtige Lösung besteht darin,

• eine einfache Lösung (duh) zu wählen.
• Stellen Sie sicher, dass Sie es wissen Die Rand- / Fehlerfälle, bevor Sie mit dem Codieren beginnen (schreiben Sie sie an die Tafel).
  • Oftmals einfach eine korrekte Lösung codieren, die Eingaben auf Fehler überprüft (über Asserts) reicht aus, um die Frage noch zu übergeben, bevor Sie sie aus Gründen der Klarheit oder Leistung verfeinern.
    • Sie wissen dies besonders, wenn der Interviewer zum nächsten übergeht Frage, anstatt nach Verbesserungen zu suchen. Sie wissen eigentlich nicht wirklich, wie tief er auf eine Frage eingehen möchte, bis Sie sie zuerst einfach für ihn lösen.

Answer 12

view on stackexchange narkive permalink

Wie Davidbak erwähnt hat, ist die Fehlerprüfung wichtig. Versuchen Sie, Ausnahmen abzufangen, damit Ihr Code nicht auf den Boden fällt, wenn etwas schief geht. Geben Sie bei Ihrer Fehlerbehandlung einige nützliche Informationen an den Benutzer weiter.

Die ersten von vielen Irrtümern:
Das Netzwerk ist immer vorhanden. Die Eingabe ist immer der Typ, den ich erwarte. Der Client kann vertrauenswürdig sein usw. usw.

Alles, was schief gehen kann, wird. Handle es. Dann werfen Sie ein Allheilmittel für das Zeug ein, mit dem Sie nicht gerechnet haben. Es ist absolut nichts Falsches daran, dass catch (Ausnahme $ e) {log etwas} der letzte Ihrer Fangblöcke ist. Das Überprüfen von Eingaben ist auch aus Sicherheitsgründen enorm. Eine starke Fehlerbehandlung trennt die Männer von den Jungen ;-) Es sieht auch viel besser aus als Stapelspuren (oder schlimmer noch nichts) auf Benutzer zu werfen.

Sie möchten beschreibend genug sein, um nützlich zu sein, aber nicht so nützlich, dass Ihre Fehlermeldungen gegen Sie verwendet werden können.