Knifflige logische Rätsel - Sind sie wirklich hilfreich bei der Beurteilung von Programmierkenntnissen? [geschlossen]

88

In dem letzten Interview, an dem ich teilgenommen habe, wurde ich gebeten, ein Rätsel zu lösen, bei dem genau ein Liter Wasser gemessen werden sollte, vorausgesetzt, zwei Eimer mit einem Fassungsvermögen - ein Liter Wasser und ein Liter Wasser. Ich konnte das Rätsel in der vorgegebenen Zeit (~ 5 Minuten) nicht lösen.

Der Interviewer war etwas enttäuscht und sagte, dass ein Programmierer "diese" Fähigkeiten haben muss. Ich habe nicht verstanden, über welche Fähigkeiten er sprach.

Ich war schon immer fremd in Bezug auf diese Art von Rätseln, die normalerweise bei der Programmierung von Vorstellungsgesprächen gestellt werden. Ich verstehe nicht, was, wenn überhaupt, die Verbindung zwischen solchen Rätseln und Programmierung ist. Welche Fähigkeiten wollen Interviewer mit solchen Rätseln genau einschätzen?

missingfaktor
quelle
20
sieht aus wie Die Hard 3 Krug Puzzle youtube.com/watch?v=lZ64IR2bz5o
JF Dion
64
Ein großes Problem bei solchen Fragen ist, dass sie oft messen, ob der Antragsteller dieses Problem schon einmal gesehen hat, und "hat viele logische Rätsel gesehen" ist kein wirklich gutes Einstellungskriterium.
David Thornley
37
Dies sind nur Voodoo-Einstellungspraktiken. Andere Leute stellen diese Fragen, damit sie das Gefühl haben, dass sie es sollen. Sie wissen, dass die Nichtbeantwortung der Frage "schlecht" und die Beantwortung "gut" ist, aber sie können Ihnen nicht sagen, warum nicht Antworten wie "ein Entwickler diese Fähigkeiten benötigt". Sie sind Zeitverschwendung und ein Indikator dafür, dass der Interviewer kein kompetenter Interviewer ist.
Rein Henrichs
5
Ja, diese Tests sind nicht so gut. Aber es ist schön, wenn ein Programmierer zumindest ein geringes Interesse an diesen Rätseln hat. Mein Rat: Studieren Sie einfach die Rätsel, bestehen Sie das Interview und entscheiden Sie, ob Sie teilnehmen möchten.
Job
10
Ich würde dies während eines Interviews in der Hoffnung fragen, den Kandidaten zu finden, der fragt: "WTF hat dies mit Programmierung zu tun?" und machen ihnen ein Angebot, bevor sie den Parkplatz verlassen.
JeffO

Antworten:

97

Einige Leute fragen sie, um festzustellen, ob Sie in der Lage sind, Probleme zu lösen. Persönlich glaube ich nicht, dass solche Rätsel einen genauen Indikator liefern. In der „realen Welt“, haben Sie mehr als fünf Minuten , um herauszufinden , ob Ihr mit einem Umgang bin Verpackung vs einem Tornister Problem, zum Beispiel. Anfänglich ist es manchmal leicht, das vorliegende Problem zu missverstehen, bis Sie die falsche Lösung anwenden. Das passiert Menschen mit 1, 5, 10 oder sogar 20 Jahren Erfahrung.

Die besten Interview-Rätsel sind diejenigen, bei denen Sie sich an einen Computer setzen, um ein Problem in dem Bereich zu lösen, in dem Sie Fachwissen beanspruchen. Ich mag auch nicht das Denken "Nun, ein Programmierer sollte in der Lage sein ...", weil es nicht berücksichtigt, dass Menschen Angst bekommen, wenn sie in einer ohnehin schon stressigen Umgebung mit etwas Unerwartetem getroffen werden. Sicher, Sie könnten das lösen, wenn Sie Zeit hätten, darüber nachzudenken. Und vielleicht könnten Sie es schneller lösen, wenn Sie erkennen würden, dass Ihr Leben vorbei wäre, wenn Sie es nicht tun. Möchten Sie irgendwo arbeiten, wo Ihr Leben zu Ende ist, wenn Sie Probleme nicht in fünf Minuten lösen können ? Wirst du gefeuert, wenn du nicht kannst ?

