Вконтакте Facebook Twitter Лента RSS

Пройди техническое собеседование. Как проводить технические собеседования

Как это бывает

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

В целом, такой подход бывает эффективен, но он имеет ряд недостатков:
1. Существует вероятность, что в собеседующий технический специалист может воспринять несоответствие опыта соискателя его собственному, как отсутствие опыта вообще. Например, могут быть заданы довольно узко-практические вопросы, с которыми соискатель не сталкивался на практике, что может быть истолковано как «Да как же можно такое не знать, это же так просто». А специалист от кадров, никогда не сможет это распознать в силу специфики контекста.
2. Даже если будут заданы открытые вопросы вида «А какие задачи вам приходилось решать?», опять же, несоответствие опыта может быть истолковано как «Он нам не подходит, потому что он не делал то, чем мы занимаемся уже несколько лет».
3. Отдельные технические специалисты, особенно уже с довольно большим опытом, мало признают тот факт, что незнание конкретных инструментов не является зачастую большим препятствием. Например, если человек не работал с GIT, но хорошо знает CVS, это значительно сокращает порог входа в обладание инструментом.
4. Также может иметь место проблема, когда соискатель обладает большим практическим опытом и хорошо отвечает на вопросы по конкретным решениям, но когда его берут на работу, внезапно, выясняется что он допускает довольно типичные ошибки в областях, с которыми он до этого не работал. Про таких людей складывается впечатление, что они «тупят на ровном месте» или «активно копипастят код» из своих предыдущих проектов.
5. Порой попадается специалист, который производит впечатление новичка и его резюме показывает малый практический опыт, но важно понять «выстрелит ли он». Потому что если выстрелит, вы можете малыми вложениями получить хорошую «звезду» в команду. И не понятно как это распознать максимально точно.

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

Классификация знаний

Для начала нужно определиться с классификацией знаний. Для этого их надо разбить на 3 вида:
1. Фундаментальные – это базовые знания в конкретной области. Например, это может быть вопрос «Какие основные виды запросов в SQL вы знаете?».
2. Прикладные – это навык решения конкретных задач. Например, это могут быть задачи на правильное написание SQL запросов для конкретных примеров.
3. Инструментальные – это знания о том, как применять конкретные инструменты. Например, в чем различие между innodb и myisam хранилищами?

Фундаментальные знания необходимы для того, чтобы на их основе понимать как лучше решать практические задачи. Практические задачи формируют прикладные знания, то есть понимание того, как и что лучше делать. С пониманием того, что отдельные задачи лучше решать при помощи конкретных инструментов, развиваются и инструментальные знания. Часто, человек начинает с какой-то небольшой практики, потом изучает «почему это работает именно так», потом пытается сделать что-то схожее, и потом уже оттачивает свое мастерство при помощи инструментов.
Например, точно также человек развивает навык владения языком: сперва просто пытается повторить за родителями отдельные слова; потом учит алфавит; потом пишет сочинения, статьи или деловые письма; и иногда использует для этого справочники и словари.

Когда что-то пошло не так

