Две армии
Управляющий редактор PHP в SitePoint, хорватский разработчик Бруно Скворч (Bruno Skvorc) рассказал о задании, в ходе которого на одном из собеседований его попросили создать средствами PHP две сражающиеся друг с другом армии и внести в их битву элемент случайности. И все — это была полная формулировка задачи.
По словами Скворча, который описал решение задачки в своем блоге, свободная формулировка заставила его глубоко продумать все свои действия. Прежде всего, поскольку потенциальный работодатель не дал ему никаких правил выполнения задания, ему пришлось разработать их самому — использование объектно-ориентированного подхода, одинаковая работа в командной строке и в вебе, расширяемость, отказ от сторонних библиотек и т.п.
Блок-схема алгоритма решения задачи из описания в блоге Скворча
Скворч уверен, что такие задания позволяют соискателю продемонстрировать творческое мышление, а не упражняться в реализации вещей, которые он почерпнул из теоретических книг или обсуждений на StackOverflow.
Множественные решения
Одним из самых популярных ответов в обсуждении на Quora стал рассказ инженера LinkedIn Лео Половца (Leo Polovets) о его любимых задачах на собеседовании. По его словам, больше всего ему нравятся те из них, которые подразумевают различные пути решения, на каждом из которых встречаются свои сложности.
Инженер убежден, что наблюдение за тем, как человек решает задачу, в которой постоянно «всплывают» те или иные ограничения, позволяет быстро разобраться в его реальных способностях.
Половец привел пример подобной задачи. К примеру, имеется список N+1 целых чисел от 1 до N. Одно число точно дублируется, однако возможно, что чисел-дублёров больше — например, 3,1,1,3, но может быть и 3,1,2,2.
Соискателю нужно вывести на экран число, которое появляется более одного раза (например, в первом случае это 1 и 3). Кандидат предлагает самый очевидный способ — сравнивать все числа в списке, пока не найдётся дубль.
Тогда интервьюер усложняет задачу — говорит, что время, затрачиваемое на подобную операцию, слишком велико, и нужен способ быстрее. Соискатель предлагает использовать хэш, чтобы исключать повторяющиеся числа. Интервьюер усложняет условия, говоря, что памяти для копии списка не хватит и вновь нужен другой способ... И так далее.
Такой вид собеседования, по мнению Половца, позволяют оценить не только профессиональные способности кандидата (например, знание стандартных алгоритмов), но и его креативность и находчивость в сложных ситуациях.
Рисование на доске
Нейт Вадупс (Nate Waddoups), в том числе работавший над линейкой компьютеров Commodore PET, также рассказал о своем любимом задании с собеседования. В тот раз потенциальный работодатель попросил его нарисовать на доске функцию malloc языка C. Сделать это быстро просто невозможно, однако интервьюер сказал, что можно не торопиться. Пока Вадупс аккуратно выводил на доске структуру функции и описывал разные участки кода, интервьюер общался с ним и обсуждал детали реализации.
Разработчик говорит, что изначально посчитал такое задание нелепым, однако элемент неожиданности и позитивная реакция интервьюера позволили «растопить лед» между ними.
Кроме того, по словам Вадупса, графическое представление столь сложных элементов позволяет потратить больше времени на изучение деталей, а также плюсов и минусов разных подходов к решению задачи.
Выбор из двух задач
Java-разработчику Лукасу Эдеру (Lukas Eder), в свою очередь, больше всего понравилось задание на собеседовании в компании Adobe, в ходе которого ему предложили создать drag-n-drop приложение на JavaScript или написать многопоточный HTTP веб-сервер. При этом никаких дополнительных деталей или уточнений соискателю не предоставили — была полная свобода выбора подходов и конкретных способов реализации.
Задача была не «моментальной» — соискателю дали две недели на ее решение и его защиту. В итоге Эдер создал небольшой файл-сервер с каталогами, потоковыми файлами, который поддерживал основные HTTP-коды — например 404, 500, 200 и т.д.
Проект с нуля за три часа
Некоторым программистам, наоборот, нравится, когда им приходится решать задачу в крайне сжатые сроки. К примеру, iOS-разработчик Амир Мемон (Amir Memon) назвал лучшим собеседованием в своей жизни интервью, в ходе которого ему предоставили ноутбук и попросили «что-нибудь запрограммировать».
На решение этой задачи соискателю дали три часа, после чего он должен был презентовать созданное решение своим потенциальным коллегам на обычной доске. После этого в течение двух часов они критиковали решение, члены команды думали о том, как сделать его лучше. В конце шестого часа собеседования сам Мемон смог задать вопросы потенциальным коллегам.
По мнению разработчика, во время таких интервью о соискателе можно узнать очень многое — например больше половины претендентов не укладываются в сроки по программированию или же просто сдаются, столкнувшись с непонятной на первый взгляд задачей. Это позволяет работодателю сразу отфильтровать тех, кто не подходит, и выбирать из лучших кандидатов.
Сам Мемон в итоге успешно прошел собеседование и получил предложение о работе, однако не принял его, хотя и сохранил о том интервью самые добрые воспоминания.
Поиск решения для проблем из прошлых проектов
iOS-разработчик Yahoo! Маджид Мужалед (Maijid Fiifi Moujaled) больше всего оценил собеседование, в ходе которого интервьюер попросил его рассказать о сложных технических проблемах, с которыми столкнулся при работе в прошлом проекте. Мужалед честно признался в существовании одной проблемы, которую он не знал, как решить.
Тогда интервьюер предложил попробовать найти для нее решение прямо на собеседовании. Сначала Мужалед расстроился, поскольку решения он не знал, однако совместными усилиями с разработчиком-интервьюером, который сам решал подобную задачу ранее, им удалось перебрать различные варианты решения и выбрать подходящий.
В итоге после собеседования Мужалед смог решить задачу в своем собственном проекте, а позднее получил и предложение о работе в новой компании.
Заключение: совет интервьюеру от разработчика
В качестве заключения можно привести самый популярный ответ дискусии от инженера по имени Уильям Пиетри, который описал свой подход к программированию — его пост получил больше 3,7 тысяч голосов «за» от пользователей Quora.
Пиетри советует интервьюерам не пытаться выяснить, насколько хорошо кандидат умеет решать головоломки. «Вы нанимаете человека, чтобы он решал проблемы пользователей продукта, а не для прохождения Менса-тестов».
Вместо этого инженер рекомендует интервьюеру уделить время совместному с кандидатом написанию кода. Это позволит получить ответы на самые важные вопросы:
- достаточно ли у кандидата практики в программировании;
- насколько хорошо он знаком с конкретным языком;
- как он подходит к написанию кода;
- умеет ли работать в команде;
- задает ли правильные вопросы о задаче;
- успешно ли преодолевает сложности;
- не отвлекается ли на ерунду;
- знаком ли с автоматизированным тестированием;
- проверяет ли свою работу.
На сегодня все, спасибо за внимание. В продолжение темы – в нашем блоге мы уже рассказывали о том, что могут спрашивать у разработчиков на собеседованиях в крупных ИТ-компаниях, а также разбирали конкретное задание по Java.
Источник: https://rb.ru/opinion/nravki/