Sollten alle großen Programmierer auch Sudoku-Meister sein? Ich bin mir sicher, dass es eine Menge gibt, aber es ist keine Grundvoraussetzung für Kompetenz.

Ich sage nicht, dass Sie nicht darauf getestet werden sollten , wie Sie Probleme angehen, aber die Tests sollten Spaß machen und das "Beste" einladen, das der Bewerber angesichts seines Fachwissens zu geben hat. Zu beweisen, dass Sie so klug sind wie eine Figur, die Bruce Willis porträtiert, erscheint irgendwie sinnlos, wenn man bedenkt, dass die Produzenten eine hübsche Summe ausgegeben haben, um diese Szene genau richtig zu machen.

Mit anderen Worten, wenn Sie feststellen, dass Sie von jemandem interviewt werden, der wenig Ahnung davon hat, was Sie tatsächlich tun , entschuldigen Sie sich, dass Sie auf die Toilette gehen und niemals zurückkehren.

Tim Post
quelle
8
Dies ist die Perspektive, die alle Interviewer haben müssen. Lösen Sie ein Problem in Ihrer Domain und Ihre Bemerkungen zu Stress und unerwarteten Fragen sind gleichrangig!
Chris
20
+1 für In der "realen Welt" haben Sie mehr als fünf Minuten Zeit, um herauszufinden , nette Antwort!
Ameisen
7
Ich mag
10
Ich würde mich so sehr anstrengen excuse yourself to go to the restroom and never return!
Florian Margaine
Ja, ich versuche immer, dass sich der Bewerber so wohl wie möglich fühlt, damit ich herausfinden kann, wie gut diese Person für den Job sein wird. Fragen nach "Ihren Stärken" anstelle von "Was mögen Sie?" und dumme Rätsel anstelle von Kodierungsphilosophien geben mir keinen Hinweis darauf, wie gut diese Person für den Job ist.
Winkbrace
56

Microsoft begann diese Fragen in den frühen 1980er Jahren zu verwenden. Als Microsoft bemerkenswert erfolgreich wurde, begannen andere Unternehmen, sie zu kopieren, aber einige wichtige Punkte gingen bei der Übersetzung verloren.

Zu der Zeit versuchte Microsoft, eine Menge technischer, aber nicht programmierbarer Positionen zu besetzen: Technische Redakteure, Tester, telefonischer Support usw. Diese Jobs waren früher nicht üblich, und Leute mit tatsächlichen Erfahrungen in diesen Bereichen waren schwer zu besetzen finden. Als Alternative dachte Microsoft, sie könnten wirklich kluge, kluge und flexible Leute einstellen und sie im Job ausbilden. Da diese Leute keinen Programmierhintergrund hatten, war es sinnlos, ihnen im Interview Programmierfragen zu stellen. Die Rätsel wurden ausgewählt, um Leute zu identifizieren, die klug waren und außergewöhnlich gute analytische Fähigkeiten besaßen. Programmierer bekamen im Allgemeinen Probleme mit der Programmierung von Whiteboards, obwohl ihnen beim Mittag- oder Abendessen möglicherweise auch Rätsel gestellt wurden.

Diese Fragen sollten niemals bestanden-nicht bestanden werden. Sie sollten den Beginn eines Gesprächs darüber darstellen, wie Sie das Problem angehen und wie Sie über Probleme nachdenken, die Sie noch nie zuvor gesehen hatten. Der einzig sichere Weg zum "Scheitern" war, sich zu weigern, das Problem zu lösen. Zu der Zeit war dies eine neuartige Strategie, und Sie konnten die Fragen nicht einfach bei Google nachschlagen.

Bearbeiten:

Irgendwann nach dem Schreiben dieser Antwort las ich The Computer Boys Take Over , eine Geschichte des institutionellen Rechnens in den 1950er und 1960er Jahren. Offensichtlich reicht die Praxis, Rätsel und Denksportaufgaben zu lösen, bis in die 1950er-Jahre zurück. Die USA versuchten, ihr Luftverteidigungssystem zu computerisieren, und IBM schätzte, dass sie mehrere tausend Programmierer benötigen würden, um die Arbeit zu erledigen. Die Antwort war Schock und Bestürzung: Es gab nur ein paar Dutzend "professioneller Programmierer" auf der ganzen Welt. Es wurden verschiedene Ansätze ausprobiert: abstrakte Programmierfähigkeitstests, Rekrutierung von Mathematikern als Programmierer, Rekrutierung von Schachspielern und Kreuzworträtsellösern und Überprüfung von Bewerbern mit Rätseln und Denksportaufgaben.

