iOS-разработчик Андрей Малыгин написал для dev.by колонку о том, что старое доброе техническое интервью безнадёжно устарело и «работает со сферическими лошадьми в вакууме». Или всё-таки нет?

Читать далее...

Техническое собеседование — это больная тема для всей ИT-индустрии. Компаниям оно не позволяет составить чёткое представление о возможностях кандидата, а кандидатам не даёт понять, с чем им придётся столкнуться в работе. Не говоря уже о потраченном времени, силах и сгоревших нервных клетках. Техническим собеседованиям в текущем формате пророчат скорую смерть, тем не менее — они существуют.

Может, настало время подумать над тем, что с этим делать? Давайте порассуждаем вместе.

Как это выглядит сейчас?

В сети есть много шуток на тему того, как бы проходил приём на работу представителей других профессий, если бы с них спрашивали, как с программистов. Вот бородатый пример про водителей, а вот про плотников.

Действительно, объём требуемых знаний часто бездумно завышается, а с учётом сжатых временных рамок это оказывает дополнительное давление на кандидатов. Однако всё равно не даёт чёткого понимания, действительно ли человек разбирается в своей области — или же он хорошо подготовился к собеседованию, нагуглив самые популярные вопросы.

Ещё обиднее бывает, когда на собеседовании тебя спрашивают об архитектурных изысках или новейших парадигмах, а выйдя на работу ты сталкиваешься с некрасивым (мягко говоря) кодом, написанным неделю назад тем самым человеком, твоим интервьюером. Невольно задаёшься вопросом: зачем всё это было?

Такой формат проведения интервью достался нам в наследство прямиком из середины прошлого века. В то время доступ к информации был затруднён, поэтому все приходилось держать в голове. Представьте, что документация была доступна только в библиотеке, возможно — на другом конце города.  В таких обстоятельствах энциклопедические знания и опыт работы с определёнными технологиями могли заметно ускорить разработку. Но это время давно в прошлом. Информация доступна мгновенно и в огромных объемах.

Операционные системы, языки программирования, библиотеки существенно изменяются несколько раз в год. Держать всё в голове бесполезно, нужно владеть навыком поиска и извлечения нужной информации.

Есть мнение, что причины здесь примерно те же, что и у дедовщины в армии: мы через это прошли, теперь страдать будут другие.

Давайте попробуем понять, почему компании не спешат менять текущий порядок вещей.

• Стандартные интервью являются повторяющимся процессом, а значит, можно измерить, как с ним справляются разные люди. Все знают, как это работает. Нужно лишь составить стандартный список вопросов — и любой свободный разработчик будет в состоянии провести интервью.
• Интервью позволяет отсеить совершенно неподходящих кандидатов. Это экономит время, а значит, и деньги для компании. Ведь считается, что самое худшее — это нанять неподходящего человека.
• Правда, при этом случается, что талантливые разработчики, которые не подходят под парадигму всезнайки, тоже отсеиваются.

Получается, что технические интервью худо-бедно справляются с поставленной задачей. Кому как не программистам знать: если что-то работает, не стоит это ломать. Поэтому, если мы хотим что-то изменить, нужно предложить достойную альтернативу. Рассмотрим варианты.

Списать у отличника

Зачем изобретать очередной велосипед, если можно обратиться к опыту всемирно известных компаний вроде Google и Facebook и начать проводить собеседования по их образцу. Даже далёкие от ИT-индустрии люди слышали про головоломки вроде «Почему крышки на люках круглые?» или «Сколько футбольных мячей поместится в автобусе?». Однако, несколько лет назад глава HR подразделения Google признался, что такие головоломки «пустая трата времени».

Тем не менее, все топовые компании до сих пор проводят интервью, задавая алгоритмические задачи, пусть и не такие радикальные. В этом есть своя логика, очень похожая на описанную мною выше. Вдобавок это позволяет компании быть более гибкой. Алгоритмические задачи не привязаны к конкретной технологии, а значит, провести собеседование может специалист любого профиля. Далее: алгоритмические задачи представляют собой чистые логические вопросы, которые (в теории) должны проверять именно мышление, а не память. А это именно то, что нужно в работе программиста: решать задачи, с которыми до этого не сталкивался.

Но тут есть ряд недочётов. Во-первых, найти оригинальную и действительно сложную задачу, которая бы не требовала знания некоего особого трюка, довольно сложно. Учитывая, что есть целые сервисы по обмену задачами с собеседований. Во-вторых, спросите себя: когда в последний раз на практике вам приходилось писать алгоритм сортировки или находить максимальный поток? Получается, что для прохождения такого интервью вам нужно готовится отдельно и весь ваш накопленный опыт здесь слабо пригодится.

