Собеседования на аутстаф, которые бесят: истории неудач при найме разработчиков
Собеседование в аутстафе можно сравнить с тестом на IQ, по итогам которого хотят понять насколько ты хорошо сыграешь в постановке Гамлета. Неочевидные задания, созвоны на английском в 2 часа ночи, открытые вопросы, на которые у интервьюера есть свой идеальный ответ — это неполный список того, с чем в реале сталкивались наши разработчики. Опроси…
Что от аутстаф-собеседования ждет заказчик: удостовериться, что, запрашивая middle java developer, он получит именно его знания и коммерческий опыт, а не junior'а после курсов c опытом прохождения собеседований.
В 99% случаях ни в чём он не хочет удостовериваться, он хочет, чтобы его фича была быстро сделана в срок, и нормально работала. Как - уже другой разговор
Совет: подробно рассказывайте о проекте, освещайте проблемы, чтобы специалист мог уже на собеседовании понять, с чем ему придется работать. Распишите должностные обязанности. Расскажите, чем предстоит пользоваться в работе.
Это если компания нормальная. Как раз таки подобная практика и используется с целью нанять себе дурачка, который по джуновской цене будет деплоить, тестить, разрабатывать, дизайнить и т.д.
Я бы сказал, что если этот компонент отсутствует, надо сразу искать себе какое-нибудь другое место.
2. Сдаем экзамен
Советы очень противоречивые. Можно согласиться с тем, что нужно спрашивать только конкретику и только то, чем предстоит реально заниматься. Но разработка - она на то и разработка, что неизвестно, что предстоит делать завтра. Тем более во всяких аутсорсах. Неоднократно был опыт собеседования на senior разработчика и тимлида, и в следующие пары месяцев приходилось верстать формочки, потому что один заболел, второй в отпуске, у третьего ещё что-то, а задачи делать надо.
Я бы сформулировал совет так - нет смысла спрашивать выше той сложности, какая потенциально может быть, как нет смысла у высококвалифицированного специалиста спрашивать, знает ли он flex-box. Если приходишь верстать формы - нет смысла спрашивать про паттерны. Но если ты условный скилловый middle/senior в нормальный проект, будь добр, рассказывай про SOLID. При любом отклонении возникает вопрос - а зачем? И этот вопрос стоит задавать интервьюеру.
4. Открытые вопросы, закрытые ответы
Тут люто плюсую, и в принципе, изначально со стороны интервьера хорошо задавать рамки - тут да/нет, а вот тут развёрнуто. Считаю это правилом хорошего тона. Особенно раздражает отдельный вид чертей, когда в практических заданиях они ожидают какое-то конкретное решение, а на все остальные безосновательно ругаются. Даже когда ты им проговариваешь полностью алгоритм, просят, чтобы ты его написал, потом докапываются до каких-то мелочей. Вот такое - сразу в самое далёкое путешествие.
А так, статья хорошая, но считаю, что темы раскрыты недостаточно хорошо. Большинство описанных проблем - уровня стартапов, в больших компаниях их, как правило, нет.