就職面接用ペアプログラミング【終了しました】

https://stackoverflow.com/questions/596426

09-09-2019
|

質問

私たちの会社は、面接手順を廃止し、各候補者をプログラマー数名と 4 ～ 5 時間座らせ、ペアプログラミングだけを行うことを検討しています。

理論的にはこのアイデアは気に入っていますが、各候補者にとって実際に公平にするにはどうすればよいかわかりません。それらをどう評価しますか?彼らの入力は、実際には各プログラマーがその日に取り組んでいた内容に依存するのではないでしょうか?

これが良いアイデアか悪いアイデアか、またはそれを機能させる方法についての考えが、私がここで探しているものです。

乾杯！

編集：

結果 - 要求どおり

面接の最初のステップはこれまでと同様に実施します。電話の次に対面。3 回目の最後のグリルのために彼らを呼び戻す代わりに、3 人の開発者を呼び戻し、チームの 7 人のメンバー全員と一緒に座らせるつもりです。その後誰を採用するかはチームに決定させることにしました。

私たちがこの結論に至った理由はいくつかあります。これにより、開発者が誰に取り組むかを選択できるようになり、開発者に権限が与えられると私たちは信じています。2 番目の理由は、グループのダイナミックさです。私たちは、グループのダイナミクスを良好にすることが非常に重要であると考えていますが、人を雇うまでその人が溶け込めるかどうかを判断するのは困難です。

その結果、私たちはペアプログラミングセッションを進めることになりますが、当初の意図とはまったく異なる方法で行われます。

このアプローチに関するご意見やご批判は大歓迎です。(この編集は以下の回答として投稿されているため、これが最良のアプローチではないと思われる場合は、自由に反対票を投じてください)

解決

この先、あなたがたくさんのステップを踏んでいることを願っています。これを機能させるには、優れた履歴書と電話スクリーンが必要です。そもそも話し合うべきではない候補者に多大な時間を費やしたくないでしょう。

それで、あなたは最初のインタビューを提案し、おそらくペアプログラミングセッションとして2回目のインタビューをするでしょうか？- テッド・スミス（1分前）

うん。次のようなものを使用して、簡単なコーディング面接を Web 上で行うことも考えられるかもしれません。コパイロット.

他のヒント

実際の開発でペアプログラミングを頻繁に使用しない限り、これを使用することは非常にためらわれます。私は、ペアプログラミングに対する強い嫌悪感を口にし、そのようなプロセスではスキルが適切に評価されない質の高いプロの開発者に何人も会いました。

最も簡単な方法は、各人に同じプログラマとまったく同じコードを与えて作業を行うことです。

これから直面する問題は、採用はプログラミングとは異なるということです。誰を雇用するかについて正しい答えを導くための段階的なプロセスはありません。(決定を容易にするために複数のステップを行うことができます)。それぞれの長所などを考慮して評価する必要があります。そして基本的に、誰を雇用するのが最適であるかについて知識に基づいた推測を行います。時々、あなたは間違った推測をします。

ペアプログラミングに関して注意しなければならないもう 1 つのことは、その段階の各候補者にその種のテストを受けさせるのに必要な時間です。私が就職活動をしているとしたら、そんなことを要求する企業に面接に行くのは躊躇します。なぜ？なぜなら、それは膨大な時間であり、複数の場所で面接を行っている場合、就かないかもしれない、あるいは望んでいないかもしれない仕事の面接に行くだけで文字通り何日も費やしてしまう可能性があるからです。Google や MS などの一部の企業は例外ですが、ほとんどの企業はこれら 2 社とは異なります。(彼らが実際のコードに取り組んでいる場合、基本的に誰かの仕事を無償で依頼していることになるという事実は言うまでもありません)。

私はちょうどアジャイル手法などに誇りを持っているサンフランシスコを拠点とする企業と面接したところです。CEO本人にインタビューすることになった。私は業界で約 20 年の経験がありますが、TDD アプローチを使用してペアプログラミングや開発をしたことはありません。「プログラミング面接」だと言われましたが、何を期待すればよいのかわかりませんでした。始める前に、その男性は、すべての面接はこのように行われるべきであるということに私が同意するかもしれないと思うと言いました。（今にして思えば、これは傲慢な発言に過ぎませんでした）。

