雇用主にとって、面接中にコードに関する質問をすることのメリットとデメリットは何ですか?[閉まっている]

https://softwareengineering.stackexchange.com/questions/21230

22-10-2019
|

質問

ジョエルテスト質問 #11 は次のとおりです。「新しい候補者は面接中にコードを書きますか?」面接中に新しい候補者にコードを書くように要求し、それに基づいて決定を下すことについて、どのような賛否両論があるでしょうか?

解決

短所が見えません。インタビューには多くの部分があり、候補者は数回「チェーンを上げる」ことを承認する必要があります。

私は毎週10人にインタビューします。 HRがすべてのバックグラウンドワークを行って、たくさんのメモを提示したという事実を本当に、本当に、本当に感謝しています。彼らが私に到達する頃には、私が彼らのテストを獲得する時が来ました。

テストは完全に位置に依存します。一般的に、私はプローブを試みます：

一般的なプログラミングスキル。オペレーターを効果的に使用できますか？ 10ではない基数を持つ数値システムを想像できますか？
私たちがあなたに雇っていることをする方法を知っていますか？
リストしたオープンソースプロジェクトへの貢献の評価

私はそれを短く、そして楽しいままにしようとしています。私がオフィスに行くとき、私は答えをつかみ、それらを見渡してから、二次インタビューを行います。雇われるには、通常、3回のインタビューを行う必要があります。

また、私はあなたがあなたを受け取るチームとどれだけうまく溶け込むかを測定します。そのチームは私がそれを効果的に行うことを期待しています。

メタ形式で質問に答えることは1つであり、実際にコードを作成することは別です。私があなたを雇うつもりなら、私はあなたがコードを作成するのを見る必要があります。

他のヒント

スコット・ホイットロックに謝罪して：

短所：

なし

長所：

プログラムできない人の雇用を防ぐと、多くの時間と心痛を路上で節約します
インタビューに技術者を持つ必要があります

あなたがジャグラーを雇うつもりなら、あなたは彼をあなたのためにジャグリングさせないように狂っているでしょう。または、オーディションがあるミュージシャン。それ以外の場合は、次のようなものを取得します Awesome Yo-Yo "Master" K-Strass.

ホワイトボードの上で何かを歩くことは、クイックデモジャグルに相当するプログラマーです。

これは非常に便利だと思うので、いつもそうしていますが、メリットについては十分に説明されているので、（一見した）マイナス点についてのみ説明します。

コードテストで誤検知が発生する可能性はかなり低いと思います。実際にコードを書くことができない人が、少なくとも、質問の難易度が徐々に上がっていく場合には、面接でそれを偽ることができる可能性は低いです。（おそらく最も可能性の高いシナリオは、対面インタビューではない場合、友人に尋ねて不正行為をしているということです。）

問題はむしろ偽陰性側にあります。コードテストによって、実際に最適な候補者を拒否することになるでしょうか?

舞台負け

実際には非常に優れた開発者であるにもかかわらず、この面接では非常に緊張し、基本的にステージ恐怖症になる人がいるかもしれません。プレッシャーの下でパフォーマンスを発揮することはある程度重要ですが、舞台恐怖症に対処することは（他の職業と比較して）プログラマーとしてそれほど重要な部分ではありません。そして、舞台恐怖症にひどく苦しんでいる人を拒否するのは残念なことです。これにより、次のことがさらに悪化する可能性があります。答えるべきだとわかっている質問に答えられない場合、その人はさらに緊張するかもしれません。または、この質問のように, 、彼らは話すこととコードを同時に書くことはできないと感じています。

緩和：技術的な質問に入る前に、背景や目標などについていくつかの質問から始めてください。おそらく、簡単な技術的な質問から始めて、勢いをつけてください。面接中にバカなことをしないでください（セミコロンについての屁理屈など）。

騒々しい措置だ

興味深いコードの質問には、複数の正解がある場合があります。ある人が正しい答えを書き、別の人がより正確で効率的な答えを書いた場合、どれだけの比重を置くべきでしょうか?

ある程度、これはいくつかの「パズル」の問題に似ています。その人が洞察力を持っているかどうかで、ほぼ二値的な結果が得られます。知能はおそらくその洞察を得る確率に影響しますが、サンプリングを数回行うだけで大まかな尺度が得られます。

これは、コードに関する質問について私を悩ませます (ただし、私はまだ質問を使用しています)。私が考えることができる最善の軽減策は、可能な限り解決策を用意しておくことです。その人は、少なくとも粗雑な強引な答え、または問題の一部に対する答えを書くことができます。何もしないよりはマシだと認識するのは良い兆候です。その後、さらに発見した場合は、より効率的またはよりエレガントなコードを作成できます。可能な限り、二者択一の回答が得られるような質問は避けてください。

あまり代表的なものではありません

プログラミングは、10 分間のアルゴリズムの問題を次々に解決する仕事ではありません。対人関係のスキルは言うまでもなく、大規模なシステムを理解して設計し、長時間集中することに関する仕事はたくさんあります。コードの質問では実際にはこれをテストできません。

