![](https://habrastorage.org/getpro/habr/upload_files/ef3/c00/03b/ef3c0003b8f32260683589fedba65c34.jpeg)
«Можно вечно смотреть на три вещи: как горит огонь, как течет вода и как несколько
бездельниковSenior dev собеседуют Junior».
Собеседования и в целом рынок IT вакансий одни из самых частых тем мемов в комьюнити, особенно среди людей с небольшим опытом.
Как их проводить, как понять, что компания не подходит, с кем соглашаться работать, а с кем нет?
Как начать за здравие
Один из важных моментов в собеседованиях - оценить друг друга. Что имеется ввиду: понять насколько разработчик подходит команде и наоборот. Факапом можно назвать ситуацию, когда разработчика начинают гонять по технической части, а потом выясняется, что ему в принципе не интересен проект или рабочие процессы. Поэтому очень важно в начале обозначить в чем заключается суть работы, на которую ищут работника, ну и не забыть рассказать о внутреннем устройстве рабочих процессов. Про диапазон зарплат и говорить смысла нет.
Что по поводу тестовых заданий?
Я лично не разделяю практику, когда человеку могут отправить тестовое на 3+ часов работы, это трата времени людей (если речь не о джунах, им полезно, простите). Есть легкое ощущение, что и в небольшом тестовом можно проверить компетенции человека: выстраивание архитектуры, принятый StyleCode в сообществе (PEP 8 для Python например).
Бывают истории, когда не дают обратную связь на тестовое, не делайте так, никто такое не любит и отношение будет соответствующее.
Наилучший вариант - небольшое тестовое, в идеальном мире - оплата за его выполнение.
Самый комичный случай из моего опыта: вакансия Middle Frontend на 500$ (на тот момент у меня уже был год опыта в сфере) и тестовое в 3 этапа в отведенное время, суммарно: 20 часов.
А как насчет live coding и leetcode?
Не хотелось бы развязывать споры, но под многие задачи на рынке не нужны высококвалифицированные инженеры-математики, которые умеют в алгоритмы сложнее бинарного поиска или сортировки.
![](https://habrastorage.org/getpro/habr/upload_files/c46/563/8f8/c465638f84347c1d3b7a811de70c97da.png)
Но live coding мне кажется неплохая практика. Все опять же зависит от подачи, человек всегда может занервничать и не решить что-то, но в целом это позволяет увидеть как человек думает и пишет код.
Для джунов без опыта опять же исключение: странно брать человека, если он нигде не работал и нет никаких примеров, надо хоть какое-то подтверждение навыков. Если конечно же задача не в том, чтобы вырастить с полного нуля под себя.
Техническая часть или самое пугающее
О чем спрашивать? Что должен уметь Frontend Middle? Тут уже для каждой компании индивидуально, как и само понятие грейдов у всех своё, самое честное как мне кажется у банков и больших компаний - усредненный вариант.
Разумнее всего для начала проверить знание основ разработки, общие для всех паттерны вроде KISS, DRY, SOLID. Даже если разработчик не силен в названиях всегда можно спросить какие он сам для себя бы вывел и как бы их описал.
По технической части все индивидуально для стеков. Как frontend dev я предпочитаю спрашивать основы из документации. Например на проект с React нельзя не спросить про хуки, HOC, методы оптимизации, state менеджеры. Но в тоже время гонять лишний раз по Flux-архитектуре не целесообразно, скорее всегда это никогда не пригодится, особенно если речь не о высококвалифицированном разработчике.
С кем лучше не работать
В заключении выведу несколько пунктов, по которым я бы лично не стал продолжать общение с компанией (ну или несколько советов как не надо делать):
большое тестовое задание (хотя может вы единственный его сделаете и получите оффер на 1000000000 денег в секунду)
ситуация с несколькими разработчиками на собеседовании (если вас допрашивают на протяжении часа 3 человека - сделайте вывод о тайм-менеджменте компании)
токсичный интервьюер, который пытается показать как он хорош в чем-то, а вы нет
отсутствие понимания у компании, кто им надо
попытки купить Вас как можно дешевле нелепыми способами, кейс: "там зп указана до вычета налогов, забыли упомянуть" (деньги это важно, своим навыкам надо знать цену, хотя лучше просить как можно больше)
Всем спасибо! Цените себя и своё время.