インタビュアーがコードを読むように申請者に求めないのはなぜですか？[閉まっている]

私は人生で数十回のインタビューを受けました（卒業しようとしています）が、なぜコードを読んで説明するように一度しか頼まれなかったのでしょうか。大体、90％の仕事は既存のシステムの維持に関するものです。他の人のコードを読み取るIMOの能力は重要なスキルです。

インタビュアーがチェックしないのはなぜですか？*

* _{友達の中では、コードのレビューを依頼されたのは私だけです。}

インタビューの質問をしていたとき、最初はやりましたが、徐々に段階的に廃止しました。面接でコードを上手に書くことができた応募者はすべて、面接でコードを上手に読むことができました。コードを読むことができなかった申請者もそれを書くことができませんでした。コードの読み取りに関係する質問は、実際に応募者を区別しませんでした。

短縮版

ジョブがアプリケーションの保守で構成される場合、面接中にテストする必要があるスキルは次のとおりです。

• ドキュメント、単体テストなどで大規模なコードベースを理解する能力

• コードをリファクタリングし、すべてを壊すことなく変更をもたらす機能。

コードを読むように人々に頼っても、それらの能力を評価するのに役立ちません。

ロングバージョン

コードを書くように頼まれましたか？はいの場合、サインが彼の答えで述べたように、これで十分です。少し一般化すると、明確でわかりやすいソースコードを書いた人は、他の人が書いたソースコードを読むことができるでしょう。

あなたがコードを書くように頼まれなかったなら、あなたはおそらく人事部の人からインタビューを受けたでしょう。そのようなインタビューはあまり技術的ではなく、ほとんど価値がありません。なぜなら、彼らはあなたのスキルとあなたの能力がうまく機能しないからです

メンテナンスジョブのコードを読み取らないようにするには、さらにいくつかの理由があります。

1.確実に行うのは難しい

具体的には、インタビュアーだったらどうしますか？候補者にコードを読んでもらいます。どのコード？どの言語で？どれくらい上手く書かれているか？コメントの有無にかかわらず？ドキュメントの有無にかかわらず？

さらに重要なことは、候補者について何を伝えているのですか？コードベース自体とどの程度相関していますか？

保守するレガシーVB.NETアプリがあるとしましょう。あなたは、ソースコードがほとんどくてテストされていないこと、そしていくつかのコメントが時代遅れまたは誤解を招くものであることを知っています。過去3か月間、非常に熟練した開発者がソリューションに取り組んでいました。彼はアプリケーションの最も重要な部分をリファクタリングし、ユニットテストを行い、コメントが必要な箇所にコメントを追加し、最も重要なこととして、アーキテクチャ全体、重要な部分、落とし穴に関する詳細なドキュメントを作成しました。

このコードベースを維持するために開発者を雇っています。インタビュー中に、レガシー（テストされていない）コードを提供しますか、それとも前の開発者によってリファクタリングされたコードを提供しますか？

ドキュメントを提供しますか？ドキュメントを読むために、候補者は少なくとも数時間を費やす必要があります。これにより、インタビュー中に行うことができなくなります。

2.短いコードを読むことは、おなじみのプロジェクトのコードを読むことと同じではありません

覚えておいて、仕事はプロジェクトを維持することです。プロジェクトに慣れていない最初の数日または数週間は、大きなコードベースを維持することは困難です。すべてのドキュメントを書き、コードベース全体を明確に把握できれば、数か月後にそれを行うのははるかに簡単です。

テストするべき最も重要なことは、その月に人が効率的になるかどうかです。最初の2日間でその人が何も理解できなくても構いません。

短いコードを最初から読むように人に頼むことは、この人が何千ものLOCの使い慣れた文書化されたコードに対処する方法をテストすることではありません。

3.ソースコードの維持は、単に読むだけではありません

コードベースを保守しているとき、それを変更しています。コードを読むだけの開発者は、彼の会社にとって何の役に立つものでもありません。

便利なスキルがする機能ですリファクタリングコードする、ユニットテストを追加し、変更の影響を予測するなど、あなたがインタビューの中で、コードを読むために人を尋ねることによって、それらのスキルをテストしていません。

読書は、書く能力が存在するという事実に基づいた仮定です。任意の言語の概念を検討してください。プログラミングは、人間と機械の間で通信するための単なる言語です。人間同士のコミュニケーションを考えてください。日本語の通訳をする人を雇っているなら、特定のトピックについて1,000語のエッセイを書いて読めると考えるのは理にかなっていないでしょうか？

プログラマーとしての主な活動は、コードの作成と抽象的なアイデアの具体的な実装への変換です。これは一般的に書くことを意味します。読書も同様に重要ですが、ほとんどの場合、書き込み能力が存在する場合、読み取り能力も存在します。際立った違いを見ることができる唯一の実際のケースは、時間の経過とともに進化した非常に複雑なケースが多数ある環境です。ただし、これらを与えられたとしても、少なくともある程度の勉強をしなくても、誰かがそれらを読んで理解できるとは思わないでしょう。

また、コードを読んで、考えていることを説明することは、クリティカルシンキングスキルをどのように使用するかをインタビュアーに実際には表明しません。それは少し分析を示していますが、ほとんどの雇用者は、あなたが箱に入れられずに考えることができるかどうかを見たいです。彼らは、既存のコードの利点なしで（または松葉杖でも）概念を把握して、何をどのように行うかを伝えることができるかどうかを知りたがっています。

過去に、コードを読むことはインタビューで実証されるべきだと思っていましたが、時間が経つにつれて、これはインタビュアーとインタビュイーの両方にとって時間の無駄であることに気づきました。どうして？悪いコーダーでもコードの断片を読むことができるからです。

誰かのコードを読む能力を判断できるようになるのは、複雑なものを見たり、多くのクラスやファイルにまたがるコードを見たりするときだけです。コードが何をしているのかを把握するためにトレースできるのは望ましい特性ですが、誰かが良い例（本番コードではない）を考え出すのに十分な時間がないか、インタビューでそのような質問をする時間がありません。

そのため、悪いコーダーはコードを読むことができますが、コードをうまく書くことはできません。候補者の仕事の例を見てもらうか、インタビューで候補者にコードを書くように頼むことは、彼らのスキルのより良い指標です。簡潔で簡潔なコードを記述できれば、コードを読むことができる可能性は十分にあります。

インタビューしているすべての候補者に、FizzBu​​zz問題のバリエーションを尋ねます。それは速くて簡単で、通常、私が見つけた他の何よりもはるかに速く悪いコーダーを選ぶことができます。優れたプログラマーは、非常に迅速かつ簡単にそれを入手し、コーディングスタイルと思考プロセスをすばやく確認できます。