Так как «академическое образование» в области ИТ все еще довольно слабо, большинство специалистов во многом являются самоучками. Это создает определенные отклонения, которые хорошо можно понять на данной модели если гипертрофировать одну из областей знаний. Приведу классические портреты кандидатов и их объяснение:
1. Всезнайка – имеет значительный объем фундаментальных знаний, например приобретенных в рамках каких-либо курсов и чтения книг/статей, однако, практических навыков их применения не имеет, что его никак не смущает. Даже если вы начнете его спрашивать какие-то практические задачи, вы всегда услышите массу знаний о том как это на самом деле должно работать, как устроены отдельные части, но собрать все вместе для решения задачи, без ваших подсказок, такому кандидату будет довольно сложно. Довольно частая ситуация если спрашивать кандидата про мало используемые паттерны ООП: услышите описание паттерна, когда его применяют на каком-нибудь академическом примере, но встраивание в живую задачу будет идти «со скрипом».
2. Stackoverflow-разработчик – обычно, такие разработчики довольно активно рассказывают про свой опыт, про то какие задачи и как им удавалось решать, но при попытке ответить на вопрос «А как сделать…?» из неизвестной им практической области, вы услышите или попытку «притянуть за уши» другое решение, или же ответ в стиле «Да это гуглится за 5 минут, я уже такое где-то видел». Подобные разработчики часто стараются притянуть какие-то готовые решения, которые они уже делали, аргументируя это как «Зачем делать 2 раза?», либо же просто копипастят код из интернета и других проектов. При вопросах «А почему это работает именно так?» или «А как это можно сделать по-другому?» часто могут теряться и пытаться перевести тему.
3. Tools&Frameworks-разработчик . Есть старый анекдот: «Как начать делать сайт в 1995 году? Открыть блокнот и начать писать код. Как начать делать сайт в 2015 году? Скачать и установить composer, framework, cms-extension, bootstrap, jquery, bower, less, поставить IDE, начать писать код». Вот примерно тоже самое для подобного рода специалистов. Большая часть прикладного опыта таких специалистов связана исключено с конкретным инструментом. Такое понятие как «bitrix головного мозга» вполне конкретно характеризует этот случай. Для таких кандидатов очень сложно даются задания по «нативному» коду, потому как без инструмента для них это практически невозможная задача.
Данные примеры приведены для случаев, когда одна из областей знаний занимает ведущую позицию, а так как ощущение «превосходства» в этой области зарождает чувство собственного «величия», то специалист старается удержаться за нее всеми возможностями («каждый хочет быть крутым»). Например, Stackoverflow-разработчик, при попытке выяснения фундаментальных знаний, до последнего будет аргументировать к тому, что «да мне это и не нужно знать, я такое уже сто раз делал и все и так работало».

Как работает эффективное развитие

Самым эффективным же сценарием развития знаний является именно баланс между областями. Достигать его можно разными способами, но нельзя допускать именно «перекоса». Например, вы захотели сделать домашнюю страничку и ничего в этом не понимаете (все с этого начинали): скачали wordpress (взяли «инструмент»); загуглили как все настроить и сделали свой первый блог с несколькими статьями (приобрели прикладные знания); а теперь разберитесь как и почему это работает, например как устроена база и кеш, какова архитектура движка и т.п. (приобретите фундаментальные знания). Дальше можно уже и посмотреть какие еще инструменты и как могут решать эту задачу, либо написать свой инструмент. Если же остановиться только на первом или втором шаге, то можно легко попасть в одну из категорий специалистов, приведенных выше, а вы, я уверен, явно не этого желаете:)

Как оценивать знания

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

Например: Что такое составные b-tree индексы и как они работают? А можете привести пример, когда могут потребоваться такие индексы или когда наоборот они будут неуместны? А как понять, что данные индексы работают эффективно и что вообще можно для этого использовать?

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

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

Типичные ошибки при оценке

Многие склонны переоценивать важность прикладных знаний по отношению к остальным областям, а именно, что люди с большим опытом выполнения задач являются хорошими специалистами, но это совершенно не так. Если практика не подкреплена фундаментальными знаниями, или специалист никогда не расширял свой инструментарий, то эффективность такого специалиста может быть очень низка. Ищите тех, кто умеет развивать каждую из областей. Они – лучшие, даже если и не имеют гигантского опыта за плечами.

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

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

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

На что обращать внимание

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

Пытливость ума . Насколько кандидат старается решить задачу, если не знает решения «с ходу». Ищет ли альтернативные пути, анализирует ли подсказки, спрашивает и анализирует ли предложенное решение. Слабые кандидаты «пропускают мимо» все, что не смогли понять.
Здравая самоуверенность . Насколько кандидат допускает что может чего-то не знать. В силу воспитания, иногда, люди имеют комплексы касательно собственных знаний («краснодипломники» и т.п.). Иногда, такие люди в резко категоричной форме выдают решения и не признают альтернативных мнений, если таковые говорят об отсутствии каких-то знаний у кандидата.
Стремление к саморазвитию . Самые лучшие кандидаты - это которые стремятся развиваться как специалисты, либо же стремятся «сделать мир лучше» через создание какой-то пользы. Слабые кандидаты считают что они уже «у потолка знаний» и просто хотят зарабатывать на этом как можно больше. Также бывают и кандидаты, которые считают что их должен развивать работодатель, а не они сами себя, потому как именно работодатель ставит задачи.

Стратегия интервьюирования

