就職の面接のためのペアプログラミング
当社は、面接手順を廃止し、各候補者を4〜5時間、一部のプログラマーと一緒に座って、ペアプログラミングを行うことを検討しています。
私は理論的にはそのアイデアが好きですが、どのようにして各候補者に対してそれを本当に公平にすることができるのかわかりません。それらをどのように評価しますか？それらの入力は、各プログラマがその日に何をしていたかに本当に依存するのではないでしょうか？
これが良いアイデア/悪いアイデアであるかどうか、またはそれをどのように機能させるかについての考えは、私がここで探しているものです。
乾杯！
編集：
結果-要求どおり
面接の最初のステップは以前と同じように実施します。電話に続いて対面。 3回目の最後のグリルに戻すのではなく、3人の開発者をチームの7人のメンバー全員と一緒に座らせます。その後、誰を採用するかをチームに決定させることにしました。
いくつかの理由でこの結論に達しました。これにより、開発者が作業する相手を選択できるようになり、開発者に力が与えられると信じています。 2番目の理由は、グループダイナミックです。良いグループダイナミクスを持つことは非常に重要であり、採用するまで、彼らが収まるかどうかはわかりません。
したがって、最終的な結果として、ペアプログラミングセッションに進むことになりますが、完全に異なる方法で、当初の意図とはまったく異なる方法で行われます。
このアプローチについての考えや批判は大歓迎です！ （この編集は以下の回答として投稿されているので、これが最善のアプローチではないと思われる場合は遠慮なく投票してください）
これに先んじてたくさんのステップがあるといいのですが。これが機能するには、優れた履歴書と電話スクリーンが必要です。そもそも、話をしてはいけない候補者に時間をかけたくないのです。
では、最初のインタビューを提案し、2番目のインタビューをペアプログラミングセッションとして持つ可能性はありますか？ – Ted Smith（1分前）
うん。 CoPilot のようなものを使用して、ウェブ上で簡単なコーディングインタビューを行うことも考えられます。
実際の開発でペアプログラミングを広範囲に使用しない限り、これを使用することは非常にためらいます。私は、ペアプログラミングへの強い嫌悪感を述べ、そのようなプロセスでスキルが十分に判断されないであろう、多くの高品質なプロの開発者に会いました。
最も簡単な方法は、各ユーザーに同じプログラマーとまったく同じコードを与えることです。
あなたが遭遇する問題は、雇用はプログラミングのようなものではないということです。誰を雇うかについて正しい答えを導き出すための段階的なプロセスはありません。 （決定を容易にするために複数のステップを含めることができます）。あなたはそれぞれの強みなどを評価し、基本的にどちらを雇うのが最善かを教育的に推測する必要があります。時々あなたは間違っていると思います。
ペアプログラミングで注意しなければならないもう1つのことは、その段階の各候補者がそのような種類のテストを受けるのに必要な時間です。仕事を探していたら、会社で面接をするのをためらっています。どうして？それは長い時間であり、私が複数の場所で面接している場合、文字通り何日も過ごすこともできます。 GoogleやMSのような場所は例外ですが、ほとんどの場所はこれら2つとは異なります。 （実際のコードで作業している場合は、基本的に誰かに無料で誰かに仕事を依頼しているということは言うまでもありません）。
私は、アジャイル手法などを誇るサンフランシスコを拠点とする会社にインタビューをしました。私はCEO自身にインタビューする予定でした。私は業界で約20年の経験がありますが、TDDアプローチを使用してプログラミングまたは開発されたペアはありません。 「プログラミングインタビュー」だと言われましたが、何を期待すべきかわからなかったので、始める前に彼は、すべてのインタビューはこのようにすべきだと私は同意するかもしれないと思ったと言いました。 （振り返ってみると、これは傲慢な声明にすぎませんでした）。
とにかく、インタビューでの演習は、TDDを使用してクラスを開発することでした。 TDDをペアでプログラムしたり実行したことがなかったので、プロセス全体の考え方を調整するのに1秒かかりました。あちこちでつまずいたが、結局大丈夫だった。しかし彼の返答は、私が彼らがペアのプログラミング環境に必要とする攻撃的な前後の性質を示さなかったというものでした。さて、それは「お前が素晴らしいとは思わなかった」というメッセージを下手な言い方にしたかもしれない。
幸いなことに、私は仕事を必要としませんでした。また、正直に言うと、開発で毎日ペアで作業する必要があるソフトウェアエンジニアである必要はなく、別のキャリアを見つけたいと思いました。コード。奇妙なことに、時々私はコードで他の人と一緒に仕事をしたことがあるため、何でも可能です。
結局、彼らは私がぴったりだとは思っていなかったし、彼らの働き方を気にしなかったので、それは良い結果だったと思います。しかし、私が自分自身についてさらに数分間話し、彼が彼らの仕事についてどのように進んでいるかについてもう少し情報を与えてくれれば、同じ結論に達したでしょう。つまり、完全な見知らぬ人とのペアプログラミングのストレスにさらす以外に、適切な候補を見つける方法は他にもあるということです。コンピテンシーimoを測定する偽の方法。
個人的な逸話として、私はこのようなテクニックのためにインタビューでぶつかりました。私は彼らの面接プロセスをはるかに進んでいました。履歴書チェック、コード提出に合格し、これは面接の対面部分でした。
私は大学を出たばかりで、ペアリングしたことも、TDDをしたこともありませんでした。彼らはカードエクササイズのデッキを作るために私を座らせました、そしてそれはフロップしました。ひどく！インタビュアーが馬鹿げているように見えるテスト（IE "return null;"）を書いている理由がわかりませんでした。理由を説明しなかったのはもちろん、TDDとは無関係であるため、どのような質問をすればよいのかわかりませんでした。その結果、私は紙袋から自分の道をプログラムすることができないように見えました。
この種のエクササイズを行う場合は、面接対象者が適性のあるさまざまな場所にいるため、面接を受ける必要があります。つまり、実際の才能に基づいていない可能性のあるさまざまな評価が得られるため、偏りが大きくなります。
** TDDが理解できたので、このようなテストと、それがどのように機能するのかを理解しましたが、当時、人間はそれを馬鹿げているように思いました！*
数日前にペアプログラミングのインタビューを受けたばかりで、正直なところ、私はあまり好きではありません。インタビューの前日にこのことを通知され、インタビュアーからペアプログラミングが結局私が仕事でやろうとしていることだと言われました。私はオフィスに入り、非常に上級のソフトウェアエンジニアである誰かとペアになりました。同社はサンフランシスコにあり、ペアプログラミングで有名な会社で、全員がオフィスでペアプログラムを行っています。最初は問題ないように見えましたが、彼が使用したすべてのツール、彼らが構築した独自の単体テストフレームワーク、およびプロジェクトの一部について説明しました。それから彼は基本的に一連の単体テストを書いて、それを通過させるために実装に取り組んでほしいと言っていました。参考までに、すでに存在するコードベースは巨大です。つまり、1万行と言っても、非常に複雑なプロジェクトのようではありませんが、クラス階層などを事前に理解せずにステップインしてコードを記述するのは複雑です。 。彼が誰かがすでに存在するソースコードの10k行にすぐにジャンプすることを期待していると信じるのは本当に難しいと思います。ペアプログラミングインタビューには適合しません。小さいコードベースが役立ちます。すでに存在するクラス/コードの量に圧倒されたため、クラス名を思い出せないため、クラス間を移動して前後に移動するのに少し苦労しました。正直に言って、これは面接プロセスで本当に恐ろしいことをしました。結局、あまり気分が良くなかった。私はこれまでペアプログラミングをしたことがありませんが、大部分は私の大学の宿題の最中です。
私にとってペアプログラミングの力は、ペアに既に熟達している/快適である場合に活用できますが、インタビューにはあまり適していません。ときどきペアに質問したいのですが、あまり質問しすぎると、私は愚かで実行できないと思い込んでしまいました。これがすでに本当の仕事であるなら、私は尋ねることを躊躇しませんが、面接ではそれは難しいです..あなたが立ち往生しているときにあなたのペアがあなたを助ける必要があるので、あなたは尋ねたいですが、同時にそれはインタビューですなので、あまり質問することはできません。
それは私がペアプログラミングインタビューから得た私の経験であり、あなたが本当にこれをしたいのであれば私の提案です：
- 大規模なコードベースで作業する候補者に、小さなコードベースで作業することを許可しないようにしてください。したがって、彼/彼女は彼/彼女のスキルを最大限に発揮できます
- ペアプログラミングインタビューの前に候補者を前にしてください。行き詰まったときに質問できますか。これができるとしたら、何ができないのでしょうか。
- できるだけ詳細に
結局、私はそれをお勧めしません。ペアプログラミングでの候補者のパフォーマンスを測定することは難しく、バイアスもかかる可能性があります。
特定の会社が極端なインタビューと呼ばれる手法を使用しています。極端なインタビューの場合、彼らは、例えば30人の開発者を招き、15人のペアにグループ化します。彼らは他の人とうまく働く人を探していると説明します。彼らが他者と協力する能力にのみ基づいて採用決定を下すこと。
彼らはペアが解決する問題を提供します。彼らは、各プログラマが他の人と協力する能力だけではソリューションに興味がないことを強調します。各ペアについて、ペアのオブザーバーを提供します。エクササイズ中（持続時間は約2〜4時間）、観察者はペアリングする人の能力についてメモします...
彼らは、多くのプログラマーが共同作業ではなく問題の解決に集中することに驚いています。 15組のうち、彼らは2回目のインタビューで約4〜6人の開発者を特定します。それらの開発者は、チームに戻って1週間過ごすように求められます（彼らは給与を受け取ります）。 1週間後、彼らは誰を保持するかを決定します。一般的にはそれらの約半分（開発者2〜3人）。
作業が完了すると、共同作業が可能な開発者がいます。1週間後にさまざまなペアで作業した後、チームはソフトウェアを効果的に開発できる強い兆候を示しています。プロセスは革新的で効果的です。彼らは彼らが雇ったそれらと高い成功率を持っています。
このアイデアが好きです。しかし、候補者があなたとペアになるプロジェクトについてある程度の知識を持っている必要があるので、それは難しいかもしれないと思います。また、4〜5時間は少し長いようです。それがうまくいかないことがすぐにわかるとしたら、候補者とのセッション全体を通して座りますか？
良い質問ですが。考えるもの。
私の限られた経験から、私の気持ちは複雑です。私はインタビューの一部としてペアリングするというアイデアが好きです。会社がペアリングを頻繁に使用する場合、それは両方のフィット感をより良くするためです。候補者として、私はしばしばインタビューに出て、部屋に数時間質問に答えましたが、その後、彼らの環境で実際に仕事をするのはどういう感じなのか、よくわかりませんでした。インタビュアーがそれらを介して誰かを操作することに熟練していない限り、ペアリングはランダムなコーディング演習よりも有益かもしれません。そして、私は双方から技術的なことについて話し合うことができるのが好きです。そして候補者として、質問に答えたり、コードの問題を自分で解決したりするのではなく、誰かとやり取りしたいと思っています。
しかし...他の人が指摘したように、必要な時間は問題になる可能性があります。私はペアリングインタビューを数日間行ったところ、いくつかの期間は良いことがわかりましたが、他の人は数時間を無駄にしたような気がしました。もう1つは、envの問題により、しばらくの間多くの有用な作業が妨げられたためです。仕事がうまくいかない場合、このために1日か2日仕事を休んだことはイライラするかもしれません。
このアプローチを試す1つの場所では、社外の誰かが顧客のプロジェクトに取り組む必要があるかどうか確信が持てませんでした。彼らはまた、ドメインと実行中の作業の説明に時間がかかりすぎることを心配しましたが、それがないと候補者はあまり貢献できない可能性があります。そこで、従業員が取り組んでいたオープンソースプロジェクトを選択しました。
これは重要なポイントのようです：候補者がすぐに理解でき、貢献できる適切に選択されたタスクが必要です。後半は、候補者のスキルにある程度依存します。また、このアプローチで誰かを評価する従業員の能力も重要です。誰もが通常の面接に優れているわけではありません。それはおそらく、ペアリングインタビューに当てはまります。
また、企業がペアリングをあまり行わない場合、この種のインタビューはそれほど役に立たない可能性があります。 （Joel Spolskyが指摘しているように）誰かのコードを見るとメリットがあるように思われますが、これはそのための良い方法かもしれません。しかし、ペアリングが仕事の典型的な部分ではない場合、おそらく完全なペアリングセッションは適切ではありません。多分修正バージョン。
このアプローチを採用した企業が結果をどう思うか知りたいです。この質問に対する他のいくつかの回答を読むと、候補者の観点からは必ずしも理想的とは限らないことがわかります。
何故なの？また、インタビューが常に（またはこれまで）公平であるとは限りません。新しいアプローチの最終結果を、従来のインタビューベースのアプローチと比較して評価する必要があります。
また、ペアプログラミングセッションの前にミニインタビューを行うと、不適切な人とプログラマーの時間を無駄にしないようにできます。
正直なところ、それは素晴らしいアイデアのように思えますが、Jason Punyonは、開発者の大量の淘汰に時間を費やす前に、多くの除草を行うべきであることは確かに正しいです。面接では他の方法ではほとんど得られない重要な測定基準、つまり誰かがどのような作業をしたいかを垣間見ることができます。
正しい評価態度を維持している場合、主題に基づいて「公正」であること、またはさまざまな候補者に一貫した状況を提示しようとすることについて心配する必要は本当にないと思います。 「正しい答えを得た」または正しい一連のフープを飛び越えたが、彼らが示したどのような努力、問題解決、コミュニケーションの適性および柔軟性。開発者がある程度の利益を得ることができるもの（または、少なくとも一部の作業を実行できるもの）から大量の廃棄物に変更することは言うまでもなく、それを人工的なテストに変えることによって、運動の利点のほとんどを失います。彼らの時間。
それを公平に保つには、参加しているすべてのスタッフに、候補者を評価するための準備された問題を持たせる必要があります。できれば、会社の経験で現実の世界を形成しているが、すでに解決されているものが望ましい。これは、問題に関する知識を評価し、プログラミングスキルだけでなく評価する良い機会です。
あまりにも具体的な質問に答えるのは嫌です。プログラマーがSTLの知識をテストしていて、広範囲に使用し、カスタムアロケーターが必要であると答えさせようとしているところ、一度インタビューを受けました。私はそれらのことを聞いたことがありますが、それらを使用することはなく（窓では特に）、馬鹿げた感じにさせられました。 IOW、批判的であることは避けてください。
つまり、「ペアプログラミング」のアイデアを使用すれば、より定性的な個性と問題解決のアプローチを評価できるので、プログラミングの知識をテストすることではなく、実用的な質問をします。
良い質問！
Joel Spolskyには優れた インタビューのゲリラガイド があり、とりわけプログラミングタスクについて説明しています。
雑学：Joel Spolskyは、stackoverflow.comの共同創設者です。