SQL на 12 из 10: почему шкала навыков не работает и как оценивать по задачам

«Оцените знание SQL по шкале от 1 до 10» – многие сталкивались с таким вопросом на собеседованиях. Порой кандидаты отвечают легко и самоуверенно. Известен анекдотичный случай, когда выпускник вуза заявил: «Я бы поставил себе 10, но вообще-то скорее 12». Но что на самом деле значат эти цифры?

Один человек ставит себе «семёрку» – это много или мало? А если кто-то заявляет «десятку», означает ли это, что он без труда напишет запрос с 100 JOIN’ами или спроектирует собственный SQL-движок? В блоге Talentnauts справедливо заметили: без контекста такой самооценке грош цена (источник talentnauts.com). Цифра сама по себе ничего не говорит о реальных умениях – нужны конкретные критерии и примеры задач, которые подтолкнут кандидата объяснить свой уровень в содержательных терминах, а не просто баллах.

Почему рейтинги «на глазок» обманывают

Когда соискатель слышит вопрос про «оценку навыков в баллах», чаще всего он отвечает интуитивно, опираясь на субъективное ощущение уверенности. Многие воспринимают цифру как уровень собственной уверенности, а не фактических знаний. Не случайно появились негласные советы: не занижать себя ниже 7, но и не называть 10 – мол, 10 баллов могут показать излишнюю самоуверенность, а 6 и меньше – неуверенность. В результате кандидаты массово называют «8 из 10» или около того, и вопрос превращается в пустую формальность.

При этом сам интервьюер часто не имеет чёткого определения, что значит тот или иной балл. Как метко пишет Vidya Patil, без явных критериев «я понятия не имею, что означает любая цифра на этой шкале». Вывод: оценка «на глазок» в X баллов по шкале – вещь почти бесполезная, если заранее не определить, что стоит за каждой цифрой.

Чтобы сделать такой вопрос осмысленным, нужен контекст и описание уровней. Иными словами: что кандидат умеет делать на уровне «5/10», «7/10» или «10/10»? На практике гораздо полезнее спросить: «Что вы уже сделали с помощью SQL? С какими задачами справлялись?».

Эксперты по найму рекомендуют вместо процентных диаграмм и самодельных «шкал знаний» просто перечислять конкретные навыки и достижения. Например, вместо абстрактного «SQL – 80% из 100» лучше написать: «умею составлять сложные запросы с пятью JOIN’ами; использую материализованные представления; понимаю и оптимизирую план выполнения запросов». Согласитесь, такой ответ говорит куда больше, чем просто «я на 8 из 10». А уж заявить уровень выше максимума – это почти мем, который точно насторожит специалиста: действительно ли человек досконально знает SQL, или переоценивает себя?

Уровни задач: от простых запросов к сложным кейсам

Раз вместо цифр лучше говорить о задачах, возникает вопрос: какие бывают уровни SQL-заданий? Сообщество разработчиков и преподавателей фактически уже выработало некую шкалу сложности задач по SQL. Учебные курсы и тренажёры делят практику на базовый, средний и продвинутый уровни (источник geeksforgeeks.org). На базовом – простейшие операции выборки данных: SELECT с фильтрацией, простые условия WHERE.

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

Примеры. Новичку по силам запрос вроде: «Получить список всех сотрудников с именем David из таблицы Employees», который решается элементарным условием WHERE first_name = 'David'habr.com. Такой запрос не требует ничего, кроме умения выбрать данные из одной таблицы. Но вот задача посложнее: «Для каждого региона вывести количество сотрудников, работающих в нём».

Она уже подразумевает соединение сразу нескольких таблиц – Employees, Departments, Locations, Countries, Regions – и группировку результатов по региону. Решение потребует написания цепочки JOIN’ов через все пять таблиц и использования агрегатной функции COUNT() для подсчёта сотрудников. Очевидно, что новичок с таким не справится – тут нужен как минимум уверенный middle-уровень знаний SQL.

Ещё более сложные задачи могут включать, например, коррелированные подзапросы (запросы внутри запроса, зависящие от внешних данных) или оконные функции для сложных аналитических выборок. Отдельная высшая лига – оптимизационные задачи, где нужно не только написать запрос, но и сделать его максимально эффективным. Например, умение читать и интерпретировать query plan (план выполнения) – признак действительно продвинутого специалиста. Такой эксперт знает, как ведёт себя запрос «под капотом» СУБД, и может улучшить его производительность, переписав или добавив индексы.