Предварительно, до собеседования, составьте список ключевых областей, в которых вам требуется опыт от специалиста. Хорошо, если их будет не менее 10. Например: PHP + паттерны ООП; SQL + оптимизация запросов; архитектура высоконагруженных проектов; работа с кешом и т.п.
В каждой из ключевых областей составьте минимум по 5 вопросов для каждого вида знаний, итого минимум по 15 вопросов на каждую область. Это сделать лучше для того, чтобы не придумывать вопросы на ходу. Желательно, чтобы такие вопросы обеспечивали между собой вертикальную связанность.

Например:
Область: архитектура высоконагруженных проектов.
Фундаментальные вопросы: Какие основные параметры важно учитывать при проектировании высоконагруженных систем? Какие типовые архитектурные решения вы знаете? В чем отличие горизонтального и вертикального масштабирования?
Прикладные вопросы: Если пользователи могут загружать файлы, то каким образом лучше решить вопрос их горизонтального масштабирования на отдачу? Если имеется страница с высоким RPM, и информационным блоком, который имеет длительное время генерации, то каким образом можно ускорить отдачу страницы? Если в проекте в результате роста нагрузки узким местом стала единственная база данных, то каким образом лучше подойти к этому вопросу?
Инструментальные вопросы: Какие инструменты можно использовать для балансирования нагрузки HTTP траффика? Какие кеширующие сервера вы знаете и в чем их отличия? Каким образом можно измерять производительность приложения при больших нагрузках?

Начните с любого из вопросов на свое усмотрение. Последовательно задавайте вопросы из каждого типа знаний в выбранной области (вертикально). Если вы видите что кандидат уверенно владеет теорией, практикой и инструментами, значит вы можете быть в значительной степени уверенным, что и смежные практические задачи он также сможет уверенно решить.

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

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

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

Где еще можно использовать модель

Приведенная модель, на самом деле, может быть использована не только для технических специалистов, но и вообще для любой профессии. Разница будет лишь в том, насколько полно реализованы отдельные виды знаний в этих областях. Возьмем, для примера, дворника: Какие критерии чистоты вы знаете? Если вам нужно убрать за один день 10 домов, как это лучше сделать? Для каких поверхностей какие средства для уборки лучше использовать?

В качестве заключения

Недавно я решил собрать свои заметки по вопросам на собеседования для PHP-разработчиков и выложить их в открытый доступ (проект «на коленке», так что не обессудьте). Там, конечно, не все, но хватит для того, чтобы собрать мысли вместе и настроиться на проведение собеседования. Вы можете посмотреть вопросы по ссылке:
pagerton.com/hr/question/all
Если будут позитивные отклики, то буду развивать проект по мере возможности, хотелось туда еще скинуть ссылки по хорошим курсам для разработчиков, так что буду признателен за обратную связь.
Надеюсь, эта модель сможет быть полезна и вам. Не только как собеседующим, но и как собеседуемым, потому как понимание своих сильных и слабых сторон поможет вам эффективнее развиваться.
Желаю вам быть лучшими, и работать с лучшими.

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

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

При этом «модели» используются самые разные. В гугле когда-то считали, что человек, который сможет ответить на вопрос: сколько шариков для гольфа влезет в багажник 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 позиции.

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

З.Ы. Если так уж случилось, что вы были на моих собеседованиях (Земля ведь квадратная;), будет интересно услышать ваше мнение о нем.

уже устал слышать от компаний из Силиконовой долины фразы вроде «нанимайте только лучших и талантливейших». Как бы эти фразы ни вертелись на языках, большинство нанимателей всё равно принимают решения, основываясь на интуиции, анкете соискателя, среднем балле, дипломе университета, громких названиях предыдущих работодателей… Розман категорически против такого положения дел. Как бывший вице-президент в Amazon и Zynga, он провёл собеседования с сотнями людей и уверен в том, что каждая стадия собеседования должна быть тщательно продумана и призвана оценить навыки соискателя, его достижения, способности к командной работе и лидерских качества.

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

На безымянной высоте

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

    После интервью у вас должно сложиться ясное представление о том, сможет ли этот человек внести вклад в успех компании.

    Хорошее собеседование — это труд. К нему нужно готовиться, его нужно провести, а потом потратить время на обсуждение результатов. Если вы к этому не готовы — не проводите собеседования.

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

    Во время собеседования делайте подробные заметки, чтобы обеспечить себя убедительными доводами за или против кандидата.

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

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

    Тот, кого вы хотите нанять — умный, трудолюбивый человек, обладающий навыками, необходимыми для конкретной вакансии.

Как правильно читать резюме и составлять вопросы

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

