Перевод блога JitBit с рекомендация для собеседования по знанию SQL

Моя предыдущая статья неожиданно вызвала бурное обсуждение. Я решил вспомнить молодость (30 лет назад я подрабатывал переводчиком технической литературы) и перевести блог от компании JitBit с рекомендуемыми вопросами по SQL на собеседовании, с которого и началась предыдущая статья. На литературность перевод не претендует, все же я не писатель, я программист. Смайлики и маскирование слов сохранены как в оригинале.

Вопросы по SQL на собеседовании от JitBit

Автор Alex Yumashev, 24 августа 2019 года.

Многие инженеры читают этот блог (с тех пор как мы продаём help desk ticketing system, по большей части, айтишникам). Поэтому мы решили поделиться нашими SQL вопросами, которые мы даём кандидатам во время собеседования, ваши парни могут найти их полезными.

Хотя большинство нашей работы основано на M$ SQL и наши машины, которые мы предоставляем для тестовых заданий, подключены к M$ SQL базе данных, тестовые задания подходят для любой СУБД (Oracle, PostgreSQL, MySQL и т.д.), потому что они очень просты.

Кто-то скажет, что они слишком просты, но это ошибочная точка зрения. Задача тестовых заданий не в том, чтобы выявить гениев или рок звезд среди «нормальных» разработчиков. Их цель сэкономить ваше время и быстро отфильтровать парней имеющих опыт работы с базами данных от тех, кто только заявляют, что они таковыми являются.

Тестовое задание

Мы даём нашим кандидатам эту простую схему базы данных и задаём их следующие вопросы.

1. Выбрать сотрудников (имена): кто имеет зарплату больше, чем у их начальника.

2. Выбрать сотрудников: кто имеет самую большую зарплату в своём подразделении.

3. Выбрать подразделения, в которых меньше чем три сотрудника.

4. Вывести все подразделения вместе с числом людей в них (подвох — люди часто делают «inner join» и тогда пропадают пустые подразделения).

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

6. Вывести все подразделения вместе с суммарной зарплатой в них.

Как я уже сказал, это довольно просто. И существует больше одного правильного решения для каждого из этих заданий.

Вы можете использовать их в своих собеседованиях. И если вы будите это делать, обратная связь будет высоко оценена. 😉

Вопросы не связанные с SQL запросами

Плохо: спрашивать кандидатов: «назови функцию,которая делает X». Или «как получить ключ последней вставленной записи». Или «чем varchar отличается от nvarchar?» Сейчас давно уже не 90е, непереводимый американский мат, никому не нужно это б*чье говно, у нас давно для этого есть Гугл. Вы можете найти ответ буквально за секунды.

Так же плохо: «академичные» вопросы типа «Что такое DML (язык управления данными)?» или «Чем Первая Нормальная Форма отличается от Второй Нормальной Формы?» — непереводимый американский мат, кому это надо?

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

Например, «ваш сервер базы данных стал медленнее работать, что вам следует делать?» — и здесь нет правильного ответа. Это всего лишь повод начать разговор. Ваша работа заткнуться и слушать.

И знаете, это нормально, если кандидат ответит «Я открою браузер и начну гуглить для того, чтобы найти решение» — это на 100% допустимый ответ. Или, один кандидат в самом деле сказал такое — «Я размещу вопрос на StackOverflow или его дочернем сайте посвященном базам данных» — почему нет!

Или «Пожалуйста, назовите вашу любимую сложную проблему с базами данных, которую вы сумели преодолеть» — снова повод для разговора. И если ответ -«если честно, мне нечего на это сказать»- это нормально. Переходите к следующему вопросу.

Только убедитесь, что вопрос не будет подразумевать однозначный ответ. Будет помогать глубокому осмысленному рассказу. Это единственный способ, как выявить людей, которые смогут сделать работу, а не только выигрывать телевикторины от Микрософт.