🐈 Прямой эфир завтра в 18:00 🐈

Заметил, какой большой отклик у вас вызвали посты про онбординг в новую компанию и технические собеседования. Для тех, кто пропустил:
➡️ Онбординг, ч.1
➡️ Онбординг, ч.2
➡️ Онбординг, ч.3
➡️ Собеседования, ч.1
➡️ Собеседования, ч.2

Решил следующий прямой эфир посвятить карьерным вопросам и позвать на него настоящего эксперта — Елену Муся, основателя и CEO HuntProfi, кадрового и консалтингового агентства, которое занимается подбором IT-специалистов.

Вместе с Еленой мы:

🟠 Разберём, как найти инженера мечты (но это не точно) и не потерять его на бесконечных этапах отбора.
🟠 Обсудим, как не превратить собеседование в допрос, и почему тестовые задания не работают (особенно на высоких грейдах).

А ещё поделимся фейлами, кринж-историями и выясним, почему «мы вам перезвоним» — это худший паттерн найма.

➡️ Когда: 12 марта в 18:00 мск

Будет весело, полезно и без «а как бы вы спроектировали свой Netflix?». Подключайтесь!

Прямой эфир через 3 часа

Сегодня встречаюсь с Еленой Муся, чтобы поговорить про технические собеседования.

➡️ Запись будет, но только в виде отдельных фрагментов. Чтобы обсудить всё без цензуры, подключайтесь онлайн.

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

Маркус уже тоже ждёт эфира. Подключайтесь в 18:00! 🐈

🐈 Мы начинаем! 🐈

Подключайтесь к трансляции.

Почему «HR нанимают не того»

➡️ Типичная история:

Рекрутер приходит к CTO:

— Какие у вас требования к кандидату?

CTO отвечает:

— Нужен сильный backend-разработчик, 3+ года опыта, который сможет оптимизировать нагрузку, работать с микросервисами и знает Kafka.

Рекрутер делает пометки:

— Так, микросервисы, Kafka…

➡️ Ремарка: что такое «знает Kafka»? Умеет подключаться и консьюмить сообщения? Знает про сложность построения exactly-once delivery? Понимает, как тюнить под нагрузки, строить мониторинг и алертинг вокруг этого?

В небольших компаниях удобно, когда человек закрывает как можно больше вопросов, но это рискованно (bus factor). А платят как за одного разработчика.Поэтому уже на этом этапе важно понять, а что скрывается под «знает Kafka».

➡️ Проходит неделя.

Рекрутер приносит кандидата:

— Вот, 3+ года опыта, знает Kafka!

CTO смотрит и говорит:

— Эм… А он вообще понимает, как писать отказоустойчивые сервисы? Он работал с highload?

Рекрутер:

— Такого в описании вакансии не было…

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

➡️ Получается, что не «HR нанял не того», а техлид сам не знал, кого ищет.

Где чаще всего ломается процесс?

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

Рекрутер ищет: 3+ года опыта, технологии, желательно из той же отрасли.

➡️ Ремарка: годы опыта мало значат. По опыту проведения технических собеседований, для примера, на позицию php разработчика на symfony, 8 из 10 кандидатов не пилили ничего сложнее CRUD сервисов. И это нормально, что для части людей разработка это просто работа, что не хочется заниматься достигаторством, а просто выполнять задачи.

Однако рынок таков, каков есть: без хотя бы частичного следования культу постоянного роста над собой в профессиональном плане сложно найти более интересные проекты. Пилить CRUD-ы 5 лет подряд просто надоедает и хочется нового. А еще неплохо бы изучать новое постоянно, потому что рынок меняется, языки и фреймворки меняются или уходят и есть риск остаться без нормальной работы, потому что твой опыт перестает так сильно котироваться на рынке, как раньше.

➡️ Решение: вместо чек-листа технологий нужно разбирать реальные кейсы, с которыми столкнётся кандидат.

Второе — разные взгляды на софт-скиллы.

Рекрутер: коммуникабельный, дружелюбный, легко вольётся.

CTO: код-то нормальный пишет?

➡️ Ремарка: по стилю общения вы могли уже догадаться, что CTO может быть довольно неприятным человеком, и с этим придется работать. Человек может не задумываться о стиле поведения, а сотрудники компании побоятся ему перечить, чтобы не вступать в конфликт. Особенно, если бесполезно спорить, и CTO на вашу работу мало влияет. А вот рекрутерам, нанимающим менеджерам, техлидам часто приходится напрямую с такими людьми общаться и добиваться от них внятных требований.

➡️ Решение: заранее договориться, какие софт-скиллы важны. Если кандидат будет общаться с бизнесом — одно, если сидеть в коде — другое.

Третье — размытые формулировки.

Рекрутер: у нас открытая, гибкая компания!

CTO: хаос, нет документации, спасайся кто может.

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

Четвертое — неправильно составленная вакансия

Рекрутер: просит нанимающего составить вакансию

