it-swarm-eu.dev

Tricky Logic Puzzles - Sind sie wirklich nützlich bei der Beurteilung von Programmierkenntnissen?

Im letzten Interview, an dem ich teilnahm, wurde ich gebeten, ein Rätsel zu lösen, bei dem von mir erwartet wurde, dass ich genau zwei Liter Wasser mit zwei Eimern mit Kapazitäten messe - bla und bla Liter. Ich konnte das Rätsel in der vorgegebenen Zeit (~ 5 Minuten) nicht lösen.

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

Ich habe mich immer seltsam gefühlt über diese Art von Rätseln, die normalerweise beim Programmieren von Vorstellungsgesprächen gestellt werden. Ich verstehe nicht, was, wenn überhaupt, die Verbindung zwischen solchen Rätseln und der Programmierung ist. Welche Fähigkeiten wollen Interviewer mit solchen Rätseln genau einschätzen?

89
missingfaktor

Einige Leute fragen sie, um Ihre Fähigkeiten und Ihren Lösungsansatz einzuschätzen. Persönlich glaube ich nicht, dass solche Rätsel einen genauen Indikator liefern. In der "realen Welt" haben Sie mehr als fünf Minuten Zeit, um herauszufinden, ob Sie beispielsweise mit einem Bin Packing vs einem Back Pack Problem zu tun haben. Anfänglich ist es manchmal leicht, das vorliegende Problem falsch zu verstehen, bis Sie gerade dabei sind, die falsche Lösung anzuwenden. 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 "Nun, ein Programmierer sollte in der Lage sein ..." zu denken, weil es nicht berücksichtigt, dass Leute ängstlich werden, wenn sie getroffen werden mit etwas Unerwartetem in einer Umgebung, die bereits stressig ist. 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, dass Ihr Leben vorbei wäre wenn du es nicht getan hast. Möchten Sie an einem Ort arbeiten, an dem 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 Champion-Sudoku-Löser sein? Ich bin mir sicher, dass es viele gibt, aber es ist keine Voraussetzung 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 hat muss geben, angesichts ihres Fachgebiets. Zu beweisen, dass Sie so schlau 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 Verständnis dafür hat , was Sie tatsächlich tun , entschuldigen Sie sich, dass Sie gehen auf die Toilette und nie zurückkehren.

97
Tim Post

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

Zu dieser Zeit versuchte Microsoft, viele technische, aber nicht programmierbare Positionen zu besetzen: technische Redakteure, Tester, Telefonsupport usw. Dies waren damals keine alltäglichen Aufgaben, und Leute mit tatsächlicher Erfahrung 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 schulen. 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 hatten. Programmierer hatten im Allgemeinen Probleme mit der Programmierung von Whiteboards, obwohl ihnen möglicherweise auch beim Mittag- oder Abendessen Rätsel gestellt wurden.

Diese Fragen sollten niemals bestanden werden. Sie sollten der Beginn eines Gesprächs darüber sein, wie Sie das Problem angehen würden und wie Sie über Probleme nachdachten, die Sie noch nie zuvor gesehen hatten. Der einzig sichere Weg, um "zu scheitern", bestand darin, sich zu weigern, das Problem zu lösen. Zu dieser 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. Anscheinend reicht die Praxis, Denksportaufgaben und Rätsel von Kandidaten für Programmierjobs zu stellen, 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 Reaktion war Schock und Bestürzung: Es gab nur ein paar Dutzend "professionelle Programmierer" auf der ganzen Welt. Es wurden verschiedene Ansätze ausprobiert: Eignungsprüfungen für abstrakte Programmierer, Rekrutierung von Mathematikern als Programmierer, Rekrutierung von Schachspielern und Kreuzworträtsellösern sowie Ü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 die Chance, die Rekruten zu identifizieren, die als Programmierer besonders erfolgreich waren.

56

