Joel Testの質問＃11は、「新しい候補者はインタビュー中にコードを書きますか？」です。インタビュー中に新しい候補者にコードを記述し、それに基づいて決定を下すよう求めるための賛否両論は何ですか？
回答:
短所はありません。面接には多くの部分があり、候補者は数回「チェーン」を支持する必要があります。
毎週10人にインタビューしています。私は本当に、本当に、人事がすべてのバックグラウンド作業を行い、たくさんのメモをくれたという事実に本当に感謝しています。彼らが私に到達するまでに、私は彼らのテストを採点する時が来ました。
テストは位置に完全に依存します。一般的に、私はプローブしようとしています：
一般的なプログラミングスキル。演算子を効果的に使用できますか？10以外の基数を持つ数値システムを想像できますか？
私たちがあなたを雇うことをする方法を知っていますか？
リストしたオープンソースプロジェクトへの貢献の評価
私はそれを短く、そして楽しいものにしようとしています。私がオフィスに行くとき、私は答えをつかみ、それらに目を通し、それから二次面接を行います。雇用されるには、通常、3つの面接を受けなければなりません。
また、あなたを迎えるチームとあなたがどれだけうまく溶け合うかを評価します。そのチームは、それを効果的に行うことを期待しています。
質問をメタ形式で回答することと、実際にコードを生成することは別の問題です。私があなたを雇うつもりなら、私は本当にあなたがコードを生産するのを見る必要があります。
あなたがジャグラーを雇うつもりなら、あなたは彼があなたのためにジャグリングしないように狂っています。または、オーディションを受けるミュージシャン。そうでなければ、素晴らしいヨーヨー「マスター」K-strassのようなものを手に入れます。
ホワイトボード上の何かを歩き回るのは、プログラマーが簡単なデモジャグリングに相当するものです。
私はそれが非常に便利だと思うし、私はいつもそれをしますが、利益が非常によくカバーされているので、（見かけの）ネガだけを議論するつもりです。
コードテストでは誤検知が発生する可能性はかなり低いと思います。実際にコードを書くことができない人がインタビューでそれを偽造する可能性は低く、少なくとも難易度が増加する質問の規模がある場合はそうです。（おそらく最も可能性の高いシナリオは、対面式のインタビューではない場合、友人に質問することでごまかしていることです。）
問題はさらに偽陰性側にあります。コードテストでは、実際に最良の候補者を拒否することになりますか？
舞台負け
実際に非常に優れた開発者であるが、このインタビューに非常に神経質で、基本的に舞台恐怖症になる人がいる場合があります。プレッシャーの下で実行することはある程度重要ですが、舞台恐怖症に対処することはプログラマーの重要な部分ではありません（他の職業と比較して）、それでひどく苦しんでいる人を拒否するのは残念です。これはさらに悪化する可能性があります。その人が答えるべきだとわかっている質問に答えることができない場合、彼らはもっと緊張するかもしれません。または、この質問のように、彼らは同時に話すこともコーディングすることもできないと感じています。
軽減策：技術的な質問に進む前に、背景、目標などについての理解を深める質問から始めます。おそらく、技術的な質問を簡単に始めることから始めて、ある程度の勢いをつけてください。面接中にペニスにならないでください（セミコロンなどについて口論する）。
うるさい尺度です
興味深いコードの質問には、複数の正解がある場合があります。ある人が正解を書き、別の人が正解でより効率的な解答を書く場合、どれだけの重みをかけるべきですか？
ある程度まで、これはいくつかの「パズル」問題の問題のようなものです。その人は洞察力を持っているか、持っていないかのどちらかであり、ほぼバイナリの結果が得られます。インテリジェンスはおそらくその洞察を得る確率に影響を与えますが、サンプリングを数回行うだけで大雑把な尺度が得られます。
これは、コードの質問に悩まされます（私は今でも使用しています）。考えられる最善の緩和策は、可能な解決策を可能な限り増やすことです。少なくとも粗雑なブルートフォースの回答、または問題の一部。それが何もないよりも良いことを認識するのは良い兆候です。その後、さらに発見した場合、より効率的またはよりエレガントなコードにすることができます。可能な限り、バイナリ応答を得る質問をしないでください。
それは本当に代表的ではありません
プログラミングは、10分間のアルゴリズム問題を次々と解決する仕事ではありません。対人スキルは言うまでもなく、より大きなシステムを理解して設計し、長期間集中することについては、さらに多くの作業があります。コードの質問はこれを実際にテストしません。
しかし、質問するのはコードの質問だけではありません。その背景、参考文献、オープンソースの作業（ある場合）を調べて、持続的な努力、創造性、対人スキルの証拠を見つけることができます。
小さなアルゴリズムの問題を解決する方法とそれらをコードに減らす方法を知ることは必要ですが、十分な条件ではありません：小さな問題を解決できず、自明でないコードを書くことができない場合、世界のすべての大局的な考えはそうではありません生産的な開発者になります。
誰でもそれを解決できます
いいえ、明らかにそうではありません。有名なFizzBuzzポストは指摘し、あなたが考えるかもしれない問題は、業界での長年の経験を持つ些細なトラップ新卒人々だけではありません。理由はわかりません。コードテストが不十分な尺度（可能性は高いとは思いますが、可能性は低いと思われます）か、履歴書のプロジェクトにあまり貢献していないか、非コピーと貼り付けによって多くのことを行っていましたアルゴリズムコード（これは可能です。）
アルゴリズムコードを記述することなく、本当に多くのことを成し遂げることができることを認める価値があります。人々は、あなたが「プログラミング」と呼ぶものではなく、グラフィックスまたはビジネスロジックに価値があるアプリで多くのお金を稼ぎ、それは問題ありません。ただし、実際にプログラマが必要な場合は、適切ではありません。
適切に調整されていない可能性があります
質問を思いついたら、答えはとても簡単に思えるかもしれません。ただし、青以外の比較可能な質問、またはあなた自身の特定の興味や背景に偏っていない質問をされた場合、それははるかに難しいかもしれません。
軽減策：すでに知っている開発者に対してテストを実行し、それらがどのように機能するかを確認します。おそらく、あなたのチームで既に非常に頭がいいとわかっている誰かが、そのうちの1人に問題を抱えている可能性があり、調整を検討できます。おそらく、彼らはより良いまたは異なる答えを考えるでしょう。
雑学みたいです
人々があいまいなAPIを心から知っていると主張したり、構文を完璧にしたり、自明でないアルゴリズムの正確な定義を覚えていたりすれば、コードの質問は確かにトリビアになると思います。それらはすべて、ドキュメント、Web検索、またはコンパイラエラーに頼って拾うのが合理的であり、実際の専門知識とはほとんど関係がありません。APIがどこにある可能性があるかさえ知らないことは、おそらくその人が最近それを使用していない手掛かりかもしれませんが、履歴書に載っていない限り、それは必ずしも問題ではありません。
したがって、これに対する答えは非常に簡単です。ささいな質問をせず、ささいな間違いにとらわれないでください。候補者にAPIの名前を思い出させるか、調べさせます。構文エラーを修正します。データ構造の定義を覚えている人をテストしないでください。
どのように比較しますか？
2人の候補者がいて、両方が質問によく答えている場合、どのように候補者を選択しますか？最速で終了した人を選ぶこともできますが、おそらく、カメよりノウサギを選び始めます。別のラウンドを実行して、より難しい質問をすることもできますが、それについてもわかりません。おそらくあなたは彼らに両方のA +を与え、他の基準でそれらのどちらかを選択しようとします（または両方を雇うためにお金を見つけようとします）。
私が考えることができる1つの欠点は、他の人の前で「大声でコード化する」のが難しいということです。私の肩越しに見ている人とタイプすることさえ難しく、私は一人ではありません。誰かが何かを手伝うためにワークステーションに電話をかけてきたとき、彼らは突然タイプミスを始め、間違ったコード補完を選択し、ひどい間違いを犯し始めます-私がそこに座っていなければ誰も犯さなかったでしょう。地獄、私は人々が観察されていたという理由だけで、カット＆ペースト操作のためにメニューを使い始めるのを見ました。これは正常な動作ではなく、私が話しているコーダーは優秀なプログラマーであり、非常に賢い人物です。
私は最近、インタビュー担当者から特定の操作をどのようにコーディングするかを尋ねられ、「数学を見せてください」と言ったインタビューを受けました。まあ、私はそれの数学に着く前に最初に問題について考えなければなりませんでした、それで私はヘミングとハウイングを持っていました。最初にホワイトボードに書いたのは恥ずかしいことで、その時点で負けていると感じました。最終的にA-haの瞬間を得て、答えを見つけました（実際に彼が本当に求めていたものが最終的に私に起こったとき）が、そこに着く前に私が作った「混乱」は私を非常に不快に感じました。それにもかかわらず、私は仕事を得たが、インタビュアーがより忍耐強くなかったならば、私はそうしなかったかもしれない。
インタビュイーにコーディングのタスクを与えたら、コンピューターで、おそらく使い慣れたIDEでさえ、それを解決するために一人で時間を割いてください。彼らにあなたのためにコードを書いてもらい、それについて話させてください。なぜ彼らが特定の方法で物事をしたのか、そして別の方法がより良いのではないかと彼らに尋ねてください。目の前のカップを（形容的に）おしっこするように頼むよりも、この種のプロセスからより多くを知ることができます。
短所：
長所：
あなたは本当にインタビューの中で、人の書き込みのコードを持つようにしたい-より良い、（あなたが快適に、時間/人材に余裕があるものは何でも）、時間のX量のためのあなたのチームのメンバーとペアプログラムにそれらを得ます。
その人がコーディングできるかどうかを判断できる唯一の方法の1つです。
チームの仕事を見せ、実際のIDEを提供し、「本当の」問題に取り組むことができるので、ペアプログラミングを少し好みます（ペアのもう一方の人は、インタビュー対象の環境の詳細をガイドすることができます）合理的に知ることはできませんでした）。
この採用ポリシーの使用を開始しましたが、結果には本当に満足しています。
私は言うだろう：
長所
短所
Reverseメソッドなどが存在する場合、または「クラスのFooメソッドの引数は何か」などの記述テストのBar場合、バカがGoogleを使用するか、ドキュメントを使用できる場合）候補者は物事を成し遂げ、ビジネス上の問題を解決できます。あるプロは、誰かがプログラミングなど何でも基本的な知識を持っていることを示しているということです（私が最後にそれに出会ったとき、SQLの質問がどれほど基本的だったかに驚きました）。また、技術的な議論の基礎としても役立ち、候補者がそのようなことをした理由、および改善方法を尋ねます。
インタビューでは時間がかかりますが、これは他のことに使用できます。さらに、ホワイトボードにコードを書くことは自然な環境ではなく、一部の人々はそれに深刻な問題を抱えています。通常のツールやリファレンスがなくても緊張する開発者を見逃す可能性があります。
プログラミングは非常に技術的なスキルであり、明確な「成果物」がたくさんあります。候補者がそれらを配信できるかできないか。したがって、技術的な質問をするための「短所」はありません。「このアプリケーションのコードをいくつか見せてください」または「既に作成したアプリケーションのコードを見せてください」と言うためです。
そうしないと、次のような結果につながる可能性があります。金持ちの男性が家庭教師にインタビューして、子供たちにチェスをすることを教えました（心を広げる運動として）。家庭教師は市松模様のボードを開き、64個の正方形について話し始めましたが、チェスの駒には触れませんでした。とにかく押された父は、とにかく家庭教師を雇った。そして、家庭教師は子供たちにチェッカーをするように教えました。