web-dev-qa-db-ja.com

OO技術面接での設計関連の質問

私は最近かなりの数のインタビューに参加しており、企業から「[モデルを挿入]を設計する」という質問に何度も答えるように求められました。

  1. 最近の業界ではこれは正常ですか？私は20年以上ソフトウェアの世界にいて、インタビューのシェアに参加してきましたが、インタビューでこのパターンが出現したのはごく最近のことです。
  2. 質問は非常に開かれたものだと思います。たとえば、「駐車場を設計する」ためにクラス図を描くように依頼されました。インタビュアーがどの程度の詳細を期待しているかはわかりません。これは、Visioの図表を添付することが期待されていたオンラインテストでした。
  3. このような質問を面接で使用しますか？それらはクラス図のみに関連していますか、それともシーケンス、フローチャート、およびERD（もちろん職位の性質に基づく）に質問しますか？採用プロセスに効果的でしたか？

* Kevinの応答を編集*

例：完全な質問は、「空きスロットを見つけるために使用できる駐車場管理システムを設計する」でしょう。

ParkingLotとSlotの2つのクラスを使用して実行するか、またはIVehicleとVehicleとCarとMotorcycleクラスを追加することができます。どこに線を引くのですか？

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}
designinterviewobject-oriented-designumlhiring
14
Nick

  1. ある程度、そうです。誰もが構文を暗唱したり、ソリューションを通じて自分のやり方をコピー/貼り付けたりすることができます。問題を解決できる人を雇いたい。

  2. 彼らは、あなたが彼らがそれを理解できるように（そしてそれ以上ではない）十分に設計を文書化することを期待しています。

  3. はい、XYZ問題をどのように解決するかを人々に尋ねます。通常は口頭で説明します。要件を明確にするために質問するかどうかを確認します。彼らが他のプログラマーとどのようにコミュニケーションするかを見たいです。彼らが自分の足で考えることができるかどうかを見たいです。

それは私にとって役に立ちました。コードモンキーは必要ありません。ソフトウェアエンジニアが必要です。

10
Telastyn

私はこれらの質問をかなりばかげています。本当の答えは「ユースケースは何ですか？」です。ユースケースがなければ、デザインは必要ありません。たとえば、駐車場の質問に対する完全に合理的な答えは次のとおりです。

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

1つの明らかなユースケースを満たします。

6
kevin cline

実際に、編集可能なこのモデルの設計に失敗した編集で、この質問の1つの使用法を示します。

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

また、CarクラスとMotorcycleクラスの作成についても触れていますが、これは、これ以上検討しなければ意味がありません。あなたのデザインはVehicleをサブクラス化することから何の利益も得ません。 MotorcycleとVehicleの動作に違いがない場合は、失敗と見なします。

単一のVehicle問題を見つけなかった場合は、ライブインタビューでほぼ完了します。あなたがそれを修正した場合（おそらくそれをList<IVehicle>）、私はあなたのデザインの進化を見る出発点としてこれを使用します。要件が基本的である理由があり、明確に定義されたユースケースがない-それは世界が機能する方法とほぼ同じです。

「2つのオートバイが1つのスロットに駐車できる」という新しい要件を投げかけて、それを処理するためにデザインをどのように進化させるかを確認します。次に、並行性について話し合います（2つの入り口があり、2台の車が同時にプルアップした場合-デザインは失敗しますか？どのように？それを修正するために何ができますか？）。探索する他の可能な手段としては、割り当てられた駐車の実装方法、駐車料金、列あたりの料金（列が近いほど多くの料金を支払う必要がある）、時間制限のある駐車場、違反者の見つけ方などがあります。

また、駐車場に関する思考プロセスは、問題をインテリジェントに分析する一般的な能力を示していると考えます。基本的な使用例を尋ねたり、奇数の例（駐車場で2対1の特別料金など）を考え出す必要がある場合、実際に駐車場を使用したことがなく、少し複雑なものについてはコミュニケーションが困難になります。

5
Mark Brackett

コード生成のためにクラス図を作成したとき、私はこれらを尋ねていました。私はまだ時々行いますが、日常的には行いません。人の考えを見ることができるので、私は質問が好きです。

それはオープンエンドであることが意図されています。それで大丈夫です。正解は1つではありません。心の中で答えはありません。どこにつながるのか見たい。 「回答メール」ではなく、直接質問する方がいいと思います。コミュニケーション、仮定、相互作用についてです。ただの答えではありません！

3
Jeanne Boyarsky

  1. 私はこのタイプのインタビューを少なくとも12年前に見ました。それは私が過去6年間使用してきたアプローチです。経験によれば、20問の質問よりも優れた求職者が選択され、20点満点のスコアが与えられます。

  2. 繰り返しますが、私も非常にオープンエンドにしたいと思います。目標は、候補者が能力を発揮するためのスペースを提供することです。この段階で関連する質問をした候補者がいることはプラスです。適切な仮定をしている候補者と同じですが、それらが仮定であり、実装前に確認する必要があることを示すフラグを立てます。

  3. 私は、面接での仕事に必要なスキルを示すために、すべての潜在的な従業員に必要です。プログラマーにとっては、コードを実装し、その設計について話す必要があります。悪い採用を防ぐのに非常に効果的ですが、面接時に90％の失敗率に備えることができます。

3
Michael Shaw

小さなシステムを設計することは、実際にインタビューで尋ねるのに非常に関連のある演習です。これは、ドメインの問題に対する優れたソフトウェアソリューションを考案するスキルを示しています。

しかし、人間の操作なしでクラス図をオンラインで投稿するように依頼するのは奇妙だと思います。

  • 彼らは本質を逃します-ダイアグラムの背後にある推論と、そのように物事を設計するようになった理由.
  • 申請者が行き過ぎないようにする「パラペット」はありません。図に最終的な実装を反映させると、おそらく数十のクラスと判読不能なスキーマができます。
  • UMLクラス図を描くことができるということは、本質的なスキルではありませんが、OO表記法の1つ）だけです。

ライブ面接では、候補者がとるべき理想的なステップは次のとおりです。

  • 採用担当者と問題について話し、基本的な解決策を口頭で表現し、質問をし、採用担当者がより正確なニーズに応じて調整するようにします。
  • 立ち上がって、システムの全体像とコンポーネントがどのように相互作用するかをスケッチします。 UMLの最も純粋なスタイルである可能性があり、単なるボックスとサークルである可能性があります。
  • 高レベルの受け入れテストまたはコンポーネント/クラスの1つに対する単体テストのいずれかのテストを記述します。
  • 対応する実装の記述を開始します。

うまくいけば、ある時点で、採用担当者は候補者のスキルに関する十分な情報を収集し、それを1日と呼ぶようになるでしょう。目標は、完全に機能するソリューションを実装することではありません（偽装インタビューでこれらの無料サービスの1つでない限り）。

2
guillaume31

OOP質問は自由回答です。正解も不正解もありませんが、インタビュアーが期待するいくつかの原則があります（コンストラクターを使用して変数を初期化する、メソッドを小さく保つ、カプセル化/合成/ポリモーフィズム/継承（該当する場合）など）。

インタビューでは常にデータ構造、OOP、およびデータベース関連の質問を期待してください。これらは非常に一般的です。 「コーディングインタビューの解読」や「プログラミングインタビューの公開」などの本は、準備に役立ちます。

0
sakisk