人のデバッグスキルを確認または評価する方法 [閉まっている]

コードを簡単にデバッグできる人をどのようなスキルが決定しますか？しばらく前、私の友人が比較的優秀なプログラマーとのインタビューを実施しました。プログラマーが雇われました。彼は良いコードを書き、フレームワークとデザインパターンを理解できました。彼が見逃していたのは、デバッグスキルです。彼はまったくデバッグできず、彼または他の誰かのコードの問題を見つけることは彼にとって大きな苦痛でした。

それ以来、人のデバッグスキルをどのように評価または推定できるかを考えています。

それで最初の質問は、人がソフトウェアを効果的にデバッグできるかどうかを決定するスキルは何ですか？

2番目：インタビュー中にこれらのスキルをテストする方法ですか？

その人が最初にしたいことは、コードを見てデバッガーでステップ実行することである場合、その人は素晴らしいトラブルシューティングではありません。

まだアクションの計画がなく、デバッガーブラインドに飛び込む場合、基本的にイースターエッグです。これは、あらゆる種類のトラブルシューティングに当てはまります。

インタビューの状況では、システムの動作方法を尋ね、システムの履歴について尋ねる人は、適切なトラブルシューティング担当者になる可能性があります。最初にシステムを考え、次にメカニクスを考える人は、良いトラブルシューティングになる可能性があります。

これは、複雑なシステムに当てはまります。

特定の言語またはフレームワークの優れたソフトウェア開発者の最善の尺度は、複雑な問題を批判的に分析し、その言語またはフレームワークで優れたデバッグスキルを身に付ける能力だと主張します。一般的なデバッグツールを使用して、低レベルのデバッグと高レベルのデバッグの習熟度を実証できる必要があります。

これは、選択したIDEでデバッグツールの高い適性を示すシナリオを作成することを意味します。次のようなものを探す必要があります。

• サンドボックスアプリケーションまたはサーバーをデバッグモードで実行するか、デバッグ用のシンボルを使用してアプリケーションを構築する

• リモートデバッグポートを利用可能にし、デモンストレーションするか、シンボルで構築されたサンドボックス化されていないアプリケーションのデバッグ（言語に該当する場合）

• ブレークポイントの戦略的使用

• ブレークポイントのカスタムプロパティ、ブレークポイントの条件式（言語に該当する場合）

• 変数値または参照を監視するための式または変数ウォッチの使用

• リアルタイムのアドホック変数値または参照またはポインター操作の使用

• アプリケーションフローにステップイン、ステップオーバー、ステップアウトする能力を実証する

• 呼び出しスタックの重要な評価

• マルチスレッドアプリケーションのデバッグとこれの理解。

ログやソースコードの分析、IDEを使用せずに低レベルのデバッグを実行する機能など、ツールを使用しない他のデバッグ戦略も実証する必要があります。

あなたのシステムにあったバグを、インタビューの文脈で議論できるものに蒸留するのはいいと思います。デバッガーを起動して、彼に任せてください。

彼に次のような質問をしてください。

1. どのように問題に取り組みますか？

2. あなたがした複雑なプロジェクトの1つは何で、どのように達成しましたか？

3. どのデバッグツールを使用しましたか？

4. 特定のツールを好みますか？

5. あなた自身のシナリオの例を挙げて、彼がどのようにそれに取り組むか彼に尋ねてください？

6. 他の人のコードを取得する能力をどのように評価しますか？

質問することで懸念に対処できます。特定のスキルが得意な場合と得意でない場合があります。しかし、彼が良い学習者であれば、それは大いに役立ちます。

プログラマがデバッグできるかどうかを確認したい場合は、修正するコードを提供します。あなたが彼らがコードを書くことができるかどうかを見たいなら、それは同じアプローチです。彼らに問題を与えて、彼らにコードを書かせてください。

今、私はコードを書くのに問題はないが、デバッグを求められたときに悲惨に失敗するこのプログラマについて混乱しています。この人はコード例を逆流するのですか、それとも単にデータベースの読み取りや書き込みのような経験がある領域にこだわるのでしょうか？初めてコードを正しく取得しない限り、修正できませんか？

たぶん、その人はデバッグが好きではなく、努力もしませんか？私はこれが得意ではないので、それをするように頼むのをやめてください-無力を学びました。

既存のコードベースで作業するには、コード、ドキュメントを調べ、場合によっては独自のメモや設計を作成する必要があります。

