インタビュー中に、基本的なデータベース設計の質問をします。データベース設計に関しては、正規化（When-Why）が懸念事項の1つです。同期されたサーバーと関連する問題を考慮した理由/理由/方法を含むサイトのシナリオ。セキュリティ問題など。
ありがとうございました。
回答:
ここだシニアデータベース管理者のための私のトップ10のインタビューの質問は、ここだジュニアDBAのためのトムLarock著のトップ10の質問が。
他の人が候補者がサーバーのトラブルシューティングを行うことを提案していることに気付きました。そのアプローチをとる場合は、スナップショット付きの仮想マシンを使用してください。特定の構成またはパフォーマンスの問題がある特定の方法でサーバーをセットアップし、そのスナップショットを取得してから、インタビューのたびにスナップショットにロールバックできます。
その場合は、タスクを実際に実行させる種類のタスクに限定してください。本番DBAに正規化について尋ねたり、開発DBAに1つのノードがクラスターに参加しない理由を尋ねたりしないでください。
本番DBAタスクは次のとおりです。
開発タスクは次のとおりです。
AdventureWorksスキーマを使用します。おそらく彼らは最近それで遊んだことがないが、少なくとも説明するのは簡単だ。
私のソフトウェアチームでは、インタビューの一環として、データベースの理解度をテストしています。
提示-非常に貧弱な設計（CRMタイプのアプリケーションを考えてください）で、約30分の思考時間の後、設計を改善するように依頼します。
次に、彼らが話していることに基づいて、さらに質問をします。
私たちは理解を探っています
その後、チームとして、これらのタイプの質問に対するジュニア/シニア/アーキテクトタイプの回答と考えるものについて考えました。
そのため-パフォーマンスv規範化-
そもそも問題を見て、その理由を議論することができます（ジュニア）
4/5 NFを推奨しますが、パフォーマンスの問題を非正規化し、問題を明確にする方法を理解します（シニア）
彼らはスタースキーマなどの異なるタイプの設計を推奨し、多くのレベルでの影響を議論しますか（建築家）
参照整合性はデータの関係を強化するために必要であり、これについて議論することができますが、Key Choice and Design（Junior）の問題は表示されません
データボリュームとデータタイプに関する問題を議論しますvデータの自然キーを探して、なぜこれらを見るのか、そして参照整合性に伴う問題（上級）について話し合うことができます
キーと整合性に関連するさまざまな視点を議論し、迅速な設計のためにさまざまな実際のモデルを思い付くことができます（Architect）
写真が撮れます。
さらにコメントを追加したい場合は、コメントを投稿し、残りの部分について私たちが考えていることを詳しく説明しますが、最初の2つだけを含めて、私たちが考えたことに関するアイデアを提供します。
ポイントは、1。質問について考えることです。2.私たちは、チームとして、これらのタイプの質問に対するジュニア/シニア/アーキテクトタイプの回答と考えるものについて考えました。
私は候補者としてチームを強調し、チームは入ってくる人のスキルに自信を持たなければなりません。もし彼らが異なるレベルへの答えとして彼らが見ているものを考え出せば、入ってくる人はチームにより良く適合することを望みます。また、チームが候補者の選択に影響を与えることができます。また、質問パネルに参加する人を指名します。チームの賛同で大いに役立ちます。
いくつかの正規化問題、潜在的なセキュリティ障害があった架空のデータベースを作成できますが、一般的には従業員データベースのように非常に典型的に見えます。次に、参加者が結合を介してデータベース内の特定のデータを取得する方法について簡単な質問をすることから始め、正規化およびセキュリティの問題に関するより難しい質問に進みます。
スマートを参照してください
...そして、最近読んだ本、読んでいるブログ、聞いているポッドキャストを尋ねます。そして、彼らがstackoverflow.comとserverfault.comに参加しているかどうか尋ねます;-)
これは必ずしもデータベース関連ではありませんが、インタビューに追加したいのは、実践的な問題解決と設計シナリオです。
実践的な問題については、人がアクセスできるシステムを用意し、オープンエンドの問題をトラブルシューティングしてもらいます。ここでの私の個人的なお気に入りはパフォーマンスの問題です。インタビューの要求に応じて必要に応じて再現できるものではなく、正解が1つしかないことはまれです。代わりに、候補者がトラブルシューティングプロセスを実行するのを見ることができます。また、候補者は、環境に関する詳細情報を入手するために、ディスカッションを開く必要があります。重要なのは、インタビュアーが問題について正直になり、設定を誤って設定したり、そのような何かのためにシナリオをイースターエッグハントに変えないことです。
設計シナリオでは、候補者に新しいプロジェクトの一般的な概要を提示し（つまり、レガシーの依存関係がない）、プロジェクトの目標を満たす特定の領域（DBA、システム、またはネットワーク）で一般的な設計を考え出すよう依頼します。重要なのは、誰かが頭の中でシナリオ全体を維持できるようにプロジェクトを小さく保つことであり、説明するのに数分もかからない。
ここで使用しているシステムおよびネットワークの人々の例は、ビジネスの特定の制約を考慮して、セットアップされている小さなブランチオフィスの設計を説明することです。DBA側では、おそらく小さくて明白なCRUDアプリケーションを使用します。どちらの場合でも、詳細な設計ではなく概要を探し、候補者が出てくる一般的な問題を探すかどうかを確認します。
これらのシナリオの両方の重要なポイントは、トピックに関するディスカッションを開き、候補者が自分の質問でディスカッションをリードできるようにすることです。どちらに対しても正確な答えを求めていないことは明らかです。
あなたがイメージできるように、私はインタビューでトリビアを大いに嫌います。