インタビュー中に「ホワイトボードコーディング」は不適切ですか？[閉まっている]

これはやや主観的な質問ですが、このトピックに関するインタビュアー/インタビュイーからのフィードバック/意見を聞きたいです。

テクニカルインタビューを4つのパートに分けました。ホワイトボード上のコードの記述、コードの読み取りと分析、デザインセッションとコード。

最後の部分について、インタビュー対象者にお願いすることは、ホワイトボードに小さなコードスニペット（4〜5行）を記述し、説明することです。目的を人々を捕まえることではないことをはっきりさせてください。完全な構文を探しているわけではありません。地獄それは擬似コードでさえありえます。しかし、ポイントは彼らに非常に単純な問題を与え、彼らの脳が解決策を私たちに伝えることができるかどうかを確認することです。単純な問題とは、「文字列を逆にする」、「FizzBu​​zz」などを意味します...

最初に明示的な言語を常に要求することに注意してください。私たちは.NET C＃の家です。誰かがコードを消している/本当に苦労している「擬似コード」とだけ言いました。

私の質問は、「プログラマがインタビュー中にホワイトボードにコードスニペットを書くことを期待するのは不適切/不合理ですか？」です。

私の見解では、それは非常に適切です。特定のスキルを仕事に就かせたい場合は、面接でそのスキルを発揮することが期待されます。

採用プロセスに対するこの手法の効果は非常に顕著です。候補者の90％がこのタスクに失敗しました。しかし、採用された開発者は優秀であり、開発者は社内で尊敬されます。

このテクニックに直面している候補者として、まずリラックスしてください。プログラマとしてのあなたとあなたの思考プロセスを評価することについて。それはあなたの完璧な構文に関するものではありません。構文エラーを犯すと、コンパイラーの役割を果たして、特定の行でコードがコンパイルに失敗し、エラーメッセージが表示され、どのように応答するかを確認できます。同様に、;を追加した場合 コンパイルするループまたはifステートメントにデバッガーを再生し、コードの1つのステップを説明します。繰り返しますが、それは間違いではなく、あなたがどのように間違いに対処するかについてであり、あなたの思考プロセスは良いものです。

私の質問は、「インタビュー中にプログラマーがホワイトボードにコードスニペットを書くことを期待するのは不適切/不合理ですか？」です。

非常に合理的です。プログラマはホワイトボードよりもキーボードでコードを書くことに慣れているため、ホワイトボードの代わりにラップトップとビーマーがあります。EclipseやVS、Idleなどの開発環境が、候補者が開始した時点で既に空のプロジェクトで実行されていることを確認してください。そうすることで、インストールされたアプリケーションを検索する時間を無駄にする必要がありません。

これは不適切ではありませんが、面接している人のプログラミングや問題解決能力に関する真の洞察を常に明らかにするわけではないことを知っておいてください。そして、それがまさにあなたが求めていることだと思います。

第二に、常に失敗を恐れ、常に人の脳を揺さぶることに注意してください。「どうしたの？」「馬鹿げた間違いをしたら」その人の脳の大部分は、彼らがどうやって外れるのかを常に検査するのに忙しく、神経を保持できるのはごくわずかです。

したがって、この種の状況では、最高の結果であっても、結果が不安定になる可能性があります。

最後の部分では、インタビュイーに依頼して、ホワイトボードに小さなコードスニペット（4〜5行）を書き、説明することです。

それで大丈夫です。しかし、ここでも、誰かが何かを適切に説明できなかったからといって、彼らがそれをよく知らないわけではありません。（説明はスピーチの芸術です）。

もし私があなただったら、私はこれをやるだろう最後の部分のために ...

非常に小さな（しかし現実的な）プロジェクトのためにそれらを雇います。彼らがどのようにコーディングし、決定を下し、労働条件やチームメンバーを同化するかなどを確認し、それに基づいて最終決定を下します。

不適切ではありませんが、一部の人々（およびプログラマ群衆の大部分）がインタビューで非常にストレスを感じる可能性があることを忘れないでください。私たちのほとんどは、優秀なコーダーであり、非常に信頼できる人物であるオフィスの人を知っていると思いますが、そのような状況では溶けてしまうでしょう。そのようなテストでは彼のパフォーマンスを測定できなかったので、これをgo / no goテストにしないでください。

