インタビューで任意のシステムを設計するにはどうすればよいですか？[閉まっている]

Tech Interviewでよくある質問は、特定のシステム、通常は会社の既存の製品を設計することです。たとえば、「Googleドキュメントの設計」。

そのような質問に対して期待される答えは何ですか？つまり、そのようなシステムは確かに複雑なデザインであり、インタビューの範囲を超えています。インタビュアーはこのような短い時間に何を期待していますか？

あなたの脳がこの問題をどのように見ているかについての洞察。この会話をどのように試みることができるかについて、私が見ることができるいくつかの出発点を以下に示します。

• トップダウン-非常に高いレベルから見下ろしてデザインを構築し、さまざまなコンポーネントが完成するにつれてデザインを肉付けします。ここにいくつかのコンポーネントがあります。

• ボトムアップ-ゼロから見ると、ここに、組み立てようとするために構築できる断片があります。

• 要件の明確化-この設計に使用される予測される規模、サイズ、予算、およびチームについて質問する。人に非常に単純化されたワードプロセッサをコーディングしてもらうか、数億ドルを費やして、Google Docが極端に進化したと思われる究極のドキュメント管理システムを作ってみることができます。また、「Google Docでどういう意味ですか？その機能のどれだけを複製したいのですか？」質問も。

重要なのは、この種の問題への取り組みに関する考えやアプローチをどれだけうまく伝えることができるかということです。ユーザーにアプローチして「2週間以内にこのようなことをしてもらえますか」と尋ねることがあります。それは実際に起こる可能性があります。したがって、答えを出す方法は、答えが何であるかよりも重要です。

私の個人的な意見では、過去のプロジェクトはここでは良いアイデアではないと思います。見つけようとしているのは、過去に何かが行われたことを思い出すのではなく、新しい分野でどのような創造性とコミュニケーション能力があるかです。新しい位置で起こることは過去のものと似ているかもしれませんが、古い解決策が実行できないほど十分な違いがあるかもしれません。これが、構築されるものが既存のアプリケーションに似ている一方で、ソリューションを最初の例とはまったく異なるものにするさまざまなカスタマイズが存在する理由です。

インタビューは双方向の道です。マネージャーや他の開発者がインタビューの達人になることはめったにないので、就職の面接で主題の専門家であるべきだと言おうとする価値があるとは確信できません。面接の方法を知っていると期待できるリクルーターですが、これが必ずしも良いアイデアではない理由の例として使用できる多くの貧しいリクルーターがいます。

特に上級開発者にとって、これらの質問は非常に良いものになると思います。彼らは、開発者が大規模で複雑な記述から現実的な実装に移行できることを示しています。まったく馴染みのないシステムであっても、インタビュアーにとって多くの興味深い活動を行えるはずです。

• 質問に回答するための要件を収集します（範囲など）
• 問題をより管理しやすい部分に分けます。必要なインターフェイスやオブジェクトを特定したり、ロジックをフロントエンド、バックエンド、DBなどに分割したりできます。
• Googleドキュメントの場合のウェブアプリなど、そのタイプのシステムの背後にある構造と概念に精通していることを示します。
• 設計上の問題が提示されたときに焦点を当てる傾向があるものを表示します（オブジェクト設計？SQLテーブル？設計パターン？）
• 上司に新しいシステムを開発するのがどのようなものかプレビューを見せます。上司は仕様書を提示して、「これを構築するには何が必要ですか？」と言います。

この質問は、「これに使用するオブジェクト階層を記述してください。」の単なる上位レベルのバージョンです。「このために設計するインターフェイスを説明してください。」「このデータ用のリレーショナルDBテーブルのセットを設計します...」など、中級レベルから中級レベルの開発者に提供されます。下位レベルの開発者では、インタビュアーは会社の成長に対するその人の長期的な可能性を評価するか、圧倒される可能性のある大きな問題に直面したときに彼らが何をするかを見ているだけかもしれません。

それは、あなたの思考プロセスが実際に動いているのを見ることです。彼らは解決策に興味はありませんが、問題の解決方法、尋ねる質問、特定する問題などに興味があります。