Es gelang ihnen schließlich, genügend Programmierer zu rekrutieren, um das Projekt abzuschließen, aber die Schlussfolgerung war, dass keine der Screening-Methoden besser war als der Zufall, die Rekruten zu identifizieren, die als Programmierer besonders erfolgreich waren.

Charles E. Grant
quelle
49

Sind sie nützlich Nein nicht wirklich. Früher waren sie bei Microsoft so verbreitet, dass sie sogar als "Microsoft-Fragen" bezeichnet wurden, und es wurden Bücher darüber geschrieben. Diese sind eigentlich ziemlich gut zu lesen.

Es gibt 2 Probleme mit ihnen. Erstens, wenn der Bewerber recherchiert (und das Buch liest), kennt er sie trotzdem und zweitens, selbst wenn er sie lösen kann, wie zeigt das, dass das ein guter Entwickler / Test / PM sein wird.

Aus diesen Gründen werden sie bei Microsoft nur noch selten gefragt. Es ist weitaus besser, Codierungsfragen oder Fragen zur Problemlösung zu stellen, für die keine "Trick" -Antwort erforderlich ist. Mit anderen Worten, Sie müssen Fragen stellen, mit denen Sie die Fähigkeiten und das Verhalten des Bewerbers untersuchen können, während dieser versucht, das Problem zu lösen. Als Interviewer möchte ich, dass er Fragen stellt, Lösungen findet und dann zurückverfolgt, wenn er es herausfindet ein Problem, vielleicht nicht einmal eine Lösung in der Zeit, die sie haben, aber zumindest auf vernünftige Weise zu gehen. Das spiegelt die Arbeit im wirklichen Leben wider. Ich musste noch nie 3 Pints ​​mit 2 Eimern und einem Huhn messen (oder was auch immer die Frage war).

Trotzdem wurden mir in meiner Zeit einige Trickfragen gestellt, und ich betrachte mich jetzt als Experte für den Transport von Hühnern und Füchsen in kleinen Booten und die Berechnung der Lebensdauer einer Fliege, die in einem Zug lebt. Ich musste diese Informationen nie verwenden, aber wer weiß, vielleicht eines Tages ...

Steve Haigh
quelle
26

Vielleicht möchten Sie das Buch lesen. Wie würden Sie den Fuji bewegen? . Es wird argumentiert, dass viele Leute beim Interview Rätsel verwenden, und meiner Meinung nach handelt es sich um eine Kombination aus Frachtkult-Verhalten ( "Microsoft macht es, und wenn wir so erfolgreich sein wollen, wie sie es sind, dann tun wir besser, was sie tun do " ) und fraternity hazing ( " by gosh !, ich musste diese Fragen beantworten und du glaubst besser, der nächste Typ muss sie beantworten! " ).

Die Geschichte dieser Fragen als Interviewpraxis begann mit William Shockley in den 1950er Jahren. Es handelte sich um eine ziemlich häufige Frage, die Interviewer im Silicon Valley stellten, weil andere Interviewer es taten (und wussten sie vielleicht etwas, das dieser Interviewer nicht wusste?). Shockley beabsichtigte sie als Intelligenztest, und die Frage mit den 2 Eimern bezog sich auf einen der ursprünglichen Stanford Binet IQ-Tests im Jahr 1916.

Möglicherweise möchten die Befragten wissen, wie Sie nach Antworten suchen, sodass sie keine Möglichkeit haben, Fragen zu berechnen, z. B. wie viele Zapfsäulen in Ihrer Stadt vorhanden sind. Diese Art von Problemen sind Fermi-Probleme . Zwei interessante Blogposts von Jeff zu diesem Thema sind The Hardest Interview Puzzle Question Ever und How Good an Estimator are You? Teil III .