СТО: недовольно гуглит и выдает какого-то франкенштейна из понравившихся фраз в вакансиях других компаний. Рекрутер делает то же самое, когда получает сухое «нам нужен рубист».

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

➡️ Решение: научиться четко формулировать запрос. Нам нужен человек под определенные задачи, определенного типажа и знаний.

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

Благодарю Елену за помощь в проведении эфира и написании поста. До новых встреч!

Подписаться на каналы Елены:
➡️ Личный блог
➡️ Канал про найм в IT

Ставьте 🔥, чтобы я понял, что эта тема важна, и ее нужно развивать дальше.

➡️ Найм специалистов DevOps — это война за кадры

DevOps супер востребованы на рынке. Грамотных специалистов мало, а потому спрос выше предложения. Длинный процесс найма = потеря кандидата.

У инженеров резюме часто не такое структурированное, как у backend-разработчиков. В нем меньше «достижений в цифрах» и больше про стек, инструменты, процессы CI/CD, мониторинг, автоматизацию.

➡️ Критично не залипать на список технологий — важнее глубина использования конкретных инструментов.

Ремарка: иногда встречаю, что глубже базовых концепций инструмента X кандидаты не идут. По резюме все может быть красиво. 2-3 года опыта с X, а на практике использование одних и тех же подходов без профессионального роста. Это не просто про то, что кандидат занимался рутиной, а еще и про то, что не пытался упростить себе работу, задействовав больше возможностей.

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

Как правильно составлять вакансию

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

➡️ Вакансия — это не просто объявление, а инструмент продаж. Нужно продать не только должность, но и компанию, команду, процессы и даже культуру разработки.

Что должно быть в хорошей вакансии:

🟣 Четкое и честное описание задач. Не «нам нужен Python-разработчик», а «мы строим новый highload-сервис для работы с big data».

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

Самый просто пример: «мы хотим переехать на k8s». Чтобы что? И вот это «чтобы что» может вылиться во много встреч, где нужно четко очертить границы того, что и как поменяется в работе, какими плюсами и, что самое главное, какими минусами для компании это грозит.

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

🟣 Реальные требования. Не список из 15 технологий, а ключевой стек.

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

🟣 Какие проблемы предстоит решать (оптимизация CI/CD, переход с on-prem на cloud и т. д.). Не надо писать только список технологий вместо реальных задач. Человек видит: «Kubernetes, Terraform, Ansible, Prometheus, Python» – и не понимает, что конкретно будет делать.

🟣 Информация о нагрузках, масштабах и зоне ответственности. Специалистам DevOps важно понимать, работают ли они на пару сервисов или на инфраструктуру, поддерживающую 100 тысяч пользователей.

🟣 Адекватное описание процесса. Как проходит найм? Сколько этапов? Какие задачи?

Тестовые задания: нужны ли они вообще?

Здесь можно долго спорить и холиварить. На практике тестовые могут понадобиться в трех случаях:

➡️ если у вас джун или миддл, а тестовое не занимает больше двух часов;
➡️ если кандидат понимает, зачем нужно выполнить тестовое;
➡️ если нет других способов проверить навыки.

Чем заменить тестовое?

🟣 Код-ревью на реальном примере.
🟣 Живое решение проблемы на интервью. Live-coding + обсуждение решений (чтобы видеть, как человек мыслит). Разбор задач, с которыми реально придётся работать.

И никакого литкода, он применяется в реальности примерно никогда за очень редкими исключениями (например, разработчиками баз данных).

Как не превратить собеседование в допрос?

➡️ Создать нормальную атмосферу. Кандидат, который нервничает, не покажет реальный уровень. Объяснить, что ждет кандидата, и по какой логике будут строиться вопросы.

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

Ремарка: такой кандидат, скорее всего, не прошел бы по софт-скиллам. Большой вопрос, как он будет дальше общаться с разными командами и людьми разного уровня.

➡️ Задавать умные вопросы, а не ловушки. «Сколько люков в Нью-Йорке?» — это не проверка логики.

➡️ Давать кандидату шанс показать себя.

Если кандидат ушёл с ощущением, что его проверяли, но не рассказали ничего о компании — значит, интервью провалилось.

Какие вопросы реально работают?

➡️ Вопросы, которые не провоцируют автоматический ответ.

Какую задачу в этом году ты сделал и гордишься? Был ли проект, который изменил твой подход?

➡️ Реальные кейсы – какие проблемы приходилось решать?

➡️ Подход к инженерным задачам вместо абстрактных HR-вопросов

➡️ Вопросы, проверяющие профессиональный кругозор — умеет ли кандидат работать с облаками, безопасностью, CI/CD.

Привет! На связи Маркус 🐈

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

Через месяц стартует поток «Kubernetes Мега» — для тех, кто уже работал с кубами или прошел базовый курс по кубам. В комментариях к этому посту напишите две темы, которые вы считаете нужным освещать в рамках продвинутого курса ⬇️