技術面接でのOOデザイン関連の質問[終了]

私は最近、かなりの数のインタビューに参加しており、企業から「[モデルを挿入]を設計する」という質問に数回以上回答するように依頼されています。

1. これは最近の業界では普通ですか？私は20年以上ソフトウェアの世界にいて、インタビューに参加していますが、インタビューでこのパターンが現れるのはごく最近です。
2. 質問は非常に開かれていると感じています。たとえば、「駐車場を設計する」ためにクラス図を描くように頼まれました。インタビュアーがどのレベルの詳細を期待しているのかわかりません。これは、Visioダイアグラムを添付することが期待されていたオンラインテストであったため、彼らの期待を尋ねることはできませんでした。
3. この種の質問を面接プロセスで使用していますか？それらはクラス図のみに関連していますか、またはシーケンス、フローチャート、ERD（もちろん職種の性質に基づいて）を求めていますか？

*ケビンの応答用に編集*

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

I 2クラスで行うことができ、ParkingLotかつSlot追加したり、私が上で行くことができる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; }
}

1. ある程度、はい。誰でも構文を暗唱したり、ソリューションをコピー/ペーストしたりできます。問題を解決できる人を雇いたいです。

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

3. はい、XYZ問題をどのように解決するかを人々に尋ねます。通常、彼らはそれを口頭で説明するだけです。要件を明確にするために彼らが質問するかどうかを見たいです。私は彼らが他のプログラマーとどのように通信するかを見たいです。彼らが自分の足で考えることができるかどうかを見たいです。

私にとっては助かりました。コードモンキーが欲しくなく、ソフトウェアエンジニアが欲しいです。

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

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

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

あなたは実際にあなたの編集でこの質問の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問題をは、ライブインタビューでほぼ完了します。それを修正した場合（おそらくaにすることでList<IVehicle>）、これを出発点として使用して、デザインの進化を検討します。要件が基本的である理由があり、明確に定義されたユースケースはありません-それはほとんど世界の仕組みです。

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

また、駐車場に関するあなたの思考プロセスは、問題を知的に分析するあなたの一般的な能力を示していると考えます。基本的なユースケースを尋ねたり、奇妙なもの（駐車場での特別な2分の1など）を考えたりする必要がある場合、私はあなたが以前に実際に駐車場を使用したことがなく、私たちがいることを心配し始めます少し複雑なことをやり取りするのは大変です。

私はこれらを尋ねていました-コード生成のためのクラス図を作成したとき。私は今でも時々していますが、定期的にではありません。質問が好きなのは、その人が考えることを見ることができるからです。

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

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

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

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

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

しかし、人間の介入なしでクラス図をオンラインで投稿するように頼むのは奇妙です：

• ダイアグラムの背後にある理由と、そのように物事を設計することになった理由を、彼らは欠場するでしょう。
• 申請者が行き過ぎないようにする「欄干」はありません。最終的な実装を図に反映すると、おそらく数十のクラスと読み取り不可能なスキーマができます。
• UMLクラス図を描画できることは、実際には必須のスキルではなく、特にオブジェクト指向の表記法の1つにすぎません。堅牢なデザインを作成する機能は次のとおりです。

ライブインタビューで、候補者がとるべき理想的な手順は次のとおりです。

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

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

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

インタビューでは常にデータ構造、OOP、およびデータベース関連の質問を期待します。これらは非常に一般的です。「コーディングインタビューのクラッキング」や「露出したプログラミングインタビュー」などの書籍は、準備に役立ちます。

少し前に駐車場のデザインを出すように頼まれました。そもそもユースケースは提供されませんでしたが、後でいくつか言及しました。私のデザインは、インタビュアーが考えていたものに合わなかったと思います。ソフトウェア設計は、特定のユースケースに対してのみ有効であることに同意します。このインタビューの質問に戻りますが、私のインタビュアーには実際のデザインの経験はなかったと思います。それらの人々は、彼らが求めるものを知っていると信じています。それが本当かどうかは別の話です。