Persönlich habe ich eine geringe Meinung zu solchen Fragen, da sie im Allgemeinen von Interviewern verwendet werden, die nicht wissen, was sie tun oder wie sie nach Entwicklern suchen sollen. Wenn Sie nicht für eine Firma arbeiten, die Rätsel macht, gehören sie zusammen mit "Was ist Ihre größte Schwäche?" (Beantworten Sie die Wahrheit und beenden Sie Ihr Interview auf eine schlechte Art und Weise) oder "Warum" auf den Müllhaufen der Geschichte sind Kanaldeckel rund "(nicht alle).

Tangurena
quelle
3
+1, konnte nicht mehr mit dem letzten Absatz übereinstimmen!
Fehlender Faktor
+1 für den Fermi-Problemlink: Es ist interessant zu sehen, ob jemand in der Lage ist, Schätzungen mit angemessenen Fehlergrenzen vorzunehmen. Sie könnten genauso gut eine Vertrauensspanne für "Wie viele Länder gibt es?" Ich denke jedoch, dass es für die Entwicklung nicht wirklich wesentlich ist, zu wissen, wie man so denkt, obwohl dies bewundernswert und nützlich ist. Es ist ein bisschen wie ein Entwickler, der sich mit Kalkül oder Statistik auskennt: Es ist gut, sagt aber mehr über ihren Hintergrund aus als darüber, ob sie gut im Job sind.
Poolie
17

Andere haben Antworten gegeben , die ich als eine Angelegenheit von upvoted haben muss . Der Grund, warum ich eine andere Antwort schreibe, ist, dass das, was ich sagen möchte, wahrscheinlich nicht in einen Kommentar passt und dass etwas darüber gesagt werden muss, wie ein gutes Programmier-Vorstellungsgespräch aussehen kann.

In dem ersten guten Interview, an das ich mich erinnere, haben wir viel geredet, ohne es eilig zu haben. Zunächst eine Stunde telefonisch über objektorientiertes Design und die Vor- und Nachteile der Implementierung in C ++. Vor Ort sprach ich dann mit mehreren Personen über ihre Softwareentwicklungspraktiken, Integration, Tests, Versionskontrolle und Konfigurationsmanagement, über Teams und Verantwortlichkeiten, über Technologie und über Design. Es war ein ganztägiges Interview, das das Mittagessen mit den Leuten beinhaltete, die mich interviewt haben. Im Nachhinein ging es darum, ob ich produktiv in das hineinpassen würde, was sie bereits taten.

Seitdem waren die guten Interviews alle lang, ein bis zweistündige Gespräche über Softwareentwicklung. Es gab keine Fragen zur Problemlösung, keine Rätsel und keine Herausforderungen beim Programmieren.

Wenn ich heute jemanden für einen Programmierjob interviewen würde, würde ich in etwa so vorgehen. Ich fordere Meinungen zu einer Vielzahl von Themen an und lasse die Tiefe beiseite:

  1. Welche Programmiersprachen bevorzugen Sie? Warum?
  2. Wie nähere ich mich der Ausnahmebehandlung?
  3. Sind die Vorteile von Layered Design nicht ein Mythos?
  4. Ist kontinuierliche Integration nicht eine Belastung für die Effizienz?
  5. Wem auch immer ein Stück Code geschrieben wurde, der sollte es besitzen, oder?
  6. Was machst du, um in "Flow" zu kommen?
  7. Wie sollen gemeldete Mängel in einen Projektplan aufgenommen werden?
  8. ...

Das sind Fragen mit mehr als einer Antwort, und es geht um Themen, zu denen ein Softwareentwickler eine fundierte Meinung haben sollte. Ich stimme voll und ganz den Antworten zu, in denen die bisherigen realen Probleme als Gesprächsthema erwähnt werden (nicht als Fragen).

Die wissenschaftlicheren Studien über effektive Softwareentwicklung seit Peopleware besagen, dass die besten Programmierer diejenigen sind, die die Dynamik der Softwareentwicklung verstehen, auch wenn sie nicht die höchsten IQs haben. Ich würde lieber einen Anfänger nehmen, der lernbegierig ist, als jemanden mit njahrelanger Erfahrung, die sich auf ein 1Jahr wiederholter Erfahrungen beschränkt n. Meine persönliche Vorliebe gilt Kandidaten, die dazu neigen, über den Tellerrand hinaus zu denken und gleichzeitig zu wissen, wie sie in die aktuelle (meine) Box passen.