Googleドキュメントの例を考えると、頭に浮かぶ明らかな問題は、ストレージ、セキュリティ、スケーラビリティ、可用性、クライアントインターフェイスの設計、ブラウザーの互換性などのようなものです。サーバーとクライアントの間で責任をどのように分けますか。バックアップをどのように処理しますか？サーバーがダウンするとどうなりますか？「放棄された」ドキュメント（長期間アクセスまたは変更されていないもの）で何をしますか？

繰り返しますが、ポイントはそれらの問題を解決することではなく、それらを特定し、それらを通して話し、それらに対処する方法について少しブレインストーミングするなどです。

私は、インタビューでこの種の質問を頻繁に行う有罪の当事者の1人です。（記録のために、私は彼らの「お気に入りのプロジェクト」について同様の質問をします。）私が尋ねる理由は、それが私たちがここで頻繁に行うことだからです。インターフェイスのあらゆる側面からデザインエンジニア、システムエンジニアリングからの人、テストからの人、および機能の顧客ユースケースについてある程度の知識を持つ人を獲得します。ホワイトボードの周りに立って、「わかりました、どうやってこれを構築するのですか？」と言います。多くの場合、その時点で新機能についてほとんど知らず、システムの一部に関する専門知識のためにそこにしか存在しませんが、それでも生産的な貢献が期待されます。これは単なる仮想的なアカデミック演習ではありません。

どんな種類の答えが期待できるかについては、たとえば、サーバーから新しいファームウェアをダウンロードするシステムの設計、中央オフィスの20の組み込みラインカードを使用して、フィールドの5000セットトップボックスを一度にアップグレードします。サーバーとラインカードの間のリンクに非常に少ない予備容量があると仮定します。

悪い答え：

ええと、おそらくイーサネットかそのようなものを使用するでしょう。

いい答えだ：

どれくらい大きな画像について話しているのでしょうか？[約7 MB。]さて、ダウンロード中にサービスが影響を受けていないことを確認する必要があります。2つの画像を一度に保存するには、追加のフラッシュまたはRAMが必要です。サーバーから同じ画像が何度もダウンロードされるのを避けるために、ラインカードに画像をキャッシュすることをお勧めします。埋め込まれているため、ラインカード自体のCPUが制限されている可能性が高いため、サービスに十分な容量を残すために、ダウンロードをシリアル化する必要があります。イメージが良好であることを確認し、機能しない場合は古いバージョンにフォールバックする何らかの方法が必要です。アップグレードが失敗した場合、数回再試行してエラーを人間に報告する何らかの方法が必要です。セットトップボックスのブランドが異なる場合、送信する必要がある画像を特定する何らかの方法が必要になります。

これらは、2つの異なる候補者の単語転写のほとんどの単語です。ほとんどの候補者は中間にいますが、通常は少しプロンプトを表示して最終的にそこに到着しますが、これはまったく問題ありません。ここでは次のアインシュタインを探しているのではなく、毎日取り​​組んでいる問題の種類について実際に理性的に推論できることを示しています。

私もこの種の質問をしますが、他のほとんどの答えにも同意します。たぶん、この種の質問が重要な理由を理解することは、インタビューを受けた人に役立つでしょうか？重要なビジネス上の意思決定があり、それを行うには、新しいシステムを構築する必要があるとします。誰かがあなたに駆け寄り、Xを実行するシステムを構築するために何が必要かを尋ねた場合、必要な主要な課題とリソースを予測する洞察に満ちた答えを彼らに与えることができますか？

若手プログラマーはどこから始めればいいのか分かりません。彼らは詳細な仕様なしに話を始める準備ができていません。上級プログラマーは、問題に多くの側面があることを即座に認識し、課題に焦点を合わせようとします。すべての側面を設計する必要はありません。アーキテクチャ上の課題を特定し、それに対処する方法を見つけてください。

Googleドキュメントの問題を検討してください。

おもしろいことの1つは、今後のリクエストのシェアスケールです。単一のサーバーを取得してそこにコードを展開することはできません-これはより大きな仕事です。面接に成功した人はこれに焦点を合わせ、必要なリソースの種類と、その規模で実装する際の技術的な課題について説明します。状態を持つだけでなく、複数のユーザー間で状態を共有します。

