Провести собеседование и не остаться «душнилой»
»Можно вечно смотреть на три вещи: как горит огонь, как течет вода и как несколько бездельников Senior dev собеседуют Junior».
Собеседования и в целом рынок IT вакансий одни из самых частых тем мемов в комьюнити, особенно среди людей с небольшим опытом.
Как их проводить, как понять, что компания не подходит, с кем соглашаться работать, а с кем нет?
Как начать за здравие
Один из важных моментов в собеседованиях — оценить друг друга. Что имеется ввиду: понять насколько разработчик подходит команде и наоборот. Факапом можно назвать ситуацию, когда разработчика начинают гонять по технической части, а потом выясняется, что ему в принципе не интересен проект или рабочие процессы. Поэтому очень важно в начале обозначить в чем заключается суть работы, на которую ищут работника, ну и не забыть рассказать о внутреннем устройстве рабочих процессов. Про диапазон зарплат и говорить смысла нет.
Что по поводу тестовых заданий?
Я лично не разделяю практику, когда человеку могут отправить тестовое на 3+ часов работы, это трата времени людей (если речь не о джунах, им полезно, простите). Есть легкое ощущение, что и в небольшом тестовом можно проверить компетенции человека: выстраивание архитектуры, принятый StyleCode в сообществе (PEP 8 для Python например).
Бывают истории, когда на дают обратную связь на тестовое, не делайте так, никто такое не любит и отношение будет соответствующее.
Наилучший вариант — небольшое тестовое, в идеальном мире — оплата за его выполнение.
Самый комичный случай из моего опыта: вакансия Middle Frontend на 500$ (на тот момент у меня уже был год опыта в сфере) и тестовое в 3 этапа в отведенное время, суммарно: 20 часов.
А как насчет live coding и leetcode?
Не хотелось бы развязывать споры, но под многие задачи на рынке не нужны высококвалифицированные инженеры-математики, которые умеют в алгоритмы сложнее бинарного поиска или сортировки.
Но live coding мне кажется неплохая практика. Все опять же зависит от подачи, человек всегда может занервничать и не решить что-то, но в целом это позволяет увидеть как человек думает и пишет код.
Для джунов без опыта опять же исключение: странно брать человека, если он нигде не работал и нет никаких примеров, надо хоть какое-то подтверждение навыков. Если конечно же задача не в том, чтобы вырастить с полного нуля под себя.
Техническая часть или самое пугающее
О чем спрашивать? Что должен уметь Frontend Middle? Тут уже для каждой компании индивидуально, как и само понятие грейдов у всех своё, самое честное как мне кажется у банков и больших компаний — усредненный вариант.
Разумнее всего для начала проверить знание основ разработки, общие для всех паттерны вроде KISS, DRY, SOLID. Даже если разработчик не силен в названиях всегда можно спросить какие он сам для себя бы вывел и как бы их описал.
По технической части все индивидуально для стеков. Как frontend dev я предпочитаю спрашивать основы из документации. Например на проект с React нельзя не спросить про хуки, HOC, методы оптимизации, state менеджеры. Но в тоже время гонять лишний раз по Flux-архитектуре не целесообразно, скорее всегда это никогда не пригодится, особенно если речь не о высококвалифицированном разработчике.
С кем лучше не работать
В заключении выведу несколько пунктов, по которым я бы лично не стал продолжать общение с компанией (ну или несколько советов как не надо делать):
большое тестовое задание (хотя может вы единственный его сделаете и получите оффер на 1000000000 денег в секунду)
ситуация с несколькими разработчиками на собеседовании (если вас допрашивают на протяжении часа 3 человека — сделайте вывод о тайм-менеджменте компании)
токсичный интервьюер, который пытается показать как он хорош в чем-то, а вы нет
отсутсвие понимания у компании, кто им надо
попытки купить Вас как можно дешевле нелепыми способами, кейс: «там зп указана до вычета налогов, забыли упомянуть» (деньги это важно, своим навыкам надо знать цену, хотя лучше просить как можно больше)
Всем спасибо! Цените себя и своё время.