Apalala
quelle
Hervorragende Antwort. Offtopic: Ihre Beispielfrage # 3 macht mich neugierig. Ich bin daran interessiert, mehr über Ihre Meinung zu Layered Design zu erfahren.
Fehlender Faktor
2
@missingfaktor # 3 ist, wie bereits erwähnt, eine trickreiche Frage, um ein Gespräch über schnell erledigte und richtig erledigte Dinge zu entfachen. Nr. 4 und Nr. 5 sind gleich. # 7 ist wahrscheinlich die schwierigste und nur für Führungsrollen geeignet.
Apalala
1
@missingfaktor Ich habe wieder eine andere Frage beantwortet. Dieser Wikipedia-Artikel, die verwandten und die externen Links bieten eine Fülle von Informationen darüber, warum die Trennung von Bedenken für den Entwurf und die Konstruktion eines komplexen Systems von größter Bedeutung ist: en.wikipedia.org/wiki/Modularity
Apalala
Macht Sinn. Danke vielmals! :-) Wieder eine hervorragende Antwort. Macht viele gute Punkte, die in anderen Antworten hier nicht erwähnt werden.
Fehlender Faktor
Persönlich würde ich auch eine Frage zum Werkzeug hinzufügen. Menschen, die sich für die von ihnen verwendeten Tools interessieren, sind in der Regel bessere Programmierer. Als Emacs-Benutzer ziehe ich einen Vim-Benutzer einem vor, der nur mit den Schultern zuckt und sich nicht darum kümmert.
Singletoned
13

Sie können bei der Beurteilung von Fähigkeiten zur Problemlösung hilfreich sein , was natürlich einer der Schlüsselaspekte der Programmierung ist.

Als Interviewer vieler Menschen im Laufe der Jahre stelle ich normalerweise keine Fragen vom Typ Gotcha , wie Sie sie zu beschreiben scheinen, aber ich frage vielleicht etwas und frage: "Wie würden Sie das lösen?".

Ich erwarte in diesem Fall, dass Sie Ihre Herangehensweise an das Problem artikulieren. Welche anderen Daten würden Sie versuchen zu sammeln? Wie würden Sie Ihre Hypothesen usw. testen?

sdg
quelle
1
Ich habe das Gleiche getan, als ich unzählige Leute interviewt habe. Bei der Frage geht es darum zu beobachten, wie sie auf die Lösung hinarbeiten, und nicht unbedingt, ob sie die richtige Antwort erhalten. Sie können gute Programmierer ziemlich schnell erkennen, indem Sie diesen Prozess beobachten.
Dave Wise
2
@ Dave, versuch es mit mir. Wenn ich solche Rätsel löse, nehme ich normalerweise ein Blatt Papier, zeichne Diagramme oder Tabellen oder streiche Figuren aus, die Schauspieler darstellen, oder schreibe Zahlen, die irgendwie mit dem Prozess der Lösung des Problems in meinem Kopf zusammenhängen. Ich mache das alles in völliger Stille, manchmal unterbrochen von ununterscheidbarem Murmeln. Also, bin ich ein guter Programmierer?
P Shved
4
Heisenberg würde nicht genehmigen. Eine Person ist möglicherweise in der Lage, eine gute Lösung für ein Problem zu finden, kann jedoch den internen Prozess, den sie verwendet hat, nicht gut kommunizieren. Wenn Sie sie bitten, dies zu tun, testen Sie nicht nur ihre Fähigkeiten unter Umständen, unter denen sie normalerweise nicht arbeiten, sondern sind auch voreingenommen in der Fähigkeit oder Unfähigkeit, einer anderen Person zu erklären, wie ihr Denkprozess funktioniert. Sie wissen vielleicht nicht einmal, wie es selbst funktioniert.
Jason
4
Einige Leute glauben, dass jeder extrovertiert sein sollte, nur weil sie extrovertiert sind. Mein derzeitiges Team besteht aus Introvertierten und ist mit Abstand das beste Team, mit dem ich je zusammengearbeitet habe.
Dunk
2
@Charles Was ich sagte, ist, dass introvertierte Menschen im Allgemeinen das Problem überdenken müssen, bevor sie eine Lösung finden können, die sie zufriedenstellt, und dann in der Lage sind, es anderen zu erklären. Das ist ganz anders als "Unfähig zu kommunizieren". Extrovertierte müssen sich im Allgemeinen durch das Lösen von Problemen unterhalten. Das Originalplakat erwartet eindeutig einen extrovertierten Stil zur Lösung von Problemen.
Dunk
8