Sind sie nützlich? Nein nicht wirklich. Sie waren einmal so häufig bei Microsoft, dass sie sogar als "Microsoft-Fragen" bezeichnet wurden, und es wurden Bücher darüber geschrieben. dieses ist eigentlich eine ziemlich gute Lektüre.

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

Aus diesen Gründen werden sie bei Microsoft selten mehr gefragt. Es ist weitaus besser, Codierungsfragen zu stellen 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, wenn dieser versucht, das Problem anzugehen. 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 zu finden, die sie haben, aber zumindest auf vernünftige Weise. 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 ...

49
Steve

Vielleicht möchten Sie das Buch lesen Wie würden Sie den Fuji bewegen? . Es geht in die Argumentation ein, dass viele Leute Rätsel bei Interviews verwenden, und meine Meinung ist, dass es eine Kombination aus Frachtkultverhalten ist ( "Microsoft macht es und wenn wir so erfolgreich sein wollen wie Sie sind es, dann tun wir besser das, was sie tun ") und Brüderlichkeitsschikanen (", meine Güte! Ich musste diese Fragen beantworten und du glaubst es besser Der nächste muss sie beantworten! ").

Die Geschichte dieser Fragen als Interviewpraxis begann mit William Shockley in den 1950er Jahren. Sie waren eine ziemlich häufige Frage aus dem Silicon Valley, die Interviewer stellten, weil andere Interviewer dies taten (und vielleicht wussten sie etwas, das dieser Interviewer nicht wusste?). Shockley beabsichtigte sie als Intelligenztest, und die Frage mit den 2 Eimern war auf einem der ursprünglichen Stanford Binet IQ-Test im Jahr 1916.

Möglicherweise möchten die Personen, die das Interview führen, tatsächlich sehen, wie Sie nach Antworten suchen, sodass es unmöglich ist, Fragen zu berechnen, z. B. wie viele Zapfsäulen in Ihrer Stadt vorhanden sind. Diese Art von Problemen sind Fermi-Probleme . Zwei interessante Blog-Beiträge von Jeff zu diesem Thema sind Die schwierigste Interview-Puzzle-Frage aller Zeiten und Wie gut sind Sie als Schätzer? 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. Sofern Sie nicht für ein Unternehmen arbeiten, das Rätsel herstellt, gehören sie zusammen mit "Was ist Ihre größte Schwäche" (beantworten Sie die Wahrheit und beenden Sie Ihr Interview auf schlechte Weise) oder "Warum" zum Staubhaufen der Geschichte sind Schachtabdeckungen rund "(nicht alle von ihnen sind).

26
Tangurena

Andere haben Antworten geliefert, die ich als eine Frage von muss bewertet habe. 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 Vorstellungsgespräch für Programmierer aussehen kann.

Im ersten guten Interview, an das ich mich erinnere, haben wir viel und ohne Eile geredet. Zunächst eine Stunde lang am Telefon über objektorientiertes Design und die Vor- und Nachteile der Implementierung in C++. Dann sprach ich vor Ort 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 ein Mittagessen mit den Leuten beinhaltete, die mich interviewten. Im Nachhinein ging es darum, ob ich produktiv in das passen würde, was sie bereits taten.

Seitdem waren die guten Interviews alle lang, ein bis zwei Stunden Gespräche über Softwareentwicklung. Es gab keine Fragen zur Problemlösung, keine Rätsel und keine Codierungsprobleme.

Wenn ich heute jemanden für einen Programmierjob interviewen würde, würde ich so weitermachen. Ich würde um Meinungen zu einer Vielzahl von Themen bitten und die Tiefe beiseite lassen:

  1. Welche Programmiersprachen bevorzugen Sie? Warum?
  2. Wie gehe ich mit der Ausnahmebehandlung um?
  3. Sind die Vorteile von Layered Design nicht ein Mythos?
  4. Ist kontinuierliche Integration nicht eine Belastung für die Effizienz?
  5. Wer auch immer einen Code geschrieben hat, sollte ihn besitzen, oder?
  6. Was machst du, um in den "Fluss" zu kommen?.
  7. Wie sollen gemeldete Mängel in einen Projektplan aufgenommen werden?
  8. ...

