表「従業員」を考える
employee_id | salary | department_id
-------------+--------+---------------
SQLを使用した場合のみ、ある部門から別の部門への従業員の異動すべてが検出されるため、「出発」部門と「到着」部門の両方の平均給与が増加しました。
PS私はインタビューで質問を受けましたが、決して答えることはありませんでしたが、Googleはほとんど役に立ちません。
表「従業員」を考える
employee_id | salary | department_id
-------------+--------+---------------
SQLを使用した場合のみ、ある部門から別の部門への従業員の異動すべてが検出されるため、「出発」部門と「到着」部門の両方の平均給与が増加しました。
PS私はインタビューで質問を受けましたが、決して答えることはありませんでしたが、Googleはほとんど役に立ちません。
回答:
そのため、現在の部門では平均よりも低いが、将来の新しい部門では平均よりも高い従業員を探しています。
これを満たすすべての従業員の転勤を取得する1つの可能な方法は
WITH departments
AS (SELECT AVG(salary) AS AvgSalary,
department_id
FROM employees
GROUP BY department_id)
SELECT e.employee_id,
dept_current.department_id AS current_department_id,
dept_new.department_id AS new_department_id
FROM employees e
JOIN departments dept_current
ON e.department_id = dept_current.department_id
AND dept_current.AvgSalary > e.salary
JOIN departments dept_new
ON dept_new.AvgSalary < e.salary
employees
。これにより、条件に一致する(もしあれば)転送できるすべての部門が検索されます。
これはインタビューの質問であり(テストの質問ではない)、コンテキストに応じていくつかの可能性があります。
質問は述べられているように不完全です できないおそらく現在の形式では回答すべきではありません(下記の更新セクションをご覧ください)。何が欠けている?さて、例えば:
これがOLTPテーブルの場合は、employee_id
フィールドで定義されたPK /ユニークインデックス/ユニーク制約が必要です。また、その場合、エントリは1つだけであるemployee_id
ため、転送を決定する方法はありません(つまり、「古い」department_id
レコードはありません)。
これがOLAPテーブルである場合、これはゆっくり変化するディメンションである可能性があり、その場合、複数のemployee_id
レコードが存在します。ただし、出発および到着部門を適切な順序で決定できるように、ValidFrom
およびValidTo
DATE / DATETIMEフィールドも必要です。これらの分野がなければ、どの部門が出発であり、どの部門が到着であるかを決定する方法が全くありません。そして、その区別が要求の反対であるレコードを取り戻すことを可能にすることを知らない。
したがって、この質問をどのように解釈するかの「コンテキスト」が、質問がそのように述べられている理由です。
インタビューとここでの質問の間にいくつかの詳細を忘れました:
それは起こりますが、その場合は、不足している情報を埋めるために質問を更新する必要があります。そうでない場合は回答できません(少なくとも意味のある回答を得るという点では)。
質問はここに正確に転写されており、これらの問題はインタビュアーによって知られていないか、意図されていません。
この場合、あなたがこれらの問題に気づいていて、彼らが答えを期待していたなら、あなたは可能な雇用主としてそれらを取り除く手段としてこれを使うことができます;-)。
質問はここに正確に転写されており、これらの問題はインタビュアーによって知られているか、インタビュアーによって意図されていました。
この場合、彼らはおそらく、生の技術的能力以上のものを見ることによって人々を除草する手段としてこれを使用していたでしょう。ほとんどのエンドユーザーや製品所有者などは、低レベルの技術的詳細を考えたり話したりしないため、作業中のプロジェクトについて非常に明確になるように質問することは非常に重要です。想定するのではなく、要求のソースに戻って説明を取得し、間違った方向で時間を無駄にしないようにすることが重要です。
技術的な質問に単純に答えるだけの立場を求めて面接しているわけではないことを忘れないでください。あなたはプロジェクトに取り組むポジションを求めて面接を行っていますが、何をするように求められているかについては常に曖昧さや誤解を招く情報があります。優れたインタビュアーは、あなたのスキルレベルと実際に生産的になるかどうかの両方を理解しようとします。技術的な質問にはよく答えるが、あまりにも多くの手持ちが必要でチームを遅くする人を排除するために、人々にインタビューするとき、私はこのような質問をしました。
更新:
これは単純なクエリスキルの質問であり、@ Martinが彼の答えで行ったように解釈されていると感じている人の説明を明確にするためです:OPに提示された質問の正確な表現であるかどうかはわかりませんが、状況を信頼できる限り、これがインタビューで与えられたことを知っています。そして良いインタビュアーは、候補者の技術的スキルだけでなく、非技術的/「ソフト」スキルも引き出す質問をします。マーティンは、質問が将来の転送の組み合わせの可能性について質問しているという彼の解釈が正しいことは非常によくありえます(つまり、「葉巻は葉巻にすぎない場合がある」)。これがテスト用の質問である場合、彼の答えが正しくない場合、私は驚かれるでしょう。しかし、これはテスト問題ではありません。確かに、それは、候補者がどんなタイプの人物であるか、そしてほとんどの人が気づくよりもそのようなあいまいさが頻繁に現れるデザイン会議でどのように実行するかを見ようとしない誰かによって尋ねられるインタビューの質問かもしれません。しかし、答えはありませんでした。物事を成し遂げます(「あなたは探している人を探しています」のページで検索しますが、本当に全部読んでください)。だから、すべての点で平等な2人の候補者の間で、一方は解釈を仮定して正しかったが、もう一方は質問をしてから正しい答えを得たので、私は間違いなく最初に尋ねた人と一緒に行くだろう。