Dies sind nur Voodoo-Einstellungsmethoden. Andere Leute stellen diese Fragen, damit sie das Gefühl haben, dass sie es sollen. Sie wissen, dass die Nichtbeantwortung der Frage "schlecht" und die Beantwortung "gut" ist, aber sie können Ihnen nicht sagen, warum nicht Antworten wie "ein Entwickler diese Fähigkeiten benötigt". Sie sind Zeitverschwendung und ein Indikator dafür, dass der Interviewer kein kompetenter Interviewer ist.

Rein Henrichs
quelle
5

Das ist das Old-Skool-Rational, dass Sie grundlegende logische Fähigkeiten haben müssen; alles andere kann gelehrt werden. Das stimmt aber nicht ganz. Das Lesen von Boolescher Logik , Bedingungen und Schleifen ist nicht dasselbe wie das Lösen eines logischen Puzzles .

Das heißt, in den Tagen der Verfahrenssprachen war es wahrscheinlich wahr, dass jemand, der diese Probleme lösen konnte, eine höhere Neigung hatte, ein Problem in Bezug auf Schalter anwenden zu können. Meines Erachtens erfordert OO / Functional Programming jedoch eine ganz andere (wenn auch nicht widersprüchliche) technische Denkweise.

Persönlich bin ich mir nicht sicher, ob ich einen Job bei einem Unternehmen haben möchte, bei dem Logik noch wichtiger war als praktische Programmierkenntnisse.

Haftungsausschluss: Ich bin sehr gut in logischen Rätseln und hätte ohne diese Rationalität wahrscheinlich nicht in dieser Branche angefangen.

pdr
quelle
2

Der Interviewer muss sich auf Problemlösungs- und Logikfähigkeiten bezogen haben, die Teil der täglichen Arbeit eines Programmierers sind. Wenn Sie ein Problem erhalten, müssen Sie es analysieren, unterteilen und eine Lösung dafür schreiben können, indem Sie den optimalsten Ansatz verwenden.

Sie könnten sich darüber streiten, wie gut ein solches Puzzle Ihre Fähigkeit darstellt, dies zu tun. Ich sehe nicht den Vorteil, eine Puzzle-Frage zu stellen, anstatt nur ein echtes Programmierproblem zu stellen.

Steven Jeuris
quelle
1

Beim Programmieren geht es nicht darum, Codezeilen zu schreiben, sondern Probleme für und von anderen Personen (Kunden, Benutzer usw.) zu lösen.

Es kommt vor, dass die Lösung für Programmierer die Form eines Programms hat.

Aus diesem Grund ist es wichtig, über Fähigkeiten zur Problemlösung zu verfügen, und warum diese getestet werden.

Abgesehen davon bin ich mir nicht sicher, ob das Lösen von kniffligen Rätseln die beste Möglichkeit ist, jemanden zu bewerten.

Xavier T.
quelle
1

Rätsel in Interviews lassen sich in zwei Kategorien unterteilen: "Logische Rätsel" (wie die, nach denen Sie gefragt wurden) und "Anders denken". Die Kategorie "Anders denken" (ich bin mir nicht sicher, ob sie auch als Seitenpuzzles bezeichnet werden) lautet normalerweise wie folgt: Wie viele Blätter gibt es in diesem Baum? oder Wie viele Schneider gibt es in Ihrer Stadt?

Ich bin in Ordnung mit "Logischen Rätseln", weil sie höchstens eine oder vielleicht zwei Lösungen haben und durch einfache Logik gefunden werden können. Und ich glaube, dass logische Rätsel in gewissem Maße gut sind, weil der Prozess, der zu ihrer Lösung benötigt wird, genau so ist, wie ein Programmierer es im wirklichen Leben denken muss.

Die Art "anders denken" nervt mich ohne Ende, weil sie Sie dazu zwingt, Annahmen zu treffen und dann einige Berechnungen basierend auf den Annahmen durchzuführen. Einfach ausgedrückt, wenn Ihr Interviewer mit Ihrer Logik einverstanden ist, aber nicht mit Ihren Annahmen, oder umgekehrt, haben Sie verloren. Der Interviewer hat zu viel Platz, um mit Ihrer Lösung nicht einverstanden zu sein.