私は個人的にこれがあなたができる最高のことの一つだと思います。あなたが言ったように、あなたはここで最も重要な部分は誰かが通信できるかどうかを確認するために正しい構文または同様のものを探していません...私は自分のスペース内で一人でのみ働くことができる非常に多くの優れた開発者を見てきました...残念ながらこれ膨大なケースでは不可能であるため、自分の考えを明確かつ簡潔に伝えることができる熟練した人がいることは、チームのより価値のあるメンバーであり、「それを理解できないとにかく、私は自分でそれをして、後でデモンストレーションします」。

コミュニケーション、コミュニケーション、コミュニケーションは、あらゆる中規模から大規模のプロジェクトの基盤となるものです（一度小さくても必要な場合があります）

それは理にかなったことではないと思います。私たちは候補者を見つけようとしますが、候補者は私たちがしたい仕事に長けています。ホワイトボードにコードを書くことはそれらの1つではなく、良い候補を見つけるのに有効なフィルターだとは思いません。

• 良いコードは書かれず、書き直されます。ホワイトボードは、不変です。作成した後は変更が困難です。問題をよりよく理解したらすぐに考えを変えるのは可能な限り簡単でなければなりません。
• 面接に参加するのはストレスの多い状況なので、候補者に追加のプレッシャーをかける必要はありません。多くのコンピューター関係者は、良い手書きをしていません。最新のIDEには、慣れ親しんだ多くのツールが用意されています。また、必要なときに何かをグーグルで検索できることも、ほとんどのプログラマーの作業スタイルの一部です。なぜこれらすべてのものを取り除いて人工環境を作成しますか。それらを提供する場合、作業する必要はありませんか？
• また、良いテストを書く能力に非常に興味があります。TDDを行うこともできます。これは、ホワイトボードのコーディング中に見ることはできません。

ホワイトボードコーディングセッションから抜け出すことができる手がかりのほとんどは、ペアリングセッションから抜け出すこともできます-そして、ペアリングは、候補者が問題をどのように解決し、どのように動作するかを感じるためのはるかに優れたツールだと思います。彼は自分のコンピューターを持ち込み、快適な環境で仕事をすることができます。また、参加した後のタスクに適用する方がはるかに簡単です。たとえば、大規模なレガシーコードベースがあるため、実際のプロジェクト用に抽出したコードをリファクタリングするよう依頼します。そして、私たちは実際に日々の仕事で可能な限りペアを組んでいるので、ぴったりです。

ホワイトボードセッションはおそらく悪い候補を除外するのに役立ちますが、おそらく多くの優秀なプログラマも除外します。

個人的に、私はFizzBu​​zzをするように頼んでいるどんなインタビュアーでも歩いて行きます。これがいつ新しい業界標準になったかはわかりませんが、それは本当に時間の無駄です。FizzBu​​zzはインタビューの前に使用できるフィルターですが、個人的には、オープンソースコードやブログを見ることができるN人の候補から選ぶ必要があると思いますが、フィルターとしてそれを好むでしょう。

簡単に言えば、プログラミングポジションのインタビュー（ジュニアやインターンシップを除く）では、インタビュー対象者がプログラムできることは既に確立/決定されているはずです。

しかし、はい、ホワイトボードは完璧ですが、別の問題を抱えるべきだと思います。彼らに現実の問題を投げかけ、UML風のスクイブルをたくさん描いて、その問題を解決するための全体的な戦略を説明してもらいます。インターネットを備えたコンピューターを提供して、squibblescapeでブラックボックスとして使用できるサードパーティのライブラリを探します。
数分以内に、彼らがどのように問題に取り組んでいるかを実際に見ることができます。実際にこれを非常に興味深いものにすることができます。必ずしも解決策を考えていない問題を選択し、それらを一緒に「解決」しようとすることで、それらがどれほどうまく通信し、入力をうまく組み込むことができるかを確認します（ただし、それらをあまりにも強く押し込まないでください-あなたがそうすれば、一部の人々はただ凍結するかもしれません）そして、その場でいくつかの要件を追加します。これは、実装を伴わないソフトウェア開発のようなものであり、最も重要なことにはデバッグを伴わないので、15分は多くの時間です。

