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

Естественный путь профессионального становления - это когда ты сначала являешься кандидатом, претендующим на вакансию, и только проходишь интервью, ну или пытаешься, а потом, со временем, еще и сам проводишь интервью для других соискателей.

Те, кто побывал в обеих ролях, в каком-то смысле, имели возможность взглянуть на себя со стороны, и, думаю, многие обращали внимание на следующий момент. Нередко бывает так, что кандидатам, особенно джунам, блок теоретический вопросов, дается легче, чем решение практических задач. Более того, некоторых кандидатов, буквально вводит в ступор, когда их просят выполнить что-то практическое.

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

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

Например, в описании требований к вакансиям Manual QA, знание SQL проскакивает настолько часто, что его можно считать частью "джентльменского" набора. И даже в тех случаях, когда в описании вакансии SQL не упоминается, это отнюдь не означает, что на интервью о нем не вспомнят.

Дело в том, что с точки зрения отбора кандидатов, знание SQL, является довольно удобным фильтром, т.к. обладает хорошей «предъявимостью», при чем не только теоретической, но и практической. Описать структура табличек, и поставить задачу перед кандидатом, можно хоть на салфетке, хоть в Codeshare. И в случаях, когда вакансия, может не предполагать знаний языков программирования, SQL, по прежнему остается кросс-профильным инструментом тестирования кандидатов разных специальностей.

Не стоит также забывать и о том, что хоть какая-то база данных, присутствует практически в любом продукте. Конечно же, это может быть далеко не только SQL-ная БД, но даже NoSQL запросы, гораздо легче изучать, когда в голове уже есть паттерны "классических" запросов SQL.

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

Можно ли научиться решать задачи по SQL, на таком уровне, чтобы очередной вызов, с которым пришлось столкнуться на собесе, вызывал бы скорее азарт, чем страх, да конечно можно! Ибо, как известно, practice makes perfect.

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

По моим субъективным наблюдениям, некоторые ресурсы, предлагают решать слишком уж тривиальные задачи, примерно на таком уровне сложности:

SELECT ProductName FROM Products WHERE Price > 100;

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

Далее будут примеры разминочных задач для тренировки.

Ну а кому интересна регулярная практика, встречаемся в Телеграм-канале SQL решает, там мы тренируемся решать задачи с реальных интервью, и те задачи, которые дают хорошую почву для тренировки мозгов.

P.S. Зайдя в ТГ канал, рекомендуется кликнуть по хештегу #задача, и порешать, то что там есть, а тут нет:)


Будем использовать схему популярной БД NorthWind

Чтобы не заморачиваться с настройкой окружения на локальной машине, можно воспользоваться площадкой w3schools нажав на любую из кнопок 'Try it yourself', вы попадете в редактор запросов.

Задачи

Задача 1

Таблица: Customers;

Выбрать имена клиентов (CustomerName), являющихся выходцами из городов, названия которых, начинаются на букву S, но не заканчиваются на букву n. А также, вывести и сами названия городов (City).

Подсказка: если правильный запрос выполнить в дефолтной базе w3schools, должно вернуться 11 записей.

Решение
SELECT CustomerName, City 
FROM Customers 
WHERE City LIKE "S%" AND City NOT LIKE "%n";

Задача 2

Таблицы: Customers, Orders;

Вывести список имен клиентов (CustomerName), которые не сделали ни одного заказа.

Решение
SELECT c.CustomerName
FROM Customers c
LEFT JOIN Orders o 
ON c.CustomerID=o.CustomerID
WHERE o.OrderID is NULL;

Задача 3

Таблица: Products;

Вывести наименование (ProductName) и цену (Price) продукта, цена которого, предшествует минимальной.

Например: Представим, что в таблице представлены продукты по следующим ценам: 0.5$, 2.8$, 6$, 22$. Из данного перечня, нам необходимо было бы получить запись о продукте, цена которого составляет 2.8$.

Решение
SELECT ProductName, Price 
FROM Products
WHERE Price > (SELECT MIN(Price) FROM Products)
ORDER BY Price ASC
LIMIT 1;

Задача 4

Таблицы: Customers, Orders;

Вывести список имен клиентов (CustomerName), даты заказов (OrderDate), и кол-во заказов, для клиентов, которые сделали более одного заказа, за январь 1997-го года.
Упорядочить список по кол-ву заказов, в обратном порядке.

Решение
SELECT c.CustomerName, o.OrderDate, Count(c.CustomerName) AS LoyalClient
FROM Customers c
JOIN Orders o ON c.CustomerID=o.CustomerID
WHERE o.OrderDate LIKE "%1997-01%"
GROUP BY c.CustomerName
HAVING LoyalClient > 1
ORDER BY LoyalClient DESC;

