「不正なコード」のインタビューを処理する方法 [閉まっている]

「不正なコード」のインタビューとは、インタビュー対象者に「不正なコード」のスニペットが表示され、それを修正するか、間違っていることを指摘することを要求するものです。コードを読み、その実行内容を把握し、欠陥を指摘するのに時間がかかるため、これらのインタビューに苦労しています。時間的なプレッシャーがある状況では、フリーズする傾向があり、コードが機能しなくても機能するはずです。

この種のインタビューを処理するための良い方法は何ですか？より一般的には、コードをすばやく読んで理解するための良いテクニックは何ですか？

不適切なコードインタビュー（適切に行われた場合）は、次のコードを示します。

• 悪い言語のテクニック（using必要なときにC＃のステートメントを使用しない、またはのArrayList代わりにを使用するList<T>）
• （一体、我々はどこにでも文字列を渡し、または使用している理由悪いデザインの決定refとoutそんなにパラメータ？）
• 構文エラー（これはコンパイルすべきではありません！）
• 実行時エラー（C＃で自分自身を参照するプロパティが原因のスタックオーバーフローなど）

上記の各ポイントを確認する必要があるメンタルチェックリストがあります。コードを見てそれができない場合、それは改善点です。「上手」と主張する言語が何であれ、コードのブロックを見て、これらの4種類のエラーを指摘できるはずです。

私は最近、これらすべての問題を示したコードについてブログに投稿しました。これは、同じ精神プロセスを経験するのに役立つはずです。

Ayendeは彼のWages of Sinシリーズでそれをさらに深くしています。

すぐに理解しようとしないでください。ここでの目標は、コードを第一人者のように理解できるかどうかを確認することではなく、自分の考えを確認することです。

重要なIMOは、単に大声で考えることです。ですから、フリーズしたとしても、「ここで強調しているが、ゆっくりと声を出してみましょう」と言うだけです。

あなたが大声で考えるスキルを持っていると仮定すると、あなたの心を正しくするのに十分に遅くなります。インタビューが十分に精通していれば、彼らはあなたの状況を見て、あなたがはっきりと考えているまであなたを助けます。彼らはあなたを馬鹿にしようとするつもりはありません-あなたがどう思うかを見るための強力なテクニックです。

オッズは、あなたが感じる「時間のプレッシャー」は完全に自主的なものです。それはあなた自身の不安感とあなたがどれだけうまく測定するかを心配することに関係しています。

誰でもできる最高のアドバイスは、リラックスです。時間をかけてコードを見て、見たとおりに見えるものについて話してください。良い部分だけでなく悪い部分についても気軽に話してください。それはあなたの緊張を和らげ、あまりにも多くの時間が過ぎているという内向きの心配を減らすのに役立ちます。

さらに、異なる「パス」を通過すると、特定の詳細を見つけるのが少し簡単になる場合があります。一致しないブレースまたはタイプミスを探す1つのパスを取ります。難読化された行を探す別のパスを取ります。別のセマンティックプレッツェルを探してみましょう。1つのタイプの「間違ったもの」に焦点を当てることで、それらの詳細を見つけやすくなり、（もう一度）十分に速く/十分にやっているかどうかを尋ねる内なる声を減らすことができます。

何よりも、あなたがしていることや考えていることを通して話してください-それはあなたとインタビュアーの両方に役立ちます。

私はこの種のインタビューに参加したことは一度もありませんが、悪いと疑われるかもしれないトリッキーなコードに取り組んでいるとき、私は時々静かに話をします。発声は問題解決に役立つことがあります。また、インタビューでは、実行のステップを図または鉛筆と紙で何かとしてトレースしてみることができます。これは私が学校で働いていたものでしたが、今でも仕事で時々します。YMMV、もちろん...

（明らかなものが表示されない場合）開始するのに適した場所は、「デバッグ」することだと思います。すぐに問題が発生する可能性がある場合を除き、開始するのに適した場所は、テスト値の小さなリストを作成することです。適切な値は、「ハッピーパス」（通常）値、「ゼロ」または「空」値、null、非常に小さい値（1文字の文字列、int 1など）、非常に大きいまたは非常に長い値、およびタイプに固有の「ストレンジ」値（たとえば、文字列のUnicode文字、intの負の数など）。通常、これらの値を使用してコードをテストする単体テストを記述し、それらを実行して関数を検証することを言及しても、ここで問題は発生しません。

ハッピーパスの値でウォークスルーを開始します。追加機能の場合は、3または4から始めることができます。各行のタイプミスや論理エラーを調べて、ローカル変数の値を追跡します。うまくいけば、いくつかのバグを見つけることができます。ハッピーパスを完了すると、コードの使い心地が良くなり、少しでも圧倒されることはないでしょう。たとえば、「このコードが何をしているのかがよくわかりました。後戻りしてそれを確認します」とそれを実行します-あなたが違ったやり方であなたに際立っているものを探します（悪い設計決定、不適切な名前の変数、起こりうるバグの調査など）。

それがどこにも行かない場合、または言いたいことがなくなったと感じた場合は、テスト値のリストに戻り、問題を引き起こす可能性があると思われる新しい値でもう一度調べてください。

これにより、少なくともあなたは行くことができます。

スティーブン・ベイリーが言ったように、面接官があなたの思考プロセスを見ることができるので、大声で考えることはこの状況で優れたテクニックです。何を理解しようとしているのかを説明してください。他にできることは、コードの悪さに関する診断を提供する前に、コードを適切に読み通すことをインタビュアーに知らせることです。私はテーブルの両側にいましたが、これらの状況では双方にとってイライラすることがあります。

筆記テストとして行う場合のプレッシャーが少ない場合は、ノートブックを引き出してメモを取り始めます。私はノートブックを引き出し、インタビューの中で思考プロセスの一環としてメモをスケッチし始めました。ノートとペンがあると、整理整頓されたように見えます。探すべき箇条書きのいくつかの箇条書き、構文、論理エラー、データ型の不一致、ローカル変数の値を書き留める場合があります（リストは、取得したコードのタイプによって異なります。SQLの複雑な部分のリストはプロセスを経るなどして、データ中心ではないコードを手に入れた人とは異なります。これらのいくつかを書き終えたら、それらを探し始めます。そうすれば、インタビュアーが先に進む前にすべての問題を見つけられなくても、彼/彼女はあなたがチェックしようとしていたもののリストを見ることができます。探したいもののチェックリストを事前に作成しておけば、どのものを調べたいかを知ってプロセスを開始することに自信が持てます。通常、これらの質問は、実際にすべてのエラーを見つけるよりも、エラーを見つける方法に関するものです。

私はこのパーティーに少し遅れていますが、使用できるテクニックの1つは、問題のコードの単体テストを作成することです。そうすれば、コードの微妙な問題にあまり集中せず、期待する結果にもっと集中できます。私は、コードのどこが悪いのかをすぐに見つけることができる人よりも、良いテストを書くことができる人を雇いたいです。

次の2つの問題がある可能性があります。

「ストレスインタビュー」http://en.wikipedia.org/wiki/Job_interview#Stressの場合があります。インタビュアーは、職場環境がそのようなものであるため、ストレスにどのように対処するかを確認しようとしています。

または

あなたは自分自身にストレスを感じているかもしれません。その場合、このストレスを管理する必要があります。たとえば、内省し、冷静さを保つ方法を確認します。