とにかく、面接では TDD を使用してクラスを開発するという演習が行われました。私はペアプログラミングや TDD を行ったことがなかったので、プロセス全体について自分の考えを調整するのに 1 秒かかりました。あちこちつまずきながらも、最終的にはうまくいきました。しかし彼の返事は、彼らのペアプログラミング環境に必要な積極的なやり取りの性質を私は示さなかったというものでした。さて、それは「あなたが素晴らしいことをしたとは思わなかった」という種類のメッセージを伝える卑劣な方法だった可能性もあります。

幸いなことに、私にはその仕事は必要ありませんでした。正直に言うと、その経験から、開発に関しては毎日ペアで働かなければならないソフトウェアエンジニアになるよりも、別のキャリアを見つけたほうが良いと気づきました。コード。奇妙なことに、私は時々、他の人と同時にコード作業をしたことがあるので、何でも可能です。

結局のところ、彼らは私が自分に合わないと思っていて、私は彼らの仕事のやり方に興味がなかったので、良い結果だったと思います。しかし、私がもう少し自分のことについて話し、彼らがどのように仕事に取り組んでいるかについてもう少し詳しく教えてくれていたら、私たちは同じ結論に達しただろう。つまり、ぴったりの候補者を見つけるには、見ず知らずの相手とのペアプログラミングのストレスを強いる以外にも方法があるということです。能力を測る偽の方法。

個人的な逸話として、私はこのようなテクニックのせいで面接で叩かれたことがあります。私は彼らの面接プロセスをかなり進めました。履歴書のチェックとコードの提出に合格し、これが面接の対面部分でした。

私は大学を卒業したばかりで、これまでペアプログラミングも TDD もやったことがありませんでした。彼らは私を座らせてトランプの練習をさせましたが、それは失敗しました。ひどく！なぜ面接官がそれほどばかばかしい* (IE "return null;") と思われるテストを作成しているのか理解できませんでした。そして、彼らはその理由を説明しませんでした。そしてもちろん、TDD とは無縁だったので、どのような質問をすればよいのかわかりませんでした。最終的な結果は、紙袋から取り出す方法をプログラムすることができないように見えました。

この種の演習を行う場合は、面接対象者は適性によって異なる場所に就くことになるため、面接対象者に応じる必要があります。これは、実際の才能に基づいていない可能性があるさまざまな評価が得られることを意味し、したがって、大きく偏ったものとなるでしょう。

**今では TDD を理解したので、このようなテストとそれがどのように機能するのかを理解していますが、当時はそれが愚かだと思われたことはありませんでした!*

数日前にペアプログラミングの面接を受けたばかりなのですが、正直に言うとあまり好きではありません。面接の直前にこのことを知らされたのですが、面接官は私に、最終的には仕事でペアプログラミングをするつもりだと言いました。私はオフィスに行き、非常に上級のソフトウェアエンジニアである人とペアになりました。この会社はサンフランシスコにあり、ペアプログラミングで有名な会社で、オフィスでは全員がペアプログラムを行っています。最初は問題ないように見えましたが、彼は使用したすべてのツール、構築した独自の単体テストフレームワーク、およびプロジェクトの一部について説明しました。その後、彼は基本的に単体テストを大量に書き、それを合格させるための実装に取り組むよう私に求めました。参考までに、既存のコードベースは巨大で、10,000 行あると思います。これは超複雑なプロジェクトのようなものではありませんが、クラス階層などを事前に理解せずに誰かが介入してコードを記述するのは複雑です。。彼が、誰かがすでに存在する 10,000 行のソースコードにすぐにジャンプすることを期待しているとは、本当に信じがたいです。これはペアプログラミングの面接には適していません。コードベースが小さい方が役に立ちます。すでに存在するクラス/コードの量に圧倒されてクラス名を思い出せないため、クラス内を移動したり行ったり来たりするのに少し苦労しました。正直に言うと、そのせいで面接ではひどい結果になりました。結局、あまり良い気分にはなれませんでした。私はこれまでペアプログラミングをしたことがなく、主に大学の課題のときにだけやりました。