Googleドキュメントのもう1つの興味深い点は、複数のユーザーが同時に編集できることです。面接に成功すると、作成されたドキュメントがゴミにならないようにするためのメカニズムについて話し合うことができます。本当に素晴らしい候補者は、編集を同期またはマージするさまざまな方法がパフォーマンスとUXに大きな影響を与えることに気付くでしょう。バリエーションについても議論するかもしれません：コードを書くための共有ドキュメントエディターは、おそらく、通常のGoogleドキュメントとは異なる競合解決方法を使用する必要があります。これは、異なる順序で発生することや構造がわずかに異なることに対する結果が異なるためです。

Googleドキュメントのようなアプリを作成する正しい方法は1つではありません。トレードオフごとに何をするかを特定する必要はありませんが、興味深い問題のある領域を見つけて、そのトレードを明確に説明することは本当に素晴らしいことです。 -オフかもしれません。

-t。

インタビュアーが聞きたいのは、

Google Docは、ワードプロセッサ用のWebインターフェイスです。ユーザードキュメントは入力および保存され、同じコンピューターまたは別のコンピューターでユーザーが取得できます。

さらに議論したいことはありますか？

その後、ボールはインタビュアーのコートにあります。彼女は詳細を知りたい場合は、尋ねることができます。インタビュアーが探しているのは、問題や製品を見て、設計を抽出できますか？

私にとって、主要なユースケース/ストーリーを特定することから始めなければ、この特定のスキルを必要とするポジションに備えていないことを知るのに十分でしょう。

その後、主要なユースケース/ストーリーに基づいたアーキテクチャソリューションを考え出すことができるはずです。うまくいけば、彼らは彼らからモジュールを引き出す以外に、いくつかの体系的なプロセスを使用してモジュールを使用しました。

ただし、アーキテクチャーモジュールの1つを選択し、設計スキルがあるかどうかを確認するために、より詳細な設計を依頼する場合があります。また、障害のケース/パフォーマンスの問題を考慮していることを確認できたらうれしいです。しかし、私はこの時点で、時間の壁にぶつかるのではないかと疑っています。したがって、私はこれらの問題を考慮しないことで彼らを罰することはできませんでした。なぜなら、時間が限られているためです。

最近、エレベータ制御システムの設計を依頼されたインタビューを受けました。基本的に、彼らはあなたのタスクへのアプローチを望んでいます。この質問をされている場合、彼らはおそらくあなたのために非常に高いレベルの仕事を念頭に置いています。おめでとうございます。

重要なことは、問題を解決する方法と、提供するソリューションのメリット、そして大まかな問題に対処できるかどうかです。

重要なことの1つは、要件について質問することだと思います。ペットソリューションが機能することを前提とするだけではありません。たとえば、ドキュメントを印刷するための本当に気の利いた方法を知っていることがあります。ただし、Googleドキュメントは直接印刷されません。クライアントが印刷するPDFを生成します。そのため、これから始めると、問題の一部ではない問題を解決するのに半分の時間を費やし、顧客の問題を解決するよりもホットテクノロジーを使用することに関心があることを実証します。

この種のインタビューの質問に対処するには、興味のあるプロジェクトだけでなく、経験から離れすぎていると感じるプロジェクトでも、「物事の仕組み」を理解することに一般的な関心を持つ必要があります。

これは、ブログ、記事、http：//www.infoq.com、Hacker Newsなどを読むことを意味します。コーディング・ホラーのハードウェアもブラフします。

あなたが読んだもののほとんどを忘れるという事実にもかかわらず（それらの情報は個人的には作品とは関係がないので）、「想像の種」であり、それらの種のごく一部であるちょっとした情報があるかもしれません遠い将来に同様の問題に出くわすと発芽します。

そのため、インタビュアーはおそらくあなたの趣味の一部としての読書習慣に興味があり、ランダムな場所からアイデアの種を収集する習慣があるかどうかを確認します。

この種の質問をすることの背後にあるポイントは、あなたの心への洞察を得ることです。私がよく使う質問は、プログラマーにPacManをシミュレートできるシステムの設計を依頼することです。

そして、はい、最初にユースケースを探します。それは、その人が考えていることを示しています。次に、マルチスレッドの場合、最初にデータ構造を検討します（問題に使用できるもの、次に決定の理由を持つより適切なまたは特定のもの）。

これは上級開発職にとって必須の必須事項です。このレベルの開発者エクスペリエンスで、人が座って実装の実装に関する質問に答えることは愚かで無意味です。システム設計は、このレベルで私が期待するものです。