デバッグは失敗した製品コードを修正することだと考えていますが、コードを書いている間にコードをデバッグする必要があります。この人はあまり優れたプログラマーではないか、単に新しいコードを書くことを好みます。みんなしないで。

同じ方法で、誰かのコーディング能力を判断し、デバッグについて質問します。

特定の状況でバグを「どのように」追跡するかを尋ねます。

さらに一歩進んで、コンピュータの前に座り、問題をデバッグするのを見てください。

私はしばしば候補者に仮想の状況を与えました...例えば、実動システムが応答を停止しました。職業はなんですか？「ログを確認する」と答えるかもしれませんが、「問題が発生し始めてからログに何も書き込まれていないことを除いて、ログには異常は表示されません」と言います。候補者の問題解決能力を評価したことに満足するまで、それは続きます。

通常、適性の良い人もデバッグのスキルが高い人です。

面接中に（彼らの年功に応じて）アルゴリズムなどのパズルのような課題を割り当てることができます。それは簡単な方法です。

可能であれば、作業からコードを印刷して、ここで何か問題があるかどうか、もしそうならそれを修正する方法を尋ねてください。

私は、構文を読んで修正する人々の能力に焦点を当てる傾向がある難読化されたインタビューの質問をすることを好まない。

インタビュー中に、過去に修正したバグと、それをデバッグする際に使用した手順について説明するよう依頼します。

彼らに彼らの最後の仕事、宿題などで何をしたか、そして彼らが問題を見つけるのに何を経験したかについてあなたに話させます。

デバッグの候補者スキルのテストに関する新人の視点と経験を共有します。私はかつて3つのステージがあるインタビューを受けました。第二段階は「実践的なケース」でした。その瞬間、私はそれ以上知りませんでした。そこに私は知らされたが、動作を停止したシステムがあり、彼らは知らない。いくつかのバグが背後にあります。

古いテスト環境へのリモートデスクトップとして配置されました。おそらく、接続されていない環境または隔離された環境です。このプロジェクトは、ASP.NETコントロールと関連するコードファイルコードを含むいくつかのWebフォームでした。コードファイルは、dllのみを持ち、ソースコードとメソッドの説明がないビジネスレイヤーの一種を参照していました。Webformsは、期待できるCRUD機能を実行しました。また、小さな検索機能。ビジネスレイヤーは、SQLサーバーのビューとSPと対話しました。

彼らは異なるレベルでいくつかの部品を壊しました。症状のある論文をもらいました。「検索できません」「「地域」フィールドは最後の更新後に消えました」など。ユーザーから受け取ることができるようなもの。

詳細はすべて覚えていませんが、少なくともテーブルフィールドの名前が変更されたため、検索機能で使用されたSPが破損しました。これは、VSにエラーがなく、フィールド名をトレースするBLソースコードがないことを意味します。Sqlcommandに対するSELECTパラメーターのスペルが間違っていて、Webフォームが誤動作しました。また、GridView（Autogeneratecolumns）で欠落しているフィールドであるフィールドが省略されました。ASP.NETボタンは、複製され、強化されたメソッドである必要があり、ボタンを新しいメソッドにポイントすることを「忘れた」ものと呼ばれていました。

また、htmlタグでタイトルを使用して許可されていないようなマイナーなもの。また、反対のALTタグは、それを必要とするコントロールで省略されました。また、不正な閉じられたhtmlタグに関するエラーもありましたが、誤動作はしませんでした。これらすべてが純粋なプレイハウスプロジェクトエラーであるか、あるいは異なる採用のための同じプロジェクトであるかどうかはわかりません。私は尋ねなかった。もちろん、難易度はリクルートのニーズと一致する必要があります。

このようなテストは、面接後、デバッグがどのように行われたかを確認するために、おそらくスクリーニングする（従わない）必要があります。その段階での私にとっては、テストが少しばかげているとわかりましたが、それも大きなポイントです。もしそうであったか、そうでなかったなら、候補者を適切な場所に持っていく価値があるはずです。

* 私は、そのテストは*に候補/私のスキルが証明されたと思います
*外国システムを分析する
*使用して、エラーやバグを見つけるのは情報の最小を
、あなたは、コードが修正を想定し、時間のストレス下では、誰かの助けなし*
知識の異なるレベルを*;
** SQLデータベースとストアドプロシージャ、
**プロジェクトでのdllの使用、
** asp.netテクニック、
**階層化アーキテクチャ
**問題指向の側面

