オーバーエンジニアリングは警告サインですか？[閉まっている]

そのため、いくつかの明確に定義された要件を備えた新しい候補者に、簡単なコーディング演習を提示します。時々、実際に目の前の問題を解決することはできませんが、認識された問題を解決するために過剰に設計されたソリューションを受け取ることがあります-多くの場合、演習の範囲外です。

さて、私の質問は、これは警告サインですか？

編集：議論のかなりの部分は、テストの欠陥に基づいています-これは公平な点です。コメントで説明したように、テストの基本的な前提は、ファイルからデータを賢明な方法で読み取る方法を示すことです（そして、私たちが見るさまざまなアプローチに驚かれることでしょう）。更新間の待ち時間を計算する前の項目。これが機能するためには、データについて特定の前提条件を作成する必要があり、これらの前提条件を探します。また、2時間ですべてのアプローチ（OOアプローチなどを含む）を見たいと明示的に述べています。時間枠。

私見、私がインタビューしたとき、それは私が出くわした中で最も完全な運動でした。

私が熟考している特定のシナリオは、ファイルから読み取るのではなく、候補がマルチスレッドアプリケーションで「ネットワーク」入力を受け入れた場合です。これは明らかに範囲外です。

問題は、テストが歪んでいることです。あなたは、数分しかかからない簡単な演習を使用して、複雑なエンタープライズレベルのソフトウェアを書く能力を実証するように誰かに求めています。他の企業には、これらの演習では候補者がオブジェクト指向設計のスキルを十分に発揮していないと不満を漏らしているため、人々が過大に補償する傾向があると他の面接官がいます。それは必ずしもあなたの候補が状況がそれを正当化するときより簡単なコードを使用できないことを意味しない。

候補者に当てはまるかどうかを知りたい場合は、やり直してもらい、具体的なガイドラインを示してください。「あなたはオブジェクト指向のデザインスキルを披露していたことがわかりますが、このような単純な問題ではやり過ぎのようです。2つの小さな機能だけを使って書き直せますか？」

これは明確な警告サインですが、必ずしも候補者の失格とは限りません。

候補者が抱えていると思われる2つの問題があります。

1. エクササイズのポイントを見逃している -これはかなり憂慮すべきです。誰かが適切に解決している問題を投げることができない場合、世界のすべてのプログラミングスキルは良い結果を生み出しません。最も生産性の高いエンジニアは、解決すべき真の問題を特定できるものであることがわかりました。尋ねられている質問について批判的に考え、おそらくそれをより簡単に解決できるものに再定式化する能力を持つことは、批判的なスキルです。問題が明確に述べられている時点を見逃すことは、大きな赤い旗であるべきです。
2. ソリューションのオーバーエンジニアリング -これは二次的な問題であり、多くの場合、最初の問題の結果です。この結果をもたらす可能性のあるいくつかの異なる病状があります。まず、問題を適切に理解していないか、広範にキャストしすぎると、ソリューションが複雑になりすぎる可能性があります。これは、上記の最初の点と明らかに関係しています。第二に、実際には関係がないかもしれない将来のシナリオを熟考することによって「誇示する」ことを試みること。これは、候補者がソリューションの単純さの価値を理解しておらず、本当に必要になるまで複雑さを延期していないことを示しているため、問題になる可能性があります。これは適切なガイダンスで修正できるものですが、組織に誰かを連れてくる際には注意が必要です。

プロセスの過程で候補者の回答についてフォローアップすることをお勧めします。結果を単に見るのではなく、何が結果につながったのかを確認し、いくつかのガイダンスを与えて、彼らがどのように応答し、答えを変えるかを考えてください。これはおそらく、問題に対する彼らの直接的な対応よりも、彼らの能力についてより明らかになるでしょう。彼らのアプローチの「理由」は、彼らがちょうどそれを得ていないのか、または彼らが応答することを選んだ方法で彼らの理解がほんの少しずれていたかの感覚をあなたに与えることができます。この種のフォローアップは、問題解決への全体的なアプローチについても明らかにします。

また、問題自体を再検討し、それが不明確で、おそらく人々が答えを定式化するときに間違った方向に進んでいるかどうかを確認します。

いいえ、就職面接ではありません。インタビュアーが多すぎると、要件を意図的に過少に指定し、インタビュイーがさらに質問をすることを期待したり、明示的に言及されていない現実の問題に注目したりすることを期待します。

