Codierungsinterviewfrage: Wie kann man sich wohl genug fühlen, um eine bestimmte Aufgabe zu erledigen, die natürlich nicht sehr oft vorkommt?

Sie sollten auf keinen Fall erwarten, alle möglichen Fragen üben zu können.

Es geht nicht darum, irgendetwas auswendig zu lernen, es geht darum, sich ausreichend mit Datenstrukturen und Algorithmen auseinanderzusetzen, damit Sie es schnell verstehen können. Und Sie erhalten diese Exposition mit Übung.

• Nehmen Sie an einigen Online-Kursen zu Datenstruktur und Algorithmen teil (z. B. von Coursera - sie sind kostenlos) - ich habe so viel aus einigen dieser Kurse gelernt, die als Grundstudium gedacht waren, obwohl ich bereits meinen Abschluss hatte - der Unterschied zwischen verschiedenen Universitäten ist so groß, dass Sie unbedingt einige dieser Kurse belegen müssen, um sicherzustellen, dass Sie auf dem neuesten Stand sind.

• Verbringen Sie einige Zeit auf konkurrierenden Programmierseiten (z. B. HackerRank , CodeChef , Topcoder ).

• Es gibt viele Blogs und dergleichen (z. B. CareerCup und GeeksforGeeks.com ) über das Codieren von Interviewfragen - lesen Sie die Lösungen nicht sofort, schreiben Sie den tatsächlich funktionierenden Code auf Papier und messen Sie, wie lange Sie brauchen - Ihr Ziel ist sagen wir unter einem Stunde, nachdem Sie mit dem Lesen der Frage begonnen haben, denn so lange dauern Interviews normalerweise.

• Stack Overflow kann sicherlich helfen, insbesondere die Tags für Algorithmen und Datenstrukturen - Sie müssen (zunächst) nicht einmal etwas beantworten, Sie können einfach die Fragen lesen, versuchen, es selbst herauszufinden (versuchen Sie, den Code zu schreiben) und dann lesen Sie die Antworten. Während viele der Fragen keine Interviewfragen sind, werden Dinge wie das Auffinden von Fehlern im Code anderer auch einiges dazu beitragen, Sie zu einem besseren Programmierer zu machen.

  Das Lesen und Schreiben verständlicher Antworten hilft auch sehr dabei, sich besser zu erklären, was in einem Interview sehr nützlich ist (posten Sie keine reinen Code-Antworten).

In Bezug auf allgemeine Interviewtipps – sprechen Sie.

Mir ist klar, dass manche Leute schweigend besser denken, aber das Problem, nichts zu sagen, ist, dass der Interviewer keine Ahnung hat, was Sie denken. Gehen Sie durch, was Sie vorhaben. Wenn Sie einige Ideen haben, auch wenn Sie denken, dass sie schlecht sind oder nicht funktionieren, teilen Sie sie einfach mit (Sie können sogar sagen, dass Sie sie für schlecht halten - ob Sie es glauben oder nicht, aber schlechte Ideen verbessern oft Ihre Chancen sehr ).

Wenn Sie nichts sagen und nichts schreiben, wird der Interviewer Ihnen höchstwahrscheinlich Fragen stellen, um festzustellen, ob Sie vielleicht einen Tipp brauchen oder was genau Ihnen durch den Kopf geht.

Sie sollten jedoch damit rechnen, jederzeit auf eine Frage zu antworten - sie fragen möglicherweise nach Ihrer Motivation für bestimmte Entscheidungen oder versuchen, Sie mit einigen Leitfragen in die richtige Richtung zu führen.

Denken Sie daran, dass eine "schlechte", wirklich offensichtliche Lösung besser ist als keine Lösung - für Ihr Beispiel, selbst wenn Sie nur Code schreiben, um die verknüpfte Liste schrittweise zu durchlaufen, und die Elemente am Anfang einer anderen verknüpften Liste einfügen, das würde zu einer umgekehrten Liste führen, das ist viel besser, als keine Lösung zu geben. Wenn Sie jemals nicht weiterkommen, gehen Sie zwei Schritte zurück und versuchen Sie, sich einen wirklich ineffizienten Weg auszudenken, um das Problem zu lösen – bei Interviewfragen gibt es oft einen.