Задача 5

Таблицы: Customers, Orders;

Вывести список имен клиентов (CutomerName), а также кол-во осуществленных ими заказов, для всех клиентов, кто сделал более 6-ти заказов.
Упорядочить записи, по количеству сделанных заказов, в обратном порядке.

Решение
SELECT c.CustomerName, COUNT(c.CustomerName) AS OrderRate
FROM Customers c
JOIN Orders o ON c.CustomerID=o.CustomerID
GROUP BY c.CustomerName
HAVING OrderRate > 6
ORDER BY OrderRate DESC


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

Если вспомнятся интересные задачи, добро пожаловать в комментарии здесь, или в ТГ канале SQL решает

Успехов в развитии!

Комментарии (8)


  1. Akina
    01.08.2023 14:34
    +4

    По оформлению - потрясающе безграмотный опус. Такое впечатление, что запятые расставлял ГСЧ. Ну и в остальном не без нареканий.

    По содержанию - совершенно бесполезное творение. ИМХО, конечно. Ибо неспособно научить ничему в принципе, хотя бы потому что не учит. Вот просто не учит и всё, нигде по тексту, ни в одной буковке. В принципе. А вероятность получения на собеседовании именно опубликованной задачи - практически нулевая.


    1. Politura
      01.08.2023 14:34
      +1

      Ибо неспособно научить ничему в принципе, хотя бы потому что не учит. Вот просто не учит и всё, нигде по тексту, ни в одной буковке.

      Ну так-то сборник задачек во все времена подразумевался как подспорье к самостоятельному изучению и сам по себе ничему не учит. Решаешь задачу, с ходу не получается - лезешь в документацию, чтоб найти что-то подходящее под алгоритм, что держишь в голове. Другое дело, что и задачек здесь очень мало и нет обычного плавного нарастания сложности (да и вообще сложных задачек нет, только немножко базы). Лет 15 назад видел в инторнетах сборник задач по SQL, как раз для подобных целей, там их было значительно больше.


      1. Akina
        01.08.2023 14:34
        +1

        Ну так-то сборник задачек во все времена подразумевался как подспорье к самостоятельному изучению и сам по себе ничему не учит.

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


  1. Politura
    01.08.2023 14:34
    +3

    Задача 3: если товаров с одинаковой ценой удовлетворяющей условию будет больше одного, предложенный запрос все равно вернет только одну запись, что обычно имеет мало смысла. Ибо еслиб нужны были не записи заказов, а именно что цена, то и вопрос бы звучал по другому.

    Задача 4: Когда требуется период по дате, надо период и задавать в условии, ибо в предложенном варианте индекс по полю OrderDate (если он есть) использоваться не будет и придется делать фулл-скан таблицы.

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


  1. FanatPHP
    01.08.2023 14:34
    +4

    Эта публикация сильно выиграет, если вступление (больше похожее на SEO текст) сократить до одного абзаца, уменьшить количество рекламы, и добавить хоть какие-то объяснения к приведенным запросам. Заодно поправив их по замечаниям выше.


  1. censor2005
    01.08.2023 14:34
    +1

    Вывести список имен клиентов (CustomerName), даты заказов (OrderDate), и кол-во заказов

    А какую именно дату выводить? В ответе несколько заказов ведь выходит, какой смысл выводить одну из результирующих дат? А группировка идёт по имени, а не по дате...


  1. Alexpwnz
    01.08.2023 14:34

    Очень много воды, задачи однотипные и совсем уж на джуна, если говорить о программистах. Если посыл был, что можно проверять например аналитиков или ещё кого то, на умение думать, то он не раскрыт, т.к. все сводится к знанию синтаксиса.


    1. Akina
      01.08.2023 14:34
      +1

      Наверное, всё же это верно наполовину... да, только на знании синтаксиса и более-менее понимании, как оно выполняется, можно написать запрос - но только если он сравнительно прост. Как только запрос более-менее сложен (особенно для эффективности если нужно использовать CTE и оконные функции) - решение на голом знании синтаксиса оказывается настолько монстрообразным, что остаётся только за голову хвататься.

      Вот как пример, совсем недавно столкнулся. Есть юзер-значение, надо поделить на группы с равным значением и добавить 2 колонки - номер группы и количество юзеров в группе. Вроде тривиально - оконные SUM и DENSE_RANK... но товарищ на голом синтаксисе такого наворотил! хотя следует признать - результат был правильный, пусть и считался долго.