Wenn ich Interviews mache, stelle ich keine logischen Rätsel. Grund: Die meisten Kandidaten, auch diejenigen mit 3-4 Jahren Erfahrung, scheitern oder geben auf, wenn ich sie auffordere, einfache Lehrbuchprobleme wie Fibonacci-Reihen oder Palindrome zu kodieren.

Das Problem mit Rätseln ist, dass die nicht so guten Programmierer wissen, dass sie Interviewer beeindrucken können, wenn sie nur nach Lösungen für solche häufigen Rätsel im Netz suchen. Sehr wenige Leute werden ehrlich genug sein, um zu sagen, dass sie die Lösung bereits kennen.

DPD
quelle
Meinen Sie mit Palindromen das sehr schwierige Problem, den längsten Palindrom-Teilstring in einer Eingabezeichenfolge in linearer Zeit zu finden? :-)
b_jonas
1

Zwei Punkte:

  1. Das Programmieren unterscheidet sich hauptsächlich vom Lösen von Rätseln. Es wird von Steve McConnell bei "Code Complete" erklärt:

    Was? Sie müssen nicht superintelligent sein? Nein, tust du nicht. Niemand ist wirklich schlau genug, um Computer zu programmieren. Um ein durchschnittliches Programm vollständig zu verstehen, ist eine nahezu unbegrenzte Fähigkeit erforderlich, Details aufzunehmen und sie alle gleichzeitig zu verstehen. Die Art und Weise, wie Sie Ihre Intelligenz fokussieren, ist wichtiger als Ihre Intelligenz. Wie in Kapitel 5 erwähnt, lieferte Edsger Dijkstra 1972 auf der Turing Award Lecture einen Artikel mit dem Titel „The Humble Programmer“ (Der bescheidene Programmierer). Er argumentierte, dass der größte Teil der Programmierung ein Versuch sei, die streng begrenzte Größe unserer Schädel auszugleichen. Die Leute, die am besten programmieren, sind die Leute, die erkennen, wie klein ihr Gehirn ist. Sie sind bescheiden. Die Leute, die am schlechtesten programmieren, sind die Leute, die sich weigern, die Tatsache zu akzeptieren, dass ihr Verstand der Aufgabe nicht gewachsen ist. Ihr Ego hindert sie daran, großartige Programmierer zu sein. Je mehr duLernen Sie, Ihr kleines Gehirn zu kompensieren, je besser Sie ein Programmierer sind . Je demütiger du bist, desto schneller wirst du dich verbessern.

  2. Solche Rätsel können während des Interviews nützlich sein, aber nur wenn der Interviewer auf den Prozess schaut , ergibt sich nichts.

Aber meiner Meinung nach sollten die Rätsel im Idealfall komplizierter und programmierbezogener sein (wie ein kleines zweistündiges Projekt). Die Sache ist, dass Interviewer Menschen sind und keine perfekten "Interviewfähigkeiten" haben.

klm123
quelle
Könnten Sie sagen, was mit meiner Antwort falsch ist, wenn Sie -1 wählen, bitte.
klm123
1
+1, weil es eine gute Antwort ist. Ich hätte es sogar anders bewertet, nur um eine ungeklärte Gegenstimme zu streichen.
Fehlender Faktor
0

Es gibt verschiedene Möglichkeiten, solche Probleme zu untersuchen:

  1. Kenntnis einer früheren Lösung. Im Film ... Stirb hart mit Rache ... erkläre mir das ...? Dies ist ein Beispiel, um eine Lösung für den Fall zu finden, dass die Blahs 4,3 und 5 sind. Einige Personen können schnell auf ihr internes Wissen über eine frühere Lösung zugreifen und es bei Bedarf anpassen. Dies ist normalerweise das, was ein Interviewer meiner Meinung nach erwarten würde, was eine gute Idee sein kann oder nicht.

  2. Kreative Improvisationsfähigkeiten. Dies ist der Fall, wenn Sie keine vorherige Lösung kennen oder das Problem gar nicht als etwas erkennen, das man als diophantinische Gleichung modellieren könnte. Die Frage ist also, wie schnell Sie das Gegebene verwenden und auf kreative Weise eine Lösung für das Problem finden können, und warum das, was Sie haben, eine gültige Lösung für das Problem ist.

