Wie werden die Fähigkeiten, die in typischen Interviewfragen verwendet werden, in der realen Arbeit angewendet? [geschlossen]

Bei SQL- und C # -Anwendungsentwicklungsjobs stellen die Interviewer in der Regel Fragen zu Baum-, Diagramm- und verknüpften Listenüberquerungen mit reinem C und Zeigern. In den 3 Jahren, die ich in meinem Job verbracht habe, musste ich eigentlich nie

Finden Sie den Pfad zum ersten Knoten rechts von einem gegebenen Knoten, der ein Vielfaches des gegebenen Knotens ist

beispielsweise

Ich kann sehen, dass diese Fähigkeiten in Jobs eingesetzt werden können, in denen Sie Compiler und Treiber schreiben und am Betriebssystemkern arbeiten müssen. Wo sonst werden diese Fähigkeiten eingesetzt?

Lesen Sie unten einige Antworten von Joel.

Beachten Sie besonders etwas wie der Maler Schmiel. Unterwegs müssen Sie vielleicht nie eine verknüpfte Liste umschreiben , aber Sie sollten unter der Haube wissen, wie es funktioniert, damit Sie Schmiel vermeiden können.

Wenn Sie zum Arzt gehen, möchten Sie im Grunde, dass der Arzt Anatomie studiert hat. Obwohl sie Ihnen nur AntiHistaminikum verschreibt, hat ein Arzt in der medizinischen Fakultät erfahren, dass bestimmte Medikamente für Menschen mit einem „chronischen Bruch mit Diamadabada am unteren Oberschenkel“ oder was auch immer schlecht sind. Diese Art von fundiertem Wissen über ALLES in diesem Fachgebiet kann manchmal den Unterschied zwischen Leben und Tod und in der Informationstechnologie zwischen Leben und Tod des Produkts oder einer Arbeit ausmachen.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

http://www.joelonsoftware.com/articles/fog0000000319.html

"... verbringe mindestens ein Semester damit, dich der Maschine zu nähern, sonst wirst du niemals in der Lage sein, effizienten Code in höheren Sprachen zu erstellen. ..."

"... Sie programmieren meiner Meinung nach auf der Grundlage von Aberglauben: ein Arzt, der die grundlegende Anatomie nicht kennt und Rezepte austeilt, die auf dem beruhen, was die Pharmaverkäuferin versprochen hat."

http://www.joelonsoftware.com/articles/CollegeAdvice.html

Sie sind nicht. Viele Interviews werden von Leuten geführt, die nicht wissen, wie sie nach talentierten Entwicklern suchen sollen und nicht wissen, welche Fragen sie stellen sollen oder nicht.

Die meisten Interviewer stellen überhaupt keine technischen Fragen und konzentrieren sich mehr auf bedeutungslose, aber messbare Dinge, wie die Anzahl der Projekte, an denen Sie teilgenommen haben (mehr ist besser für diese Interviewer) oder den Hochschulabschluss (höher ist besser für sie) ). Sie sind glücklich, eine Person einzustellen, die fünf Jahre lang nichts gelernt hat und dann zehn Jahre lang Dutzende von E-Commerce-Websites erstellt hat, aber sie werden keine Person einstellen, die nach ein paar Jahren das College verlassen hat und an einigen gearbeitet hat große technisch herausfordernde Projekte.

Zumindest theoretische Fragen zu stellen ist besser als keine zu stellen. Dies hat den Vorteil, dass überprüft wird, ob die Person über ausreichende theoretische Kenntnisse verfügt, und dass es sich nicht um einen Programmierer handelt, der über einige Jahre Erfahrung mit der Programmierung verfügt, aber nicht wirklich versteht, was unter der Haube geschieht. Entwickler, die über dieses theoretische Wissen nicht verfügen, ¹ kennen normalerweise den Unterschied zwischen einer Liste, einer verknüpften Liste, einem Lookup oder einem Hash-Set nicht und verwenden sie austauschbar.

Gute (technische) Fragen, schlechte Fragen

Während eines Interviews können Sie auf Fragen stoßen, die von sehr gut bis sehr schlecht reichen:

1. (Gesundheitsschädlich) "Wie lang sind die Zeilen des längsten Arbeitsprogramms, das Sie in dieser Sprache geschrieben haben?"

   Diese Frage ist eindeutig falsch. Ich habe bereits in einer anderen Antwort erklärt, warum . Das Unternehmen, in dem Interviewer solche Fragen stellen, hat gute Chancen, die Produktivität von Entwicklern in LOC / Monat zu bewerten. Wenn ich einen Rat geben muss: Sie brauchen keinen solchen Job.

   Dieses Beispiel unterscheidet sich von bedeutungslosen, aber messbaren Dingen, die ich zu Beginn meiner Antwort zitiert habe. Hier zeigt der Interviewer auch, dass er nicht einmal das grundlegendste Verständnis der Metriken hat, indem er eine auswählt, die bekanntermaßen schädlich ist.

2. (Schlecht) "Wer ist Dennis Ritchie?"

   Wenigstens etwas Kultur zu haben, ist in der Tat sehr nützlich, aber diese Frage zu stellen, geht daneben. Wenn das Unternehmen nach talentierten Entwicklern sucht, die in der Lage sind, Softwareentwicklungsprojekte abzuwickeln und Code zu schreiben, sollte die Tatsache, dass sie den Namen der Person nicht kennen, die C und Unix erstellt hat, keine große Rolle spielen.

3. (Gut) "Was sind die neuen Funktionen von .NET 4.5?"

   Diese Frage ist viel interessanter als die zu Dennis Ritchie. Wenn der Kandidat nicht über neue Funktionen in .NET 4.5 sprechen kann, warum nennt er sich selbst C # -Entwickler? Der Mangel an solchem ​​Wissen:

   • Zeigt an, dass die Person möglicherweise weder an der Programmiersprache noch an der .NET-Community wirklich interessiert ist.

   • Gibt an, dass der Person möglicherweise einige wichtige Kenntnisse über die Funktionen von C # /. NET fehlen, die andere Entwickler verwenden, wenn nicht täglich, zumindest häufig.

   Siehe auch die Antwort von Jerry Coffin, die eine detailliertere Analyse dieser Art von Fragen enthält.

4. (Durchschnitt) "Welches ist schneller, SSD oder RAM?"

   Dies kann nützlich sein und zeigt, ob die Person über ausreichende Hardware-Kenntnisse verfügt. Dennoch sollte ein Kandidat, der diese Frage nicht beantworten kann, nicht abgelehnt werden.

5. (Durchschnitt) "Wie werden Stack und Queue implementiert?"

   Dies ist die Art von Fragen, über die Sie sprechen. Sie sind theoretisch, vielleicht sogar zu theoretisch, aber zu wissen, was unter der Haube passiert, kann helfen, besseren Code zu schreiben.

   Ich würde einen Kandidaten, der diese Frage nicht beantworten kann, nicht ablehnen, aber genauer prüfen, ob er das Zeug wirklich kennt, indem er zum Beispiel eine verwandte, aber weniger theoretische Frage stellt:

6. (Gut) "Wie kann man ohne Rekursion durch einen Baum gehen?"

   Wenn der Kandidat diese Frage beantwortet und über FILO / FIFO und die Vor- und Nachteile der Verwendung eines Stapels im Vergleich zu einer Rekursion für das Durchlaufen von Bäumen spricht, spielt es keine Rolle, dass er die vorherige Frage nicht beantworten konnte.

   Das Stellen dieser Frage ist auch eine gute Möglichkeit, Kandidaten zu erkennen, die jahrelang ihren CS-Abschluss gemacht haben, aber keine Erfahrung vor Ort haben.

Wie stelle ich gute technische Fragen?

kojiros kommentar ist interessant und verdient eine längere antwort:

Manchmal müssen Sie jemanden einstellen, der mehr über ein Thema wissen soll als Sie. Daher sind Sie per Definition für das Vorstellungsgespräch nicht qualifiziert. Sie können nicht einmal aus dem gleichen Grund zuverlässig Hilfe bekommen, wenn Sie das Interview führen. Das Beste, was Sie tun können, ist zu versuchen, Fragen zu stellen, die darauf beruhen, wo immer Ihr Verständnis mit der Problemdomäne in Konflikt gerät, und hoffen, dass Sie Glück haben.

