トリッキーなロジックパズル-プログラミングスキルの評価に本当に役立つのでしょうか。
私が参加した最後のインタビューで、私はパズルを解くように求められました。そこでは、容量が2つのバケット（それぞれblahとblah liters）を与えられた場合、正確にblah litersの水を測定することが期待されました。パズルを所定の時間（〜5分）で解くことができませんでした。
インタビュアーは少しがっかりしており、プログラマーには「これらの」スキルが必要だと述べました。私は彼が話しているスキルを理解できませんでした。
私は通常、就職の面接で尋ねられるこの種のパズルについていつも不思議に思っています。そのようなパズルとプログラミングとの関係が何であるか、私はまったく理解していません。面接担当者は、このようなパズルでどのようなスキルを評価するつもりですか？
一部の人々はあなたの問題を解決するためのあなたの能力とアプローチを評価しようとして彼らに尋ねます。個人的には、そのようなパズルが正確な指標を提供するとは思いません。 「現実の世界」では、たとえば bin pack と back pack の問題を扱っているかどうかを判断するのに5分以上かかります。最初は、間違ったソリューションを適用するまで、手元にある問題を誤解しやすいことがあります。それは、1年、5年、10年、さらには20年の経験を持つ人々に起こります。
最高のインタビューの「パズル」は、専門知識を主張するドメインの問題を解決するためにコンピュータに座っているものです。私はまた、「まあ、プログラマーすべきであるができるはずです...」という考え方は、人々がヒットしたときに人々が不安になることを考慮に入れていないため、嫌いですすでにストレスの多い環境で予想外の何かが起こっています。確かに、あなたはそれについて考える時間があればそれを解決できますそして、おそらくあなたはあなたの人生が終わっていることに気づいたなら、あなたはそれをより早く解決できますあなたがしなかった場合。 5分で問題を解決できない場合、あなたの人生が終わる場所で働きたいですか？あなたができない場合に解雇されますか？
すべての優れたプログラマーは、数独のソルバーでもありますか？きっとたくさんあると思いますが、それはコンピテンシーの必要条件のようなものではありません。
私はあなたが問題に取り組む方法についてテストされるテストされないと言っているわけではありませんが、テストは面白く、申請者の「最高」を招待する必要があります彼らの専門分野を考えると、与える必要があります。ブルース・ウィリスが描写するキャラクターと同じくらい賢いことを証明することは、プロデューサーがかなりの金額を費やしてそのシーンをちょうど正しくすることを考えると、意味がないようです。
つまり、実際に何をしているのかをほとんど理解していない人からインタビューを受けていることに気付いた場合、失礼しますトイレに行き、二度と戻らないでください。
マイクロソフトはこれらの質問を1980年代初頭に使い始めました。マイクロソフトが著しく成功したため、他の企業がそれらをコピーし始めましたが、いくつかの重要な点が翻訳で失われました。
当時、Microsoftは、テクニカルライター、テスター、電話サポートなど、技術的だがプログラミング以外の多くの職務に就こうとしていました。これらは、当時の一般的な仕事ではなく、これらの分野で実際に経験を積んだ人は、見つける。別の方法として、マイクロソフトは本当に賢くて賢い、柔軟な人材を雇い、その仕事を訓練できると考えました。これらの人々はプログラミングの経歴を持っていなかったので、インタビューでプログラミングの質問をすることは無意味でした。なぞなぞは、賢く、非常に優れた分析スキルを持った人々を特定するために選ばれました。プログラマーは通常、ホワイトボードのプログラミング問題を抱えていましたが、昼食や夕食でなぞなぞを尋ねられることもあります。
これらの質問は、合否を表すものではありませんでした。それらは、問題への取り組み方や、これまで見たことのない問題についての考え方についての会話の始まりになることを目的としています。 「失敗」する唯一の確実な方法は、問題の解決を試みることを拒否することでした。当時、これは斬新な戦略であり、Googleで質問を検索することはできませんでした。
編集：
この回答を書いた後、私は The Computer Boys Take Over を読みました。これは、1950年代と1960年代の制度的コンピューティングの歴史です。どうやら、プログラミングの仕事のために頭の体操と候補者のなぞなぞを求める習慣は、1950年代までさかのぼります。米国はその防空システムをコンピューター化しようとしており、IBMはその作業を行うには数千人のプログラマーが必要になると見積もっていました。その反応は衝撃と驚きでした。全世界には数十人の「プロのプログラマー」しかいませんでした。いくつかのアプローチが試されました：抽象プログラミング適性テスト、プログラマーとしての数学者の採用、チェスプレーヤーとクロスワードパズルソルバーの採用、およびなぞなぞと頭の体操による応募者のスクリーニング。
彼らは最終的にプロジェクトを完了するのに十分なプログラマーを採用することに成功しましたが、結論として、どのスクリーニング方法も、プログラマーとして特に成功した新入社員を特定するチャンスよりも優れているということはありませんでした。
それらは役に立ちますか？いいえ、そうではありません。彼らはかつてMicrosoftで非常に一般的であり、「Microsoftの質問」と呼ばれることさえあり、それらについて書かれた本がありました これ は実際には非常に良い読み物です。
それらには2つの問題があります。第一に、申請者が調査（および本を読む）する場合、彼らはとにかくそれらを知っています。たとえ彼らがそれらを解決できても、それがどのようにして良い開発/テスト/ PMであることを示しているのかを解決できます。
これらの理由により、Microsoftでそれらが要求されることはほとんどありません。コーディングの質問、または「トリック」の答えを必要としない問題解決の質問をする方がはるかに良いです。言い換えると、志願者が問題に取り組み、取り組むときにスキルと行動を探求できる質問をする必要があります-面接官として、私は彼らに質問し、解決策を考え出して、彼らが理解したときに戻って欲しいと思います問題、おそらく彼らが持っている時間内に解決策を見つけられないかもしれませんが、少なくとも賢明な方法でそれについて取り組みます。それは実際の仕事を反映しています。私は2つのバケツと1つの鶏を使って3パイントを測定する必要がありませんでした（または質問が何であれ）。
とはいえ、私は自分の時間にいくつかのトリックの質問をされました、そして私は今では自分を小さなボートで鶏とキツネを輸送し、電車で生きるハエの寿命を計算する専門家と見なしています。私はこの情報を使う必要がなかったのですが、誰かが知っているかもしれませんが、たぶんある日……。
あなたは本を読みたいかもしれません 富士山をどのように動かしますか？ 。それは多くの人々がインタビューでなぞなぞを使用するという推論に入ります、そして私の意見はそれが貨物カルト行動の組み合わせであるということです（ "Microsoftはそれをします、そして私たちと同じくらい成功したいなら彼らはそうである、そして私達は彼らがすることをより良くする "）そして友愛のかすみ（"まあまあ！次の男はそれらに答える必要があります！」）。
インタビューの実践としてのこれらの質問の歴史は、1950年代に William Shockley で始まりました。それらは、他のインタビュアーがやっていたためにインタビュアーが尋ねたかなり一般的なシリコンバレーのインタビューの質問でした（そしておそらく、彼らはこのインタビュアーが知らないことを知っていましたか？）。ショックリーはそれらをインテリジェンステストとして意図しており、2つのバケットに関する質問は、1916年に元の Stanford Binet IQテスト の1つに関するものでした。
おそらく、面接をしている人々は実際にあなたが答えを探す方法を見たいと思っているので、あなたの街にあるガスポンプの数などの質問を計算することは不可能です。これらの種類の問題は Fermi Problems です。このテーマに関する Jeff からの2つの興味深いブログ投稿は これまでで最も難しいインタビューパズルの質問 と あなたはどれほど優れた評価者ですか？パートIII です。
個人的に、私はこれらの種類の質問は一般に、彼らが何をしているか、または開発者を探す方法を知らないインタビュアーによって使用されるので、低い意見です。あなたがパズル/なぞなぞを作る会社で働くつもりでない限り、彼らは「あなたの最大の弱点は何ですか」（これに真実に答えて、あなたは面接を間違った方法で終える）または「なぜマンホールの蓋は丸い」（すべてではない）。
他の人が私がmustの問題として賛成した回答を提供しています。別の答えを書く理由は、私が言いたいことがコメントに収まらない可能性があることと、優れたプログラミングの就職の面接がどのようになり得るかについて何かを言わなければならないためです。
私が覚えている最初の良いインタビューで、私たちは急いで、たくさん話しました。最初に1時間、電話で、オブジェクト指向設計と、C++での実装の賛否両論について説明します。次に、現場で、ソフトウェア開発の実践、統合、テスト、バージョン管理、構成管理、チームと責任、テクノロジーとデザインについて、何人かと話しました。私と面談した人たちとの昼食を含む終日の面接でした。振り返ってみると、彼らがすでにやっていることに生産的に適合するかどうかがすべてでした。
それ以来、優れたインタビューはすべて長く、ソフトウェア開発に関する1〜2時間の会話でした。問題解決の質問、パズル、コーディングの課題はありませんでした。
今日プログラミングの仕事のために誰かにインタビューするなら、私は好きに進みます。幅広いトピックについて意見を求め、深さは残しておきます。
- プログラミング言語の好みはどれですか？どうして？
- 例外処理へのアプローチ方法は？
- レイヤードデザインのメリットは神話ではありませんか？
- 継続的インテグレーションは効率に負担をかけませんか？
- コードを書いた人は誰でもそれを所有するべきですよね？
- 「フロー」に入るにはどうしますか。
- 報告された欠陥はどのようにプロジェクト計画に含めるべきですか？
- ...
これらは複数の答えを持つ質問であり、ソフトウェア開発者が十分な情報を得た上で意見を持つべきトピックに関するものです。私は、会話のトピックとして（質問としてではなく）経験された以前の実際の問題に言及する回答に心から同意します。
Peopleware 以降、効果的なソフトウェア開発に関するより科学的な研究によれば、最高のプログラマーは、最高のIQを持っていなくても、ソフトウェア開発のダイナミクスを理解しているプログラマーであると言われています。私はn年の経験を積んで1年の経験がn回繰り返されました。私の個人的な偏見は、枠の外で考える傾向がある候補者に向かっていると同時に、現在の（私の）枠に適合する方法を知っています。
これらは問題解決スキルの評価に役立ちます。これは、もちろんプログラミングの重要な側面の1つです。
長年にわたって多くの人々の面接担当者として、私は通常、あなたが説明しているようにgotchaタイプの質問をすることはほとんどありませんが、私は何か質問して、「どのように解決しますか？」 。」.
その場合の私の期待は、問題へのアプローチを明確に説明するのを聞くことです。他にどのようなデータを収集しようとしますか？仮説などをどのようにテストしますか？.
これらは単なるブードゥー教の雇用慣行です。他の人々がこれらの質問をするので、彼らは本来あるべきように感じます。彼らは、質問に答えないことは「悪い」、答えは「良い」ことを知っていますが、「開発者がこれらのスキルを必要としている」のような無回答以外の理由を説明することはできません。これらは時間の無駄であり、面接担当者が有能な面接担当者ではないことを示しています。
これが、基本的な論理スキルを身に付けなければならない昔ながらの理論です。他に何でも教えることができます。しかし、それは完全に真実ではありません。 ブール論理、条件とループを読むことは、論理パズルを解くことと同じではありません。
とはいえ、手続き型言語の時代には、これらの問題を解決できる人は、スイッチの問題を適用できる傾向がより高いというのはおそらく本当でした。しかし、私の考えでは、オブジェクト指向/関数型プログラミングにはエンジニアリングの考え方が必要ですが、これはまったく異なります（矛盾はしません）。
個人的には、実際のプログラミングスキルよりもロジックの方が重要だとまだ考えていた会社で仕事をしたいと思います。
免責事項：私はロジックパズルが非常に得意であり、おそらくこの理論的根拠がなければ、この一連の作業を開始することはできなかったでしょう。
インタビュアーは、プログラマーの日常の仕事の一部である問題解決と論理スキルに言及しているに違いありません。問題が発生した場合、最適なアプローチを使用して、問題を分析し、細分割し、解決策を記述できる必要があります。
そのようなパズルがこれを行うあなたの能力をどれほどよく表しているとあなたは主張することができます。現実のプログラミング問題を尋ねるだけでなく、パズルの質問をすることのメリットはわかりません。
プログラミングはコード行を書くことではなく、他の人（顧客、ユーザーなど）の問題を解決することです。
プログラマにとって、ソリューションはプログラムの形をとることがあります。
したがって、問題解決能力を備えることが重要であり、テストされる理由です。
そうは言っても、トリッキーなパズルを解くことが誰かを評価する最良の方法であるかどうかはわかりません。
2つのポイント：
プログラミングは主にパズルの解法とは異なります。それはスティーブ・マッコネルによって「コード完了」で正しく説明されています：
何？優秀である必要はありませんか？いいえ、必要ありません。コンピュータをプログラムするほど賢い人はいない。平均的なプログラムを完全に理解するには、詳細を吸収するためのほぼ無制限の能力と、それらを同時に理解するための同等の能力が必要です。インテリジェンスを集中させる方法は、インテリジェンスの量よりも重要です。第5章で述べたように、1972年のチューリング賞講演では、エズガーダイクストラが「謙虚なプログラマー」というタイトルの論文を発表しました。彼は、プログラミングのほとんどは、私たちの頭蓋骨の厳密に制限されたサイズを補うための試みであると主張しました。プログラミングが得意な人は、自分の脳がどれほど小さいかを理解している人です。彼らは謙虚です。プログラミングで最悪の人とは、自分の頭脳が課題に等しくないという事実を受け入れることを拒否する人です。彼らのエゴは、彼らが優れたプログラマであるのを妨げます。あなたが多ければ多いほどあなたの小さな頭脳を補うことを学ぶほど、あなたはより優れたプログラマーになります。謙虚さが増すほど、上達は速くなります。
このようなパズルは面接時に役立ちますが、面接担当者がProcessを調べた場合のみ、結果自体は得られません。
しかし、理想的には、パズルはもっと複雑で、プログラミングに関連している（小さな2時間のプロジェクトなど）と思います。面接官は人間であり、完璧な「面接スキル」を持っていないということです。
インタビューのパズルは2つのカテゴリに分類されます。「論理的なパズル」（あなたが尋ねられたパズルのような）と「違う考え方」のカテゴリです。考え方が違うと思います（これらはラテラルパズルとも呼ばれているのでしょうか？）通常、このタイプです：そのツリーには何枚の葉がありますか？またはあなたの街には何人の仕立て屋がいますか？
「論理パズル」は、せいぜい1つまたは2つのソリューションしかなく、簡単なロジックで到達できるので、私は問題ありません。そして、論理パズルはある程度までは良いと思います。なぜなら、それらを解決するために必要なプロセスは、コーダーが実際に考える必要がある方法と非常に同じだからです。
「別様に考える」という種類のバグは、仮定を立ててから、その仮定に基づいていくつかの計算を行うよう強制するため、終わりがありません。簡単に言えば、面接官があなたの論理に同意するがあなたの仮定に同意しない場合、またはその逆の場合、あなたは負けました。インタビュアーがあなたのソリューションに反対する余地が多すぎます。
私が面接をするとき、私は論理的なパズルを求めません。理由：ほとんどの候補者は、3〜4年の経験がある人でも、フィボナッチシリーズや回文などの単純な教科書の問題をコード化するように依頼すると失敗するか、あきらめます。
どちらの方法でもパズルの問題は、それほどよくないプログラマーが、ネット上でこのような一般的なパズルの解決策を探すだけで面接者に印象づけることができることを知っていることです。彼らがすでに解決策を知っていると言うほど十分に正直な人はほとんどいないでしょう。
このような問題を調べる方法はいくつかあります。
以前の解決策を知る。 映画の中で...復讐心を抱いて死ぬ...これを私に説明してください...？ それぞれが4、3および5である場合の解決策を知る例です。一部の人々は、過去のソリューションの内部知識をすばやく活用し、必要に応じてそれを適応させることができます。これは通常、面接担当者が期待するものであるか、そうでないかもしれないと期待するものです。
クリエイティブな即興スキル。これは、以前のソリューションがわからない場合や、問題をディオファントス方程式としてモデル化できるものとして認識している場合に当てはまります。したがって、問題は、与えられたものをどれだけ迅速に使用し、創造的な方法で問題の解決策を見つけることができるか、そしてあなたが持っているものが問題の有効な解決策である理由を説明することです。
どちらの場合も、満足のいく方法で質問をすり抜けてしまう可能性がありますが、それぞれの場合で、「これは本当に自分の立場に関連しているのですか？適用していますか？これらのスキルが最後に使用されたのはいつですか？」面接担当者が正確に見たいと思っていることについて話し合うと、興味深い対話になる可能性があります。ここでは、別のアプローチがより効果的であると考えられます。
これは特にトリッキーな問題ではありません。必要な手順は3つだけで、各手順には2つの選択肢しかありません。私の同僚のいずれかが非常に短い順序でそれを解決できなかった場合、私は驚きます。面接ではそのような問題はありませんが、そのような質問をするのは理にかなっていると思います。構文やライブラリに関する詳細な質問よりも確かに役立ちます。
OTOH、プログラミングの問題の方が便利だと思います。
誰かが仕事が得意であることを確実に知る方法はないことを覚えておく必要があります。特にCSジョブは、店内での多くの課題を予測できないためです。
したがって、潜在的な雇用主はあなたの将来の業績を推測しなければなりません。
学位、推奨事項、GPAは、時間/労力とソーシャルエンジニアリングで取得でき、実務経験は装飾的であるか、誤りである可能性があります。また、標準化されたテストは率直に言って基本的すぎて能力を過度に示すことができません。そのため、履歴書は、あなたの歴史における努力/コミットメントのレベルをある程度示しているかもしれませんが、コンピュータサイエンスの世界で発生する困難な問題を解決する実際の能力を語るものではありません。この種の能力を予測するには、いくつかの優れたロジック/数学/ CSyパズルほど良い方法は考えられません。
それは推測ゲームであり、現実は私たちの誰とでも等しいものはすべて、それらのパズルを解くことができない人よりも、それらのパズルを解くことができる誰かを雇うということです。
はい、あなたはインタビューパズルを勉強することができますが、与えられたパズルがあなたが勉強したものと一致しない場合、あなたは自分がやけどを負うと思います...そして、パズルとその解決策を覚えていない限り、おそらくパズルを勉強します彼ら自身は、実際の教育がそうであるように、実際の方法であなたをより賢い人にするでしょう。