過剰設計は警告サインですか？
したがって、いくつかの明確に定義された要件を持つ新しい候補者に簡単なコーディング演習を提示します。時々、実際の問題を実際には解決しないが、知覚された問題を解決するために過度に設計されたソリューションを受け取ることがあります-多くの場合、演習の範囲外です。
今私の質問は、これは警告の兆候ですか？
編集：かなりの議論は欠陥があるテストに基づいています-これは公正なポイントです。コメントで述べたように、テストの基本的な前提は、ファイルからデータを適切な方法で読み取ることができる方法を示すことです（そして、私たちが目にするさまざまなアプローチに驚かれるでしょう）。更新間の待ち時間を計算する前の項目。これが機能するためには、データについて特定の仮定を行う必要があり、これらの仮定を探します。また、使用するアプローチを見たいと明示的に述べます（OOアプローチを含む）等）2時間の時間枠内のすべて。
私見、私がインタビューしたとき、それは私が出会った最も完全なエクササイズでした。
私が考えている特定のシナリオは、ファイルから読み取るのではなく、候補者がマルチスレッドアプリケーションで「ネットワーク」入力を受け入れたところです。これは明らかに範囲外です。
問題は、テストが歪んでいることです。ほんの数分かかる簡単な演習を使用して、複雑なエンタープライズレベルのソフトウェアを書く能力を示すように誰かに依頼しています。他の企業の他のインタビュアーは、候補者がこれらの演習ではオブジェクト指向設計の十分なスキルを示さないため、人々は過剰に補償する傾向があると不平を言っています。状況によっては、候補者がより単純なコードを使用できない場合があるとは限りません。
それが候補者に当てはまるかどうかを知りたい場合は、具体的なガイドラインを与えてやり直すよう依頼してください。 「オブジェクト指向のデザインスキルを披露していたことがわかりますが、このような単純な問題ではやりすぎのようです。小さな関数を2つだけ使用して書き直すことはできますか？」
これは明確な警告サインですが、必ずしも候補者の失格とは限りません。
候補者が持っているように見える2つの別々の問題があります：
- 演習の要点を逃している-これはかなり憂慮すべきことです。誰かが適切に解決している問題をキャストできない場合、世界中のすべてのプログラミングスキルが良い結果を生み出すことはありません。私は、最も生産的なエンジニアは、それが正確に提起された問題ではなくても、解決すべき真の問題を特定できるエンジニアであることを発見しました。尋ねられる質問について批判的に考える能力、そしておそらくそれをより簡単に解決できる何かに再定式化する能力を持つことは、重要なスキルです。問題が明確に述べられているポイントを逃していることは、大きな赤い旗であるべきです。
- ソリューションのオーバーエンジニアリング-これは二次的な問題であり、多くの場合、最初の問題の結果です。この結果を持つことができるいくつかの異なる病状があります。まず、問題を適切に理解していない、または広範にキャストしすぎると、ソリューションが非常に複雑になる可能性があります。これは明らかに上記の最初の点に関連しています。第二に、実際には関係がないかもしれない将来のシナリオを通して考えることによって「自慢して見せよう」とすること。これは、候補者がソリューションのシンプルさの価値を理解しておらず、複雑さが本当に必要になるまで延期することを示しているため、問題になる可能性があります。これは適切なガイダンスで修正できるものですが、組織に誰かを連れてくるときは注意が必要です。
プロセスの過程で、回答について候補者にフォローアップすることをお勧めします。単に結果を見るのではなく、結果につながった原因を確認し、いくつかのガイダンスを与えて、彼らがどのように反応し、答えを変えるかを考えてください。これはおそらく、問題に対する直接の対応よりも、彼らの能力についてより明らかになります。彼らのアプローチの「理由」は、彼らが単にそれを得ていないのか、または彼らが理解するのが彼らがどのように応答することを選んだかについてほんの少しずれているのかについての感覚をあなたに与える。この種のフォローアップは、問題解決への全体的なアプローチについても明らかにします。
また、問題自体を再調査し、不明瞭で、おそらく回答を定式化するときに人々が間違った方向に進んでいないかどうかを確認します。
いいえ、面接ではありません。あまりにも多くの面接担当者は、意図的に要件を過小に指定するなどのことを行い、面接対象者がさらに質問をするか、明示的に言及されていない実際の問題への注意を見ることを期待しています。
私の頭の上のいくつかのことをここに示しますが、あなたの要件にはおそらく触れていません。
コーディング基準
コメント
例外処理
変数、クラス、メソッドの説明的な名前
言語の慣用的な使用法に従う
適切なオブジェクト指向設計
考えられる同時実行の問題への注意
コードのテストケースを書く
単一のものに明示的に言及せずにこれらのことに注意を払いましたか？候補者は、あなたが関心のあるものとそうでないものをどのようにして知るのでしょうか？
インタビューは非常に人工的な環境です。面接担当者は、面接担当者が聞きたいことを何でも聞き取れないようにするために、候補者を少し「だまそう」とすることがよくあり、面接担当者は面接担当者が何を推測しようとしているのか本当に欲求。
一般に、その推測を間違えることは、実際の設計決定を間違えることとはかなり異なります。誰かが物事を過度に設計しているかどうかを知りたい場合は、非常に人工的なコーディング演習を見るのではなく、おそらく設計について話さなければなりません。
私見答えは明らかにはい、それは警告サインです
- コーディング演習には明確な課題がありました
- 明確に定義された（また、適切に記述された）要件があります。
- 候補者は、正しい問題を解決するために質問する機会がありました。
- 建築宇宙飛行士 ではなく、チーム内に スマートで物事を成し遂げる である人が必要です。
警告サインの大きさは目前の問題を解決していないほど大きくありません。彼がクイズに失敗し、正しい解決策を提供しなかったという事実は警告の兆候です。彼が正しいソリューションを提供しなかった方法と理由に依存するため、これは必ずしもノーシナリオではありません。
多くの場合、質問は完全にがらくたで、単に答えられません。面接担当者が間違いを犯さないようにしてください。質問がくだらない理由を論じることはまだ彼の側の失敗です。要件の作成を支援することが期待されるエンジニアを雇っている場合、これは問題です。あなたがコーダーを雇っているなら、あなたは彼がそうすることを期待しないだけです。
コーディング演習がひどく台無しにされていないと想定すると、彼が失敗した方法は、問題を誤って解釈し、そこにない問題を解決しようと雑草に入り込んでいたようです。はい、それは警告サインです。
たぶんしかし、以下を考慮してください：
インタビューは難しい：人々はストレスにさらされています。これは、誰かに与えるすべての問題に深く関与する必要があります
要件の長さ：要件はどのくらい長く簡単ですか？すべてが含まれていることを確認するために、それらを余分に冗長にしましたか？結果として、それらはあなたには明白かもしれませんが、要件は多分設計されすぎているかもしれません！私は就職の面接を一度受けました比較的単純な問題の場合、約3ページのテキストによる時間の問題。場合によっては、そのすべてのテキストが面接で読んで解釈するのが難しく、誤って解釈されることもあります。
時々少ない方が良い：主な要件を示すいくつかの箇条書き、文、または例を用意し、次に誰かに質問をしたり、途中で連絡を取ったりしたい場合は、必要。私が言おうとしていることは、最初のテスト要件が単純な問題に対して過度に複雑ではないことを確認する必要があるということです。
コミュニケーションスキル：最初に問題についてコミュニケーションをとり、インテリジェントな質問をする候補者の能力をテストする必要があります。問題を理解していることを彼らが証明したら、その実装に着手できます。
ボトムライン：問題が理解されていることを確認していない場合は、過剰なエンジニアリングをどうするべきか実際にはわかりません。他の人がそれは良いことでも悪いことであるかもしれないと言ったので、あなたが前もって問題について理解をチェックしたり候補者とコミュニケーションをしなかった場合、問題の一般的な理解とそれをどうするかを知ることは困難です。
たぶん
問題を解決しないのはもちろん、何かが間違っているという明確な警告サインです。何が悪かったのか？彼らは問題を誤解しているか、彼らは悪い解決策を作りました。単純なものに対する悪い解決策は、候補者が貧しいことの明らかな兆候です。
彼らが問題を誤解している場合は、要件をよく見てください。ドメインに精通していないように見えても、ドメインに慣れていない他の人や、異なる背景（ロケール、年齢、育成）からは不明瞭かもしれません。候補者があなたと同じ部屋にいたか、質問する機会を提供しても失敗した場合、私は彼らの失敗と考えます。要件が壁を越えて投げかけられた場合、私はおそらく彼らに疑いの恩恵を与えるでしょう（そしてインタビュープロセスを修正することを考えます）。
解決策が正しかった場合、それは不明確になります。個人的には、多くの人が [〜＃〜] yagni [〜＃〜] を取りすぎると思います。複雑さを増したり、保守性を損なうことなく特定の問題を取り、一般的なソリューションを作成できる場合は、一般的なソリューションを作成してみませんか？ （文字列を逆にすることと、任意のコレクションを逆にすることを考えてください）そのような「オーバーエンジニアリング」は、私の意見では明らかに良いことです。
他のすべてはその灰色の中間点です。ソリューションは変化の可能性のある軸に対応していますか？ソリューションによって複雑さが増したり、保守性が損なわれたりしますか？勝利がほぼ保証されている将来の問題を解決するために少し複雑さを追加します。ありそうもない何かを説明するために保守性を害することはそうではありません。
優れたソフトウェアエンジニアであることは、ここで適切なバランスをとることを意味します。優れた面接担当者になることは、候補者がそのバランスをどのように、そしてなぜ選択したかについて、正しい判断/不服を打つことを意味します。
これの多くは、どのように質問に答えるか、そしてインタビュー全体をどのように視点に置いたかに起因する可能性があります。
「あなたがどれほどクリエイティブであるか見てみましょう。2+ 2とは何ですか？」四？あなたが思いつくことができるすべては、最も単純で明白で正確な答えですか？インタビューで感心したい若い/初心者レベルの開発者は、「私たちはあなたのコーディングスキルをテストするか、プログラマーの素晴らしさを知りたい」と考えます。 「非常に洗練された何かをする」という意味です。私たちは皆、物事をより困難にする場合を除いて、シンプルが最善であると考えるのが好きです。
誰かが常に過剰にエンジニアリングする傾向があるかどうかを確認する方法があります。複雑すぎるコード例を示し、より簡単な解決策を求めます。誰かがあなたがうまくいくとは思わない解決策を提供するとき、これは彼らが批判にどのように反応するかを見る絶好の機会です。個人的には、誰かが新しいアイデアを受け入れ、同じ間違いを何度も繰り返す人よりも良い解決策を認めてほしいです。
そして実際には、機能しないときに常にコードを変更する機会がないのではないでしょうか。最初は設計中または設計中のどちらでもかまいません。単純なソリューションを認識したら、実装が簡単になりませんか？
状況によりますが、一般的には違います。
一般的にデザインとは、経験とともに学んだスキルです。 Aaronaughtの説明 Marjanによってリンクされたその進行状況は、一般的に良いものです。
どのような形でのコミュニケーションも、コンテキストに大きく依存します。 1つのコンテキストで1つのことを完全に明確に示しているように見えるものも、別のコンテキスト内で別の何かを明確に意味している場合もあります。どの質問をするかを知ることも、経験に伴うものです。
彼らの思考プロセスと彼らが彼らの決定についてどのように推論するかは彼らの解決策よりはるかに重要です。彼らのソリューションと彼らとの彼らの決定を検討しないと、それが開発されたコンテキストを完全に評価することはできません。
上記の進歩を考えると、過度に設計されたソリューションを持つ候補は、単純なソリューションを持つ候補よりもはるかに優れている可能性があります。
また、あなたはどのレベルのポジションを採用していますか？エントリレベルまたは中間レベルの候補からの過剰設計は、上級レベルの候補からの過剰設計よりも問題が少ないです。
プログラマーが問題を解決しなかった場合、余分なコードはすべて、非回答を難読化しようとするコーダーの試みです。それは主題についてあまり知らない学生によるエッセイテストで使用されるのと同じテクニックです。彼または彼女は説得力のある、しかし彼の無知が言葉の数によって隠されていることを望んでいる無関係な問題についてとりとめます。
プログラマーが問題を解決したが、コードを大幅に追加した場合は、プログラマーのバックグラウンドを考慮してください。プログラミングの一部の領域では、他の領域よりも大きな許容誤差が必要です。
たとえば、商用旅客機で自動操縦を実行するコードは、無料のAndroidゲームよりも失敗に対する許容度がはるかに低くなります。開発者は、到達が難しくほとんど不可能である組み込みデバイスのプログラミングに慣れていました更新することは、1日に15の更新をプッシュできる開発者よりも多くのwhat-ifをコーディングする傾向があります。