Интервью SQL вопрос

Дается таблица «сотрудники»

 employee_id | salary | department_id 
-------------+--------+---------------

Только с помощью SQL найдите все варианты перевода сотрудников из одного отдела в другой, чтобы средняя зарплата в отделах «выезда» и «прибытия» выросла.

PS Мне задали вопрос на собеседовании, которое так и не дало ответа, и Google мало чем помог.

Итак, вы ищете сотрудников, которые зарабатывают ниже среднего в своем текущем отделе, но выше среднего в своем новом предполагаемом отделе.

Один из возможных способов получить все переводы сотрудников, которые будут соответствовать этому, будет

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 

Учитывая, что это был вопрос интервью (а не тестовый вопрос), существует несколько возможностей в зависимости от контекста.

Вопрос неполный, как указано и не можешьвозможно, не следует отвечать в его текущей форме ( см. раздел ОБНОВЛЕНИЕ ниже ). Чего не хватает? Ну например

• Задавался ли вопрос о прошлых или потенциальных будущих переводах? В формулировке есть двусмысленность.
• Есть ли в этой таблице другие поля или это все? Если так, то кто они?
• Есть ли какие-либо ограничения или индексы, определенные в этой таблице? Где остальная часть схемы?
• Это система OLTP или OLAP?

Если это больше таблица OLTP, то в employee_idполе должно быть определено ограничение PK / Уникальный индекс / Уникальный . И в этом случае, будет только одна запись для каждого employee_idи, следовательно, нет способа определить переводы (т. Е. Нет «старой» department_idзаписи).

Если это больше таблица OLAP, то это может быть медленно изменяющееся измерение, и в этом случае будет несколько employee_idзаписей. Но, также должны были бы быть ValidFromи ValidToDATE / DATETIME поля так , чтобы отправления и прибытия отделов могут быть определены в их правильной последовательности. Без этих полей невозможно определить, какой отдел является отделом отправления, а какой - отделом прибытия . И незнание этого различия позволило бы получить записи, противоположные запросу.

Таким образом, тот «контекст» для того, как интерпретировать этот вопрос, является причиной, по которой вопрос сформулирован так, как он есть.

• Вы забыли некоторые детали между интервью и спросили его здесь:

  Это происходит, но если это так, то либо вам нужно обновить вопрос, чтобы заполнить недостающую информацию, либо он останется без ответа (по крайней мере, с точки зрения получения значимого ответа).

• Вопрос был точно расшифрован здесь, и эти вопросы не были известны или не были заданы интервьюером (-ами):

  В этом случае, если вы знали об этих проблемах и ожидали ответа, вы можете использовать это как средство отсеивания их как возможного работодателя ;-).

• Вопрос был точно расшифрован здесь, и эти вопросы были известны или были заданы интервьюером (-ами):

  В этом случае они, вероятно, использовали это как средство отсеивания людей, рассматривая не только технические возможности. Часто очень важно задавать вопросы, чтобы быть очень четкими в отношении проекта, над которым вы работаете, поскольку большинство конечных пользователей и владельцев продуктов и т. Д. Не думают / не говорят о технических деталях низкого уровня и часто пропускают необходимые фрагменты. Важно не предполагать, а вместо этого возвращаться к источнику запроса, чтобы получить разъяснения, чтобы не тратить время на работу в неправильном направлении.

  Помните, что вы не проходите собеседование, чтобы просто ответить на технические вопросы в вакууме. Вы проводите собеседование на предмет работы над проектами, и всегда будет иметь место двусмысленность и / или вводящая в заблуждение информация о том, что от вас требуется. Хороший интервьюер постарается получить представление как об уровне вашего мастерства, так и о вашей продуктивности. Я задавал такие же вопросы, когда брал интервью у людей, чтобы отсеять людей, которые хорошо отвечают на технические вопросы, но нуждаются в слишком большом количестве рук и в конечном итоге замедляют работу команды.

ОБНОВИТЬ:

Просто чтобы прояснить разъяснение для тех, кто считает, что это простой вопрос об навыке запроса, интерпретируемый как @Martin в своем ответе: мы даже не знаем, является ли это точной формулировкой вопроса, который был представлен ОП, но мы знаем, насколько мы можем доверять ситуации, что это было дано в интервью. И хорошоИнтервьюеры задают вопрос, который привлекает кандидатов не только к техническим навыкам, но и к их нетехническим / «мягким» навыкам Вполне возможно, что Мартин прав в своей интерпретации, что вопрос задает вопрос о возможных будущих комбинациях передачи (то есть «иногда сигара - это просто сигара»). И если бы это был контрольный вопрос, то я был бы удивлен, если бы его ответ был неправильным. Но это не тестовый вопрос. Конечно, это может быть вопрос собеседования, заданный кем-то, кто не пытается увидеть, каким человеком является кандидат и как он будет выступать на дизайнерском совещании, где такие неясности возникают чаще, чем большинство людей даже замечают. Но ответа не было,добивается цели (поиск на странице «Вы ищете людей, которые», но вы должны действительно прочитать все это). Таким образом, между двумя кандидатами, которые равны во всех отношениях, но один принял интерпретацию и был прав, в то время как другой задал вопросы, а затем получил правильный ответ, я определенно пойду с тем, кто задал первым.