Beides könnte sein, was einen zufriedenstellend über die Frage hinaus bringt, obwohl es in jedem Fall auch einen kleinen Test der eigenen Kommunikationsfähigkeiten gibt, da man auch versuchen könnte, zu antworten: "Ist das wirklich relevant für die Position, die ich bin? Wann wurden diese Fähigkeiten zuletzt eingesetzt? " das kann zu einem interessanten dialog führen, wenn der interviewer darüber spricht, was genau er sehen möchte, dass ein alternativer ansatz hier möglicherweise als effektiver angesehen werden könnte.

JB King
quelle
0

Es ist kein besonders schwieriges Problem. Es sind nur drei Schritte erforderlich, und bei jedem Schritt stehen nur zwei Auswahlmöglichkeiten zur Verfügung. Es würde mich wundern, wenn einer meiner Kollegen es nicht in sehr kurzer Zeit lösen könnte. In Interviews stellen wir solche Probleme nicht vor, aber ich halte es für vernünftig, solche Fragen zu stellen. Sie sind sicherlich nützlicher als detaillierte Fragen zur Syntax oder zu Bibliotheken.

OTOH, ich denke, dass Programmierprobleme nützlicher sind.

Kevin Cline
quelle
0

Sie müssen bedenken, dass es keine Möglichkeit gibt, mit absoluter Sicherheit zu wissen, dass jemand in einem Job gut ist. Insbesondere ein CS-Job kann nicht vorhergesagt werden, da viele Herausforderungen, die der Job für Sie bereithält.

Der potenzielle Arbeitgeber muss also Ihre zukünftige Leistung erraten.

Abschlüsse, Empfehlungen und GPAs können mit Zeit / Mühe und Social Engineering erhalten werden, Arbeitserfahrung kann verschönert und / oder falsch sein, und standardisierte Tests sind offen gesagt zu grundlegend, um allzu aussagekräftig für Fähigkeiten zu sein. Der Lebenslauf gibt also möglicherweise einen Hinweis auf den Aufwand / das Engagement in Ihrer Geschichte, aber nichts davon spricht für Ihre tatsächliche Fähigkeit, schwierige Probleme zu lösen, die in der Welt der Informatik auftauchen. Ich kann mir keinen besseren Weg vorstellen, diese Art von Fähigkeit vorherzusagen, als ein paar gute Logik-, Mathematik- und CSy-Rätsel.

Denken Sie daran, es ist ein Ratespiel, und die Realität sieht so aus, als würde jeder von uns lieber jemanden einstellen, der in der Lage ist, diese Rätsel zu lösen, als einen, der es nicht kann.

Ja, Sie könnten Interview-Rätsel lernen, aber ich denke, Sie werden sich verbrannt fühlen, wenn das gegebene Rätsel nicht mit dem übereinstimmt, das Sie lernen ... und solange Sie sich die Rätsel und ihre Lösungen nicht merken, studieren Sie vielleicht die Rätsel selbst werden Sie in einer realen Weise zu einer intelligenteren Person machen, wie es bei jeder realen Ausbildung der Fall sein sollte.

8steve8
quelle
3
Ich weiß nichts über Sie, aber wenn ich ein Interview gebe, beschreibe ich lieber ein aktuelles schweres Problem, das kürzlich in unserer Unternehmenswelt aufgetreten ist, und schaue, wie der Befragte es angehen würde. Witzigerweise hatten wir in letzter Zeit keine Kunden, die uns beauftragten, Wassermengen mit zwei Eimern zu messen. Das meiste, was wir tun, ist Computerprogrammierung.
Carson63000
@ Carson63000 nicht, dass ein echtes Problem, auf das Ihr Unternehmen gestoßen ist, eine schlechte Idee wäre, aber aufgrund der Besonderheiten des realen Problems und der Implementierung der Lösung oft zeitaufwändig. Das ist der Grund, warum Rätsel mit Eimern großartig sind, weil die Eintrittskosten so gering sind und direkt zu den interessanten Aspekten gelangen.
8steve8
Ich stelle mir vor, Sie können die Analogie zwischen dem Bucket-Problem und dem Schreiben von Software zur Erledigung einer Aufgabe mit einer minimalen Anzahl von Disc-Suchvorgängen oder http-Anforderungen erkennen.
8steve8