Machen Sie auch keine Vermutungen – um Klärung zu bitten ist gut . Versuchen Sie aktiv , nicht sofort mit dem Schreiben von Code zu beginnen - versuchen Sie, zumindest etwas in der Frage zu finden, das unklar ist und nach dem Sie fragen können . Rechts von der Fledermaus - welche Art von Linked-List ist das? Doppelt oder einfach? Sie können nach der zeitlichen und räumlichen Komplexität fragen, aber ich würde mich zunächst nicht allzu sehr darum kümmern, da diese als große Ablenkung von einer etwas schlechteren Lösung dienen können, die möglicherweise immer noch als akzeptabel angesehen wird und Ihnen am Ende den Job verschafft.

In Bezug auf das Üben tatsächlicher Interviews - holen Sie sich einen befreundeten Programmierer, der ein paar tatsächliche Übungsinterviews mit Ihnen führt.

Holen Sie sich ein Whiteboard (oder ein Notizblock könnte auch funktionieren), lassen Sie ihn/sie Sie etwas fragen wie „eine verknüpfte Liste umkehren“ und schreiben Sie den eigentlichen Code auf das Whiteboard. Habe ihn/sie:

• Überprüfen Sie, ob Sie um Klärung bitten
• Stellen Sie sicher, dass Sie nicht zu lange still sind und nichts tun (ich bin mir nicht sicher, wie lange zu lang ist, 30 Sekunden?)
• Kommen Sie zufällig mit einer Frage vorbei, warum Sie eine bestimmte Wahl getroffen haben, oder bitten Sie Sie, Ihren Code zu erklären

Sie könnten ihre Fragen aus einem Blog über das Codieren von Interviewfragen erhalten, sodass Sie keine Ahnung haben, was kommt (es könnte eine absichtlich unterspezifizierte Frage sein, also müssen Sie um Klärung bitten (gut) oder eine Menge Annahmen treffen (schlecht)). .

Ich würde auch einige nicht codierte (z. B. HR) Interviewfragen einmischen, da Sie diese wahrscheinlich in tatsächlichen Interviews erhalten werden und die Beantwortung dieser Fragen möglicherweise eine andere Denkweise erfordert, und Sie versuchen, sie so real wie möglich zu machen möglich.

Abschließend - üben Sie das Schreiben von voll funktionsfähigem Code ohne eine IDE, ohne ihn zu testen, bevor er vollständig fertig ist (und ihn dann ausgiebig testen, um sicherzustellen, dass er funktioniert). Wenn Sie es nicht gewohnt sind, auf die Hilfe einer IDE zu verzichten, könnte es Ihnen allein mit diesem Aspekt schwer fallen.

Vor Jahrzehnten hatte ich einen Chemieingenieur-Professor, der ein wirklich kluger, ultraharter Keks war. Er würde genau sagen, was er bei seinen Prüfungen mit uns machen würde, uns genau sagen, welche Fragen er stellen würde. Und dann würde er uns auslöschen, egal wie hart wir lernten. Es war für uns unangenehm, weil es demütigend war - Normalerweise kommt man nicht auf die Ingenieurschule, weil man ein Dummkopf ist.

Wir Schüler sind schließlich schlauer geworden und haben den Schlüssel gefunden:

(1) eine gute Nachtruhe. Ernsthaft. Wenn Sie unter extremem Stress stehen, reagieren Sie besser und effektiver, wenn Sie vollständig ausgeruht sind. Oder so ausgeruht, wie man sein kann, wenn man zur Ingenieurschule geht :)

(2) Erwarten Sie das Unerwartete, aber hören Sie auf, sich darüber Sorgen zu machen. Das Problem/die Einschränkung beim Überlernen und Unterdenken ist, dass es keine Möglichkeit gibt, für alle Eventualitäten zu üben. Das Universum möglicher Fragen ist einfach zu groß. Was Sie tun können, ist, Elemente von Fragen zu erkennen, die Sie zuvor studiert haben, und sich von dort aus weiterzuentwickeln.

