Введение
В поисках работы я прошел 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.
Предлагаю задавать эти вопросы на каждом собеседовании независимо от позиции разработчика. На них интересно отвечать, они создают дополнительные темы для обсуждения. А главное, можно попытаться оценить энтузиазм и то, насколько разработчик получает кайф от своей профессии.
Комментарии (24)
ETman
15.12.2021 01:04+1Очень субъективный текст. Сложно с чем-то спорить, не потому, что это неправильно. Оно правильное, но не понятно к чему претензии в итоге.
Например, тестовые задания. У людей, которые пашут по 10-14 часов времени писать ЕЩЁ те товары задания нет. А "типа интересные" вообще нет. Но с другой стороны, что-то нужно дать для проверки навыка программирования и анализа задания. Не слишком сложные, но довольно открытое, чтобы увидеть как думает кандидат. Поэтому даёшь "не интересное" задание. Если человек его решил, то как минимум есть тема для дискуссии и понятно что замотивирован.
indestructable
15.12.2021 01:19Автору могу порекомендовать провести несколько собеседований (если не проводил). И потом послушать обратную связь от респондентов. У всех разные критерии, и разное представление о том, какое должно быть собеседование.
Для меня важно две вещи (при собеседовании джунов и миддлов): первое - как соображает кандидат, как он формулирует свои мысли, как он понимает меня (если мне с ним работать), как рассуждает о вещах, в которых он разбирается. Второе - это как пишет код, насколько быстро ориентируется в простейших конструкциях, насколько задумывается в написании циклов, условий, и тп - показывает, как много человек пишет код, насколько он освоил базу языка.
С синьорами другие критерии - там для меня важна глубина и структурированность знаний, особенно по базовым вопросам (асинхронность, архитектура, и тп), а также системность мышления и коммуникационные навыки - как человек выражает и доносит свои мысли, как объясняет сложные вещи, как рассуждает о вещах, с которыми не знаком (например, каким-то паттернам архитектуры, с которыми не работал непосредственно).
alexey_girin
15.12.2021 01:34-1Не надо.
Ваш подход к оценке кандидата - слишком субъективен, а значит - несправедлив.
Попробуйте ДАТЬ обратную связь тем кандидатам которых вы собесили и послушать что они на это скажутindestructable
15.12.2021 03:12+3Но собеседование и не должно быть справедливым, и оно должно быть субъективным, особенно если вам предстоит работать с этим человеком. Не все друг другу подходят, и это не значит, что компания плохая или кандидат плохой.
Я даю обратную связь, только если кандидат просит, либо как мягкую форму отказа (вам нужно для этой позиции подучить тото и тото). Ну и никто ничего плохого мне никогда на обратную связь не отвечал. Человек как правило осознаёт свой уровень, и насколько хорошо он отвечал.
pdepdepde Автор
15.12.2021 09:35Мне пока сложно окончательно принять вашу первую мысль. Мы вроде как хотим объективные результаты (кандидаты одной позиции +- одинаковые по навыкам и взаимозаменяемые) с помощью субъективного алгоритма.
Скорее всего у человека, который провел несколько десятков собеседований уже чуйка на хороших и адекватных специалистов. И ничего страшного, если их знания будут разными, они наоборот в процессе работы усреднятся и подтянут друг друга. Значит, по идее, в процессе собеседования можно вполне обоснованно опираться на свои ощущения.
Но из-за субъективизма у нас появляются миддлы в одной компании, которые с натяжкой считались бы джуном в другой.
JLavlinskaya
15.12.2021 09:37+3Интересный опыт) Жаль, не все могут ответить на вопрос про свежие фичи или хотя бы что вообще нравится в языке.
Когда-то я работала эйчаром и общалась с людьми из пункта как не надо, т.е. по-дружески. Собесы тогда ещё были в офисе: мы с кандидатами пили чай, болтали о жизни и попутно отвечали на вопросы друг друга.
По итогу я получала фидбэк, что приятно человеческое общение, а не отношение к кандидату как к ресурсу.
Это я к чему – все люди разные и хочу предостеречь начинающих рекрутеров от того, что существует единственно верный вариант.
var1ap
15.12.2021 09:39+2Лайфкодинг фигня собачья
если автору это нравится, большему колличеству людей это только стресс
и кандидат неможет себя показать во всю сили
fshp
15.12.2021 10:33Лайфкодинг на обязательно подразумевает кодинг. Кандидат может затупить с кодом, но на пальцах объяснить что и как должно работать. Этого бывает достаточно. Это просто ещё один вопрос, ответ на который просто удобнее записать.
nex-54
16.12.2021 16:26В тепличных условиях все код писать готовы. Только хз где есть такая работа без пожаров и прочего.
Особенно забавно, когда в резюме написано 'стрессоустойчивый', а на собеседовании человек чуть в обморок не падает от того, что его просят написать простой код.
WhiteBehemoth
17.12.2021 10:00Интересная мысль. А как кандидат может показать себя во всю силу? Чтоб и раскрыться и без стресса. Разве что заранее согласовать список вопросов...
Из личного опыта - код на интервью снимает много вопросов по уровню кандидата. Как человек пишет, на чём ошибается, как реагирует на замечания. Даже то, как приступает к работе.
Myclass
15.12.2021 15:00В моём прошлом, когда только работу разработчика искал, то подходил к этому процессу как люди из искуства. У меня была своего рода папка (я её сделал как переплетённую книжку), в которой по темам лежали различные листы. Много листов. Там были темы по разработки баз данных, куча всяким моделей. Там были всевозможные зарисовки как процессов, так и GUIs, и много чего разного. Посмотрев в таку папку люди получали хорошее представление о том, как я работаю. Было всегда неожиданностью для всех и поэтому листалось с большим интересом. Конечно программного кода там было мало, тем более специального как например c# — понятно почему, но общее преставление обо мне люди могли себе создать. И часто — оно было не ошибочное.
eldog
15.12.2021 18:06По моему опыту, при собеседованиях на сениорские позиции код писать просят довольно редко. Хотя недавно вот писал :-) Но чаще происходит "беседа двух умных людей", когда по итогам понятно, что ты в теме, работал на таких-то проектах, решал такие-то проблемы.
AlexDevFx
15.12.2021 18:27Лайвкодинг разный бывает и соответственно результаты его прохождения меняются от негативного до полного принятия. Случаи, где тебе предоставляют код на ревью или дописать логику, бывают нечасто. Меня однажды попросили архитектуру приложения описать по заданию. В остальных случаях приходилось код писать с нуля. И вот была загвоздка. Кто-то придирался к каждой мелочи, кто-то требовал получить правильный результат решения задачи, не глядя на процесс, а кто-то требовал реализовать паттерны. Плюс зависит от кандидата. Бывает что человек из-за волнения не может выдать сразу результат. Поэтому это совместное программирование - не панацея.
fasulala
15.12.2021 18:51Собеседований так много, потому что я хотел точнее узнать свою цену.
Скажите пожалуйста, сработала ли тактика? Получили максимальный оффер по своему уровню?
pdepdepde Автор
15.12.2021 18:56Сработала. Я получил интервал зарплат, которые мне готовы платить. В итоге пошел не на максимальный оффер, а чуть меньше - там проект интереснее.
Myclass
16.12.2021 00:25В итоге пошел не на максимальный оффер, а чуть меньше - там проект интереснее.
Простите, не верю таким обьяснениям. Объясню - почему. Проект интереснее? Может быть. Но всяк проект имеет тенденцию быть законченный, если конечно это не agile-проект (#полушутка). Поэтому это или боязнь чего либо или ещё симптом невзросления или нежелания изменить комфортную ситуацию. Ну там от требования других языков, или незнакомых или запутанных технологий, доп. инвестиций как например покупка машины, когда её не было, подруга/жена не хочет, чтобы чел по долгу не приезжал домой до банальных - до работы будет далеко. Интересности или неинтересности проекта, его возможные подводные камни в реализации вас как специалиста, проекта или вашего роста не возможно после 30 мин. разговора просечь. Единственное, что можно это представление о климате в коллективе, да и то не всегда. Поэтому, такие отговорки это для себя. Не желаю обидеть, но это моё мнение. А чтобы вообще не обидеть, добавлю - но всегда могут быть исключения ;)
xeAexMRK
16.12.2021 09:42Ну тогда исключение: на проекте с легаси платят больше, на проекте с C#10, .NET 6 [вставить недостающее] платят немного поменьше. Выбор может строиться в том числе и от этого. Другой вопрос - можно ли из-за этого называть проект интересным или нет, но это лишь пример.
nex-54
16.12.2021 16:30Насколько сейчас рынок .нет живой? В свое время ушел с него тк интересных компаний и зарплат не нашел.
Danik-ik
15.12.2021 21:32+1Я не стал отвечать «херню несёт», скорее, автор несёт вкусовщину. Задание «на ваше усмотрение», например, может показать работодателю моё умение работать с нечёткими требованиями (такое бывает, к сожалению). Если нет желания пытать «заказчика» вопросами, я всегда могу отметить наличие неоднозначности и явно обозначить свои предположения на этот счёт.
Но как пример частного мнения — было интересно. Постоянно убеждаюсь, что люди очень разные, что хотят они разного, и подстроиться под каждого невозможно. И всё-таки при этом есть люди, которые находят себе подходящие компании, и есть компании, которые находят себе подходящих людей. Не с первого раза зачастую, но находят.
Dekmabot
Я чуть из другой сферы собеседую, но тоже не прошу писать код на собесе, многих это вгоняет в стресс. Вопросы "а с этим работали, а про это слышали" - мало что показывают. Простой разговор про опыт, про трудности и поиск их решения - о многом говорит. Товарищ сможет где-то похвастаться, а где-то пожаловаться. Конечно же все вопросы про то, с чем придётся работать)
Из кода - на собесе даю какой-то кусок кода на листочке А4, прошу рассказать что код делает и что можно сделать по другому. Сразу видно как быстро может вникнуть в проект, на сколько внимательный и какими порядками мыслит. Этот приём позаимствовал с одного своего собеседования.
А если товарищ на столько качественно привирает что я не замечу - это будет видно на испыталке, но таких пока не встречал.
QviNSteN
Как по мне, если разраб способен наврать так что его примут, то его скорее проще принять и научить требуемому. Потому что он явно понимает о чем говорит, хоть и врёт что применял на практике :)
Говорю так, потому что первый год работы именно так и действовал. На собесе наврал полностью. А потом на первом же задании тупил потому что тупо не мог понять как вообще у них устроена архитектура.
Но спустя месяц влился и работал в общем темпе, хотя по началу было 0 знаний