При просмотре резюме Розаман ищет те ниши, которые занимает кандидат в реальности. «Я всегда смотрю, измеряют ли люди свой успех, делают ли они сравнения и используют ли процентные соотношения». Например, «прибыль выросла на 50%, время простоя снизилось на 30%».

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

Лакмусовой бумажкой будет то, насколько чётко кандидат оценивает себя и свою роль в проделанной прежде работе. «Кандидат может думать, что заявление вроде «я улучшил доступность системы на 50%» звучит круто, но если мы ищем человека на вакансию системного инженера, мне нужно знать, как именно он это сделал. В большинстве случаев, несмотря на такие громкие заявления, человек на самом деле был лишь участником процесса и мало понимает в его сути. Он не сможет внятно ответить на вопрос, как он добился такого результата». Хороший кандидат всегда объяснит и подтвердит свои заявления, каким бы дотошным вы ни были.

В одном из недавних резюме, полученных Розманом, было написано: «Был тим-лидом команды из 3 инженеров, создавал высоконагруженную инфраструктуру, используемую различными продуктами Google». Розман записал это себе в блокнот и во время собеседования попросил кандидата нарисовать на доске инфраструктуру, рассказать о своём вкладе в её создание и ответить на вопросы— - что позволило выяснить, действительно ли человек знает, о чём говорит.

Иными словами, хорошие вопросы на собеседовании потребуют от кандидата ответа с конкретными примерами своих действий, принятых решений и его роли в проекте.

    Прощупайте почву: приведите мне пример…

    Уточняйте: кто, что, где, когда, почему, как - о каждом достижении или проекте

    Выясняйте: мы или я; хорошо или отлично; отдаленное представление или точное знание; участник или лидер…

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

    Над чем вы работали в компании?

    Какие задачи выполняли?

    Какие действия вы предпринимали для решения задач?

    Какие результаты получили?

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

Техническое интервью

Очень часто HR-менеджеры на собеседовании с места в карьер начинают опрашивать кандидата по всем пунктам, указанным в его резюме. По мнению Розмана, такой вопрос можно задавать только в том случае, если вы уже решили отказать человеку. Есть множество других способов расположить соискателя к беседе. Розман рекомендует интервьюеру представиться и обозначить цели интервью. «Потом я прошу человека представитьтся самому и рассказать о том, чем ему интересно заниматься. Так намного проще расслабиться, настроиться на беседу и убедиться, что оба чувствуют себя комфортно».

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

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

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

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

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

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

Розману очень нравится подталкивать кандидатов на инженерные должности к дизайну продуктов. Хороший инженер - это не просто исполнитель, а активный участник разработки продукта. Вопросы, связанные с дизайном, позволят лучше понять ход мыслей соискателя. Розман просит кандидатов перечислить продукты, в разработке которых они принимали участие, просит их написать небольшую план развития продукта. Также он может попросить выполнить достаточно общую задачу вроде «обдумать разработку лифта для слепых людей».

«Если бы у меня было достаточно времени, я бы выдавал на собеседовании ноутбук и просил бы написать простое приложение в командной строке, либо же нарисовать процесс на доске, и дал бы возможность задать мне вопросы по поводу того, какой продукт я хочу получить. Очень важно, чтобы соискатель задавал вопросы. Мне нужен сотрудник, который задаёт вопросы, а не просто сидит в углу и ждёт указаний».

В технических вопросах есть одна проблема: ответы могут занять очень много времени. Вот тут важно следить за временем и вовремя прервать ответ. Ответ на сложный вопрос может запросто съесть 45 минут из часового собеседования.

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

С этой целью Розман задаёт всем кандидатам, вне зависимости от предполагаемой должности, один свой любимый вопрос: «Считаете ли вы себя счастливым?»

«Оглянитесь на то, что сделали, и подумайте: можете ли вы себя отнести к тем людям, кто был счастлив на своём жизненном и профессиональном пути? Многие на этот вопрос отвечали мне: «Я бы получил повышение, но менеджер отменил мой проект…» Это как раз те, кто не считает себя счастливым человеком. Удача улыбается подготовленным умам. Я ищу тех людей, кто готов найти выгоду в каждом обстоятельстве».