私にとって、ペアプログラミングの力は、すでにペアに習熟している/慣れている場合には活用できますが、面接にはあまり適していません。時々、ペアに質問したいことがありますが、質問しすぎると、彼らは私が愚かでパフォーマンスができないと思われるだろうと思いました。これがすでに実際の仕事にあるなら、躊躇せずに尋ねるでしょうが、面接では難しいです...行き詰まったときにペアが助けてくれるはずなので聞きたいのですが、同時にそれは面接なので、あまり多くを聞くことはできません。

これはペアプログラミングのインタビューで得た私の経験にすぎません。本当にこれをやりたい場合の私の提案は次のとおりです。

候補者に大きなコードベースで作業するように与えないようにしてください。
ペアプログラミングインタビューの前に候補者と一緒に前に出てください、あなたが立ち往生しているとき、あなたがこれを行うことができれば、あなたができないことができれば、あなたはあなたが立ち往生しているときに質問することができますか
できるだけ詳しく

結局のところ、私はそれをお勧めしません。ペアプログラミングで候補者のパフォーマンスを測定するのは難しく、偏りがある可能性もあります。

ある特定の企業は、と呼ばれる手法を使用しています。 極端なインタビュー. 。極端な面接では、たとえば 30 人の開発者を集め、15 組にグループ化します。彼らは、他の人たちとうまく協力できる人材を求めていると説明します。他の人たちと協力して働く能力のみに基づいて採用を決定すること。

彼らはペアに解決すべき問題を提供します。彼らは、ソリューションに興味があるのではなく、各プログラマーが他のプログラマーと協力する能力だけに興味があることを強調するでしょう。各ペアに対して、ペアのオブザーバーを提供します。演習中 (所要時間約 2 ～ 4 時間)、観察者は人のペアリング能力についてメモを取ります。解決策ではありません。

彼らは、いかに多くのプログラマが共同作業ではなく問題の解決に集中しているかに驚いています。15 組の中から、2 回目の面接のために約 4 ～ 6 人の開発者を特定します。それらの開発者は、戻ってきてチームと 1 週間過ごすよう求められます (報酬が支払われます)。1週間後、誰を残すか決める。通常、その約半数 (2 ～ 3 人の開発者)。

それが完了すると、共同作業ができる開発者が集まり、さまざまなペアで 1 週間作業した後、誰がソフトウェアを効果的に開発できるかがチームに明確になります。このプロセスは革新的かつ効果的です。彼らは採用した人材の成功率が高いです。

このアイデアは気に入っています。ただし、候補者があなたとペアを組むプロジェクトについてある程度の知識を持っている必要があるため、これは難しいかもしれないと思います。また、4～5時間は少し長く感じます。それがうまくいかないとすぐにわかった場合、候補者とのセッション全体を座って続けるつもりですか?

良い質問ですが。考えるべきこと。

なぜだめですか？また、面接が常に（または常に）公平であるわけではありません。従来の面接ベースのアプローチと比較して、新しいアプローチの最終結果を評価する必要があります。

また、合わない人とプログラマーの時間を無駄にしないために、ペアプログラミングセッションの前にミニインタビューを行うのもよいでしょう。

私の限られた経験からすると、私の気持ちは複雑です。私は、特に面接の一環としてペアリングをするというアイデアが好きです。会社がペアリングを頻繁に使用する場合は、両方のフィット感が向上するためです。候補者として、私は面接で数時間部屋に座って質問に答えることがよくありましたが、その後、彼らの環境で働くことが実際にどのようなものなのかについてはよくわかりませんでした。面接官がペアリングを行うことに熟練していない限り、ランダムなコーディング演習よりもペアリングの方が有益である可能性があります。そして、技術的なことについて双方の立場から議論できることが気に入っています。そして候補者として、私は質問に答えたり、コードの問題を自分で解決したりするだけではなく、誰かと対話することを望んでいます。