ここに、あなたの要件がおそらく言及しなかったいくつかの事柄を、私の頭の一番上にあります：

• コーディング標準

• コメント

• 例外処理

• 変数、クラス、メソッドの説明的な名前

• 言語の慣用的な使用法に従う

• 適切なオブジェクト指向設計

• 並行性の問題の可能性への注意

• コードのテストケースを書く

明示的に述べずに、これらの1つに注目しましたか？候補者は、あなたが関心のあるものとそうでないものをどのように知るのでしょうか？

インタビューは高度に人工的な環境です。インタビュアーは、聞き手が聞きたいことを伝えるのを難しくするために、候補者を少し「だまそう」とすることが多く、インタビュイーは面接官が本当に望んでいることを推測しようとしています。

一般に、その推測で間違いを犯すことは、現実世界の設計決定で間違いを犯すこととはかなり異なります。誰かが物事をオーバーエンジニアリングしているかどうかを知りたい場合は、非常に人工的なコーディング演習を見るのではなく、設計について話す必要があります。

私見の答えは明らかにはい、それは警告サインです、

• コーディング演習には明確なタスクがありました
• 明確に定義された（また、よく書かれた）要件を持っています。
• 候補者は質問をして、正しい問題を確実に解決する機会がありました。
• 建築の宇宙飛行士ではなく、賢くてチームで物事を成し遂げる人々が必要です。

目前の問題を解決しないほどの警告サインではありません。彼がクイズに失敗し、正しい解決策を提供しなかったという事実は、警告サインです。彼が正しい解決策を提供しなかった方法と理由に依存するため、必ずしも失敗しないシナリオではありません。

多くの場合、質問は完全にくだらないものであり、単に答えられません。インタビュアーが間違いを犯さないと偽装しないでください。なぜ質問がくだらないのかを突き止めるのは、彼の側の失敗です。要件の作成を支援することが期待されているエンジニアを採用している場合、これは問題です。コーダーを雇っている場合、彼がそうすることを期待しないでください。

コーディングの練習が恐ろしく台無しにされていないと仮定すると、彼が失敗した方法は問題を誤って解釈し、そこにない問題を解決しようとして雑草に出ていたようです。はい、それは警告サインです。

多分。

もちろん、問題を解決しないことは、何かが間違っているという明確な警告サインです。何が悪かったのか？彼らは問題を誤解したか、悪い解決策をとった。単純なものに対する悪い解決策は、候補者が貧しいという明確な兆候です。

彼らが問題を誤解している場合は、要件をよく見てください。あなたにとって非常に明確に見えるものでさえ、ドメインに不慣れな他の人や、異なる背景（ロケール、年齢、生い立ち）からは不明瞭かもしれません。候補者があなたと一緒に部屋にいた場合、または質問する機会を提供し、それでも失敗した場合、私は彼らの側の失敗と考えます。要件が壁を越えて投げられた場合、私は彼らに疑いの利益を与える可能性が高いです（そしてインタビュープロセスを修正することを考えてください）。

解決策が正しければ、それはあまり明確になりません。個人的には、多くの人がYAGNIを使いすぎていると思います。複雑さを増したり、保守性を損なうことなく、特定の問題を取り上げて一般的なソリューションを作成できる場合は、一般的なソリューションを作成してみませんか？（文字列を逆にするのとコレクションを逆にするのを考えてみてください）この種の「過剰なエンジニアリング」は、私の意見では明らかに良いことです。

他のすべてはその灰色の中間点です。ソリューションは変化の可能性のある軸に対処していますか？ソリューションは複雑さを増したり、保守性を損なったりしますか？少しの複雑さを追加して、将来の問題を解決します。これは、ほぼ確実に勝利を収めることが保証されています。まったく起こりそうにないことを説明するために保守性を大きく損なうことはありません。

優れたソフトウェアエンジニアであることは、ここで適切なバランスをとることを意味します。優れたインタビュアーであるということは、候補者がそのバランスを選択した方法と理由について正しい判断/推論を行い、しばしばインタビューの他の部分を使用して評価することを意味します。

たぶん、しかし、次の点を考慮します。

• インタビューは難しい：人々はストレスにさらされている。これは、あなたが誰かに与える問題に重く考慮されるべきです