(3) Seien Sie absolut selbstbewusst. Wenn du es vermasselt hast, hast du es vermasselt. Aber wenn Sie sich selbst für schlau und zäh und zu allem bereit halten, dann werden Sie genau das: schlau, zäh und zu allem bereit. So werden Sie erfolgreich. Denn die Göttin des Erfolgs ist launisch mit oberflächlichen Loyalitäten und sie liebt diejenigen, die schlau, hart und zu allem bereit sind.

(4) Arbeiten Sie an Ihren Grundlagen. Arbeiten Sie weiter an Ihren Grundlagen, bis Sie sie im Schlaf ausführen können. Es geht nicht um Auswendiglernen und Pauken, sondern darum, zu verstehen und zu kontrollieren, was man tut.

Gewinnen ist am Ende eine Frage des Vertrauens: Vertrauen in Ihre Fähigkeiten, Vertrauen in Ihr Training, Vertrauen in Ihr Wissen um Ihre Stärken und Schwächen, Vertrauen in Ihre Fähigkeit zur kompromisslosen, aber fairen Selbstprüfung, Vertrauen, dass Sie Ich werde gewinnen, egal was sonst noch schief gehen kann. Und wissen Sie was, Arbeitgeber mögen selbstbewusste Menschen. Weil sie wissen oder wissen sollten, dass sie ihr Schicksal in die Hände ihrer Mitarbeiter legen.

Bei den Whiteboard-Codierungsfragen geht es um Kommunikation , nicht um das Auswendiglernen . Während Sie vielleicht am Ende wissen, was die technisch richtige Antwort in Bezug auf Code ist, ist Ihnen klar, dass hier wirklich bewertet wird, wie gut Sie Ihre Meinung kommunizieren, stellen Sie klärende Fragen, welche Nebenüberlegungen Sie einbringen und insgesamt, wie gut präsentieren Sie Ihre Antwort?

Mein Vorschlag ist, mindestens eine Handvoll ziemlich einfacher Programmieraufgaben zu übernehmen, wie das Umkehren einer verknüpften Liste, das Umkehren einer Zeichenfolge, das Erstellen einer Prioritätswarteschlange, das Lösen von Fizzbuzz, und erwägen Sie, die Schritte zum Einrichten Ihrer Lösung durchzugehen. Welche Fragen stellen Sie im Vorfeld? Wo suchen Sie nach Klärung, ob Zeit oder Raum für die Lösung Priorität haben? Welche Sprachen verwenden Sie und gibt es andere, die interessant sein könnten, um zu sehen, wie die Lösung in diesen Sprachen aussehen würde, die Sie vielleicht nicht so gut beherrschen?

Ich kann mich erinnern, dass ich von einem Personalvermittler einen kleinen Crashkurs zu diesen Themen bekommen habe, als ich in Seattle, Washington, lebte, und es war ziemlich nützlich, das Grundgerüst zu haben, zu wissen, wo ich den Code schreiben würde, wo ich Testfälle platzieren würde, wo Würde ich Komplexitäten usw. angeben, damit ich einen Ausgangspunkt hätte, um organisiert zu sein und mich durch das Problem zu bewegen, da diese so einfach sein sollen, dass Sie es wahrscheinlich im Interview so könnten, wie es ist, wenn Sie es herausfinden müssten nicht um den Trick, den Algorithmus zu finden, sondern wie gut man zeigen kann, dass man am Ende eine gute Lösung hat.

Wenn Sie etwas zu Vergleichszwecken wollen, ziehen Sie mathematische Wortaufgaben in der Schule in Betracht. In Klasse 2 reicht es aus, die Zahl am Ende richtig zu machen, während es in Klasse 7 wichtiger ist, darauf zu achten, wie Sie Ihre Antwort begründet haben. Während in der 2. Klasse der Lehrer die Antwort kennt und dem Kind, das sie gefunden hat, Anerkennung zollen kann, ist es in den höheren Klassen wichtiger zu wissen, warum etwas richtig ist, damit jemand nicht eine Rechtfertigung gibt mit: „Nun, ich habe gerade denke gut, also dachte ich, das würde funktionieren ... "