Gute Fragen zu finden, kann eine Herausforderung sein, insbesondere wenn Sie Ihren ersten Entwickler einstellen oder wenn Sie einen Entwickler einstellen, von dem erwartet wird, dass er erfahrener ist als alle Entwickler, die tatsächlich im Unternehmen arbeiten.

Hier sind drei Tipps, die helfen können:

1. Finden Sie einen Freund / Kollegen, von dem Sie glauben, dass er geschickt ist, und bitten Sie ihn , die Überprüfungen durchzuführen. Dies erfordert viel Vertrauen, kann aber Ihrem Unternehmen sehr zugute kommen.

2. Finden Sie einen Berater, den Sie für kompetent halten, und bitten Sie ihn, Sie zu unterstützen oder den technischen Teil des Interviews zu übernehmen.

3. Geben Sie "Interviewfragen" in Google ein. Es funktioniert ziemlich gut und erklärt normalerweise mögliche Antworten. Beispiel:

   • Python : Diese zehn Fragen scheinen ziemlich gut zu sein. Sie sind vielleicht ein bisschen einfach, helfen aber dabei, 95% der Kandidaten herauszufiltern, die Sie sowieso nicht einstellen möchten.

   • SQL von Dave Pinal, wie immer exzellent.

   • C # : ein bisschen zu einfach, aber sie werden wieder 95% Kandidaten filtern,

   • JavaScript : Die Fragen sind offener, was bei technischen Fragen möglicherweise nicht der Fall ist, wenn Sie möchten, dass das Interview kurz ist und Sie mehr Zeit für offene, nicht technische Fragen haben. Die Liste hilft weiterhin dabei, die Kandidaten, die grundlegende Konzepte in JavaScript nicht verstehen, einfach zu filtern.

   Der Nachteil dieses Ansatzes ist, dass der Kandidat dieselbe Technik anwenden kann, um für das Interview zu trainieren. Wenn er jede Frage der ersten Website überprüft, die er in Google gefunden hat, kann er gut punkten, ohne tatsächlich über die erforderlichen Fähigkeiten zu verfügen.

^{¹ Es gibt einige Entwickler, die nicht erklären können, was ein B-Tree ist (abgesehen von der "Datenstruktur"), aber dennoch in der Lage sind, sich korrekt zu entwickeln.}

Aufgrund meiner Erfahrung in meiner Firma, in der ich viele Interviews geführt habe, besteht eine gute Chance, dass die befragte Person keine Ahnung hat, wie das richtig gemacht werden soll. Also haben sie eine Reihe von technischen Fragen vorbereitet und daraus eine Punktzahl errechnet und daraus Ihren Lebenslauf gemacht. Dies hat jedoch viele Nachteile und sollte aus den folgenden Gründen nicht durchgeführt werden:

• Sie fragen Punktwissen. Wenn der Programmierer in diesem Bereich noch nie etwas getan hat, ist er / sie möglicherweise immer noch ein ausgezeichneter Mitarbeiter, kennt diese bestimmte Antwort jedoch nicht. Im Gegensatz dazu: Wenn sich jemand auf das Interview vorbereitet und die Antwort auf diese spezielle Frage im Internet gefunden hat, erhalten Sie die richtige Antwort, aber diese Person hat möglicherweise überhaupt keine Ahnung vom eigentlichen Thema.

• Die Leute sind nervös in Vorstellungsgesprächen. Das Gehirn hat diese großartige Funktion, um viele übergeordnete Bereiche (wie die Logik) in Panik zu schließen, was bedeutet: Wenn Sie nervös sind, liefern Sie möglicherweise nicht die Qualität der Antworten, die Sie in einer alltäglichen Situation erwarten würden. Manche Menschen können mit einer stressigen Situation wie einem Interview umgehen, viele nicht.

• Mit einer einzigen, korrekten Antwort testen Sie die Fähigkeit dieser Person, diese bestimmte Antwort zu finden. Dies ist eine von vielen Fähigkeiten, die ein IT-Mitarbeiter benötigt, aber nicht die einzige, die erforderlich ist. Daher sollten eine oder zwei dieser Fragen ausreichen, um diesen Wissensbereich zu testen, und dann sollten andere Fähigkeiten abgefragt werden. Ein Interview, das nur Fragen zur Problemlösung enthält, testet dieselbe Fähigkeit immer wieder.