Розман часто использует вопросы типа «опишите себя тремя прилагательными». Многие интервьюеры просят описать свои сильные и слабые стороны, но Розман ставит акцент на другом. «Я прошу кандидата вспомнить тех людей, с кем он работал, своих учителей, однокурсников, менеджеров и прочих, и представить, какими бы тремя словами эти люди описали бы его. Это позволяет взглянуть на себя с другой стороны. И уже не так просто сказать, что самое твоё плохое качество - это трудоголизм». И если кандидат назвал эти три качества, Розман на этом не останавливается. Если кандидат сказал: «творческий», вам нужно спросить: «А приведите примеры своего творческого подхода».

Даже если уже после 15 минут общения вы поняли, что это не ваш кандидат, важно довести собеседование до конца. «Мир очень тесен, и даже если вы отказываете кандидату, очень здорово, если у человека останутся от собеседования хорошие воспоминания».

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

Розман старается предугадать мотивы кандидата, и что может заставить кандидата отказаться от предложения. «Сейчас я, как старый морской волк, могу не задавать вопросы типа «А кем вы себя видите через 2-3-5 лет?». Но я хочу убедиться, что я правильно понимаю ожидания кандидата».

HR-команда

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

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

Каждое решение на собрании HR-комианды критично, а критичные решения требуют глубокого осмысления. Розман говорит о двух вещах:

    Если отдел кадров не может предоставить внятных комментариев, они потратили впустую и своё время, и время компании, и время кандидата;

    Если вы провели собеседование и всё, что можете сказать, это: «Ну да, он вроде ничего, мне понравился», - вы тоже потратили время зря. Вы не справились с работой, и вам нужно либо научиться делать это, либо больше не проводить собеседования. Я не заставляю никого делать эту работу, но если вы взялись за неё, я требую, чтобы она была сделана хорошо.

Хороший интервьюер не должен работать самоотверженно и бескорыстно. Его труд отражается и на существующих работниках. «Покажите, что вы - человек, на котором лежит большая ответственность».

Несмотря на свой командный подход к принятию решений по найму, Розман осторожно относится к HR-менеджерам, слишком вовлечённым в процесс. Важно учитывать мнения людей, которые будут работать с новым сотрудником ежедневно. «Что бы ни случилось, не позволяйте мнению менеджера победить мнение команды».

Если вернуться к запредельным стандартам Силиконовой долины, Розман признаёт, что очень часто кандидату отказывают, потому что он не проявил никаких способностей супермена. Но далеко не ото всех требуются такие сверхспособности на собеседовании. Розман предлагает установить такую планку: «Чего нужно ожидать - так это того, каждое поколение работников лучше, чем предыдущее. Нет никакой гарантии, что если вы уволитесь и захотите вернуться, вас возьмут обратно на ту же должность. С каждой новой работой вы повышаете свою собственную планку. Другими словами, каждый новый сотрудник должен быть лучше, чем ваш среднестатистический работник».

Та же логика применима и для найма новых сотрудников по рекомендации работников.

Итак, краткая сводка правил Розмана:

    Не забывайте представиться и беречь нервы всех участников собеседования.

    «Расскажите немного о себе» - самый бесполезный вопрос для технического интервью.

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

    Фильтруйте информацию в резюме с длинным списком навыков. Отделяйте зерна от плевел.

    Не испытывайте новые вопросы на кандидатах. Тестируйте их на своих сотрудниках.

    Пусть кандидат напишет код на собеседовании! Почему так часто забывают это сделать?

    Остановитесь подробней на алгоритмах, структуре данных, организации и простоте кода.

    Задайте расплывчатые и двусмысленные вопросы. Посмотрите, попросит ли кандидат у вас уточнений.

    Задайте вопрос о дизайне продукта. Посмотрите, есть ли у соискателя общее представление.

    Определите основные ценности вашей компании. Убедитесь, что у соискателя осталось верное впечатление.

    Собеседование должно быть сложным, но не занудным. Хороший разработчик с удовольствием поговорит с умными ребятами.

Перевод: Люся Ширшова. По материалам статьи на

11 июля 2011 в 02:36
  • 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. Постарайтесь убрать все, что будет мешать вам четко говорить.
Это может показаться очевидным, но я все-таки упомяну - не надо жевать жевачку во время интервью. И кушать тоже не надо. Если у вас есть пирсинг в языке, который имеет обыкновение издавать цокающий звук когда вы говорите, то на время интервью его тоже лучше достать.

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

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

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

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

В чем заключается весь этот процесс

