Введение
В поисках работы я прошел 20 собеседований и теперь хотел бы поделиться субъективным мнением на этот счет. Все компании российские и вы точно их знаете.
Общее впечатление положительное. Все собеседования проходили удаленно, в один или два этапа. Не было опозданий, переносов, на всех собеседованиях у интервьюера была включена камера, в целом все вежливо и адекватно.
Для меня собеседование это не стресс, а возможность проявить себя и узнать что-то новое. Собеседований так много, потому что я хотел точнее узнать свою цену.
Жирным шрифтом в тексте выделены основные мысли, которые я почерпнул.
Собеседование
У компании нет четкого понимания кто и зачем ей нужен.
Процесс собеседования не стандартизован. Зачастую складывается впечатление, что сотрудника просто выдернули за руку, включили перед ним камеру и сказали задавать любые технические вопросы из головы. В результате собеседование превращается в стохастическое блуждание со скатыванием в локальный минимум холивар.
Без четкого плана собеседования легко закопаться в какой-то одной теме и забыть спросить что-то важное. На мой взгляд у интервьюера должен быть список обязательных тем, на которые стоит поболтать: архитектура, база данных, язык, асинхронное программирование, разработка веб приложений, ORM и т.д. Желательно этот список сразу озвучить, чтобы я мог напомнить, если вы что-то упустили.
Можно даже зафиксировать единый список вопросов для всех кандидатов одной позиции. Переобучение, да. Но ведь всегда можно копнуть влево/вправо, да и проверка практических навыков программирования будет уникальной.
Еще для меня странно, когда работодатель задает только теоретические вопросы и не требует продемонстрировать практических навыков программирования. Мне, конечно, льстит, что меня и так готовы брать, но ребят, камон. Вы берете человека на работу, чтобы он программировал и не проверяете, что он умеет программировать.
Проверяйте, мне будет приятно. А главное, я буду уверен, что человек, сидящий рядом, знает не меньше меня и умеет примерно то же самое. Мне будет интересно с ним работать, вместе развиваться и просто болтать на кофе-поинте.
Тестовые задания
Я нормально отношусь к тестовым заданиям. Если у вас нет примеров кода в открытом доступе, желание работодателя увидеть, как вы программируете, естественно.
Скучные тестовые задания обречены на невыполнение.
Предложения написать классы для рисования геометрических фигур в консоли сразу отправляются в корзину. Возьмите себе студента второго курса технического вуза, у него как раз недавно лаба такая была.
Интересные тестовые задания хочется выполнить.
В одной из компаний мне предложили представить, что я разрабытываю Web API для системы выдачи заказов. Был предложен набор классов, описывающих заказ и высокоуровневое описание методов для работы с ним. При этом выбор всех технологий для реализации, за исключением языка программирования, был отдан на откуп разработчика.
Но без точных требований они также обречены не невыполнение.
В формулировке тестового задания не должно быть фразы "на ваше усмотрение".
Вы же сами прекрасно знаете, какие технологии используете, чем кандидату предстоит заниматься и какие навыки нужно проверить в первую очередь. Не стесняйтесь, впишите их в требования к заданию, так правда будет проще.
Я ведь могу усмотреть использовать Dapper для работы с базой, а у вас везде EF и вы вообще не пишите SQL. Или я возьму в качестве БД для тестового задания Postgres в локальном Docker, а у вас CosmosDb в Azure. Или напишу API на REST, а у вас внутри все сервисы по GRPC общаются. И что вы тогда проверите этим тестовым? Что я владею нерелевантными для вас технологиями?
Если копнуть глубже, появляются еще вопросы. Обработку исключений делать нужно? А тесты написать? А валидацию модели делать? А модель у вас вообще анемичная или богатая? А mediatr используете? А...? А...? А...?
Хорошее тестовое задание не должно порождать вопросов.
У меня помимо основной работы 2 собеседования в день + собака/жена/дети/новый эпизод любимого сериала. Я не хочу тратить время ночью на попытки угадать, что от меня хотят.
Отсутствие четкой формулировки задачи - катализатор прокрастинации. Если у меня цель найти интересную и хорошо оплачиваемую работу, а не устроиться именно к вам в компанию, смысла выполнять тестовое задание нет. Есть куча предложений без тестового. Или с ним, но гораздо лучше сформулированным.
Поэтому лучше давайте программировать вместе.
Ведь именно это моя работа и я ее люблю. Я всеми руками за лайвкодинг. Накидайте заранее классов и попросите их исправить или провести ревью. Опишите кусочек логики на уровне интерфейсов и попросите написать реализации. Или давайте в отладке попробуем найти ошибку в бизнес логике.
Только прошу. Если требуете, чтобы весь написанный код компилировался, дайте нормальный инструмент, хотя бы с подсветкой синтаксиса, можно без IntelliSense.
HR
Минимальное знание предметной области, пожалуйста.
Это скорее придирка, я ведь все равно вас пойму. Но улыбка на лице появляется каждый раз, когда слышу в телефонной трубке: "Вы работали с эс-кэ-эл?", "А с рЕст?"
– У вас есть опыт программирования на языке C#?
– Да, около 2,5 лет.
– Вы работали с netcore 3.1?
– Да, мы раньше использовали 2.0, потом перетащили сервисы на 3.1
– А программировали на .net framework?
– Эмм, да. Кстати, я еще и net5 знаю.
Возможно примеры несколько утрированы, но суть, думаю, ясна. Я не обижаюсь, но раз вы уж пишите в статусе "набираю кандидатов на C#", произносите хотя бы аббревиатуры не по буквам и с правильными ударениями.
Простите, но мы с вами не друзья.
Как бы странно это не звучало, но я хочу, чтобы со мной общались сухо. Без смайлов, стикеров, скобочек и т.д. Мне так будет проще вам отказать.
Все вот эти "команда тебя очень ждет :) " или "тимлид Ваня хочет поработать с тобой" создают дополнительную эмоциональную привязку и показывают ваш непрофессионализм. А еще мне потом неудобно говорить вам "нет" и неловко объяснять, почему именно я выбрал другую компанию.
Еще один очень субъективный момент. Для меня странно, когда ваш личный аккаунт совпадает с рабочим. Когда вы пишите мне в мессенджере, а на фото вы в купальнике на фоне моря, с мужем и ребенком возле подъезда или на групповом фото с корпоратива, где вообще непонятно кто конкретно мне пишет.
Заключение
Я нашел наиболее приятный для себя формат собеседования: технический блиц в виде вопрос/средней глубины ответ, а затем совместное программирование.
Только на одном собеседовании меня спросили:
– Следишь ли ты за языком C#? Какие новые фичи языка ты знаешь?
– Какие последние книги/видео/подкасты/блоги ты смотрел по C# ?
Я с большим удовольствием рассказывал про POH, отдельные типы для даты и времени, "Микросервисы" Ричардсона и два русскоязычных подкаста про dotnet.
Предлагаю задавать эти вопросы на каждом собеседовании независимо от позиции разработчика. На них интересно отвечать, они создают дополнительные темы для обсуждения. А главное, можно попытаться оценить энтузиазм и то, насколько разработчик получает кайф от своей профессии.
