Техническое интервью с человеческим лицом. Технические вопросы на собеседовании. Тестовые задачи на программирование
Много боли изливается на страницы Сети по поводу неудачных собеседований. Кому-то не понравились вопросы интервьюеров, другого обидели насмешками, иных посудили по страничке вконтакте. Интервьюеры не отстают от соискателей и ругаются на то, как плохо нынче с кадрами, и какие глупые ответы дают неопытные программисты на их заковыристые технические вопросы.
К сожалению, универсальных правил прохождения и проведения собеседования нет и быть не может, потому что сотрудников подбирают не только по их техническим навыкам и личностным качествам, но и по совпадению с некоторым (зачастую неявным и очень субъективным) «профилем», который, по мнению интервьюеров, вписывается в их команду или компанию. Что же касается руководств из серии «как правильно проходить собеседования», то они обычно вызывают не меньше боли в комментариях, потому что очень субъективны и обязательно задевают чьи-нибудь болевые точки.
За свою профессиональную карьеру мне довелось побывать по обе стороны баррикад, хотя, пожалуй, проводить технические собеседования приходилось всё же немного больше, чем проходить их. Но за это время у меня накопилось некоторое количество «пунктиков», которые отпугивают меня во время технического интервью и сразу в моём сознании ставят крест на дальнейшей беседе. Об этом мне и хотелось рассказать - с позиций интервьюера и соискателя. Хочу сразу оговориться, что статья отражает мои личные субъективные впечатления и не претендует на «руководство по прохождению собеседований». С другой стороны, это не минутный всплеск ярости от неудавшегося интервью, а давно взвешенный набор тех критериев, которые, хотя и по негативному принципу, позволяют мне отсеять варианты, либо самому не отпугнуть потенциально подходящего соискателя.
А что на собеседованиях раздражает или напрягает вас? Поделитесь в комментариях.
Собеседование с позиции соискателя
Каждый раз при поиске работы программисту приходится проходить множество технических собеседований. Он ходит по офисам или разговаривает по скайпу, решает задачки или делает тестовые задания, отвечает на заковыристые технические вопросы, пытаясь продемонстрировать себя с лучшей стороны. Однако и сам он при этом оценивает людей, которые собеседуют и проверяют его, думая о том, что завтра ему потенциально с этими людьми придётся работать. И есть множество способов для технических интервьюеров отпугнуть соискателя от интересной должности. Я расскажу о том, что всегда отпугивало лично меня, и чего стараюсь не допустить я как интервьюер.1. «Какое ещё техническое собеседование?»
Первое и главное, что всегда настораживало меня в техническом собеседовании - это его отсутствие. Бывает так, что вся беседа с техническими специалистами - потенциально будущими коллегами - строится на вопросах относительно профессионального опыта: где работал, какими проектами занимался, какую функцию в них выполнял. По технологиям или знаниям - вопросы уровня «какого цвета учебник». Знаете, что такое Message Broker? Отлично, мы вас берём!Такой подход к проведению собеседования всегда резко настраивал меня против потенциального работодателя. Мне не задали ни одного вопроса, чтобы проверить, что я действительно знаю своё дело. Выглядит это так, будто собеседующие меня люди либо сами ничего не понимают в теме и ищут хоть одного человека, который понимает, либо просто отчаялись и готовы брать кого угодно. В любом случае, в коллективе, набранном подобным образом, мне едва ли захочется работать.
2. «Ну и чем вы там занимались в этом своём…»
Удивительно, как часто встречается пренебрежительное отношение к соискателям на технических собеседованиях. Да, возможно, вы суровый и опытный программист с кучей проектов за плечами, вас оторвали от чрезвычайно важной работы ради каких-то ненужных интервью с людьми, большая часть из которых, по вашему мнению, совершенно некомпетентна. Но не забывайте о том, что вы в этот момент представляете свою компанию и свою команду, и человек по вашему поведению обязательно составит оценку о климате в коллективе и о том, как к нему в этом коллективе будут относиться. Будьте вежливы и уважительны к соискателю, даже если вы с первых пяти минут поняли, что его и близко нельзя подпускать к вашему драгоценному коду.3. «Что-то у вас имя/фамилия/отчество в резюме неправильно написано!»
Это совсем не технический, но, тем не менее, часто встречающийся косяк даже на технических интервью. У меня, к счастью, достаточно простое и распространённое имя, и таких проблем со мной не случалось. Однако я знаю, что существует удивительно много людей, которые свято уверены в том, что определённых имён и даже отчеств попросту не существует. Они будут вас убеждать, что правильно не «Данила», а «Даниил», или что имени «Алёна» нет, а есть только «Елена». Будут предлагать исправить и записать в своих документах «правильно». С такими грамотеями-доброхотами приходится часто иметь дело людям с редкими или необычными именами, и поверьте, это невероятно раздражает. Так вот, есть одно простое правило: нет таких имён, которых нет. Правильно писать так, как записано в паспорте. Проявите уважение к соискателю и не считайте его настолько глупым, что он не в состоянии переписать из паспорта в резюме собственное имя. Если даже подозреваете ошибку, это можно уточнить как-то более тактично.4. «Сколько шариков для гольфа понадобится, чтобы помыть все круглые окна в школьном автобусе, уменьшенном до размеров пятицентовой монеты, во время эвакуации из Сан-Франциско, используя не более 3 взвешиваний?»
Ни одна статья про собеседования не будет полной без упоминания канализационных люков. Можете считать это моим персональным пунктиком, связанным с неумением быстро и под напряжением решать нестандартные задачи. Но я уверен, что брейн-тизеры на собеседованиях абсолютно бесполезны. Вернее, это отличный способ набрать полный отдел вундеркиндов с олимпиадой головного мозга, которые круглыми днями вместо работы будут перекидываться свеженькими брейн-тизерами. Реальный программист в естественной среде обитания, даже занимающийся очень крутыми и нестандартными задачами, всё равно редко кодит под напряжением, а большую часть дня сидит и в относительно спокойной обстановке неспешно думает над тем, как ему красиво распилить код по методам. «Мозговые мышцы» для решения хитрых задачек он не задействует в этом процессе ни разу.5. «Неправильно. Дальше.»
Конечно, заниматься обучением приходящих на собеседование людей - это не задача интервьюера. Однако, если соискатель не смог ответить на вопрос, но всё же заинтересовался, то подсказать или хотя бы указать ему на правильное решение, прежде чем переходить к следующему вопросу - это вопрос профессиональной этики, демонстрация того, что здесь ему в случае чего помогут, научат, не бросят наедине с техническими проблемами. Скажите хотя бы пару слов, что ему погуглить, что почитать. Ведь интерес к правильному решению задачи - это само по себе положительное качество технического специалиста, и не стоит демотивировать такого человека пренебрежительным отношением к его ошибкам или неточностям.Собеседование с позиции интервьюера
Каждый раз при открытии новой вакансии ведущему специалисту или начальнику отдела приходится проводить множество технических собеседований. На собеседования приходят люди с разным техническим опытом, уровнем подготовки, ожиданиями. Для проведения собеседований нужно продумывать план разговора, составлять список вопросов, а потом пытаться по ответам на эти вопросы понять, подходит человек на должность или нет. И вот иногда соискатели на собеседованиях говорят такие вещи, что становится сразу ясно - нет, ты с этим человеком работать вместе не сможешь. Вот некоторый набор ключевых фраз соискателей, которые настораживают лично меня.1. «Какие-то у вас вопросы теоретические. Я не силён в теории, я закалён в практике! Давайте лучше тестовое!»
Слово «теоретические» обычно произносится с пренебрежительным оттенком, как будто это что-то плохое. Но беда даже не в этом. Думаете, этой фразе предшествовала просьба интервьюера доказать теорему Коши? Дать точное определение третьей нормальной форме? Отнюдь. Такие возгласы я слышал в ответ на следующие вопросы:- чем сравнение по == отличается от сравнения по equals в Java?
- расскажите, как устроена хэш-карта.
- объясните своими словами, что такое REST.
- что такое транзакции и зачем они нужны?
2. «Не ожидал здесь испанскую инквизицию! У вас прямо как на экзамене в институте. Обычно просто спрашивают, где работал, что делал»
Вы пришли на техническое собеседование. На техническом собеседовании вам будут задавать технические вопросы, чтобы проверить ваши технические навыки. Методику проверки и выбор вопросов оставьте на совести интервьюера - вопросы не всегда могут вам казаться адекватными, но интервьюер знает, какую именно информацию он хочет о вас получить, анализируя ваши ответы. Многие вопросы нужны не затем, чтобы проверить знания, а чтобы заставить вас порассуждать и посмотреть на ход ваших мыслей. Помните также, что не на все вопросы требуется идеально точный ответ, и если вы внятно ответите хотя бы на половину из того, о чём вас спросили, это уже произведёт хорошее впечатление.3. «Мне и не нужно это знать, я специализируюсь на более высокоуровневых задачах!»
Не надо путать специализацию и незнание основ программирования. От разработчиков мобильных приложений я слышал подобные вещи про протоколы стека TCP/IP, от фронтэнд-программистов - в ответ на вопросы про алгоритмы сортировки и поиска. «Зачем мне это знать, всё есть в стандартной библиотеке, я работаю на более высоком уровне». В ответ на такие заявления я давно придумал пару небольших задачек с подло скрытой алгоритмикой - в надежде показать, что «наивное» решение, выданное от незнания алгоритмов, не выдерживает критики, и побудить хотя бы к самообразованию. Причём это не какие-то искусственно сконструированные задачи, а такие вещи, которые встречаются в разработке ежедневно. Любой код это алгоритм. Понимание основных алгоритмов и структур данных важно для любого программиста, а протоколы сети Интернет - это база, без знания которой невозможно грамотно написать хоть что-то, что выходит за пределы одного компьютера.4. «А сами-то! / А покажите ваш код! / А вот я зашёл к вам на GitHub, а там такое...»
Меньше всего интервьюеру хочется взять человека на работу, а потом выслушивать от него критику своей кодобазы. Да, она, скорее всего, неидеальна. Да, технический долг есть везде и у всех. В любом коде найдётся что покритиковать. Но если вы действительно считаете себя настолько крутым, что видите очевидные проблемы в коде своих потенциальных работодателей - переведите это в конструктивный позитив: я знаю, как улучшить, у меня есть наработки на эту тему, я смогу принести вам пользу.5. «Вы не правы!»
Всякое бывает, конечно, но мнение относительно неправоты интервьюера или сомнения в его компетентности лучше оставить при себе до окончания собеседования. Потом погуглите и разберётесь, кто из вас был прав. Техническое собеседование - это не место для дискуссий или самоутверждения, и вопросы здесь в первую очередь задают вам. Интервьюер не станет спрашивать о том, в чём сам не разбирается.Заключение
А знаете, какую самую приятную вещь я слышал на собеседовании от соискателей? «Что-то я не очень наотвечал, да? А можете дать листочек? Я запишу ваши вопросы и дома поразбираюсь, даже если не возьмёте меня, хоть буду знать теперь». Слёзы гордости наворачиваются на глаза - ты не зря потратил на человека полтора часа времени, он и сам что-то вынес из этого собеседования. Даже если сейчас он слабоват для этой должности, возможно, это побудит его к самообразованию, и через годик-другой он придёт ещё раз, покажет себя с лучшей стороны и получит работу - как это случилось однажды и в моей собственной карьере.Не стоит ожидать, что я смогу ответить на вопрос, который остается открытым для компаний с многомиллионными бюджетами на рекрутинг. Чтобы понять, насколько сложен вопрос подбора хороших специалистов, достаточно посмотреть на разнообразие подходов, которые используют мировые гиганты разработки ПО.
Для чего мы проводим собеседование? Мы хотим найти кандидата, который бы подходил под наши требования «подходящего» разработчика. Но поскольку мы не можем взять человека и посадить его на три недели за решение наших текущих задач, мы придумываем некую модель, соответствие которой означает, что кандидат нам подходит.
При этом «модели» используются самые разные. В гугле когда-то считали, что человек, который сможет ответить на вопрос: сколько шариков для гольфа влезет в багажник Lexus LS470 является хорошим программистом и сможет успешно решать их задачи. Майкрософт когда-то использовал похожий подход (вспомните «Чтобы сделал мистер Фейнман» Эрика Липперта), а сейчас они садят кандидата за стол и просят его покодить. Очевидно, что эта модель также не совершенна, ведь она не соответствует реальному миру, ведь мы никогда не кодим на работе, когда от этого зависит наша судьба, а наш начальник при этом заглядывает в код через наше левое плечо.
В отечественном аутсорсе применяется несколько иной подход. У нас считается, что если человек хорошо разбирается с некоторой технологией, то он достаточно разумен и талантлив, чтобы решать «замечательные» задачи их корпоративных клиентов.
ПРИМЕЧАНИЕ
Помимо отечественного аутсорса подобные тип собеседований активно используется и в некоторых компаниях в США. Например, в Нью Йорке большинство собеседований очень напоминают киевские;)
Кого мы хотим найти?
Прежде чем решить, как же нам подобрать правильных людей (и отсеять «неправильных») нужно определиться с тем, кого же мы ищем.
Проблема здесь в том, что к отечественному аутсорсу (который составляет существенную часть нашего рынка труда) не применимы те же самые критерии, что и к мировым гигантам, типа МС-а, Фейсбука или Гугла. Главное отличие между этими мирами в том, что аусорсу нужно не столько высочайшее качество, сколько большее количество при вменяемом качестве. И хотя требования к разработчикам в аутсорсе может быть и недотягивают до гугловских, тем не менее они достаточно высокие и наши программисты обычно превосходят в техническом плане многих представителей заказчика.
Так что планка в наши компании несколько ниже, ключевые критерии совпадают: нам нужно найти человека, который умеет думать, решать задачи и доводить дело до конца (кстати, именно умение довести дело до конца Бертран Мейер считает самой полезной чертой разработчика, о чем он поведал в своем недавнем интервью).
ПРИМЕЧАНИЕ
Я тут здорово все упростил, поскольку процесс отбора существенно сложнее. Как минимум нужно учитывать человеческие качества, ведь даже rock star разработчику стоит отказать, если из-за него развалится вся команда.
Техническое собеседование
На рынке существует множество способов определения таланта разработчика: начиная от задач на бредо логику, типа квадратных и круглых люков, заканчивая решением олимпиадных задач на клочке бумаги.
Отечественный аутсорс при отборе уделяют максимальное внимание конкретным техническим навыкам: знаниям языков программирования, технологий и платформ. Можно сколько угодно спорить, насколько коррелируют знания языка C# с умением решать рабочие задачи и насколько этот подход лучше/хуже альтернативных вариантов. Как по мне, значительно важнее не то, какие вопросы вы задаете и какие знания проверяете, а то, как вы слушаете ответы и каким образом их анализируете.
Не зависимо от задаваемых вопросов и типе технического собеседования, есть ряд простых советов, которым разумно следовать.
Узнайте, как человек думает
Капитан подсказывает, что наиболее эффективными являются не те вопросы, на которые кандидат знает ответ, а вопросы, ответ на который заранее не известен . На практике мы довольно часто решаем задачи, с которыми не сталкивались ранее, поэтому важно понять ход мыслей и рассуждения кандидата при ответе на вопрос, ответ на который ему заранее не известен.
Например, вполне нормальным попросить реализовать StringBuilder самостоятельно или спросить о том, как он реализован в.NET. При этом значительно интереснее обсуждать этот вопрос, когда кандидат не знает решения. Тут можно затронуть компромиссы между эффективностью реализации методов Append и ToString , подумать о выборе структуры данных и т.п..
СОВЕТ
Очень полезно обсуждать задачи, суть которых хорошо известна кандидату, но которые он не решал на практике. Это немного выведет кандидата из зоны комфорта и будет показывать не его способность запоминать факты, а его способность думать и принимать решения.
Никаких вопросов из "тестов"
Из первого совета вытекает второй совет о том, чего делать никогда не нужно. Не нужно задавать вопросы, ответы на которые легко гуглятся, и главное, нельзя трактовать ответы по принципу тестов: "ответил/не ответил", без продолжения обсуждения.
Меня всегда очень беспокоит, когда на собеседовании задается вопрос следующего вида: "Скажите, а какой тип возвращаемого значения должен быть у перегруженного оператора = в С++? Ссылка или константная ссылка?". Особенно печально, когда ответ на этот вопрос просто записывается на бумажке и интервьюер переходит к следующему подобному вопросу.
На самом деле, сам вопрос не так и плох, но тут важно понять, почему кандидат выбирает тот или иной вариант, и как изменяется его мнение в зависимости от дополнительных наводящих вопросов. Здесь легко можно подтолкнуть к определенной ситуации, с которой кандидат не сталкивался, что, опять-таки, покажет его способность анализа и выбора подходящего решения.
Сосредоточьтесь на фундаментальных вещах
Есть некоторые позиции, которые требуют очень глубокой экспертизы в определенной области. Бывает, что команде нужен эксперт по WCF, WPF или ASP.NET, который должен знать технологию очень глубоко и тогда на собеседовании придется гонять кандидата по всем дебрям. Во всех других случаях значительно полезнее сосредоточиться на фундаментальных вопросах, даже если они и привязаны к конкретной технологии.
Обычно под фундаментальными вещами я понимаю ключевые концепции: основы типов в.NET, основы сборки мусора и проблемы управления ресурсами; основы языка C# типа делегатов, событий, замыканий. Фундаментальные вещи из области проектирования, типа cohesion & coupling, проблемы наследования/агрегации, опасностей изменяемости и т.п; паттерны проектирования, отношение к ним и их роль в арсенале разработчика. Основы алгоритмов, можно в привязке к платформе ("Что будет если метод GetHashCode будет всегда возвращать 42?") и т.п.
Даже в контексте конкретной технологии можно найти достаточно общие вопросы, и не мучить мелкими частностями. Нам важно определить кругозор и фундамент, а не проверить, какая у человека память.
Определите свой уровень по шкале от 1 до 10
Я уже несколько лет пользуюсь подходом, подсмотренным когда-то у Эрика Липперта и в качестве первого вопроса собеседования задаю следующий: "Определите, пожалуйста свой уровень знания языка C# по шкале от 1 до 10, где 1 – это уровень моей мамы, преподавателя математики, а 10 – уровень автора языка C# – Андерса Хейлсберга.".
Это довольно распространенный вопрос, но для меня он не самодостаточен (хотя бывает любопытно услышать от синьера, что его уровень ниже 6 или выше 8). После этого вопроса я всегда задаю второй: "Ок, ваш уровень 8, а какие именно знания перевели вас с уровня 7 на уровень 8?".
Польза такого подхода в том, что можно узнать следующее: (1) чем человек интересуется и интересуется ли чем-то вообще, и (2) можно пропустить ряд простых тем, если кандидат говорит о недавнем изучении каких-то продвинутых вещей. Так, если кандидат говорит, что он узнал о сегментах в GC и Card Table, о реализации обобщений, деревьях выражений, о проблемах изменяемых значимых типах или о генерации IL-кода, то вполне можно пропустить базовые вопросы, типа разницы между ссылочными и значимыми типами и углубиться в более серьезные подробности.
К тому же такой вопрос позволит оценить человеческие качества: насколько кандидат уверен в себе и насколько он адекватно оценивает свои знания, насколько сильно он отстаивает знания в тех областях, в которых он считает себя экспертом и т.п.
ПРИМЕЧАНИЕ
Не так давно на rsdn было обсуждение этого вопроса: "Как вы оцениваете... по 10ти бальной шкале?" , в котором я также принял участие .
Тяните за ниточку
Я очень редко провожу собеседование по бумажке. Обычно происходит следующее: берется несколько ключевых вопросов (таких себе "якорей"), на основе которых строится все обсуждение. Ответ на вопрос n зачастую дает почву для вопроса n+1, который в свою очередь дает почву для следующих вопросов.
Обычно даже невинный вопрос, типа, а зачем нужен интерфейс IDisposable приводик к обсуждению управляемых и неуправляемых ресурсов, Dispose-паттерна, откуда легко перейти к обсуждению стандартов кодирования (поскольку все эти вещи описаны в Framework Design Guideline).
Аналогично, невинный вопрос, типа "А атомарна ли операция i++, где i – это System.Int32?" может послужить хорошим началом разговора, поскольку наверняка даст почву к другим темам, таким как неизменяемость и многопоточность, проблеме гонок, вопросам об атомик операциях и многим другим.
Именно поэтому мне нравится сверх простая задача следующего вида:
class Foo{
public event EventHandler MyEvent;
private readonly int _syncRoot = 42 ;public void RaiseMyEvent()
{
Monitor . Enter(_syncRoot);
try
{
if (MyEvent != null )
MyEvent(this , new EventArgs ());
}
finally
{
Monitor . Exit(_syncRoot);
}
}
}
Здесь можно обсудить массу вещей: начиная от проблем упаковки, заканчивая гонками и проблемами вызова событий из под блокировки.
При этом кандидаты очень часто сами себя закапывают, пытаясь ответить "умнее", чем в их силах, затрагивая темы, в которых они не сильны. Если же кандидат действительно силен в определенной теме, то такой способ быстрее позволит перейти к продвинутым темам и позволит лучше определить уровень кандидата.
Насколько "технологическое" интервью эффективно?
Есть ли связь между знанием языка C# и умением решать производственные задачи? Тут все не так просто. Можно выделить две крайние ситуации.
Во-первых , есть техно-гики, которые идеально ответят на все технические вопросы, но не смогут (или не захотят) решать бизнес-задачи. Обычно такие кандидаты обладают очень хорошей памятью и отвечают на многие вопросы практически не задумываясь. Попытка вывести их из зоны комфорта (перевести тему на дизайн, другой язык или платформу) позволит лучше понять, как они будут вести себя при решении неизвестных для них задач. Отсеять таких кандидатов должны лиды и ПМ-ы проверяя софт-скиллы кандидата (это не просто, но, в целом, возможно).
Во-вторых , есть замечательные практики, которые не сильны в теории. Есть вероятность, что такой кандидат будет отсеян, но опытный интервьюер может постараться перейти из теоретической области в более практическую и определить таланты такого кандидата. Один из моих текущих коллег попадает именно под эту категорию, и на многие продвинутые вопросы во время интервью смело отвечал, что "этой ерунды он не знает". Но его открытость и практичность подкупила с самого начала, поэтому мы уже почти год работаем в одной команде.
В целом, разумный подход на основе технологических интервью показал вполне хорошие результаты. Полноценный синьер не обязан знать про Card Table, но сможет относительно легко ответить о пользе поколений в сборке мусора, и даже не зная о SOLID принципах мы наверняка сможем пообщаться на предмет cohesion и coupling, о роле тестов и паттернах проектирования.
Талантливый разработчик знает свою кухню, как минимум на продвинутом уровне, поэтому "технологический" критерий не хуже любого другого.
Интервью – это двусторонний процесс
Для любого специалиста собеседование является двусторонним процессом: интервьюер оценивает кандидата, а кандидат оценивает компанию посредством оценки интервьюера.
Именно поэтому меня вгоняют в ступор собеседования, на которых практически не проверяются технические знания кандидата или его аналитические способности. Меня пугает как минимум два момента: во-первых, вопросы и обсуждения показывают не только уровень кандидата, но и уровень собеседующего, с которым мне (как кандидату), возможно, придется работать. Во-вторых, слабый отсев кандидатов путем невнятных вопросов вызывает сомнения в среднем уровне команды, поскольку в этом случае в команду может попасть множество "случайных" людей.
Можно подумать, что это лишь мое личное наблюдение, и не каждый интервьюер готов спрашивать C# MVP о языке C# (хотя лично я не вижу в этом ни каких проблем). Но ведь такую же картину видят и многие мои коллеги, которые проходят собеседования на Senior или даже Middle позиции.
Поскольку отечественный рынок является "перегретым", то интересное техническое интервью может играть дополнительную положительную роль: с его помощью вы можете показать кандидату, что он будет работать в интересном коллективе, что перевесит чашу весов в вашу сторону.
З.Ы. Если так уж случилось, что вы были на моих собеседованиях (Земля ведь квадратная;), будет интересно услышать ваше мнение о нем.
Вы уже разместили на объявление на работных сайтах с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать.
У Вас есть продукт, устоявшаяся команда и финансирование. Вы (команда) хорошо работали, и руководство готово заплатить еще денег чтобы нанять человека, чтобы, соответственно, ускорить разработку, повысить качество и иметь возможность тратить ресурсы на технологическое развитие продукта. Вы уже разместили на hh объявление с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать. Знакомая ситуация? Тогда добро пожаловать под кат.
Возможно, ситуация немного утопическая, но многие кейсы также входят в рамки этой статьи. Исключения составляют компании которым «человек нужен вчера» или компаниям которым новый человек вообще не нужен, они просто «наблюдают рынок» и (или) надеются найти «редкого профессионала».
Иными словами, это статья для тех кто хочет вложить деньги и силы в то, чтобы команда стала сильнее.
Для начала заметим, что крайне вредно нанимать человека под сиюминутную потребность. Скажем, сейчас у вас слегка «тормозит» разработка серверной части. Значит ли это что надо нанять server-side программиста? Вообще-то нет. Если у вас достаточно активная разработка, то приоритет разных кусков будет неизбежно меняться. В этом смысле глупо нанимать человека под задачу на ближайший месяц. Ведь месяц пройдет, а человек у Вас останется. И если в этом месяце Вы залатаете дыру в server-side разработке, то в следующем выяснится что server-side пишется быстрее чем клепается интерфейс. И что, в следующем месяце надо нанимать UI-программиста? Или уволить «слабое звено» в server-side? Нет, тут стоит подойти по-другому. Посмотрите, чем Вы занимались раньше в разработке продукта. Расспросите продажи, инвесторов или кто там определяет цели для разработки, и постарайтесь построить картину того что ждет вас, скажем, на год вперед. А теперь представьте, какой человек помог бы Вам работать в прошлом и будущем эффективнее. Надеюсь, Вам представился не один человек. Скорее всего окажется, что можно и тут укрепить команду, и здесь. А если где-то окажется слишком крепко (и соответственно где-то - слишком тонко), то кто-то из существующей команды возможно согласится «переключить» род деятельности.
Итак, Вы набросали несколько портретов «идеальных» кандидатов. Настала пора провести техническое собеседование. Кстати, надеюсь в Вашей компании именно техническое собеседование влияет на решение о найме сотрудников? Часто говорят о компании как о «семье» или о «коллективе где приятно проводить время». Так вот, компания это все таки не семья. И не друзья с которыми вы ходите в боулинг. Конечно, если человек болен клептоманией или проказой то брать его на работу опасно, даже если он лучше всех прошел техническое собеседование. Но не стоит слишком зацикливаться на личных качествах. В принципе, до или после технического собеседования необходимо выяснить, не выкинет ли человек какой-то фокус, и в этом смысле такое «не техническое» собеседование будет иметь роль «порога» - тот кто его не пройдет в компании точно работать не будет, а если пройдет - то не имеет значения будет ли он «душой компании» или просто добросовестным работником. Но это и все, собственно, все остальные решения должны определяться именно техническим собеседованием. Если в вашей компании HR донимают кандидатов вопросами об их карьерных устремлениях и «кем они видят себя через 10 лет» или «почему компания должна нанять вас», то вам еще рано искать технических специалистов. Для начала вам надо найти нового HR.
Но что же спросить на техническом собеседовании? Составить тест? Выяснить что человек делал на прошлом месте работы? Задать каверзный вопрос? Дать задачку с braingames.ru?
Давайте рассмотрим эти варианты по порядку.
Тест может показаться полезной вещью чтобы сэкономить время. Однако хороший тест составить достаточно трудно - на эту задачу саму по себе надо потратить немало времени. Плохой тест может отсеять лишь кандидатов, мало ходящих по собеседованиям и не знающий ответов на «типовые» вопросы. Очень плохой тест может отсеять действительно крутых кандидатов, которые просто занимались немного другими вещами. В целом же тест это просто некоторый первичный фильтр. Вы можете не нанять человека, который не смог ответить на пять банальных по вашему мнению вопросов. Но уж точно не стоит нанимать человека после теста, не спросив у него ни слова.
Чем вы занимались на прошлом месте работы? Ну знаете, тем, чем соискатель занимался на прошлой работе, у Вас он уже заниматься не будет. В принципе можно задать такой вопрос чтобы нащупать тему для беседы. Но, честно говоря, это выглядит пустой тратой времени. Приведу пример из своей практики.
Чем Вы занимались на прошлой работе?
- Ну там была сложная система моделирующая систему городских коммуникаций с поиском оптимальных маршрутов и (…)
- Что такое алгоритм Дейкстры?
- Эмм, да, и что-то такое я слышал.
Итого - что мы узнали? Да ничего. Какой-то сложный проект. Толком не понятно что за проект, что именно делал этот сотрудник, что он в итоге научился делать хорошо. Мы промотали 5 минут на то, чтобы не выяснить о человеке ничего. Конечно, можно потратить полчаса и разобрать все по полочкам. Но есть два «но».
Во-первых, цените время. Если на каждого кандидата будете тратить по 4 часа, то вы можете просто «не дойти» до действительно стоящего. Вообще, на мой взгляд, собеседование стоит жестко ограничить временными рамками, скажем одним часом. И постараться вытрясти за этот час из человека все, что Вам необходимо для принятия решения.
Во-вторых, не зацикливайтесь на том, кем человек был. Попробуйте оценить, кем бы он мог стать в вашей компании. Ваш кандидат говорит, что на прошлой работе сделал за неделю модуль, который Вы делали месяц? Так может на прошлой работе крутые бизнес процессы и гора готового кода, а у вас он бы делал этот модуль ровно столько же, сколько и Вы? Или Вам показалось, что на прошлой работе кандидат не сделал ничего сколько-нибудь примечательного? Очень может быть. Но может это талантливый человек, прозябавший в третьесортных «рогах и копытах», а у Вас раскроется весь его потенциал! Поверьте, во многих ситуациях за такого человека стоит побороться даже больше, чем за состоявшегося специалиста.
Стоит ли спросить что-то каверзное? Скажем вчера Вы прочитали на хабре, что, оказывается, хеш-код в джаве это не адрес (как Вы всегда считали), а случайное число, и Вам интересно, знает ли это кандидат. Или Вы на прошлой неделе ковырялись в никсах и выяснили, что "[" это не часть bash-скрипта как языка, а обычная программа с именем "[". Полезно ли будет выяснить, известно ли это кандидату?
Тут стоит опять же попробовать проиграть вопрос и варианты ответа.
Поиграйте по ролям.
- Ну это адрес объекта
И второй вариант:
Что такое Object.hashCode()?
- Да там генератор случайный чисел, вот он и возвращает.
Вы потратили 3 минуты на этот вопрос. Как вы сравните первого и второго кандидата? Можно ли сказать, что один из них лучше другого? Может быть второй листал на досуге grepcode. Или читал хабр вместо работы. А может и не вместо. Но вам-то это что-то говорит?
Не то чтобы не имело значения знает или нет человек тонкости реализации. Напротив - я считаю что очень важно знать мелочи. Человек, который знает ассемблер, для меня ценнее того, кто его не знает, даже когда я ищу джава разработчика. Но, к сожалению, мелочей так много, что прямой вопрос «А знаете ли вы что» почти никогда не несет смысла. А спросить о сотни вещей мы не можем, у нас ведь ограничено время.
Так что же спросить?
Мне кажется, лучше всего вести беседу, в ключе того чем Вы обычно занимаетесь и смотреть, как кандидат решает задачки которые Вы часто решаете.
Скажем в Вашем приложении есть UI-логика и серверный код. Спросите у кандидата, что, как ему кажется, интереснее.
Серверный код? Отлично. Давайте представим какой-нибудь типичный кусок кода в Вашей программе. Нам интересно, какие вопросы возникают у кандидата, и как увязывает он теоретические знания с практическими потребностями.
Скажем такая задачка:
Есть фрагмент кода
void x(List
…Some processing
Вопрос кандидату - предположим в этом коде нам надо перед «Some processing» отсортировать список в алфавитном порядке. Что будете делать? Кстати да, тут же можно сказать кандидату про Collections.sort - мы же не «словарный запас» проверяем.
Положим наш кандидат написал что-то типа
void x(List
List
Collections.sort(b);
…Some processing with b
(надеюсь наш кандидат именно так решил эту задачу а не начал сортировать a).
Однако решение задачи тут не главное. Главное дискуссия.
Почему он создал новый список а не использовал старый? Всегда ли это правильно?
Почему использовал ArrayList а не что-то еще? А знает ли он что еще есть?
Самое интересное что дискуссия тут может быть почти бесконечная. Кандидат скажет что ArrayList лучше тем что он random access, а Вы скажите что sort все равно копирует перед сортировкой данные в массив, а потом возвращает обратно. Стал ли ArrayList лучше теперь, по мнений кандидата? Как, уже нет? Или все равно лучше?
Беседа с кандидатом должна раскрывать образ его мыслей. Посмотрите как много деталей он знает. Как реагирует на что-то новое? А самое главное - может ли правильно распорядится информацией, которую Вы ему дадите? Ведь абстрактное «знание всего» обычно не особенно важно, в конце-концов рядом есть коллеги и проблемный вопрос часто можно обсудить. Коллеги могут подсказать, но писать код вместо нового сотрудника не будут, так попробуйте понять, сможет ли он, выслушав совет, написать программу лучше?
Или скажем другой пример.
Не спрашивайте «что такое garbage collector». Не спрашивайте «сколько там поколений». Какая разница сколько. Какая разница может или нет человек рассказать как устроен gc - для вашей работы может быть важно только то, сможет ли человек исправить performance проблему если таковая возникнет, а не может ли он поведать душещипательную историю про сборку поколениями или там про concurrent mark sweep gc.
Я не говорю, что кто-то может решать сколько-нибудь интересные проблемы с GC не зная, как он работает. Один раз, конечно, может и повезет. Но на практике знание чрезвычайно важно. Проблема в другом - не каждый, кто может рассказать как что-то работает, может исправить проблему с этим чем-то. И, вообще говоря, интуиция, общая техническая подкованность часто для решения задачи важнее прочитанного где-то описания алгоритма.
Например, для gc хорошо будет привести опять же какую-нибудь практическую задачку.
Скажем, «вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?».
Увеличу хип
А станет ли быстрее? И самое интересное, а разве не стоит перед ответом на этот вопрос спросить, а что такое для меня «быстрее»? Посмотрите, понимает ли кандидат разницу между throughput и latency. Не спрашивайте что это и в чем разница. Если кандидату при вышеописанной постановке задачи не приходит в голову задаться такими банальными вопросами, значит и на практике у него этих вопросов не возникнет. Однако не стоит забывать, что мы ведем беседу. Если кандидат прыгнул с места в карьер, остановите его, расскажите про разные характеристики производительности. Кандидат никогда про них не слышал, но сходу сообразил что рост хипа возможно улучшит одно, но точно ухудшит другое? Ну так это же замечательно!
Таких примеров можно привести бесконечное множество. Самое приятное тут, что такие задачки придумываются элементарно, и им нет числа - можно каждого нового кандидата спрашивать про разные вещи и адаптировать задачки под конкретного кандидата.
- Подбор и отбор, Оценка, Рынок труда, Адаптация
- IT-компании
Я уже достаточно давно провожу технические интервью с кандидатами на позицию Software engineer и на моем счету их имеется несколько десятков. Сегодня я попробую сформулировать основные моменты, которые лично мне, как интервьюеру, кажутся довольно важными.
Советы довольно очевидные (хотя, как показывает практика, бывают и те, кто не знает этих очевидных вещей) и субъективные.
1. Отвечая на общие вопросы помните, что интервьюер может ничего не знать о том, о чем вы говорите
.
Бывает, что в самом начале интервью интервьюер задает общие вопросы - например «Расскажите о проекте Х, над котором вы работали в У» (список проектов берется из резюме) или «Расскажите про самую любимую технологию» или еще что-нибудь такое. Отвечая на этот вопрос очень важно помнить, что вы рассказываете о проекте не себе, а интервьюеру - и ваша задача, чтобы интервьюер вас понял.
Не надо предполагать, что интервьюер очень умный и все знает - он, вероятно, действительно умный, но точно знает далеко не все. И то, что для вас может быть очевидным потому, что вы этим занимались пару лет кряду, для интервьюера может быть совершенно новой областью. И поэтому не стесняйтесь начать с самых основ и время от времени интересуйтесь, понимает ли вас интервьюер.
2. Не гуглите во время интервью.
Бывает такое, что интервьюер задает вопрос, ответ на который вы смутно помните, и если бы только одним глазком взглянуть в википедию… Так вот - не надо этого делать. Стук клавиш обычно довольно неплохо слышен через телефон и ответ, который зачитывается из википедии без особого понимания - тоже довольно несложно отличить. Стоит ли говорить, какое впечатление оставляет у интервьюера такой кандидат?
3. Не врите в резюме.
Есть вещи, которые проверить относительно легко - знание какой-то технологии, например. И вещи, которые проверить сложно - например, если кандидат написал, что он в top 100 на topcoder (это такой сайт, где проводятся соревнования по программированию). Лично я этого на уровне «А под каким ником вы там числитесь?» никогда не проверяю, но от кандидата, который в top 100 на топкодере я жду, что простые вещи он напишет не приходя в сознание (я уже интервьюировала олимпиадников - и по моему опыту так и происходит). И если вдруг окажется, что кандидат пишет код медленно, с кучей ошибок - то это, скорее всего, значит, что либо он очень плохо себя чувствует, либо в резюме он указал неверную информацию.
Конечно, в компетенцию интервьюера не входит оценивать состояние кандидата, но я обязательно упомяну об этом несоответствии в своем отзыве.
4. Не пытайтесь «уболтать» интервьюера.
Если интервьюер задал вопрос - например, «Какая сложность у сортировки пузырьком?» - а вы не помните, то ли это O(N^2), то ли O(N), то ли O(NlogN), то ни в коем случае не надо маскировать свое незнание под кучей фраз, которые вы надеетесь что интервьюер примет за правильный ответ. Интервьюер очень внимательно вас слушает и замечает все попытки невзначай увести его от вопроса, на который кандидат не знает ответа. Лучше просто признаться, что вы точно не помните и подумать вслух - скорее всего вы придете к правильному ответу и так.
5. Говорите и объясняйте. Но не слишком много.
Бывают две крайности - кандидат, который молчит и почти ничего не говорит и даже на вопрос вроде «Расскажите мне, что вы думаете о Х, какие у Х достоинства и недостатки» умудряется ответить максимум одним предложением. И кандидат, который говорит и объясняет все вплоть до последней запятой - «Вот тут я ставлю запятую, потому, что таков синтаксис языка». И первый, и второй тип кандидатов очень сложно интервьюировать - из одних приходится тянуть ответы клещами, а других постоянно обрывать на полуслове.
Объяснений должно быть в самый раз - чтобы интервьюер понял суть, но при этом не чувствовал, что кандидат постоянно хочет сорваться в объяснение тривиальных основ.
6. Тестируйте код сами.
Во время интервью вы написали какой-то код, который по вашему мнению правильный. В этот момент важно этот код протестировать не дожидаясь, пока интервьюер вам скажет «А теперь давайте протестируем код на простом примере 123». Во время тестирования очень важно проверить так называемые corner cases - например, null, пустые строки и массивы, отрицательные числа, ноль - и еще более важно удостовериться, что код действительно работает на простых примерах. Потому что кандидат, который тестирует код, но при этом во время тестирования не замечает очень грубую ошибку, обычно не производит самого лучшего впечатления.
7. Не пытайтесь угодить интервьюеру.
В фильме «Bad teacher» есть один момент - один из главных героев спрашивает другого об акулах:
1: Что вы думаете об акулах?
2: О, акулы это такие ужасные рыбы, я слышал что они едят людей…
1: Но некоторые из них никого не едят, и очень даже милые…
2: О да, это ужасно, что люди истребляют акул, ведь акулы - это вымирающий вид и Бог создал их такими. Они - прекрасные создания…
1: Но ведь они едят людей…
2: Да, да, это ужасно, целые семьи бывают разрушены из-за акул…
Я не помню точно, но суть примерно такая. Так вот, не надо вести «разговор об акулах» с интервьюером. Интервьюер задает вопрос, чтобы узнать, что кандидат думает о том или ином аспекте, а не чтобы услышать, что кандидат с ним в любом случае согласен.
8. Постарайтесь убрать все, что будет мешать вам четко говорить.
Это может показаться очевидным, но я все-таки упомяну - не надо жевать жевачку во время интервью. И кушать тоже не надо. Если у вас есть пирсинг в языке, который имеет обыкновение издавать цокающий звук когда вы говорите, то на время интервью его тоже лучше достать.
Ну и самое главное - вопрос, который интервьюер себе сознательно или подсознательно задает это «Хотел бы я работать в одной команде с этим человеком?». И ответ на этот вопрос складывается не только из знаний и умений кандидата, но и из способности ясно и четко излагать свои мысли, способности слушать и еще многих других мелочей.
Виктория Придатко – известный эксперт в области позитивного управления ИТ-персоналом: её можно встретить на ИТ-конференциях, посвящённых менеджменту. В этом году она является одним из хедлайнеров конференции HR-специалистов в ИТ «Найти Ответ» в Питере.
Мы публикуем её доклад с конференции Software Project Management Conference , которая в этом году пройдёт в Минске.
Презентация доклада
Видео доклада
Текст доклада
Одна из моих любимых фраз – я её часто повторяю, поскольку это «Капитан Очевидность», –Первое впечатление второй раз не создашь.Первое впечатление является очень важным, и часто кандидаты составляют впечатление о компании именно по первому собеседованию. Если оно было негативым – очень трудно потом убедить их в обратном. Зачем вам это надо? Где могут пригодиться эти знания? Чем приятней общение с вами, тем лучше ваша репутация, тем больше денег и больше выбор. Когда вы известны, в хорошем смысле этого слова, когда на вас обращают внимание – претенденты хотят попасть на собеседование именно к вам. И чем больше людей хотят к вам попасть, тем больше компаний делают вам предложения. А чем лучше вы проводите собеседования, тем больше у вас принятых офферов. Часто ПМ-ы говорят так: рекрутеры не могут нам никого найти, поэтому мы не можем создать команду. Когда я прихожу к ним на техническое собеседование и смотрю, как они его проводят, – я понимаю, почему так трудно найти людей, которые согласились бы там собеседоваться. Хорошее собеседование – это шаг к должности менеджера: если вы ещё не менеджер, но хотите стать им, вам надо уметь собеседовать.
- Собеседование – это коммуникация. Об этом мы и поговорим,
- Как это происходит? Я буду рассказывать о своём опыте.
- Ошибки в собеседованиях.
- Признаки классного интервью.
- Кто\что может помочь?
Интервью с HR-ом
Я не могу говорить за Россию, но в Украине сейчас в HR-ы берут очень симпатичных, не побоюсь этого слова – сексуальных девушек, которые всячески заманивают кандидатов. Как правило, организуются два интервью: с HR-ом и техническое. Часто кандидат на первом интервью расслабляется, а второе интервью очень сильно отличается от первого – собеседовать приходит технически сильный специалист. Проблема еще и в том, что очень часто такие специалисты хотят не сколько провести интервью, сколько показать себя. К сожалению, в компаниях этот процесс не всегда построен, и технических специалистов не спрашивают, когда им удобнее проводить интервью, – их просто вырывают из проекта. Как вы знаете, программисты работают в потоке, и им потом очень трудно в него вернуться... к сожалению, не все компании это учитывают. Соответственно, ощущения технического интервьюера следующие:- Чёрт, опять собеседование!
- Ну, рассказывай что знаешь...
- Ага, так этого ты не знаешь, бугага – опять рекрутеры пригласили тупняков.
- А я вот знаю это и это, поэтому – я ПЕРЕЦ!
У меня как-то был такой опыт: мы очень долго искали джависта в одну компанию, и вот рекрутеры нашли классного джависта, пригласили на интервью, всё было супер, он пришёл во второй раз, и его собеседовал другой джавист, которому надо было самоутвердиться. В итоге он сказал: «Ну что, будем… меряться или поговорим?» Это впечатление просто убило кандидата, и впечатление сложилось соответствующее. Самое плохое, что эта информация потом транслируется дальше.
Почему так делать нельзя?
Потому что по собеседованию люди часто составляют мнение о всей компании. Как известно – люди приходят в компанию, а уходят от менеджера. Допустим, во время интервью вы померялись… и ушли с ощущением, что вы классный, а кандидат ушёл с ощущением, что он ужасен, и что он будет рассказывать людям?.. Чем больше у вас таких собеседований, тем, к сожалению, меньше у вас кандидатов.
Основные ошибки на техническом собеседовании:
- Понты;
- Умничанье и болтовня – когда люди компетенты в какой-то теме, они склонны эту тему развивать, и в результате интервью превращается в рассказ интервьюирующего о его любимом вопросе. Хочешь рассказать о себе – вали на конференцию и рассказывай, какая проблема?
- Равнодушие – тоже часто встречающийся паттерн, когда технические интервьюверы сидят устало, вся их поза свидетельствует о том, что им страшно скучно и вообще непонятно, что они здесь делают… Опять же, это очень сильно зависит от того, как это организованно в компаниях. Я знаю компании, где этот процесс организован классно, где людям, проводящим техническое интервью, за это еще и платят...
- Стресс-собеседование – такой вид панельного интервью, когда пять собеседующих тебя по очереди «мочит»… Хотя я видела интервью, когда интервьюировали пять человек и при этом была вполне дружественная обстановка.
- Опоздание . Давайте уважительно относиться к кандидатам: мы часто вырываем людей из проекта их компании, мы забираем их рабочее время и при этом сами позволяем себе опаздывать… Моя позиция такая: если человек приходит к вам в обеденный перерыв – накормите его обедом. Для компании это копейки – предложите ему сэндвич, а не только кофе или чай! Или, допустим, кандидат пришёл вечером – если рабочий день заканчивается в 18:00, а вы пригласили его на 19:00, то понятно, что он пришел к вам голодный. Ребята! Простой сэндвич творит чудеса! Вы не поверите, как сильно у людей меняется впечатление о вас.
- Отсутствие фидбэка . Итак, мы провели техническое интервью, а дальше мы считаем, что фидбэк – это ответственность рекрутера (я, кстати, тоже так считаю). Но фидбэк по техническому интервью должен давать тот человек, который его проводил. Когда мы звоним человеку – неважно, взяли мы его или нет – мы можем сказать ему, что нам понравилось, а что, на наш взгляд, можно улучшить. Чувство благодарности, которое возникает у людей после того, как вы им это рассказали, – это просто ни с чем не сравнимое ощущение. Они будут об этом помнить, и вы потом еще не раз удивитесь, в какие моменты это будет всплывать. Ведь кандидата всегда есть за что похвалить, и нет таких людей, которые вообще ни в чем не разбираются, – иначе мы не приглашали бы этого человека на собеседование. При этом очень важно сказать, что было хорошо, а что можно улучшить, и что плохо. У HR-ов есть такое выражение «зона развития»: не то чтобы у тебя всё плохо, просто у тебя в какой-то области наметилась «зона развития».
- Не плюй в колодец . Иногда случается, что человек, которого вы собеседовали, потом может собеседовать вас. У меня был такой случай в жизни – у меня достаточно много знакомых, и, допустим, наша компания отсобеседовала кандидата не очень хорошо, а потом ты сам попадаешь к нему на собеседование, и он говорит, ага, сейчас я тебя отсобеседую.
- Be nice or leave … Как я уже говорила, очень важно оставить у людей положительное впечатление. Для технических специалистов важна компетентность человека, который проводит собеседование, но его «хорошесть» (в хорошем смысле этого слова – его уважительное отношение, его «принятие другого человека») – важна не менее, чем техническая компетентность, а иногда даже больше.
- Тот человек, которого вы собеседуете, может оказаться вашим руководителем или рекомендателем в будущем. Рынок непредсказуем – люди растут по-разному, переходят в разные компании и, соответсвенно, все друг друга знают.
Загрузка...
