41

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

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

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

乾杯！

編集：

結果 - 要求どおり

インタビューの最初のステップはこれまでと同じように実施します。電話の次は対面。彼らを 3 回目の最終的なグリルに戻す代わりに、3 人の開発者をチームの 7 人のメンバー全員と一緒に座らせることにします。誰を採用するかはチームに任せることにしました。

いくつかの理由から、この結論に達しました。これにより、誰と仕事をするかを選択できるようになり、開発者に力を与えることができると信じています。2 番目の理由は、グループ ダイナミクスです。私たちは、優れたグループのダイナミクスを持つことが非常に重要であると考えており、人を雇うまでは、その人が適合するかどうかを判断するのは困難です.

したがって、最終的には、ペア プログラミング セッションを進めることになりますが、当初の意図とはまったく異なる方法で、まったく異なる方法で行うことになります。

このアプローチについての考えや批判は大歓迎です!! （この編集は以下の回答として投稿されているため、これが最善のアプローチではないと思われる場合は、遠慮なく反対票を投じてください）

4

13 に答える 13

34

実際の開発でペア プログラミングを広く使用しない限り、これを使用するのは非常にためらいます。私は、ペア プログラミングに対して強い嫌悪感を示し、そのようなプロセスではスキルが十分に評価されない、質の高いプロの開発者に数多く会ってきました。

于 2009-02-27T20:14:25.307 に答える
12

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

では、一次面接を提案し、二次面接をペアプログラミングセッションとして行うことは可能ですか? – テッド・スミス (1 分前)

うん。CoPilotのようなものを使用して、Web 上で簡単なコーディング インタビューを行うことを考えるかもしれません。

于 2009-02-27T20:12:20.507 に答える
12

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

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

ペア プログラミングでもう 1 つ気を付けなければならないことは、その段階の各候補者がその種のテストを受けるのに必要な時間です。仕事を探していたら、そのような会社の面接に行くのをためらうでしょう。なんで？それには多くの時間がかかるため、複数の場所で面接する場合、私が得られない、または望んでいない可能性のある仕事の面接に行くだけで、文字通り何日も費やすことができます. Google や MS などは例外ですが、ほとんどの場所はこの 2 つとは異なります。（彼らが実際のコードに取り組んでいる場合、あなたは本質的に彼らに誰かの仕事を無料で行うように頼んでいるという事実は言うまでもありません）.

于 2009-02-27T20:12:38.460 に答える
10

個人的な逸話として、私はこのようなテクニックのせいでインタビューで叩かれました. 私は彼らの面接プロセスで遠くまで行きました。履歴書のチェック、コードの提出に合格し、これが面接の対面部分でした。

私は大学を出たばかりで、ペアプログラミングもTDDもしたことがありませんでした。彼らは私を座ってカードの練習をしましたが、それはフロップでした。ひどく！なぜインタビュアーが非常にばかげているように見える* (IE "return null;") テストを書いているのか理解できませんでした。その結果、紙袋から抜け出す方法をプログラムできないように見えました。

この種の演習を行う場合は、面接対象者が適性を備えたさまざまな場所にいるため、面接対象者に対応する必要があります。これは、実際の才能に基づいていない可能性があるさまざまな評価を取得することを意味し、その結果、偏りが大きくなります.

**TDD を理解した今、私はこのようなテストとそれがどのように機能するべきかを理解していますが、当時は馬鹿げているように思えました!*

于 2009-02-27T20:31:50.817 に答える
10

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

とにかく、面接での演習は、TDD を使用してクラスを開発することでした。ペアでプログラムしたり TDD を行ったりしたことがなかったので、プロセス全体の考え方を調整するのに少し時間がかかりました。あちこちでつまずきましたが、最終的には大丈夫でした。しかし、彼の返事は、彼らが彼らのペア プログラミング環境に必要とする攻撃的な往復の性質を私は示さなかったというものでした。さて、それはまた、「あなたが素晴らしいことをしたとは思わなかった」というようなメッセージを不当に言った可能性もあります.

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

最終的には良い結果だったと思います。なぜなら、彼らは私が自分に合わないと思っていたからです。しかし、私が自分自身についてもう少し話し、彼らがどのように仕事をしているのかについて彼がもう少し情報を提供してくれていれば、同じ結論に達したでしょう. つまり、完全に見知らぬ人とペアプログラミングのストレスを経験する以外に、ぴったりの候補者を見つける方法は他にもあるということです。コンピテンシーのイモを測定するための偽の方法。

于 2009-06-29T20:04:19.703 に答える
7

