Что-то я загулялся по аэропорту и забыл о намеченном холиварчике. Так вот, собеседования. Я имею относительно широкий опыт по обе стороны баррикад. За свою карьеру я был на интервью в качестве кандидата под сотню раз, а собеседующим - около 200.
В начале меня бесили бессмысленные алгоритмические секции, задачки на логику и тому подобные круглые люки. Однако со временем я понял, что для хорошего интервью по настоящему важны 2 вещи: четкая коммуникация и соответствие командному духу.
Начнем с четкой коммуникации. Нет ничего хуже, когда ты сидишь на интервью и понятия не имеешь, что от тебя хотят и когда это кончится.
Поэтому я считаю чрезвычайно важным в начале интервью обозначить ключевые моменты: кто я, что мы собираемся проверить на интервью, будет ли кто-то присоединяться, сколько это займет время, какая структура.
Прося решить задачку, я стараюсь пояснить, что я хочу увидеть: важен ли для этой задачи код стайл и организация или нет, какие детали можно опустить и так далее.
Таким образом, минимизируется риск отсеять классного кандидата только потому, что он не понял, что от него хотят. А у самого кандидата (я надеюсь) уменьшается уровень стресса.
С соответствием духу команды сложнее. Я убежден, что хорошего специалиста можно распознать за 40-50 минут в течение одного интервью. Являются ли 5 этапные интервью с алгоритмами из-за этого полным дерьмом? Я так не считаю.
Ни один технический пробел в знаниях не может замедлить работу так, как замедляет несовпадение людей в команде.
Если для команды важно, чтобы весь код выполнялся за O(N), а лучше за O(1), то это нужно проверить. Если команде важно, чтобы человек хорошо организовывал код и умел в архитектуру - нужно посмотреть сюда.
В Joom 4 этапа технического собеседования. По мне, это многовато. Но если бы убрали половину из них - наша команда могла бы превратиться в тяни-толкай, погрязший в рутине пулл реквестов.
А сколько этапов интервью вы считаете оптимальным?
🤔
4.7% Ни одного, интервью - дно🤔
38.7% Одного хватит🤔
53.8% 2-3🤔
2.8% 4+Теперь расскажу о своем идеальном интервью. Длительность в пределах часа, чтобы никто не устал. Три секции: предыдущий опыт, теория, задача - у каждой секции свое предназначение.
То, как человек рассказывает о своем опыте, показывает как он будет общаться на рабочие темы, а также масштаб и глубину проблем, которые он решал. В одной и той же задаче разные кандидаты находят проблемы совершенно разной глубины.
Последнее время у меня появился своеобразный эталон в этом плане - чатик. Много людей писали чатик, но немного людей думают о проблемах синхронизации, открытых сокетах и тд.
В теории у меня нет обязательного списка тем, которые кандидат должен знать. Вместо этого я рандомно тыкаю в 4-5 областей и смотрю, насколько кандидат готов рассуждать и поддерживать диалог.
Почему в Obj-C нет перегрузки операторов? Зачем нужен autorelease, когда есть release? GCD или OperationQueue? Чем больше он готов аргументированно рассуждать на заданную тему, тем больше он погружен в платформу (вынуждено или добровольно).
А если погружен, то есть шансы, что и в задачи будет погружен. Бонусом, у такого разработчика реже случаются затупы из-за того, что происходит какая-то “магия”.
Остается задачка. Вот тут многие, даже годные разработчики, затупляют. Пытаюсь решить эту проблему задачкой на дом. Но без задачки нельзя: как понять, что программист готов находить решения проблем, готов писать код? Как увидеть рассуждения?