Просто небольшой обзор процесса, через который проходит средняя техническая компания при найме разработчиков:

  1. Предварительное собеседование по телефону (Phone Screen)
  2. Техническое собеседование
  3. Тестовое техническое задание
  4. Последующие собеседования, чтобы убедиться, что вы подходите (Fit Interviews)
  5. Предложение работы (Job Offer)
  6. Обсуждение условий предложения (Offer Negotiation)
  7. Принятие предложения (Offer Acceptance)

Предварительное собеседование по телефону

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

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

ФИНАЛЬНОЕ ПРИМЕЧАНИЕ - это не универсальный метод и многие компании пропускают его, чтобы сразу же нырнуть в глубины технического собеседования, поэтому вам нужно приготовиться просто на всякий случай. Ссылка ниже на Coding Horror самая иллюстративная для этого случая.

  • Добейтесь совершенства в телефонных собеседованиях от Monster
  • 7 шагов на пути к достижению вершин мастерства телефонного собеседования

Техническое собеседование

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

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

Решая задачу, убедитесь, что делаете это понятным и логичным способом, вслух поясняя, почему вы делаете тот или иной шаг. Проговорите все встреченные препятствия и приведите примеры того, как вы решили бы это в "реальном мире". Зачастую ответом является "погуглить" какую-то определенную функцию. Так и скажите! Они знают, что вы не эксперт Ruby, но они должны знать и то, что вы способны находить решения проблем, с которыми неизбежно столкнетесь на работе.

Также совершенно нормально, если вы используете брутфорс (brute force) - неэффективный метод - для решения задачи на написание кода. Это часто бывает лучшей отправной точкой для того, чтобы правильно прочувствовать проблему. Скорей всего вас спросят, как можно улучшить решение, но это намного лучше, чем пытаться придумать идеальное решение и не успеть ничего написать в итоге. Еще раз, ваша задача не в том, чтобы быть выдающимся кандидатом, а в том, чтобы показать, что вы способны адптироваться и не теряете голову, встречаясь с трудностями.

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

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

Ссылки

  • Разбиремся с собеседованием для программистов это ОБЯЗАТЕЛЬНЫЙ К ПРОЧТЕНИЮ МАТЕРИАЛ , который станет вашим лучшим другом. Он всесторонне рассматривает все виды задач, с которыми вы столкнетесь на собеседовании. Он выходит за рамки того, что мы уже изучили в этом курсе и затрагивает такие вещи, которые хорошо было бы знать, потому что скорей всего вы с ними встретитесь. Потратьте время на то, чтобы познакомиться с как можно большим количеством материала.
  • Interviewing.io дает вам шанс попрактиковать анонимно и онлайн техническое собеседование.
  • Как получить высшую оценку на техническом собеседовании
  • Как выделиться на следующем собеседовани на должность веб-разработчика
  • Прочитайте 40 ключевых концептов информатики, объясненных доступным языком
  • Руководство для развития технических навыков от Google (для продвинутых)

Тестовые задачи на программирование:

  • 8 королев - это классическая задача.
  • Программирование на собеседоваии: знай стандартные библиотеки может оказаться перебором для начинающего, но никогда не повредит, если вы найдете на него время.
  • На Project Euler вы найдете более обобщенные и сложные задачи, которые нужно эффективно решить (они могут потребовать большого объема вычислений).
  • На Coding Bat опубликованы практические вопросы для Java и Python.

Обучение алгоритмам:

  • Курс по алгоритмам от Udacity (несинхронизированны)
  • Курс по алгоритмам от Coursera (частично-синхронизированный)

Архитектура:

Техническое тестовое задание

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

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

Финальное собеседование ("Fit")

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

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

Немного о заработной плате

Не. Озвучивайте. Ваши. Зарплатные. Ожидания.

Вас всегда спросят "сколько вы хотели бы получать?" Ваш ответ? "Я хотел бы получать среднерыночную оплату" (если только вы не настолько наглы, чтобы просить выше рыночной. Посмотрим, как это у вас получится). Вы ничего не выиграете, назвав уровень желаемой зарплаты. Если она окажется ниже, чем они хотели вам предложить, они просто снизят этот уровень. А если выше, то они просто прервут весь процесс, решив, что вы слишком дороги для них.

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

© 2024 Новогодний портал. Елки. Вязание. Поздравления. Сценарии. Игрушки. Подарки. Шары