別の質問に答えさせてください。

ホワイトボードにコードを書くことは、コンピューターでコードを入力して実行することと比較して、プログラミング能力を評価する上で実際の利点を提供しますか？

候補者にインタビューでコードを書くように依頼することは絶対に適切だと思います。しかし、私にとって、コードを実行できることは、プログラミングを構成するフィードバックループの重要な部分です。ホワイトボードでは、あなたは片方の手を私の背中の後ろに縛っていますが、問題をどのように解決するかについての全体像を把握できていません。

いいえ、しかし、IMOのより良いアプローチは、古い「すべてのレコードを取得するためのsqlクエリを書く」または「次のメソッドを書く」よりも、意図した目的でホワイトボードを使用し、架空のプロジェクトでUML / sketches / notesを使用することです文字列を逆にします。」

私が行った最高のインタビューの1つは、20分の時間をかけて開発者とマッドサイエンティストの邸宅（秘密の隠れ家、死の光線、犬小屋を完備）のアーキテクチャ（非ソフトウェア）について話し合うことでした。彼は問題を解決する私のアプローチを見ることができました。問題は、現代の言語で何千回も解決された典型的なローテートプログラミング101のようなものではなく、楽しいものでした。ちなみに、私は以前にもこのようなコードを実行しましたが、アーキテクチャ部分よりも「プレッシャーにさらされている」と感じました。

最近では、多くのプログラミングがチームで行われています。チームが仕事をするためには、人々がコミュニケーションをとることができなければなりません。これの大部分は、ホワイトボードの前で通信できることです（ブレーンストーミング、メンタリング、修正コードのレビューなど）。

候補者がホワイトボードコードを使用してプログラミングの問題を解決する方法を説明したかどうかを探します。説明が十分であれば、部屋にいる他の優秀なプログラマーは、ボード上のタイプミスや間違いをメンタルに自動修正します。

ほとんどのタイプのチームポジションでは、候補者が解決策の試みを説明し、走り書きできると期待しないのは不合理です。

いいえ、インタビューのためにコーディングするのは良いことですが、通常、適切な言語のコードを許可する必要があります競争力のあるレベルに。

それは適切だと思いますが、ほとんどの場合、誰がプログラミングが得意で、誰が得意ではないかを見つける効率的な方法ではありません。仕事をしたい（=有能な人を雇う）場合、インタビューは実生活のスキルの測定に焦点を当てる必要があります。これまでのところ、私がこのように働いた中で最高のインタビュー：

• ご挨拶、人事歓迎。
• 私について、会社についてなど、いくつかの言葉を...そして彼女はインタビューの残りの部分を説明した。
• 彼女は私に、いくつかの部品を見逃したプログラムを備えたラップトップをくれました。そのためユニットテストに失敗しました。不足している部分はテキストとしてそこにコメントされました。それは、いくつかのクラス間の接続を作成し、シンプルなビジネスロジックを導入するなどの基本的なタスクの実装に関するものでした。
• すべてがうまくいけば、ユニットテストは緑色になりました。
• さよならを言い、数日後に戻ってくることに同意します。
• その日、リーダーは私に会い、完成したプログラムについて、私は何をしたのか、そしてその理由について尋ねました。
• また、このリーダーは私の過去の経験と他のいくつかの質問について尋ねました。

要約すると、実動コードに従事する従業員を探している場合は、実際の環境でスキルをテストしてください。あなたが彼らの理論的知識に興味があるなら、これらのことについて彼らに尋ねたほうが良いです。IDEから脱落している場合、または誰かの前でホワイトボードにプログラムする必要があるために緊張している場合、特にITの人々は時々内向的であり、私たちの多くはこれらの状況をうまく処理できないので、私は理解できます私たちの効率は実際よりも悪くなります。

面接を受ける人がひどい悪い筆跡を持たない限り（または私はボードライティングと言うべきです）:-)。あなたのアプローチの唯一の違いは、ボードとマーカーの使用です。場合によってはインタビュアーがこれを行いますが、代わりに紙とペンを渡します。3〜4人が面接を実施している場合、あなたのアプローチははるかに良く、適していると思います。