数日前にペアプログラミングのインタビューをしたばかりですが、正直言って、あまり好きではありません。面接の前日にそのことを知らされたのですが、面接官からペアプログラミングがやがて仕事でやろうと言われました。私はオフィスに行き、非常に上級のソフトウェアエンジニアである誰かとペアになりました。同社はサンフランシスコにあり、ペアプログラミングで有名な会社であり、誰もがオフィスでペアプログラミングを行っています。最初は問題ないようでしたが、彼は彼らが使用したすべてのツール、彼らが構築した独自の単体テストフレームワーク、およびプロジェクトの一部について説明しました。それから彼は基本的にたくさんのユニットテストを書き、それをパスさせるために実装に取り​​組むことを私に望んでいました。参考までに、すでに存在するコードベースは巨大です。1万行と言えます。非常に複雑なプロジェクトのようではありませんが、クラス階層などを事前に理解せずに、誰かが介入してコードを書くのは複雑です。彼が誰かが10k行ですぐにジャンプすることを期待しているとは信じがたいです。すでに存在するソースコードの。ペアプログラミングのインタビューには合わないので、コードベースを小さくすると便利です。すでに存在するクラス/コードの量に圧倒されてクラス名を思い出せないため、クラス内を移動したり前後に移動したりするのに少し苦労しました。正直なところ、これは私が面接の過程で本当にひどいことをしました。結局、私はそれについて本当に気分が良くありませんでした。私はこれまでペアプログラミングを行ったことがありません。ほとんどの場合、大学時代の任務中です。しかし、クラス階層などを事前に理解せずに、誰かが介入してコードを書くのは複雑です。すでに存在する10k行のソースコードに誰かがすぐにジャンプすることを彼が期待しているとは信じがたいです。ペアプログラミングのインタビューには合わないので、コードベースを小さくすると便利です。すでに存在するクラス/コードの量に圧倒されてクラス名を思い出せないため、クラス内を移動したり前後に移動したりするのに少し苦労しました。正直なところ、これは私が面接の過程で本当にひどいことをしました。結局、私はそれについて本当に気分が良くありませんでした。私はこれまでペアプログラミングを行ったことがありません。ほとんどの場合、大学時代の任務中です。しかし、クラス階層などを事前に理解せずに、誰かが介入してコードを書くのは複雑です。すでに存在する10k行のソースコードに誰かがすぐにジャンプすることを彼が期待しているとは信じがたいです。ペアプログラミングのインタビューには合わないので、コードベースを小さくすると便利です。すでに存在するクラス/コードの量に圧倒されてクラス名を思い出せないため、クラス内を移動したり前後に移動したりするのに少し苦労しました。正直なところ、これは私が面接の過程で本当にひどいことをしました。結局、私はそれについて本当に気分が良くありませんでした。私はこれまでペアプログラミングを行ったことがありません。ほとんどの場合、大学時代の任務中です。彼が誰かがすでに存在する10k行のソースコードにすぐにジャンプすることを期待しているとは信じがたいです。ペアプログラミングのインタビューには合わないので、コードベースを小さくすると便利です。すでに存在するクラス/コードの量に圧倒されてクラス名を思い出せないため、クラス内を移動したり前後に移動したりするのに少し苦労しました。正直なところ、これは私が面接の過程で本当にひどいことをしました。結局、私はそれについて本当に気分が良くありませんでした。私はこれまでペアプログラミングを行ったことがありません。ほとんどの場合、大学時代の任務中です。彼が誰かがすでに存在する10k行のソースコードにすぐにジャンプすることを期待しているとは信じがたいです。ペアプログラミングのインタビューには合わないので、コードベースを小さくすると便利です。すでに存在するクラス/コードの量に圧倒されてクラス名を思い出せないため、クラス内を移動したり前後に移動したりするのに少し苦労しました。正直なところ、これは私が面接の過程で本当にひどいことをしました。結局、私はそれについて本当に気分が良くありませんでした。私はこれまでペアプログラミングを行ったことがありません。ほとんどの場合、大学時代の任務中です。すでに存在するクラス/コードの量に圧倒されてクラス名を思い出せないため、クラス内を移動したり前後に移動したりするのに少し苦労しました。正直なところ、これは私が面接の過程で本当にひどいことをしました。結局、私はそれについて本当に気分が良くありませんでした。私はこれまでペアプログラミングを行ったことがありません。ほとんどの場合、大学時代の任務中です。すでに存在するクラス/コードの量に圧倒されてクラス名を思い出せないため、クラス内を移動したり前後に移動したりするのに少し苦労しました。正直なところ、これは私が面接の過程で本当にひどいことをしました。結局、私はそれについて本当に気分が良くありませんでした。私はこれまでペアプログラミングを行ったことがありません。ほとんどの場合、大学時代の任務中です。