ただし、コードに関する質問だけが尋ねられるわけではありません。彼らの経歴、参考資料、オープンソース作品 (ある場合) を調べて、継続的な努力、創造性、対人スキルの証拠を見つけることができます。

小さなアルゴリズムの問題を解決する方法と、それをコードに落とし込む方法を知っていることは、必要条件ではありますが、十分条件ではありません。小さな問題を解決できず、重要なコードを書くことができないのであれば、世の中の大局的な思考を駆使しても生産的な開発者にはなれません。

それなら誰でも解けるよ

いいえ、そうではないようです。として有名な FizzBuzz の投稿氏が指摘するように、新卒者だけでなく業界で長年の経験を持つ人にとっては、些細な罠だと思われるかもしれない問題があります。理由がわからない。コードのテストが不十分な尺度であるか (その可能性はありますが、可能性は低いと思います)、履歴書に記載されているプロジェクトにあまり貢献していないか、そうでないものをコピーアンドペーストすることで多くの成果を上げていたかのいずれかです。アルゴリズムコード (可能です。)

アルゴリズムコードをまったく記述しなくても、実際には多くのことを実行できることを認識する価値があります。人々は、いわゆる「プログラミング」ではなく、グラフィックスやビジネスロジックに価値があるアプリで大金を稼いでいますが、それは問題ありません。しかし、実際にプログラマーが必要な場合、それは適切ではありません。

うまく校正されていない可能性があります

質問を思いついたとき、その答えは簡単に思えるかもしれません。ただし、似たような質問を突然尋ねられた場合、または自分の特定の興味や背景に偏っていない質問をされた場合、それははるかに困難になる可能性があります。

緩和：すでに知っている何人かの開発者に対してテストを実行し、その結果を確認してください。おそらく、すでにチームに所属している、非常に賢い人がそのうちの 1 人に問題を抱えている可能性があるため、調整することを検討できます。おそらく彼らは、より良い、または異なる答えを考えるでしょう。

トリビアっぽすぎる

あいまいな API を暗記したり、構文を完璧に理解したり、自明ではないアルゴリズムの正確な定義を覚えていると人々に主張する場合、コードに関する質問は確かに雑学に入り込む可能性があると思います。これらはすべて、ドキュメント、Web 検索、またはコンパイラエラーに頼って見つけ出すのが合理的であり、実際の専門知識との相関性はほとんどありません。API がどこにある可能性があるかさえわからないということは、その人が最近その API を使用していないことを示す手がかりになる可能性がありますが、履歴書に嘘を書いていない限り、必ずしも問題になるわけではありません。

したがって、これに対する答えは非常に簡単です。つまらない質問をしたり、些細な間違いにこだわったりしないでください。候補者に API の名前を思い出させるか、調べさせます。構文エラーを修正します。データ構造の定義を暗記している人をテストしないでください。

どうやって比較しますか？

候補者が 2 人いて、どちらも質問にうまく答えた場合、どのようにしてどちらかを選択しますか?最も速くゴールした人を選ぶこともできますが、おそらくそこではカメよりウサギを選び始めるでしょう。もう一度ラウンドして、もっと難しい質問をすることもできますが、それについてもわかりません。おそらく、両方に A+ を与えて、他の基準でどちらかを選択しようとする (または、両方を雇用するための資金を見つけようとする) かもしれません。

私が考えることができる詐欺の1つは、他の人の前で「大声でコードアウトする」のが難しいということです。私の肩越しに誰かとタイプするのは難しいと思います。私は一人ではありません。誰かが私にワークステーションに電話をかけて何かを手伝ったとき、彼らは突然タイプミスを作り始め、間違ったコードの完了を選択し、まったく間違いを犯してさえありませんでした。地獄、私は、彼らが観察されていたからといって、カット＆ペースト操作にメニューを使用し始めるのを見てきました。これは通常の動作ではなく、私が話しているコーダーは優れたプログラマーであり、さらに賢いです。

私は最近、インタビュアーが特定の操作をどのようにコーディングするか尋ねて、「数学を見せて」と言ったインタビューを受けました。まあ、私は最初にその数学に到達する前に問題について考えなければなりませんでした。最初は白いボードに置いたものは恥ずかしくて、その時点で負けていると感じました。私は最終的にa-haの瞬間を得て、答えを見つけました（実際、彼が何であるかが最終的に私に起こったとき本当尋ねる）、しかし、私がそこに着く前に私が作った「混乱」は私を非常に不快に感じさせました。それにもかかわらず、私は仕事を得ましたが、インタビュアーが忍耐強くなかったら、私は持っていないかもしれません。

インタビュー対象者にコーディングタスクを提供する場合は、おそらく彼らがよく知っているIDEでさえ、コンピューターでそれを解決するために時間を彼らに与えてください。彼らにあなたのためにコードを書いてからそれについて話させてください。なぜ彼らが特定の方法で物事をしたのか、そして別の方法が良くないかどうかを尋ねてください。そのようなプロセスから（比fig的に言えば）おしっこを目の前のカップに尋ねることよりも、そのようなプロセスからもっと多くを見つけるでしょう。