Подобные навыки обычно отличают Senior-уровень или даже архитектора баз данных. Недаром в том же примере от Patil отмечалось: если кандидат ставит себе «10/10», подразумевается, что он способен не только писать любые запросы, но и, условно, «спроектировать движок базы данных». Конечно, в реальности далеко не все, даже опытные разработчики SQL, имеют такой уровень понимания внутренностей СУБД – отсюда и сомнительность самооценки «десятка из десяти».

Как измерить свой уровень объективно

Одно дело – разделить абстрактно задачи на «простые» и «сложные», а другое – померить навык на практике. Существует несколько подходов к объективной оценке уровня SQL. Во-первых, это тесты с баллами. К примеру, платформа Stepik предлагает пройти онлайн-тест из практических заданий и получить оценку по 70-балльной шкале – результат сразу покажет, дотягиваете ли вы до уровня Middle или пока остались на Junior.

Другой вариант – оценки в процентах и сертификаты. Сайт LearnSQL.com, например, выдает сертификат компетентности, если вы прошли их SQL-ассессмент минимум на 70% (источник learnsql.com). Формальные метрики вроде «70 из 100 баллов» смотрятся куда убедительнее голословного «я знаю SQL хорошо». Но и здесь важнее не сам балл, а что стояло за ним – какие задачи вы смогли решить, а какие оказались не по зубам.

Во-вторых, это специализированные тренажёры и соревнования. Существуют онлайн-платформы (той же SQL-ex, Hackerrank, Codewars и др.), где сотни практических задач рассортированы по уровням. На SQL-ex.ru, например, задания разделены на этапы, и каждому присвоен уровень сложности от 1 до 4 (грубо говоря, от элементарного до весьма хитрого). Более того, система фиксирует, сколько времени решали задачу лучшие участники, и на основе этого вычисляет рейтинг сложности (источник sql-ex.ru).

Интересный факт: порой субъективная оценка задачи пользователями не совпадает с объективной сложностью. Задача может набрать высокие оценки «за интересность», хотя на её решение у профи уходят часы и дни. Поэтому доверять стоит именно объективным показателям: сколько людей сумели решить и сколько времени это заняло. Чем меньше решивших и чем дольше они бились – тем выше реальная сложность задачи.

Например, простые упражения на SQL-ex из базового этапа решили тысячи пользователей, и на каждый уходит не больше пары минут. А вот самые сложные задачи продвинутого уровня порой покоряются лишь единицам. Так, одна из задач с максимальным уровнем Bonus 4 там была решена лишь 9 участниками, тогда как более простое упражнение Bonus 1 из того же набора осилили десятки человек (источник sql-ex.ru). Разница очевидна. Поэтому, оценивая себя, полезно спросить: сколько типовых задач разной сложности вы готовы решить прямо сейчас?

Если вам по силам только простые выборки вроде вывода сотрудников по одному условию – ваш уровень ближе к новичковому. Если уверенно джойните таблицы и агрегируете данные – вы уже средний уровень. Если же можете разобраться с любым подзапросом, написать оконную функцию или оптимизировать тяжелый отчёт – смело относите себя к продвинутым специалистам. Такое позиционирование будет честным и понятным читателю резюме или интервьюеру, особенно если подкрепить его примерами: «умеею то-то и то-то…» вместо сухого числа баллов.

Вывод: показывайте навыки, а не цифры

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

Поэтому при оценке – будь то самодиагностика или отбор на работу – ориентируйтесь на перечень задач и технологий, освоенных вами. Подкрепляйте свои слова ссылками на проекты, сертификаты, результаты тестов. Такой подход выгодно отличит вас от конкурентов, ограничившихся пустым заявлением в духе «SQL на 8 из 10».

Вместо того чтобы пытаться перевести опыт в условные цифры, покажите знание дела. Расскажите, как вы оптимизировали сложный запрос, какой интересный кейс решили с помощью подзапроса или с какими объёмами данных работали. Это и будет честная «оценка SQL» – через призму конкретных уровней задач, а не субъективной шкалы.

Ведь в конце концов, намного убедительнее звучит фраза «писал запросы с 5 JOIN’ами и разбирал планы выполнения в PostgreSQL», чем «знаю SQL на 9 из 10». Поэтому забудьте про мифические баллы «на 12 из 10» – лучше докажите свой уровень на деле. И тогда никакая шкала не понадобится.