しかし...他の人も指摘しているように、必要な時間が問題になる可能性があります。数日間のペア面接を経験しましたが、良い時間もあれば、数時間が無駄だと感じた時間もありました。1 つは、開発者がペアリングに適したものに取り組んでいなかったためです。私の背景を考慮すると)、もう 1 つは、env の問題により、しばらくの間、多くの有用な作業が妨げられたためです。仕事がうまくいかなかった場合、そのために1日か2日仕事を休む必要があったとイライラするかもしれません。

このアプローチを試みているある企業では、顧客のプロジェクトに社外の人を従事させるべきかどうか確信が持てませんでした。彼らはまた、ドメインと行われている仕事の説明に時間がかかりすぎるのではないかと心配していましたが、それがなければ候補者はあまり貢献できないかもしれません。そこで彼らは、その従業員が取り組んでいたオープンソースプロジェクトを選択しました。

これが重要なポイントのようです: 候補者がすぐに理解し、貢献できるタスクを適切に選択する必要があります。 後半は候補者のスキルに多少依存します。また、このアプローチで誰かを評価する従業員の能力も重要です。誰もが通常の面接が得意というわけではありませんが、ペア面接ではおそらくそれがより当てはまります。

また、企業がペアリングをあまり行っていない場合、この種の面接はあまり役に立たない可能性があります。(Joel Spolsky が指摘しているように) 誰かがコードを書いているのを見ることには確かに利点があるようで、これはそれを行うための良い方法かもしれません。ただし、ペアリングが通常の仕事の一部ではない場合は、完全なペアリングセッションは適切ではない可能性があります。もしかしたら修正版かも知れません。

このアプローチを採用した企業がその結果についてどう考えているか知りたいです。この質問に対する他の回答を読むと、それが候補者の観点から見て必ずしも理想的であるとは限らないことがわかります。

公平性を保つには、参加するすべてのスタッフメンバーに、候補者を評価するための準備された問題を持たせる必要があります。できれば、会社での経験の中で現実世界から取り入れられたもの、ただしすでに解決されているものが望ましいです。これは、問題に関する知識を評価し、プログラミングスキルだけでなく評価する良い機会です。

あまりにも具体的な質問に答えられるのが嫌いです。一度面接を受けたことがありますが、プログラマーが私が頻繁に使用していた STL に関する知識をテストし、カスタムアロケーターが必要であると答えさせようとしていました。私はそれらについて聞いたことはありましたが、（特に Windows では）使用したことがなかったので、愚かに感じられました。ああ、批判的になるのは避けてください。

つまり、私が言いたいのは、プログラミングの知識をテストするというよりも、「ペアプログラミング」のアイデアを使用すれば、より定性的な性格や問題解決のアプローチを評価できる実践的な質問をするということです。

良い質問！

正直なところ、それは素晴らしいアイデアのように思えますが、開発者の時間を選別で無駄にする前に、徹底的に除草を行うべきだという Jason Punyon の意見は確かに正しいです。そこから、インタビューではほとんど得られない重要な指標を垣間見ることができます。一緒に仕事をする人がどんな人なのか。

正しい評価態度を維持していれば、主題に基づいて「公平」であることや、さまざまな候補者に一貫した状況を提示しようとすることを心配する必要はないと思います。重要なのは、彼らが評価するかどうかではないということです。「正しい答えを得た」、あるいは正しい一連のフープを飛び越えた、しかし彼らはどのような努力、問題解決、コミュニケーション適性、柔軟性を示したでしょうか。人為的なテストに変えると、演習の利点のほとんどが失われます。開発者が何らかの利益を得られる (または少なくともその間に作業を完了できる) ものから、膨大な無駄に変更することは言うまでもありません。彼らの時間。

ジョエル・スポルスキーは素晴らしいゲリラ面接ガイドここでは、特にプログラミングタスクについて説明します。

トリビア：Joel Spolsky は stackoverflow.com の共同創設者です。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow