Стратегия для технического интервью

Регулярно встречаю посты, в том числе и на хабре (Иллюзия эффективной разработки: проектирование ^[1], Красной таблетки не существует ^[2]) в которых говорится о том, что одни программисты эффективней в десять раз чем другие и о том, что выбор людей может оказаться важнее организации процесса работы и выбора технологий.

Когда мне пришлось проводить собеседования, я сильно задумался о том, как же отличить Чака Нориса эффективного профессионала в области веб-разработки, от тех, кто будет мешаться у него под ногами.

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

Сначала хочу определить, что означает для меня «эффективность».

Под эффективностью я подразумевю относительную эффективность: конечную пользу (business value), которую может приносить кандидат, работая в конкретной роли на нашем проекте, по сравнению с другими соискателями.

Один и тот же человек будет по-разному эффективен в разных проектах, даже если занимается схожими вещами. Например, кому-то agile проекты подходят больше, кому-то меньше. Относительная эффективность кандидата может меняться в любую сторону, даже по ходу одного проекта.

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

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

Реалии нашего HR процесса таковы, что технические собеседования проводятся, в основном, по телефону. Потому что кандидаты бывают из разных городов и даже стран, потому что интервьюеров бывает несколько, также возможно из разных стран. Даже в условиях одного мегаполиса, поездка на личное интервью съедает много времени у кандидата, а на телефонное собеседование люди соглашаются легче.

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

Сначала, проводя интервью с соискателем, я придерживался хорошего «правила №1» от Joel Spolsky

«Лучше упустить настоящего профи, чем взять неэффективного сотрудника и потом с ним мучиться».

Поэтому отсеивал всех «подозрительных» и при любых сомнениях.

Через какое-то время я понял, что идеальных кандидатов слишком мало (а может они существуют только в моем воображении), и в любом из них можно, при желании, найти что-то подозрительное.

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

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

Чтобы найти идеальный баланс, надо определиться — какие факторы будут решающими в вопросе эффективности кандидата на нашем проекте?

Основным фактором я выбрал умение разбираться в проблемах и придумывать решения в своей области (пресловутые problem solving skills), проще говоря, думалка должна быть прокаченной.

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

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

Третий — это кроссфункциональные навыки. Для нас идеален «человек-оркестр». Такой, чтобы разбирался в чем-то одном хорошо, но также умел тестировать, собирать аналитику, общаться с клиентом, и делать UI, и backend, и писать SQL запросы, и разрабатывать схему БД, предлагать архитектурные решения.

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

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

И только на последнем месте идет знание используемых нами технологий, которое позволяет быстрее «вкатиться» в проект. Но, на мой взгляд, эти знания не будут влиять на эффективность в долгосрочной перспективе. Мало того, что технологии, и даже языки, могут поменяться в любой момент, так ещё и требование конкретных знаний сильно сокращает наш выбор. Все это может привести к тому, что на безуспешные поиски будет потрачено слишком много времени. Что в свою очередь вынудит нас нанять уже не слишком профессионального сотрудника, который, как говорится, подвернется под руку.

Итак: problem solving skills. Как их проверять?

1. Понимание вещей, а также умение объяснить это свое понимание. Чем больше человеку пришлось разбирать сложные вещи, тем лучше может быть натренирована «думалка» (иначе, что ещё дает высшее образование?). Умение объяснить/донести свою мысль, показывает четкость и стройность мышления ^[3], так необходимые для решения проблем. Поэтому ответ не по существу моего вопроса, запутанные или отвлеченные объяснения, сооблазняют меня сэкономить дальнейшее время, воспользовавшись правилом №1.
2. Непонимание вещей. Это когда кандидат использует нечто и вообще не представляет, почему и как оно работает. Скопипастил, кликнул, вроде заработало, а потом отваливается, вылазят баги, и хрен поймешь почему. Это может свидетельствовать о лени, неумении или нежелании разбираться в проблемах. В общем, жирный минус.
3. Общий разносторонний опыт. Чем его меньше, тем реже приходилось разбираться и вероятно, что «думалка» будет не прокаченной. Меньше будет и кроссфункциональных навыков, важность которых описана выше. Богатый опыт, наоборот же, позволяет быстрее решать непредвиденные сложности на уровне интуиции.
4. Решение задачек. Я понял, что сложные задачи и «головоломки» не работают. На одном собеседовании, я очень долго пытался ответить на вопрос: «Почему канализационные люки круглые?» Мне так и не пришла в голову мысль: «Чтобы они вниз не провалились». Потому что для этого нужно озарение, а это сродни удачи, и никак, по-моему, не проявляет навыки. В конце концов, я изрек: «Они круглые, потому что в них пролезет такой же чувак, что и в квадратные люки, а металла на них уйдет меньше». Этим можно проверять лишь упорство кандидатов что, конечно, не маловажно, но это слишком долгий и негуманный способ.

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

У Joel Spolsky есть лозунг/критерий найма: «Smart & Gets things done» (Я бы перевел как «Умный и Практичный»). Все вышесказанное относится к части Smart, часть Gets things done означает способность придумать не только «идеальное» решение, а выбрать практичное решение, учитывая потребности и возможности заказчика. Для этого необходимо оставаться сфокусированным на бизнес- проблемах клиента и целях проекта, а не на собственном исследовательско-изобретательском интересе. Так что, идеальный вопрос/задача должен проявлять оба критерия: «Smart» и «Gets things done».

И вот какие вопросы я нашел:

1. Ведете ли Вы технический блог? Пишите ли тех. статьи (например, на хабре) или книги? Выступаете ли на конференциях, собраниях, мастерклассах (внутрикорпоративные считаются)? Участвуете ли в opensource проектах?

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

2. Есть ли персональные технические проекты?

   Ответ «да» может говорить о том, что человек любит свое дело, а не просто из-за денег страдает на работе. К тому же в персональных IT проектах часто приходится всем заниматься самому, а это говорит о важном кроссфункциональном опыте.

   Ответ «нет» минусом не является.

   Вопросы 1 и 2 позаимствованы из поста Nikos Maravitsas, в котором он предлагает свою методику оценки кандидатов, за что ему спасибо.

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

   Хочу сказать, что в текущем проекте мы никогда не даем оценки в часах (а только оцениваем порядок сложности задачи), но на этот вопрос я слышал оценки от 3-5 минут до 4 часов. И даже больше «так как нужно написать unit тесты» Вот так рождается расхождение эффективности на порядок.
   Возможные решения:
   • JQuery выражение, можно выполнить в firebug или аналоге и получить готовый результат. Займет 2 минуты. Если Вы назвали данный подход, не имея уверенных знаний jQuery, тогда еще больший плюс.
   • XPath выражение. Хороший способ, если вы знаете, куда это выражение вводить, например команду xmllint в линукс или знаете о соответствующей функции в Вашем любимом IDE. Кроме того, что нужно знать (или быстро придумать) куда это выражение вводить, нужно понимать, что xml и html вещи разные. Если Вы и это понимаете, тогда нужно знать, работает ли xmllint/IDE с html, если не уверены, можно придумать способ конвертации html -> xml. Способ «Погуглить» сканает, но весьма хорошо, если слышали о tidy. Отдельно проверяю адекватность оценки по времени на составление и отладку xpath выражения.
   • RegExp – пройтись регулярным выражением по файлу и выделить все «жирные» теги. Тут проверяю соображалку – куда будем вводить регулярное выражение (в какой программе/команде)? При незнании, начинаем для этого писать программу на любимом языке. Потом проверяю понимание о «жадности» регулярных выражений. И, наконец, сопоставляю оценку кандидата со сложностью решения. То есть, если кандидат делает выбор – писать программу на java (еще и с юнит тестами для этого случая) и вообще плохо понимает regexp, при этом дает мизерную оценку – то это точно минус.
   • Пишем программу на любимом языке, которая выделяет текст между «жирными» тегами. Прошу рассказать алгоритм того, как это сделать, включая то, как будет идти обращение к исходным данным. Это вполне нормальный вариант, если алгоритм рассказывается быстро и четко, а оценка соответствует уверенности кандидата. Если же человек путается в простых вещах, которые не требуют никакого особого знания или опыта, то это повод применить правило «лучше не взять, чем взять и мучиться»
   • Вручную. Вообще отличный вариант. Потому что оценка меньше и предсказуемее, чем те оценки, которые часто слышу для других вариантов. Однозначный плюс, если оценка на этот вариант адекватна, еще лучше, если используем regexp для оборачивания в кавычки и разделения запятыми. Два плюса, если меня спрашивают: «А на сколько критична ошибка в одном символе при копировании?» Это именно тот случай, когда за счет маленького уточнения требований, мы можем в несколько раз сократить стоимость решения. Вообще, чем больше разумных уточняющих вопросов от кандидата, тем лучше.
   Если же человек не может оценить время на такую «ручную» работу адекватно, или вообще наотрез отказывается рассматривать такой вариант – явный минус.

   На мой взгляд, именно такие вопросы, проявляют оба критерия «Smart» и «Gets things done» наилучшим образом.

4. Дано: .xls (Excel) файл с одним листом в 4 числовых колонки и 1000 строк.
   Требуется: Загрузить его в SQL базу данных, таблица с соответствующими колонками имеется. Ну и, сперва, оценить время на решение.
   • Уверенный ответ – использую такой-то тул. Такой ответ мне ни о чем не говорит, просто повезло со знанием тула.
   • Конвертну в csv и использую такой-то тул. Уже интререснее, додумались сконвертнуть. Маленький плюс.
   • Конвертну в csv и использую встроенные возможности SQL сервера по загрузке из CSV. Еще интереснее, потому что говорит о том, что вероятно вы плотно разбирались с СУБД, а это часто выручает. Плюс побольше.
   • Погуглю тул, уверен, должен такой быть. Плюс за чутье и то, что не запалили кучу времени на изобретение велосипеда. Так же смотрю на адекватность оценки «гугления»
   • Конвертну в csv, напишу шелл скрипт, который будет делать insert into ….; выражения и запущу их на sql сервере. При адекватной оценке уверенный плюс.
   • Добавлю колонку в excel файле, куда во всех ячейках вставлю (растяну) «insert into» и дополнительные колонки с запятыми, получу sql скрипт. Сразу плюс, даже в оценке не нуждаемся.
   • Начинаем писать программу. Обычно это плохо. Если догадались конвертнуть в CSV и работать с простым форматом, и оценка вменяема, то еще ничего. Но если начинаем использовать сложные библиотеки для работы с Excel, потом пишем юнит тесты и оцениваем задачу в 8 часов чистого времени – то минус.

   В начале, я всегда объясняю – что я хочу проверить вопросом, чтобы люди специально не отсекали более простые варианты.

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

5. Дано: массив из N рандомных чисел.
   Требуется: найти наибольшие K чисел из массива и оценить сложность алгоритма. Уточняю что K<(N/2), N большое число, интересует наиболее быстрый алгоритм, на расход памяти плевать.

   Эта задачка мне нравится тем, что в ней есть очевидное решение (практика это подтверждает), однако, не оптимальное. Я смотрю на то, может ли человек понять, что оно не оптимально самостоятельно, и как быстро добираемся до оптимального решения. В большинстве случаев добираемся, и мышление ^[3] кандидата на ней раскрывается довольно хорошо, ну у тех, кто комментирует свои мысли. Потом приходим к понятию сложности алгоритма, нормальным ответом будет O(N*log K).
   Но если у Вас плохое настроение, то можно напомнить, что числа то рандомные и их много, и заставить решать задачу исходя из теории вероятности.
   Тогда ответ должен быть существенно меньше, чем O(N*log K). Какой? Я и сам не знаю.

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

7. Ну а дальше вопросы, чтобы выявить общий уровень знаний веб программиста, в моем случае на java, может кому-то будет интересно:

• Объясните различие между <span> и <div>. Многие знают, а объяснить толком не могут, путаются, это минус.
• В Javascript, объясните, что такое prototype (Не имеется в виду название фреймворка)? Что можно передать в метод jQuery(), он же $()?
• В HTTP, что такое keep-alive?
• Может ли cookie с одим и тем же ключом иметь разное значение на двух разных страницах одного и того же сайта (с одним доменом)? Нет? А на разных сайтах?
• Чем TCP отличается от UDP. Дурацкий вопрос, но оказалось, что обычно знают ответ, теперь если кто-то не отвечает, для меня это подозрительно. А еще, бывает, что уверенно говорят полный бред, это гораздо хуже чем «не знаю, погуглил бы».
• Что такое base64?
• Можно ли сделать ajax запрос между разными доменами? Как?
• Объясните принципиальную разницу между SOAP и REST? Смотрю на четкость и краткость ответа. «Не знаю» тоже годится.
• Как реализовать producer-consumer паттерн с помощью двух параллельных потоков. (Суть паттерна объясняю
• Есть ли опыт работы с xml? Если да, каким образом, с помощью каких технологий?
• Знаете ли xpath, что такое в нем оси/axes.
• Какой опыт с линукс? Хорошее знание линукса и его команд позволяет быстро решать (или автоматизировать) довольно сложные бытовые задачи, поэтому может существенно влиять на эффективность. Как поискать по истории введенных команд? Знание команд sed,awk,sudo,ps,top,grep? Использование pipes? Писали шелл скрипты?
• Знание регулярных выражений?
• Какие Ваши часто используемые hot keys или примеры автоматизации рутинных задач? Эффективность это не всегда умение думать, иногда люди быстро работают хотя бы потому, что все основные действия вынесли на hot keys и автоматизировали большинство рутины.
  

  Вопросы по SQL.

• Отличие inner join и outer join? Смотрю на умение четко объяснить разницу.
• Transaction isolation levels. Сможете ли объяснить? Достаточно уверенного «Да»
• Как вывести все числа, встречающиеся в колонке A более двух раз?
• Как сделать сумму по нарастающей? Например, есть таблица с датой и суммой продаж на каждую дату, нужно на каждую дату выводить сумму продаж с начала года вплоть до этой даты включительно. (на пальцах это проще объяснить)
  

  По программированию знания выявляются по ходу решения задач, но все же спрашиваю основы.

• Как построчно прочесть файл?
• Объясните, как работает TreeMap и HashMap. Это обязательные основы для программиста, на мой взгляд.
• Ну и ArrayList против LinkedList. Кто из них будет быстрее при добавлении миллиона одинаковых объектов в конец? Точно сказать трудно, потому что ArrayList будет копировать несколько раз свой внутренний массив при расширении (его начальная capacity 16 по условию). А LinkedList будет для каждого вставляемого элемента создавать дополнительный объект, в котором будут храниться ссылки. Обычно отвечают очень уверенно: мол, тот будет быстрее, и упорно не хотят отвечать, почему может быть быстрее другой.

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

Если кто-то знает вопросы, которые могут лучше проявить эффективность web программиста, добро пожаловать в комменты.

Удачи на собеседованиях.

Автор: susliks