しかし、開発者環境の処理、DBサーバー管理ツールの検索と理解など、より明らかなこともあります。紙の上では本当に見栄えの良い候補は確かにありますが、実際にはそのようなタスクにこだわる可能性があります。

私は、その職務に関連する実際の問題を見つけて、それが提示されたとおりに候補者に提示します。もちろん、私は彼らにいくつかの一般的な背景と、コードスニペットや回路図のような関連ドキュメントを少し提供します。

私は彼らに彼らの仕事は問題を解決することだと言い、彼らが持っている技術的な質問に答え、彼らが実行したい実験の結果を伝えることを申し出ます。「ここにスコーププローブを入れます」と言ったら、彼らが見つけるかもしれないものの痕跡をスケッチします。printfループにaを挿入したい場合は、ループが出ない（！）か、最初に「7」を出力してから「5」を繰り返し出力することを伝えます。彼らが雑草の中であまりにも離れて意味のある答えを出すことができない場合、私たちは間違った道を歩み、他の場所に戻っていることを認めます。それらが行き詰まったら、先に進む質問をするか、先に進むまでヒントを出します。

私が見たいのは、秩序だった思考プロセス、解決策を得る決意、よく考えられた質問と実験、そして理想的には問題の特定の成功です。場合によっては、1時間のインタビューで誰かが完全にデバッグするには複雑すぎる問題を選択し、最後に本当の答えを出します。その時点で、私は彼らが問題に関与していることを示す反応を探しており、その「アハ」の瞬間と原因に到達することへの満足を経験しています。最高の候補者は、その時点で自発的にフォローアップの質問をし、問題の精神的な地図を実際に起こっていることと結び付けようとします。

nullポインター参照またはそのような+ソースコード+ gdbでセグメンテーション違反をするいくつかの単純なバイナリ（デバッグ付き）シンボルを使用してコンピューターに座って、クラッシュの原因を見つけることができるかどうかを確認しますか？

候補者に予備的なコードテストを実施してもらう場合は、面接中にバグを解決するか、新しい機能を追加するか、またはその両方を行うためにコードを修正するよう依頼してください。コードテストの仕様をかなり曖昧にすると、その時点で「バグ」を含むテストケースを作成しやすくなります。

小さなコードスニペットで「バグ」を見つけるのは非常に人為的な状況です。パズルや頭の体操と同じように役立つと思います。

より包括的なアプローチは、候補者が過去に特定のインシデントを引用してどのようにデバッグを実行したかについて行動の質問をし、その後質問でフォローアップします。

トラブルシューティングが得意な人は、IDEの単なるデバッグ機能以上のものについて話すことができます。バグ報告ツール、エンドユーザーの対話、バグの再現、ログファイルの分析、検証についてはどうですか？

デバッグには、コードのブロックをトレースするだけでなく、デバッグのスキルの評価が影響するはずです。

あなたの会社が運用環境で実行している素晴らしいコードを誰かに提供してください。微妙なバグを紹介してもらいます。彼らにその1つを選んだ理由を尋ねます。見つけて修正する方法を尋ねます。

元のコードにバグが見つかった場合のボーナスポイント。

元のコードのバグを修正できる場合は、ダブルボーナスポイント。

私は人々に、今まで追跡して修正しなければならなかった最も難しいバグと、それを見つけて修正するために何をしたかを説明するように頼む傾向があります。また、最も難しいバグが、初心者だけが難しいと思うようなものであった場合、それは良いトラブルシューティングではない可能性が高いことも知っています（これがエントリーレベルのインタビューでない限り）。それが本当に難しいものであり、彼らがそれを追跡しようとしたときの思考プロセスを説明している場合、私は彼らのスキルレベルが何であるかを感じることができます。常に私を驚かせたのは、「ヘッドライトの中の鹿」の外観を取得し、彼らがやった複雑なことの単一の例を考えることができない人々の膨大な数です。大変申し訳ありませんが、他の誰かが解決するために難しい問題を残している人は、私が学校以外の何かに興味がある人ではありません。

次のようなテクノロジーにとらわれない質問をいくつかします。

• 根本的な原因を特定し、バグ（欠陥）を修正するために行うすべての手順を実行してください
• マルチスレッドアプリのデバッグ中に呼び出しスタックをどのように使用しますか

これは電話インタビューで特にうまく機能します。問題をトラブルシューティングする際に、彼が本当に物事をどのように示しているかを示す説得力のある答えを与えるだけでいいからです。