Ihre Aufgabe als Softwareentwickler besteht nicht darin, Code zu schreiben, sondern darin, Probleme zu lösen. Wenn Sie nicht gerade das College verlassen haben, würde ich erwarten, dass Sie (sprich: jeder, der sich für einen Programmierjob bewirbt und Vorkenntnisse benötigt) mit etwas Zeit herausfinden, wie Sie eine verknüpfte Liste umkehren können. Wieso den? Weil Sie in Ihrem Job sehr ähnliche Dinge tun müssen, aber keine Dinge, die bereits in irgendeiner Standardbibliothek vorhanden sind.

Sagen Sie mir nichts über den Druck bei Vorstellungsgesprächen – Ihre tägliche Arbeit wird sehr wahrscheinlich mit Ihren Kunden oder Ihrem Chef verbunden sein, die Sie ständig unter Druck setzen.

Das mag hart sein, aber Vorstellungsgespräche sind nicht dafür gedacht, dass Sie für sie lernen. Sie sind da, um sicherzustellen, dass Sie Ihre Arbeit erledigen können. Wenn Sie Ihren Job nicht machen können (zufällige Probleme lösen, möglicherweise unter Druck), dann sollten Sie den Job nicht bekommen .

Sich hochzuarbeiten, um das Vorstellungsgespräch zu überstehen, nur um einen Job zu bekommen, bei dem man nicht für jedes neue Problem lernen kann, stellt sich nur auf einen Misserfolg ein.

Sie sollten nicht alle Fragen üben müssen und sie möchten wahrscheinlich, dass Sie an etwas arbeiten, das Sie nicht speziell geübt haben. Übungen wie diese sind nützlich, da Sie vermutlich eine Vorstellung davon haben, was das Problem ist, damit sie keine Zeit damit verschwenden, alle Details darlegen zu müssen, aber da Sie dies nicht oft tun, sehen sie ein Beispiel wie Sie in einem realen Job-Szenario arbeiten würden, in dem Sie Code für etwas programmieren, das Sie nicht getan haben oder normalerweise nicht tun.

Zu sagen "Ich darf nicht, ich denke nur" war eine okay Antwort, solange du es in einem höflichen Ton sagtest. Die Hälfte des Grundes, warum Sie ein solches Problem lösen müssen, besteht darin, die tatsächliche Implementierung zu sehen, die Sie durchgeführt haben (haben Sie viel zu viele Variablen verwendet? Hatten Sie eine O(n^4)-Lösung, wo eine O(n)-Lösung vorhanden war? ). Tun Sie in diesem Fall Ihr Bestes, und wenn Sie ein Problem in Ihrer Lösung sehen, können Sie es ihnen mitteilen (z. B. "Im Moment habe ich hier eine Platzhalterfunktion, ich kann das mit etwas mehr Zeit effizienter machen. "). Die andere Hälfte dient jedoch nur dazu, zu sehen, wie Sie arbeiten. Auf diese Weise lassen Sie sie durch Ihre Antwort wissen. Sie haben Sie vielleicht gefragt, weil sie sehen wollten, wie Sie Probleme angehen und welche Dinge Sie durchdenken. Wenn Sie einen Interviewer bekommen, der sich wirklich auf die Details konzentriert und solche Fragen stellt,

Wenn ich mich für Positionen als "Senior Software Engineer" bewerbe, ist es immer noch sehr wahrscheinlich, dass mir irgendwann während des Interviewprozesses (entweder während des Telefonbildschirms oder vor Ort) eine von drei Fragen gestellt wird, nämlich:

• Implementieren Sie eine doppelt verknüpfte Liste.
• Implementieren Sie eine Hash-Tabelle.
• Implementieren Sie eine binäre Suche.

Mein Vorschlag wäre, dass Sie als Teil Ihrer Interviewvorbereitung (vor jedem Interview) alle drei mit den entsprechenden Methoden zum Einfügen, Suchen und Entfernen implementieren.

Es wird anfangs mühsam sein, aber nach einer Weile haben Sie die Grundstruktur von jedem auswendig gelernt und können sie einfach aus dem Gedächtnis eintippen (oder an eine Tafel schreiben).

Es mag wie Zeitverschwendung erscheinen, aber einfach ausgedrückt, könnte die Möglichkeit, diese drei aus dem Gedächtnis zu streichen, bedeuten, dass Ihr Angebot 5-10.000 höher ist, als es sonst wäre, also würde ich meinen, dass sich die Zeitinvestition gelohnt hat.