Was sind gute Programmieraufgaben Fragen?

Diese berühmten "Kannst du ein kurzes Programm schreiben" -Fragen haben das große Problem, dass die meisten Programmierer keine einzige Codezeile schreiben können, ohne dass ihnen ihre IDE hilft. Aber das ist in alltäglichen Arbeitssituationen überhaupt kein Problem, denn dem Programmierer hilft immer seine IDE. Wenn Sie also Dinge wie "Find the error", "Write 50 lines of code that do ..." oder sogar einfache Fragen stellen, müssen Sie berücksichtigen, dass der Bewerber nicht über seine Tools (IDE, Google) verfügt.

Ich kann zum Beispiel im Grunde jede Frage innerhalb einer Minute beantworten, wenn mir Google hilft, aber ohne Internetverbindung bin ich scheinbar hilflos. Ich nenne das ausgelagertes Gedächtnis, und anstatt mich zu behindern, hilft es mir sehr, mich auf das zu konzentrieren, was wirklich wichtig ist - die zugrunde liegenden Mechanismen zu verstehen -, weil alles andere nachgeschlagen werden kann. Fragen Sie mich jedoch nicht nach Details von zufälligen APIs, da ich diese nicht kenne. Dafür habe ich Google.

Das heißt, eine gute Programmieraufgabe sollte sich nicht darauf konzentrieren, APIs oder spezielle Codierungsfähigkeiten zu kennen, es sei denn, dies ist eine unabdingbare Voraussetzung für den Job. Wissen kann erlangt werden, daher ist es besser herauszufinden, wie gut diese Person darin ist, Wissen zu erlangen, als zu fragen, was sie bereits weiß.

Eine gute Frage für eine Programmieraufgabe sollte kurz, einfach, in jeder Sprache mit nur wenigen Codezeilen codierbar und - insbesondere - möglichst aussagekräftig sein, wie die Person arbeitet und Antworten findet. Beispiel:

"Schreiben Sie eine Funktion in der Sprache Ihrer Wahl, die ein Array von Ganzzahlen aufnimmt und sie so neu anordnet, dass die erste Ganzzahl nach der letzten folgt, und alle anderen verschieben sich entsprechend."

Der erste, den ein Bewerber an dieser Stelle fragen sollte, lautet: "Entschuldigung ... können Sie bitte die Aufgabe erläutern?". Weil keinem Programmierer eine klare Beschreibung gegeben wurde, was er jemals tun soll. Darauf folgt die Erklärung, dass der fragliche Code den Inhalt des Arrays nach links verschieben soll, wobei der Überlauf nach rechts hinzugefügt wird.

Diese Aufgabe ist so einfach, dass jeder, der ein Programmierlevel absolviert hat, in der Lage sein sollte, richtig zu antworten. Dies berücksichtigt, dass der Programmierer ohne seine Werkzeuge arbeiten muss und dass nervöses Denken die Fähigkeit zum logischen Denken einschränkt. Es zeigt Ihnen jedoch immer noch, wie Menschen Probleme lösen, einfach aus der Art und Weise, in der die Frage formuliert ist, und aus der Art und Weise, wie Menschen sie angehen, einfach, weil eine Linksverschiebung gegen den gemeinsamen „von links nach rechts“ -Instinkt verstößt und die Menschen zum Nachdenken zwingt eine Sekunde.

Es gibt viele mögliche Antworten auf diese Frage. Ein genauer Blick auf die Art und Weise, wie der Code entwickelt wird, ist daher der wichtige Teil, nicht wenn die Lösung tatsächlich funktionieren würde. Prüft der Antragsteller auf null? Wie wird der Überlauf gespeichert? Wird eine Schleife oder ein Mem-Set verwendet? Wie überprüft der Antragsteller die Richtigkeit des Codes? Diese eine einfache Frage sagt Ihnen eine ganze Biographie darüber, wie diese Person arbeitet.

Was sind gute Allgemeinwissenfragen?

