Интервью с программистом как процесс с точки зрения собеседующего
Волею судеб так сложилось, что кроме повседневных обязанностей по написанию кода, исправлению ошибок, бесчисленных митингов и stand-up-ов, и всего прочего-прочего, я оказался вовлечён в процесс проведения собеседований.
Компания заинтересована в долгом сотрудничестве, поэтому поиск и найм людей производится очень тщательно: есть этап собеседования с рекрутерами, техническое собеседование, часто в несколько этапов, проектное собеседование, где обсуждают вопросы специфичные для конкретного проекта и финальные разговоры с руководителями подразделений на этапе предложения. Структура системы собеседований похожа у всех крупных технологических компаний — поэтому тот, кто прошел его в какой-либо организации, может легко представить процесс в десяти других.
Отработав в компании более 4х лет в нескольких смежных больших проектах я участвовал в собеседовании более чем 50 человек, из которых было нанято только 5.
На данный момент я покинул компанию о которой я описываю, и по согласованию сторон, могу поделится с тем как устроен этот процесс немного изнутри.
По большей части буду говорить о техническом интервью — том самом этапе, где мы проверяем компетентность кандидата как инженера. Процесс сложный и дорогой, в нём нет единственно правильного подхода. По своей сути, цель диалога понять — какой остаточный набор знаний есть у кандидата, его способность думать и соображать и личностные качества, ну и ответить на самый главный вопрос вселенной и всего такого — готов ли я с этим человеком работать бок-о-бок в проекте.
Зачем?!
Среди первых всегда возникает вопрос — почему решили именно работать в нашей компании? Что вы о ней знаете, зачем и почему. Почему не Google, не Яndex или любая другая крупная компания. Дежурный вопрос помогает завязать разговор, но может и “выстрелить”: один кандидат, который вылил гору маркетинговых материалов, рассказал про вселенский заговор и свои желание его познать изнутри. Мы пожали ему руку и пожелали удачи.
Резюме.
Конечно же смотрим, но есть свои особенности — первое, что интересует, что оканчивал и окончил тот или иной вуз или нет — но не более, чем интересно. Где работал, как часто менял работу, почему. Какими темами и областями занимался. Вряд ли кандидату, занимающемуся data mining или web 2.0 будет интересно у вас, хотя … who knows?
Иногда видишь в резюме название компании Х, вспоминаешь, что твой коллега Василий работал в этой компании — идешь кВасе, спрашиваешь, не был ли он, совершенно случайно, знаком с кандидатом, стоящий ли товарищ. Сарафанное радио — и ваша репутация опережает вас.
J-фактор.
Типичный полупроводник в новую компанию — это рекрутер, с одной стороны он хочет найти специалиста, но с другой стороны, сам не являясь техническим специалистом не способен хорошо оценить реальный вес кандидата и поэтому ищет резюме с использованием buzz words. Ой-вей! Да это же Java! А вот у кандидата есть Log4J — должно быть что-то для Java. Поехали!
Для себя мы определили т.н. J-фактор, как количество технологий, упомянутые кандидатом, содержащие букву J, например: jsp, jdbc, j2se, ejb и т.д и т.п.
Как правило, чем больше J-фактор, тем разговор унылей. Есть поговорка The Jack of all trades, которую можно перевести как «Мастер на все руки», только у неё есть и продолжение — and master of nothing — перевод излишний. Словом, если человек уже зрелый инженер и он знает, что он сам хочет делать, в резюме это тоже явно отражается. И, разумеется, с такими и общаться приятнее, и берем мы их гораздо чаще.
Но не стоит воспринимать всё слишком буквально — в каждом правиле бывают свои приятные исключения: однажды человек с перегрузкой в 9J (это очень большое число) был не просто взят на работу, а в виде исключения смогли сделать так, что он может начать работать раньше, чем позволяет окно найма.
Реакция HR.
Надо отметить, что если человек очень понравился на техническом интервью, за него будут биться несколько менеджеров, если понравился и на проектном интервью, которое можно рассматривать в некотором смысле как расширенное тех. интервью — менеджеры и HR делают всё возможное, чтобы не упустить отличного специалиста. На моей памяти одной очень видной птице сделали предложение уже через 5 дней после того как было отослано резюме.
У меня зазвонил телефон.
Случаются ситуации, когда либо резюме человека не вызывает полный восторг, или человек живёт очень далеко — в таких случаях проводится небольшое телефонное интервью, скажем на 30 минут. Такого телефонного собеседования (или “пре-собеседования”), как правило более, чем достаточно, чтобы понять, стоит ли с человеком дальше общаться или нет. Если стоит — приглашение на очное интервью. И не важно откуда человек — из Москвы, Питера, Тамбова или Находки — компания оплачивает поездку кандидата, помогает с билетами и прочими вопросами.
Бывает и так, что пообщавшись по телефону мы даём человеку домашнее задание из разряда модельных задач или алгоритмов. Здесь можно увидеть очень многое — и любовь человека к той или иной платформе для сборки — ant, maven и т.п, любовь к unit test-ам, способность сделать дизайн / построить архитектуру, понимание работы классических алгоритмов и вкус оформления кода.
Ближе к телу.
Итак, опираясь на наши повседневные задачи, мы сформировали несколько тем для беседы
- базовые алгоритмы: сортировка, бинарный поиск
- структуры данных: списки, ассоциативные массивы, деревья
- знание английского языка
- владение математикой
- дизайн
- многопоточность
Sprechen Sie Deutsch?
Чтобы не ходить долго вокруг да около, обычно спрашиваю как устроена быстрая сортировка, или сортировка слиянием, или бинарный поиск на английском языке — конечно же ожидая, что и кандидат будет отвечать на нём же и, поскольку вопросы не хитрые, можно убить двух зайцев зараз.
Ошибаетесь если думаете, что, например, для описания быстрой сортировки будет достаточно рассказать о нахождении опорной точки, разделении на два подмассива и рекурсивный вызов. Вопрос обладает большой глубиной — стоит пояснить деградацию быстрой сортировки до O(n2) и как один из способов решения проблемы — т.н. проблема национального голландского флага.
Standard Library and Design
Не беспокойтесь: всё, что вы знали и знаете о стандартной библиотеке будет спрошено: и какие бывают коллекции, и какие контракты использования. Рассуждая о плюсах или минусах того или иного подхода предлагаем кандидату спроектировать / задизайнить решение, если бы он мог делать, например, свой новый язык программирования. Если вы не слышали, что такоеGang of Four, вероятность, что будет трудно общаться, велика.
Ведь мы же любим спрашивать всякие красивые подходы, которые были применены в каком-то известном framework-е. Или например, почему Дональд Кнут настоятельно требует, чтобы поиск в hash структурах делался с использованием простых чисел, а инженеры Sun, а ныне Oracle, делают совсем по иному? Они не только читали Кнута, но и знают ещё кое-что.
Вообще о hashCode-е можно общаться очень долго: и откуда он берётся, и почему это не адрес, а если бы это был бы адрес, то что тогда — кому было хорошо, а кому плохо и как работает GC.
Вполне возможно, что кандидат не знает или не слышал про это — не беда — наводящими вопросами можно вывести его на правильный путь, если он или она, способны думать и рассуждать.
Coding.
Это всё слова! Хорошо бы посмотреть как человек кодит, и кодит на бумажке — этот принцип известен как white board coding. Конечно же, в жизни мы все кодим в той или иной IDE — будь то Eclipse или Idea, ОС Emacs или vi. Ведь все инструменты, которые есть у нас в распоряжении, они упрощают и ускоряют процесс, но не заменяют нас самих.
Типичный вброс на эту тему — написать функцию, возвращающую N-ый член ряда Фибоначчи. Как правило, в начале кандидат пишет рекурсивную реализацию. Хорошо. Уточняем области применимости и какие побочные эффекты возникают. Логическим продолжением служит итеративная формула. Мы не унимаемся — хотим ещё быстрее, лучше, красивее — вспомнит кандидат или нет — мы делаем вброс с точной формулой N-го члена ряда через золотое сечение. И опять же рано или поздно встаёт вопрос о границах применимости. Один кандидат буквально убил меня — он не помнил сколько бит выделяется под мантиссу в числе с плавающей точкой с двойной точностью — но как только он узнал через пару секунд резюмировал — где-то 15 значащих цифр умещается в double. Как? Он пояснил кратко и понятно, что очень немаловажно.
Беглость математического счёта и Brainteasers
Приятно, когда человек умеет бегло считать и очень печально, когда человек не может что-то простое оценить — будь то длительность вклада при известной начальной сумме и проценте, сетевую задержки между Токио и Лондона или просто корень из 42. C какой точностью? С какой легко справитесь на пальцах.
Как правило после получаса очного разговора с кандидатом становится понятно — нравится или нет. На мой сугубо личный взгляд способность решать головоломки ничего не скажет, если кандидат мощный — он всё равно решит головоломку, если же вода на киселе, т.е не пойми какой — то может как решить, так и нет. Однако, в случае мощного кандидата это может разрядить обстановку — он решил какую-то незнакомую головоломку, и вы ему ещё один плюсик в карму нарисуете.
И здесь важна не беглость счета или умение решать головоломки как таковое — а то, насколько человек умеет свободно перемещаться между уровнями абстракций. Вот минуту назад он рассуждал о сложностях алгоритмов в терминах нотации Big-O, а сейчас должен оценить, когда закончится стек у рекурсивной процедуры — с конкретными числами — хороший инженер строит модели не в вакууме, а в реальном мире. Где гарантия того, что человек, который насчитает 100 бензозаправок в Москве, точно также ни капли не удивится, получив сетевую задержку в 500 мс между двумя дата-центрами в одном городе?
Тут важно понимать, что у нас нет цели человека завалить. В ситуации собеседования традиционно роли сильно несимметричны — мы выбираем вопросы, а кандидат отвечает, к тому же для объективности оценки собеседующих обычно двое, и поэтому завалить — т.е. найти такую область, где кандидат знает меньше интервьюирующих и потоптаться там — дело, обычно, не хитрое. Бывают исключения, но в любом случае, если кандидат может ответить на любой наш вопрос — это значит, что он на голову выше нас по квалификации, и собеседование ни о чем не говорит — мы не можем адекватно оценивать уровень человека на голову выше нас. Надо просто звать более квалифицированных специалистов.
Задача стоит другая:
- понять, что кандидат знает
- примерно оценить, чего он не знает
- понять, как кандидат ведет себя тогда, когда попадает за границы области своей компетентности — и это, пожалуй, самое важное, и именно поэтому мы всегда стараемся добраться-таки до той области, где кандидат уже не очень хорошо разбирается, и там-то и потанцевать — покидать подсказки, намеки, давать отдельные справочные данные — посмотреть, сможет ли человек освоиться в незнакомой области, и насколько быстро.
Зазубрить готовые решения может любой, придумывать же новые решения — это работа инженера.
Chapter 17.
Отцы из [concurrency-interest] тонко намекают, что concurrency никто не знает, разве, что DL и все прочие толкуют сие писание как только могут. Удивительно, когда приходит человек, который заявляет, что он-таки знает concurrency и даже указывает список книг, которые он прочитал, среди которых не только Java Concurrency in Practice, а простой вопрос про wait/notify (из серии “как может нить выполнения захватить монитор, чтобы сделать notify(), если другая нитка, захватила монитор и ждёт в вызове wait()”) ставит его в тупик. Посложнее вопросы касаются устройства COWAL, CHM в её базовом виде jdk 1.6, причинно-следственные связи типа HB, почему нужно трогать volatile и т.п.
Но как бы то ни было.
Подводя итог интервью, хочется для себя понять — готов ли ты работать с таким человеком в одной команде, бок-о-бок на протяжении долгого времени, сможешь ли ты рассчитывать на то, что он будет способен заменять тебя на время отпусков, болезней, да и просто приятно поболтать за чашечкой утреннего кофе или вечерней пинты. По сути это выражается в некотором уровне комфорта работы с человеком — как много ему придётся объяснять, как много исправлять за ним (прямо или косвенно, через процесс ревью кода). Порой смышлёный и сообразительный junior вписывается в команду намного лучше, чем упёртый и несговорчивый senior с большим багажом знаний.
P.S.
Казалось бы, какой резон открывать карты и рассказывать о чём мы спрашивали и спрашиваем на собеседованиях? Безусловно вопросы, которые описал — далеко не полный список того, что мы можем спросить — как правило это некоторые случайный вопрос из большой темы, с которым можно хорошо уйти в глубь вопроса, да и при всём желании не получится за время интервью спросить все вопросы. И не к чему это.
Мотив более чем прост: на данный момент рынок качественных специалистов почти исчерпан. С другой стороны, много людей в IT среде, которые могли бы ими быть.
Готовьтесь к собеседованиям. Не день, и не неделю. Работайте, решайте модельные задачи — на это может уйти и не один месяц, и инвестиции окупятся достойным местом работы.
Источник: hr-portal.ru
