Інтерв'ю 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. І в цьому випадку був би лише один запис на, employee_idа значить, не можна визначати передачі (тобто немає "старої" department_idзаписи).

Якщо це більше таблиці OLAP, то це може бути повільно мінливим розміром, і в цьому випадку буде кілька employee_idзаписів. Але, також повинні були б бути ValidFromі ValidToDATE / DATETIME поля так , щоб відправлення і прибуття відділів можуть бути визначені в їх правильної послідовності. Без цих полів неможливо визначити, який відділ відправляється, а який - прибуття . І не знаючи, що відмінність дозволить повернути записи, протилежні запиту.

Отже, той "контекст" для того, як інтерпретувати це питання, є причиною того, що питання висловлюється таким, яким він є.

• Ви забули деякі деталі між інтерв'ю та запитували його тут:

  Це трапляється, але якщо це так, то або вам потрібно буде оновити питання, щоб заповнити інформацію, яка відсутня, або вона залишатиметься невимовною (принаймні, з точки зору отримання вагомої відповіді).

• Питання було чітко прописано тут, і інтерв'юер (а) ці питання не були відомі або призначені:

  У цьому випадку, якщо вам були відомі ці питання, і вони очікували відповіді, ви можете використовувати це як засіб вилучення їх як можливого роботодавця ;-).

• Запитання було чітко переписано тут, і ці питання були відомі інтерв'юеру чи призначеному ним:

  У цьому випадку вони, ймовірно, використовували це як засіб вилучення людей, дивлячись на більше, ніж на сирі технічні можливості. Часто дуже важливо задавати питання, щоб бути дуже зрозумілим щодо проекту, над яким ви працюєте, оскільки більшість кінцевих споживачів і власників продуктів тощо не думають / говорять у технічних деталях низького рівня і часто залишають необхідні деталі. Важливо не припускати, а натомість повернутися до джерела запиту, щоб отримати роз'яснення, щоб не витрачати час на роботу в неправильному напрямку.

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

ОНОВЛЕННЯ:

Просто для уточнення роз’яснення для тих, хто вважає, що це просте запитання щодо навичок запиту, трактоване так, як це зробив @Martin у своїй відповіді: ми навіть не знаємо, чи це точно формулювання питання, яке було представлено в ОП. ми знаємо, наскільки ми можемо довіряти ситуації, що це було дано в інтерв'ю. І добреІнтерв'юери задають питання, що не лише здобути кандидатами технічну майстерність, а й їхні нетехнічні / "м'які" навички. Цілком може бути, що Мартін правильний у своєму трактуванні, що питання задається питаннями можливих майбутніх комбінацій передачі (тобто "іноді сигара - це просто сигара"). І якби це було тестове питання, то я був би здивований, якби його відповідь була невірною. Але це не тестове питання. Звичайно, це може бути питання інтерв'ю, яке задає той, хто не намагається зрозуміти, який тип людини є кандидатом, і як вони виступатимуть на дизайнерській нараді, де такі неясності виникають частіше, ніж більшість людей навіть помічає. Але відповіді не було,робиться все (пошукайте на сторінці "Ти шукаєш людей, які", але ти справді повинен прочитати всю справу). Так, між двома кандидатами, які є рівними в усіх відношеннях, але один припустив тлумачення і був правильним, а інший ставив запитання, а потім отримав правильну відповідь, я б неодмінно пішов із тим, хто запитав першим.