Плюс это никак не помогает самому кандидату понять, с чем он будет иметь дело, выйдя на работу. Давайте признаем, Google или Facebook могут позволить себе роскошь не париться об этом. На место одного отсеянного кандидата становятся десятки других. Все хотят работать в Google, потому что это престижно и показывает твой уровень. Как же тогда быть всем остальным компаниям?

Домашнее задание

Вторая популярная альтернатива — это тестовое задание. Действительно, качество кода — это то, по чему можно судить о зрелости программиста. Однако и здесь есть несколько проблем. Во-первых, актуальна проблема с оригинальностью и сложностью. Во-вторых, нет гарантий, что человек не списал или не попросил друга помочь. И, наконец, многие программисты считают выполнение тестовых заданий ниже своего достоинства. Тем более, что за это тебе никто не заплатит.

Рыбак рыбака

Бытует мнение, что хорошего специалиста может разглядеть только другой хороший специалист. Ещё лучше, если тот, кто проводит собеседование, будет выше уровнем, чем кандидат. Тогда неважно, в каком формате будет проходить собеседование: будет это решение алгоритмических задач у доски или прогулка в парке с обсуждением прошлых проектов. Настоящий «мастер» увидит талант.

Не могу не согласиться с таким подходом. Уверен, что в идеальном мире собеседования проводятся именно так. Однако в реальности количество таких мастеров резко ограничено, да и время их стоит недёшево, чтобы тратить его на многочасовые беседы, которые могут и не принести результата. Также вопрос о поиске такого мастера остаётся открытым. Он с легкостью может не пройти стандартное интервью, как это свойственно талантливым людям.

Что делать?

Конечно, можно достичь неплохого результата, комбинируя приведённые выше методы. Например, отсекать неподходящих кандидатов тестовым заданием или стандартным собеседованием, а затем привлекать мастера. Однако это создаёт у потенциального соискателя чувство, что он один из многих, а хотелось бы, чтобы искали именно его. Да и непонятно, стоит ли овчинка выделки для обеих сторон.

Основной недостаток всех подходов, описанных выше, — оторванность от реального положения вещей.

• Стандартное техническое интервью со списком вопросов проверяет скорее память, нежели способность выполнять поставленные задачи.
• Алгоритмическое интервью работает со сферическими лошадьми  в вакууме. Безусловно, если вы устраиваетесь на должность, подразумевающую чтение и написание научных статей по предметной области — это довольно хороший вариант.

• Собеседование с мастером не исключает человеческого фактора. Талантливые люди склонны иметь больших тараканов в голове.

На этом фоне многие стартапы, похоже, нашли решение, которое удовлетворяет обе стороны.

Во-первых, небольшие компании ищут активных ребят, которые ведут свои блоги, участвуют в open source  проектах либо активно пользуются их сервисом. Это позволяет сразу присмотреться к человеку, понять его мотивацию и уровень. Кандидату же это, безусловно льстит, так как компания ищет именно его, а не просто очередного гребца на галеру. 

Во-вторых сам процесс интервью максимально приближен к реальной работе в компании. Берётся типовая задача, с которой сталкивается команда в процессе разработки. Соискатель и проводящий интервью садятся за один компьютер и в течение некоторого времени работают над задачей — так, как если бы они действительно её решали. Иногда ребят приглашают сразу в команду, чтобы они увидели все кухню. Это позволяет компании понять как человек работает, как общается с другими людьми, где ищет решение проблем и какие варианты предлагает. С другой стороны, это позволяет кандидату чётко понять, куда он попадает и с чем ему придётся иметь дело.

В итоге обе стороны могут определиться со своим решением и с большей долей вероятности не промахнуться. Конечно, вы не можете приводить людей с улицы и показывать им исходный код, но всегда можно ограничится просто парным программированием.

Вероятнее всего, это решение не подходит для всех. Возможно, некоторых нанимателей вполне устраивает сотрудник с минимальным необходимым набором знаний. Да и многие кандидаты хотят найти тихую гавань, где можно стабильно получать зарплату и не париться по поводу смены места работы.

Ну а тем, кому важнее качество, а не количество, стоит задуматься над заменой доброго старого технического интервью.

Место солидарности беларусского ИТ-комьюнити

Далучайся!