私にとって、ペアプログラミングの力は、あなたがすでにペアに習熟している/快適である場合に利用できますが、面接にはあまり適していません。時々ペアに質問したいのですが、質問が多すぎるとバカだと思って演じられないのではないかと思いました。これがすでに実際の仕事になっているのなら、私は躊躇せずに尋ねますが、面接では難しいです。あなたはあなたが立ち往生しているときにあなたのペアがあなたを助けるはずなので、あなたは尋ねたいですが、同時にそれは面接です、だからあなたは本当に多くを尋ねることはできません。

これは、ペアプログラミングのインタビューから得た私の経験です。本当にこれを実行したい場合の私の提案です。

  1. 候補者に大きなコードベースで作業するように与えないでください。小さなコードベースで作業するようにしてください。そうすれば、候補者は自分のスキルを最大限に発揮できます。
  2. ペアプログラミングの面接の前に候補者と率直に話し合ってください。行き詰まったときに質問できますか。これができるのか、それができるのか、何ができないのか。
  3. できるだけ詳細にする

結局、私はそれを提案しません。ペアプログラミングで候補者のパフォーマンスを測定することは困難であり、バイアスもかかる可能性があります。

于 2011-11-03T22:14:11.593 に答える
3

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

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

于 2009-02-27T20:15:12.417 に答える
2

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

しかし... 他の人が指摘したように、必要な時間が問題になる可能性があります. 数日間のペアリング インタビューを行ったところ、良い期間もあれば、数時間が無駄に感じられた期間もありました。もう1つは、envの問題により、しばらくの間、多くの有用な作業が妨げられたためです。仕事がうまくいかない場合、そのために 1 日か 2 日仕事を休んでいるとイライラすることがあります。

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

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

また、企業がペアリングをあまり行わない場合、この種の面接はあまり役に立たない可能性があります. (Joel Spolsky が指摘しているように) 誰かがコードを書いているところを見ることには利点があるように思われます。しかし、ペアリングが仕事の典型的な部分ではない場合、おそらく完全なペアリングセッションは適切ではありません. 修正版かも。

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

于 2011-04-10T00:29:48.603 に答える
2

なぜだめですか？また、面接が常に (または常に) 公正であるとは限りません。新しいアプローチの最終結果を、従来のインタビューベースのアプローチと比較して評価する必要があります。

また、ペア プログラミング セッションの前にミニ インタビューを行うと、相性の悪い人とプログラマーの時間を無駄にしないようにすることができます。

于 2009-02-27T20:14:27.317 に答える
1

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

あまりにも具体的な質問に答えられるのは嫌いです。私が広範囲に使用した STL に関する私の知識をプログラマーがテストしていて、カスタム アロケータが必要であると私に答えさせようとしていたとき、私はインタビューを受けました。私はそれらのことを聞いたことがありますが、それらを使用したことはなく（特にWindowsで）、ばかげていると感じさせられました。IOW、批判的であることを避けてください。

つまり、「ペア プログラミング」の考え方を使用すれば、より質的な性格や問題解決のアプローチを評価できるので、プログラミングの知識をテストすることではなく、実際的な質問をするということです。

良い質問！

于 2009-02-27T20:16:15.940 に答える
1

正直なところ、それは素晴らしいアイデアのように思えますが、Jason Punyon は、開発者の時間をかなりの量のカリングに浪費する前に、多くの雑草を取り除く必要があることは確かに正しいです。そこから、他の方法ではインタビューではほとんど得られない重要な測定基準を垣間見ることができます。

主題に基づいて「公正」であることや、さまざまな候補者に一貫した状況を提示しようとすることについて心配する必要はまったくないと思います。正しい評価態度を維持すれば、 「正しい答えを得た」または正しい一連のフープを飛び越えましたが、どのような努力、問題解決、コミュニケーション適性、および柔軟性を示しましたか. 演習を人為的なテストに変えることで、演習のメリットのほとんどを失うことになります。彼らの時間。

于 2009-02-27T20:17:15.813 に答える
0

Joel Spolsky は優れたGuerrilla Guide to Interviewingを作成しており、とりわけプログラミング タスクについて説明しています。

豆知識: Joel Spolsky は、stackoverflow.com の共同創設者です。

于 2009-02-27T20:17:29.930 に答える