Gute Fragen sind einfach zu beantworten, lassen eine Vielzahl von Antworten zu (so genannte offene Fragen) und ermöglichen es Ihnen, in der kurzen Zeit, die Sie haben, so viel wie möglich über den Bewerber zu lernen.

Beispiele:

(Frage an einen C ++ - Programmierer): "Welche anderen Sprachen neben C ++ kennen Sie?"

Dies ist eine Einstiegsfrage, die dem Antragsteller eine faire Chance bietet, in diesem Moment aus dem Ruder zu gehen, wenn er nichts über das gestellte Thema weiß. Ein "Nein" ist an dieser Stelle besser, als ihn / sie mit mehreren weiteren Fragen zu quälen, die er / sie alle beantworten muss: "Entschuldigung, darüber weiß ich nichts."

Außerdem erfahren Sie zunächst, welche anderen Sprachen diese Person kennt. Außerdem erfahren Sie, wie interessiert diese Person daran ist, einen umfassenderen Einblick in die Programmierwelt zu erhalten, oder ob Sie jemanden haben, der nur über eine einzige Sprache (und damit über Funktionen / Techniken) verfügt ) Aussicht.

(Als nächstes, sagen wir, er kennt Java): Was sind aus Ihrer Sicht die drei wichtigsten Unterschiede zwischen C ++ und Java? "

Dies ist eine offene Frage, die viele Antworten zulässt, sodass der Bewerber gute Chancen hat, mindestens drei Antworten zu finden. Nach der (persönlichen Meinung) Top 3 zu fragen, schränkt nicht nur die möglichen Antworten ein, sondern zwingt den Bewerber auch, nach Priorität zu sortieren. Trotzdem ist es einfach zu beantworten (oder sollte es auch sein).

Dies ist eine einfache Frage, die viele fundierte Kenntnisse über verschiedene Programmiersprachen testet. Wie tief ist das Wissen über diese Themen wirklich? Aus diesen Antworten können Sie viel über das Wissen und das tatsächliche Verständnis der zugrunde liegenden Mechanismen von Programmiersprachen erzählen. Wie viel diese Person mit den schmutzigen Details ausgegeben hat oder ob sie nur eine Person ist, die verschiedene API-Funktionen miteinander verknüpft, ohne wirklich zu wissen, was unter diesen passiert.

Dieses Konzept von Einstiegsfragen, gefolgt von einfachen vertieften Wissensfragen, kann auch für die meisten anderen Themen verwendet werden. Immer in diesem Schema: Rettungsfrage, Überprüfungsfrage, eingehende Frage. Ein weiteres Beispiel (aus einem Java-Interview):

1. "Wie beurteilen Sie Ihre Erfahrung mit Multithread-Entwicklung?"
2. "Bitte geben Sie an, was Ihrer Meinung nach die drei wichtigsten Aspekte sind, die bei der Entwicklung einer Multithread-Anwendung zu berücksichtigen sind."
3. "Bitte nennen Sie drei Klassen aus der Java-API, die Ihnen bei der Entwicklung dieser Anwendungen helfen können, und geben Sie eine kurze Beschreibung, wofür sie verwendet werden."

Diese drei Fragen sagen mehr als jede andere technische Frage aus, was der Bewerber über diese Themen wirklich weiß, und sind unter Berücksichtigung von Sachkenntnis und Stressniveau fair zu beantworten.

Wenn Sie das nächste Mal 20 Codierungsfragen hintereinander stellen, wissen Sie, dass er oder sie im Grunde keine Ahnung hat, wie er oder sie jemanden richtig interviewen soll. ;)

Warnung: Dies ist eine Art Kommentar zu @ MainMas Antwort, aber 1) es ist zu lang, um in einen Kommentar zu passen, und 2) ich denke, es fügt konstruktiven Fragen eine etwas andere Perspektive hinzu, so dass es eine echte Antwort für sich ist .

In seiner Antwort klassifiziert @MainMa "Was sind die neuen Funktionen von .NET 4.5?" als "gute" frage.

Ich bin anderer Ansicht. Wie er es ausdrückt, würde ich sagen, dass dies bestenfalls eine mittelmäßige Frage ist. Eine gute Frage wäre eher: "Wie unterscheidet sich der Code, den Sie heute schreiben, von dem Code, den Sie vor N Jahren geschrieben haben?" (für einen Wert von N, der unter den im Lebenslauf angegebenen Jahren liegt, vorzugsweise zwischen 3 und 5).

Wie er es formuliert hat, geht es um das Auswendiglernen. Hat dieser Kandidat die Featureliste vollständig auswendig gelernt? Von Rechts wegen sollte derjenige der Gewinner sein, der die Liste von Microsoft am genauesten zitiert.

Was Sie interessieren sollten, ist seine Programmierung. Wie hat sich das auf seinen Code ausgewirkt? Welche dieser Funktionen hat er wirklich nutzen ? Noch wichtiger ist, zeigt er ein gutes Urteil darüber, wann welche neuen Funktionen verwendet werden sollen und wann ältere Funktionen vollkommen ausreichen?

Nur in der Lage zu sein, "LINQ" zu sagen, sagt Ihnen so gut wie nichts Nützliches über den Kandidaten aus. In der Lage zu sein zu sagen: "LINQ hat dazu beigetragen, meinen Code viel kompakter und lesbarer zu machen, da ich die Konzepte X, Y und Z sauber und direkt ausdrücken kann, wo ich zuvor durch die folgenden flammenden Rahmen springen musste, um diese Dinge zu tun." (oder ähnliches) sagt Ihnen viel über den Kandidaten, welche Art von Code er schreibt, sein Urteilsvermögen, seine Flexibilität und so weiter. Es gibt Ihnen auch viel mehr Gelegenheit, Fragen zu beantworten, wie diese Person über Probleme denkt, Code schreibt, über Code denkt und so weiter. Schließlich erhalten Sie eine bessere Vorstellung davon, ob es sich um einen Kandidaten handelt, der wirklich N Jahre Erfahrung hat, oder um jemanden, der ein Jahr Erfahrung hat und N-mal wiederholt wurde.

Zusammenfassung: Es ist nutzlos, eine Feature-Liste von vor ein paar Jahren zitieren zu können. Sie gibt nur wenig Auskunft über den Kandidaten, der wahrscheinlich wirklich von Nutzen ist. Die Fortschritte des Kandidaten als Programmierer dürften von größerem Interesse sein, deshalb ist es viel besser, direkter danach zu fragen.

Die Realität ist, dass die meisten der täglichen Aufgaben, die die Entwickler in ihrem Berufsleben erledigen, trivial sind. Das bedeutet, dass einige der Fragen, mit denen Sie in einem Vorstellungsgespräch konfrontiert werden, in der Realität möglicherweise nie auf Sie zutreffen, aber das bedeutet nicht, dass es keinen Grund gibt, diese Fragen zu stellen.

Nehmen wir an, es gibt eine offene Position in Ihrem Unternehmen und Sie interviewen derzeit Leute. Sie haben bereits 20-30 Entwickler in der Warteschlange. Wie würden Sie den besten Kandidaten für diese Position auswählen? Angenommen, die schwierigste Aufgabe, die sie in diesem Job erledigen müssen, besteht darin, eine Datei aus dem Dateisystem zu öffnen, die Daten zeilenweise zu lesen, geringfügig zu ändern und wieder in die ursprüngliche Datei zu kopieren.

Wirst du sie fragen, wie du eine Datei öffnen würdest? Ich wette, Sie können keinen wirklich großen Unterschied zwischen den Antworten sehen. Sie müssen also eine Lösung finden, um zwischen den Entwicklern zu unterscheiden, die nur wissen, wie man eine Datei öffnet, und den Entwicklern, die eine wirklich schlechte Echtzeitanwendung entwickeln können. Auch wenn Sie nicht möchten, dass sie eine solche Anwendung erstellen, möchten Sie dennoch den besten Kandidaten einstellen.

Wie bei allen anderen Dingen in unserem Leben gibt es einige Punkte, bei denen Sie erkennen, dass Sie mehr lernen müssen. Wenn Sie nicht wissen, was eine verknüpfte Liste ist, bedeutet das für mich als Programmierer buchstäblich, dass Sie den Punkt in Ihrem Berufsleben noch nicht wirklich erreicht haben, um das Gefühl zu haben, dass Sie diese spezielle Sache lernen müssen. Warum? Ganz einfach, weil Sie noch nie an einem Projekt teilgenommen haben, das groß genug war, um Ihre Fähigkeiten auf diesem Niveau zu verbessern. Wenn Sie ein Einsteiger sind, können Sie sagen, dass ich für diesen speziellen Job keine wirklichen Berufserfahrungen habe. Wenn Sie dies jedoch wissen, bedeutet dies, dass Sie selbst motiviert genug sind, um sich selbst überdurchschnittlich zu verbessern mindestens.

Die für diese Aufgaben erforderlichen Fähigkeiten sind selten wichtig. Die Fähigkeiten, die in der Herangehensweise an die Beantwortung der Frage und im anschließenden Dialog gezeigt werden, sind der springende Punkt.

Wenn ich Entwickler interviewe, suche ich nach (a) klugen (b) Dingen, die erledigt werden (c), die passen. Es ist ein grundlegendes technisches Wissen erforderlich, um jede Rolle zu besetzen, die mit der Bereitschaft verbunden ist, Neues zu lernen und zu erwerben Kompetenzen. Im Interview geht es darum, diese Kästchen anzukreuzen.

Ich bevorzuge es, von einem Bewerber geschriebenen Code zu lesen. Ich mag keine Fragen zu Doseninterviews, aber sie bieten etwas, worüber man ohne Code sprechen kann. Ich frage lieber nach RAII oder IOC oder nach der Implementierung von IDisposable als nach list und collection, aber alles wird funktionieren , solange es technisch genug ist .

Die schlimmste Angst des Interviewers ist es, jemanden einzustellen, der eigentlich nicht viel über Codierung weiß. Sie müssen über etwas anderes als Berufserfahrung sprechen, um die Fälschungen auszumerzen.

Diese Fragen dienen zum Herausfiltern von Personen, die nicht programmieren können. Manchmal bewerben sich Leute, die nicht programmieren können, aber viel Wissenswertes wissen, um Entwicklungsjobs, und es ist zu zeitaufwändig, sie etwas Nützliches und Nicht-Triviales schreiben zu lassen, um ein Interview zu führen.

Ich kann sehen, dass diese Fähigkeiten in Jobs eingesetzt werden können, in denen Sie Compiler und Treiber schreiben und am Betriebssystemkern arbeiten müssen. Wo sonst werden diese Fähigkeiten eingesetzt?

Wie wäre es mit dem Schreiben von Suchmaschinen, Webservern, Webbrowsern, Textverarbeitungsprogrammen, Tabellenkalkulationsprogrammen, Bildbearbeitungsprogrammen, Zeichenprogrammen, Datenbankservern, Bioinformatikprogrammen, Handelsprogrammen, Spielen, Physiksimulatoren usw.?

Ich gebe Ihnen die Gewissheit, dass die meisten Software-Jobs das Abrufen von Daten aus einer Datenbank, das Aufrufen auf einem Bildschirm, das Bearbeiten, das Abschaben vom Bildschirm und das Zurücksetzen in eine Datenbank umfassen. Selbst dann kann es jedoch vorkommen, dass Sie auf eine Anwendung stoßen, bei der die Einschränkungen durch die integrierten Funktionen einer Plattform nicht erfüllt werden können. An diesem Punkt können Sie entweder aufgeben oder in Ihre Toolbox mit Algorithmen und Datenstrukturen greifen und versuchen, das Problem zu lösen.

Theoretische Objekte werden der Einfachheit halber verwendet, da Sie wissen sollen, worum es bei einer durchschnittlichen Baum- / Grafik- / Listenimplementierung geht, und daher wissen müssen, wie ein zufälliges Durchquerungsproblem zu lösen ist. Bei diesen Fragen handelt es sich jedoch überhaupt nicht um die theoretischen Objekte.

Es geht darum, mit abstrahierten Modellen arbeiten zu können, ein abstraktes Problem zu verstehen und es mit einem Algorithmus jeglicher Art zu lösen. Das ist reine Entwicklungskunst, es zählt also. Dies ist der Grund, warum diese Frage sinnvoll ist und nicht, weil sie genaue Situationen im wirklichen Leben sein sollen.