• 要件の長さ：要件はどのくらいの長さで簡単ですか？すべてを含めるために、それらを余分に冗長にしましたか。結果として、それらはあなたには明らかかもしれませんが、要件はおそらく過剰に設計されています！比較的簡単な問題について、約3ページのテキストを使用して、1時間に1回問題のある面接を受けました。そのテキストはすべて、インタビューで読みやすく解釈するのが難しく、誤って解釈されることもあります。

• ときどきLess is More：いくつかの箇条書き、文章、または主な要件を示す例があります。その後、必要に応じて質問をしたり、たぶん道を進んだりするために誰かと話し合ったりします。私が言いたいのは、単純な問題のためにテスト要件が過度に複雑ではないことを最初に確認する必要があるということです。

• コミュニケーションスキル：最初に問題についてコミュニケーションし、インテリジェントな質問をする候補者の能力をテストする必要があります。問題を理解していることを証明したら、実装について説明します。

• 結論：問題が理解されていることを確認していない場合、オーバーエンジニアリングをどうすればよいか本当にわかりません。他の人が言っているように、それは良いことでも悪いことでもありますが、前もって問題について理解を確認したり、候補者とコミュニケーションを取ったりしなかった場合、問題の一般的な理解とそれをどうするかを知ることは難しくなります。

これの多くは、質問をどのように表現するか、インタビュー全体をどのように見通しに入れたかに起因している可能性があります。

「あなたがどれだけクリエイティブか見てみましょう。2+ 2とは何ですか？」四？あなたが思い付くことができるのは、最も単純で、明白で、正確な答えだけですか？インタビューで感心したい若い/エントリーレベルの開発者は、「あなたのコーディングスキルをテストするか、プログラマの素晴らしさを確かめたい」と考えます。「非常に洗練された何かをする」という意味です。物事をより難しくする場合を除いて、私たちは皆、単純なものが最良であると考えています。

誰かが常に物事をオーバーエンジニアリングする傾向があるかどうかを確認する方法があります。複雑すぎるもののコード例を示し、より簡単な解決策を求めてください。誰かがあなたがうまくいかないと思う解決策を提供するとき、これは彼らが批判にどのように反応するかを見る絶好の機会です。個人的には、誰かが新しいアイデアを受け入れ、同じ間違いを何度も繰り返す人よりも良い解決策を認めることを望んでいます。

そして実際には、コードが機能しないときにコードを変更する機会は常にないのでしょうか？最初は設計不足または設計過剰が可能です。簡単な解決策に気づいたら、実装する方が簡単ではないでしょうか？

それは依存しますが、通常はありません。

一般に、デザインは経験から学んだスキルです。マルジャンによってリンクされたその進行についてのアーロンノートの説明は、一般的に良いものです。

どんな形式のコミュニケーションも、コンテキストに大きく依存します。1つのコンテキストで1つのことを意味することが完全に明確に見えるかもしれませんが、別のコンテキスト内で他の何かを明確に意味するかもしれません。どの質問をするかを知ることも、経験によってもたらされます。

彼らの思考プロセスと彼らがどのように彼らの決定について推論するかは、彼らのソリューションよりはるかに重要です。彼らのソリューションと彼らの決定を検討しないと、それが開発されたコンテキストを完全に評価することはできません。

上記の進展を考えると、過剰に設計されたソリューションを備えた候補者は、単純なソリューションを備えた候補者よりもずっと先に進む可能性があります。

また、あなたはどのレベルのポジションに雇用していますか？エントリーレベルまたは中級レベルの候補者からの過剰設計は、上級レベルの候補者からの過剰設計よりも問題ではありません。

プログラマーが問題を解決しなかった場合、余分なコードはすべて、非応答を難読化しようとするコーダーの試みです。これは、主題についてあまり知らない学生がエッセイテストで使用するのと同じテクニックです。彼または彼女は、彼の無知が単語数によって隠されていることを期待して、説得力のある、しかし無関係な問題についてとりとめなく話します。

プログラマーが問題を解決したが、さらに多くのコードを追加した場合、プログラミングの一部の領域は他の領域よりも高い許容度を必要とするため、プログラマーの背景を考慮してください。

たとえば、商用旅客機で自動操縦を実行するコードは、無料のAndroidゲームよりも障害に対する許容度がはるかに低くなります。到達が難しく、更新がほとんど不可能な組み込みデバイスのプログラミングに慣れている開発者は、1日に15の更新をプッシュできる開発者よりも多くのwhat-ifをコーディングする傾向があります。