新卒開発者からのバッファオーバーフローは許容されますか?バーを高く設定しすぎていませんか?卒業/後輩エンジニアに期待される能力は何ですか?
コンテキスト:
現在、主にLinuxのCで働くジュニア開発者のポジションを募集しています。
プロセスの一環として、候補者はCで暇なときにコードテストを完了する必要があります。
これまでのところ、2つの候補を拒否しました。それらのコードは、読み取り可能であり、ある場合には慣用的なものですが、無制限のバッファー書き込みによるバッファーオーバーフローエラーが発生したためです。
[編集]:
[更新]:
このスレッドと、他の開発者との直接の会話の結果として、コードテストの実行方法と採用の対象を変更しています。
バッファオーバーフローを修正または理解できない候補者は、私たちが実行する作業には不向きであり、特に、私たちが慣れている以上にメンタリングを行うことになると判断しました。したがって、最終的に堅牢なコードサンプルを提出できない候補者は引き続き拒否します。
ただし、採用プロセスは、採用者と候補者の両方の生産性を高めるためにいくつかの対策を講じています。
特に:
[Update 2015-07-09]:NujobのAndy Davisが、候補者の観点からのコードテストの使用に関する興味深い関連記事を書いています。そして記事は一見の価値があります。それを見つけてください ここ 。
バーを高く設定しすぎたとは思いません。別のバーが必要かもしれません。
コードテストは候補者の能力を判断するのに役立つと思いますが、合格/不合格であってはなりません。候補者とのダイアログを開始するには、コードテストの結果を使用する必要があります。
彼らが犯した間違いを見つけた場合(特に、彼らがジュニアデベロッパーの場合)、それらを指摘し、彼らが何を違う方法で行うのか、またはなぜ問題があるのかを理解しているか尋ねます。
ここではジュニア予選が違いを生むと思います。ジュニアは能力についてテストされるべきではなく、彼らは学習能力、好奇心、情熱、倫理、そして間違いなく謙虚さについてテストされるべきです。ジュニアの想定は彼らは有能ではないである必要があります。そうするのはシニアとしてのあなたの仕事です。
明らかに、fizzbuzzのような基本的なコードを記述でき、概念の一般的な知識を持っている必要があります。あなたが彼らにそれを指摘し、彼らがバッファオーバーフローが何であるかも知らなかった場合、then私はそれは行くことはないと言いますが、私はジュニアが5行以上書くとは期待していませんバグのないコードの。
後輩の能力を信頼する日は、あなたの質問されるべき日であり、後輩は多くのメンタリングと「信頼するが検証する」の健全な線量で扱われるべきです。私はかつてジュニアでしたが、当時その場にいたすべての人に申し訳ありません。後輩としてあなたがした恐ろしいことを覚えていますか? (私だけだと言わないでください。私にコンプレックスを与えます。)
ここにいくつかの問題があります。
1つ目は、平均的なコンピュータサイエンスの卒業生が何でも知っていると想定することです。彼らはしません。率直に言って、インストールとセットアップの方法を知っているコンピューターサイエンスの卒業生に会ったとき、私は嬉しいことに驚きました Visual Studio 。ヘック、私は最近、Microsoftスタックで5年以上の経験があると主張している男と協力して、 。NET 何がわからないコードを書いたか [〜#〜] tfs [〜 #〜] だったか、接続する方法。
2番目は、非常に限られたプールです。また、候補者にプログラミングテストを実施してもらいます。彼らが書かなければならない5つの別々の「プログラム」があります。彼らはそれを自宅で行い、コードを発送します。テストは非常にシンプル(データベースなし、外部依存なし)で、Visual Studioの Expressバージョン を使用して簡単に実行できます。テスト自体は、上級者が簡単に約30分で完了します。通常、これらの作業は、最長3年間の検証可能な実務経験を持つ最近の卒業生に対してのみ行われます。
私たちが定量化したのは、テストを受けた人の約70%が、決して私たちに戻ってこないということです。およそ15%は、通常は露骨な構文エラー(たとえば、;
がない)が原因で、コンパイルできないものを提出します。さらに10%はコンパイルされますが、必要なアクションを実行できません。
これはなんと5%です。現時点では、数字が必要な場合に、入力として英字を入力するなどの条件も考慮していません。これは、アプリケーションが適切な出力を行う入力として、非常に限定されたXのセットが与えられている場合に限られます。また、これらの数値は過去4年間で約500人の候補者からのものです。知りたいので統計を保持しました。
管理されていないリソースを適切に破棄したり、try .. catch
ステートメントを使用したりするなど、コード構造や防御的なコーディング手法をさらに詳しく見ていくと、ほとんど誰も合格しません。
もちろん問題は、なぜですか?
なぜ学位を持つ子供この分野のが4年間の大学出身で、簡単なプログラミングタスクを達成できないのですか?答えは、大学はビジネスニーズに完全に対応しておらず、最先端の技術と比較して何年も遅れているということです。 10年前、コーディング標準は、セキュリティが事後にしたようなものでした。ユニットテストはまだ流行っていませんでした。一方、今日のセキュリティは、あらゆる機能や機能強化で頭の中で最前線に立つことができます。覚えておいてください:ほとんどの教授はこの分野で実際に働いたことがないか、OR長い間この分野で働いていません。それがわかったら、彼らがなぜこれほど遅れているのかを理解し始めます。さらに悪いことに、一部の教授は特定のテクノロジー( Java 、 [〜#〜] php [〜#〜] など)に時間をかけすぎて、議論に失敗しているコード構造や許容可能なアプローチなどの深刻な基本的な問題(そしてなぜ!).
ほんの一例です。最近の卒業生は、彼のクラスの1つにモバイルOSを作成した経験の一部について話してくれましたが、基本的な用語でさえ、Webサーバーがどのように機能するかを説明できませんでした。彼は単に知りませんでした。 15年か20年前はおそらくOSの作り方を理解するのに適切な時期でした。今日はそれほどではありません。それでも、これは必須のクラスでした 防御的プログラミング のクラスが彼らにとっても外の世界にとってもはるかに役立つ場合。
どうしようか?
それらの5%のうち、私たちは彼らの個性とフィット感のアイデアを得るために少しインタビューします。次に、約6か月かけてそれらを「再プログラミング」して、教授たちが埋めたがらくたを取り除くという完全な知識のある「最高の」ものを選びます。
私はあなたが問題を間違った方法で見ていると思います。あなたが自問する必要があるのはこれです:候補者が仕事をするために何が必要ですか?ポジションとそれに伴うものを適切に評価する必要があります。以下は、ジュニア開発者を採用する時期と採用しない時期に関するいくつかの提案です。
ジュニア開発者を雇う時期:-簡単な作業が溢れている場合、上級開発者にとっては時間の無駄になります。 -今後数年間にわたってこの人を指導し、訓練する意思がある場合。 -あなたが会社を成長させようとしていて、長期間滞在する人が欲しいなら。 1年間しか滞在しないジュニア開発者は、会社のリソースを浪費し、何も生み出すことはほとんどなく、ほとんどの結果は自分の個人的な成長になります。 -あなたが誰かの成長にお金を使う気がしたとき。繰り返しになりますが、ほとんどのメリットは彼らが学んだことです。
ジュニア開発者を雇わない場合。 -作業が複雑すぎる場合。この場合、それは彼らのリーグからちょうど外れています。 -お金を節約したいとき。上級開発者は、同じタスクをほんの少しの時間で完了し、より良い品質の結果を得る必要があるため、常により安価である必要があります。 -業務が外部委託可能である場合、または従業員を忙しくするのに十分でない場合。このような場合は、作業の一部を民間の請負業者に委託するほうがよいでしょう。
最後の重要なポイントです。若手開発者を雇ってはいけません。なぜなら、「私たちが手に入れることができるすべて」、または「それが私たちが喜んで費やすすべて」なので、彼らが仕事に適さないときです。結局、あなたがやることになるのは、トイレにお金を流すことだけです。その上、彼らがそれらのスキルを身につけたら、彼らはとにかく大金を要求するでしょう。
私について:
他の人が述べたように、ジュニアポジションはCの経験がほとんどない可能性があります。私は個人的にはCのバッファーオーバーフローについて少しだけ教えられました。バッファオーバーフローを作成すること自体)。おそらく、ジュニア開発者の多くは、バッファオーバーフローを知っている可能性のある同様の状況になりますが、広範な方法でそれらを識別して処理する準備ができていません。
これを踏まえると、適切な対応は、問題を次の可能性のある相互作用で取り上げて、全体的な知識をテストするためにバッファオーバーフローについて知っていることを尋ねることです。その後、本番用の想定コードで1つ見つかったことを伝えます。これは、修正や指示に対して彼らがどのように反応するかを判断するための優れたウィンドウを提供します。
知識は少ないが学び、改善できる意志のあるジュニア開発者は、知識はあるが改善できない、または改善しないジュニア開発者よりも価値があるという一般的な考えではありませんか?
そうは言っても、コメントの1つで、コードを使用した場合のバッファオーバーフローを指摘するテストを渡したとおっしゃっていました。おそらく、もっと大きな問題は、なぜテストを実行しなかったのか(実行したのに、なぜバグのあるコードを提出したのか)でしょうか。
バッファオーバーフローは絶対に許されません。対応するコードの質問があるかもしれません。このコードですべてが間違っている(間違っている可能性がある)場合、候補者は問題を正確に特定できるはずです。 とにかく、クリントを実行しているので、問題が無関係であるかどうかです。
ただし、人工的な自由形式のコードテストでは、sprintfのような違反は軽度です。あまりにも短い時間(想定)、多動性、何か動作するものを提示する衝動が大きすぎます。
あなたは間違った質問をしていると思います。プロのプログラマーになるための客観的な障壁はありません。もしあれば、標準のプログラミング試験がありますが、ありません。個々のバーは、どれだけうるさくて余裕があるか、どれだけ支払う余裕があるか、ソフトウェアが許容できる失態がどれだけあるか、そして教えることに費やすことができる時間に基づいて設定する必要があります。
この場合、バッファオーバーランはおそらく、候補者が模範的な作業のサンプルとして提示したこのコードが、要求したことを実行する代わりにセグメンテーション違反でクラッシュすることを意味していると思います。それで、あなたが要求したことをする代わりに、セグメンテーション違反でクラッシュするコードを書くコーダーを受け入れるべきですか?尋ねる:
あなたの組織はできる動作するコードを書く人を引き付けることができますか?
ほぼコードを書くことができる誰かがピアレビューとテストサポートの助けを借りて実用的なコードを書くことができるように、開発プロセスは十分に堅牢ですか?
ある種のプログラマーにプログラマーになる方法を教えることができますか。その努力を費やして、おそらく数年待って、候補者の内面の才能が実を結ぶことを望んでいますか。