短所：なし。 PCのセットアップ、コードテストの設計、およびレビューに費やす時間はいつでも、将来的には膨大な頭痛を節約できます。

長所：「信頼しますが、検証」 - ロナルド・リーガン。何度も、人々がついにポジションから手放すのを見て、聞いたことがあります。インタビューでは、あなたがロックスターを手に入れていると思うでしょう。証明はプリンにあります。彼らが何ができるか見たいです。時間とお金を投資して誰かを雇い、新しいプロジェクトを前に貼り付けた後に起こることを表します。

短所：

インタビューに技術者を持つ必要があります

長所：

プログラムできない人の雇用を防ぐと、多くの時間と心痛を路上で節約します

現在の仕事のためにインタビューしたとき、リクルーターによるコードを書くための質問のリストが与えられました。質問は明らかにSQLの深い知識を持っている人によって書かれていたので、私は非常に感銘を受けました。

君は本当インタビューでその人にコードを書いてもらいたい - さらに良いことに、チームのメンバーとプログラムをXの時間（時間/人材で快適に余裕があるものは何でも）にペアリングしてもらいたい。

それは、その人がコーディングできるかどうかを知ることができる唯一の方法の1つです。

ペアプログラミングを少し好むのは、チームの仕事を示し、彼らに実際のIDEと仕事をすることを与え、「本当の」問題に取り組むことができます（ペアの他の人は、インタビュー対象者が環境の詳細を過ぎて導くことができます合理的に知ることはできませんでした）。

私たちはこの雇用ポリシーの使用を開始しましたが、結果に本当に満足しています。

あなたはその羽で鳥を彼/彼女のコードでプログラマーで判断します。

私が現在の会社から始めたとき、私は彼らのために働いています。彼らは、バイナリ入力のパリティビットを生成またはチェックするCコードを書くように頼みました（エンコードまたはデコードするかどうかに応じて）。これは、これらの種類の問題が仕事中に解決されるため、正確にインタビューの質問でした。もちろん、私はパリティチェックではなく、低レベルに取り組んでいることを考えています。

これまでのすべての答え（私が読んだ）は、その事実に対処していませんでした ジョエルのテストは（ただ）起業家のベストプラクティスリストではありません しかし、あなたを容易にするためのチェックリスト 見込み客の雇用主の評価.

事は...彼らが砂糖漬けを徹底的にテストした場合、彼らはおそらく自分のものを知っている人々を雇うことを意味します...それは意味があります あなたのために

頭痛の少ない そしてまた
の可能性の増加学ぶあなたの同僚からの何か

バグがそれらの後に固定する代わりに ...

私は言う：

プロ

履歴書を製造/装飾することができるため、候補者は少なくともプログラミングの知識を持っていることを実証します
インタビュアーが候補者とコードについて議論した場合、筆記試験のようなものであるのではなく、あなたが社会的にどのように「メッシュ」するか、そして候補者が会社/会社に適しているかどうかの良い指標になる可能性があります。候補者に適しています

短所

質問が仕事中には決して出ないだろうというrote/些細なナンセンスである場合、候補者をs辱する可能性があります（例：ジョブで使用するすべての最新のフレームワークが組み込まれている場合、「バブルソートを書く」、「文字列を逆にする」「組み込みがあるとき Reverse 方法など、または書かれたテストの場合、「 Foo の方法 Bar クラス「馬鹿がそれをグーグルで検索することができたとき、またはドキュメントを使用することができるとき）候補者にできることを示すアーキテクチャ/デザインの質問とは対照的に 物事を成し遂げます と ビジネス上の問題を解決します.

1つのプロは、誰かがプログラミングなどの基本的な知識を持っていることを示していることです（私が最後に遭遇したとき、私はSQLの質問がどれほど基本的であるかに驚きました）。また、技術的な議論の基礎として機能し、候補者がなぜそのようなことをしたのか、どのように改善できるのかを尋ねることができます。

インタビューでは時間がかかります。これは他のことに使用できます。さらに、ホワイトボードにコードを書くことは自然環境ではなく、一部の人々はそれについてますます深刻な問題を抱えています。通常のツールや参照なしで緊張する開発者を逃す可能性があります。

プログラミングは非常に技術的なスキルであり、明確な「成果物」がたくさんあります。候補者はそれらを配達することができます。したがって、技術的な質問をする「短所」はありません。「このアプリケーションのコードを見せて、「すでに書いたアプリケーションのコードを見せて」と言うのは完全にです。

そうしないと、次のような結果につながる可能性があります。金持ちは家庭教師にインタビューして、子供たちにチェスをするように教えることを教えました（心を拡大する運動として）。家庭教師は市松模様のボードを開き、64の正方形について話し始めましたが、チェスのピースに触れませんでした。とにかく父親は家庭教師を雇いました。家庭教師は子供たちにチェッカーを演じるように教えました。

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

所属していません softwareengineering.stackexchange