Dies 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 frühere reale Probleme erwähnt werden, die als Gesprächsthema aufgetreten sind (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 n jahrelanger Erfahrung, die sich auf 1 Jahr Erfahrung wiederholt n mal. 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.

17
Apalala

Sie können nützlich sein, um Problemlösung Fähigkeiten zu bewerten, was natürlich einer der Schlüsselaspekte der Programmierung ist.

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

In diesem Fall erwarte ich, 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?.

13
sdg

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 über Nichtantworten wie "Ein Entwickler braucht diese Fähigkeiten" hinausgeht. Sie sind Zeitverschwendung und ein Indikator dafür, dass der Interviewer kein kompetenter Interviewer ist.

8
Rein Henrichs

Das ist das Grundprinzip der alten Schule, dass man grundlegende logische Fähigkeiten haben muss; alles andere kann gelehrt werden. Das stimmt aber nicht ganz. Das Lesen von Boolesche Logik, Bedingungen und Schleifen, ist nicht dasselbe wie das Lösen eines Logik-Puzzles.

In den Tagen der prozeduralen Sprachen war es jedoch wahrscheinlich richtig, dass jemand, der diese Probleme lösen konnte, eine höhere Neigung hatte, jedes Problem in Bezug auf Schalter anwenden zu können. Meiner Meinung nach erfordert OO/Functional Programming eine technische Denkweise, die ganz anders ist (wenn auch nicht widersprüchlich).

Persönlich bin ich mir nicht sicher, ob ich einen Job bei einem Unternehmen haben möchte, das Logik immer noch für wichtiger hält als praktische Programmierkenntnisse.

Haftungsausschluss: Ich bin sehr gut in logischen Rätseln und hätte ohne dieses Rationalle wahrscheinlich nicht mit dieser Arbeit angefangen.

5
pdr

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

Sie könnten argumentieren, wie gut ein solches Puzzle Ihre Fähigkeit darstellt, dies zu tun. Ich sehe nicht den Vorteil, eine Rätselfrage zu stellen, anstatt nur ein echtes Programmierproblem zu stellen.

2
Steven Jeuris

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

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

Deshalb ist es wichtig, über Fähigkeiten zur Problemlösung zu verfügen, und warum es getestet wird.

Trotzdem bin ich mir nicht sicher, ob das Lösen kniffliger Rätsel der beste Weg ist, jemanden zu beurteilen.

1
Xavier T.

Zwei Punkte:

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

    Was? Sie müssen nicht superintelligent sein? Nein, tust du nicht. Niemand ist wirklich klug genug, um Computer zu programmieren. Um ein durchschnittliches Programm vollständig zu verstehen, ist eine nahezu unbegrenzte Fähigkeit erforderlich, Details aufzunehmen und die gleiche Fähigkeit, sie alle gleichzeitig zu verstehen. Die Art und Weise, wie Sie Ihre Intelligenz fokussieren, ist wichtiger als die Menge an Intelligenz, die Sie haben. Wie in Kapitel 5 erwähnt, hielt Edsger Dijkstra 1972 beim Turing Award Lecture einen Artikel mit dem Titel „The Humble Programmer“. Er argumentierte, dass der größte Teil der Programmierung ein Versuch ist, die streng begrenzte Größe unserer Schädel zu kompensieren. Die Leute, die am besten programmieren können, sind die Leute, die erkennen, wie klein ihr Gehirn ist. Sie sind demütig. Die Leute, die am schlechtesten programmieren können, sind die Leute, die sich weigern, die Tatsache zu akzeptieren, dass ihr Gehirn der Aufgabe nicht gewachsen ist. Ihr Ego hält sie davon ab, großartige Programmierer zu sein. Je mehr Sie lernen, Ihr kleines Gehirn zu kompensieren, desto besser werden Sie ein Programmierer sein. Je bescheidener Sie sind, desto schneller werden Sie sich verbessern.

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

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

1
klm123

Rätsel in Interviews lassen sich in zwei Kategorien einteilen: "logische Rätsel" (wie das, nach dem Sie gefragt wurden) und "anders denken". Die Kategorie "anders denken" (ich bin mir nicht sicher, ob sie auch als seitliche Rätsel bezeichnet werden?) Ist normalerweise wie folgt: Wie viele Blätter enthält dieser Baum? oder Wie viele Schneider gibt es in Ihrer Stadt?

Ich bin mit "logischen Rätseln" einverstanden, weil sie höchstens eine oder vielleicht zwei Lösungen haben und durch einfache Logik erreicht werden können. Und ich glaube, dass logische Rätsel bis zu einem gewissen Grad gut sind, weil der Prozess, der zur Lösung dieser Rätsel erforderlich ist, genau so ist, wie ein Programmierer im wirklichen Leben denken muss.

Die Art "anders denken" nervt mich ohne Ende, weil sie Sie dazu zwingen, Annahmen zu treffen und dann einige Berechnungen basierend auf den Annahmen durchzuführen. Einfach ausgedrückt, wenn Ihr Interviewer Ihrer Logik zustimmt, aber nicht Ihren Annahmen oder umgekehrt, haben Sie verloren. Der Interviewer hat zu viel Raum, 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-Serien oder Palindrome zu codieren.

Das Problem mit Rätseln ist, dass die nicht so guten Programmierer wissen, dass sie die Interviewer beeindrucken können, wenn sie im Internet nach Lösungen für solche gängigen Rätsel suchen. Nur sehr wenige Menschen werden ehrlich genug sein, um zu sagen, dass sie die Lösung bereits kennen.

1
DPD

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

  1. Eine frühere Lösung kennen. Im Film ... Die Hard with a Vengeance ... erkläre mir das ...? Dies ist ein Beispiel dafür, wie man eine Lösung für den Fall kennt, in dem die Blahs 4,3 bzw. 5 sind. Einige Leute werden in der Lage sein, ihr internes Wissen über eine frühere Lösung schnell zu nutzen und es bei Bedarf anzupassen. 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 wäre der Fall, wenn Sie keine frühere Lösung kennen oder das Problem nicht als etwas erkennen, das man als diophantinische Gleichung modellieren könnte. Die Frage ist also, wie schnell Sie das Gegebene nutzen und auf kreative Weise eine Lösung für das Problem finden können. Außerdem können Sie erklären, warum das, was Sie haben, eine gültige Lösung für das Problem ist.

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

0
JB King

Es ist kein besonders kniffliges Problem. Es sind nur drei Schritte erforderlich, und bei jedem Schritt stehen nur zwei Optionen zur Verfügung. Ich wäre überrascht, wenn einer meiner Kollegen es nicht in kürzester Zeit lösen könnte. Wir stellen solche Probleme nicht in Interviews vor, aber ich denke, es ist 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.

0
kevin cline

Sie müssen sich daran erinnern, dass es keine Möglichkeit gibt, mit absoluter Sicherheit zu wissen, dass jemand gut in einem Job sein wird. Insbesondere ein CS-Job, da viele Herausforderungen, die der Job möglicherweise bereithält, nicht vorhergesagt werden können.

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

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

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

Ja, Sie könnten Interview-Rätsel studieren, aber ich denke, Sie werden sich verbrannt fühlen, wenn das gegebene Rätsel nicht mit dem übereinstimmt, das Sie studieren ... und solange Sie sich die Rätsel und ihre Lösungen nicht merken, studieren Sie vielleicht die Rätsel selbst werden Sie auf echte Weise zu einer klügeren Person machen, wie es jede echte Bildung tun sollte.

0
8steve8