Пара советов к прохождению технических интервью. Техническое интервью с человеческим лицом
Сирадж Равал, разработчик, писатель и видеоблоггер, рассказывает как успешно пройти любое техническое собеседование в 5 шагов.
Я проходил через этот процесс дюжины раз в различных IT-компаниях, на моей памяти огромное число как отказов, так и предложений. И вот какие уроки я из этого извлек. Собеседование требует труда: не верьте тем, кто утверждает, что это должно быть легко. Это не так. Люди говорят только о своих успехах и никогда - о провалах.
Я выделил несколько шагов, которые позволят избежать многих ошибок и успешно пройти любое техническое собеседование.
Шаг 1. План подготовки
Учитесь. Еще до того, как вас посетит светлая мысль попытаться устроиться куда-нибудь работать, вы должны сконцентрироваться на прокачке своих технических навыков.
Процесс найма на позицию разработчика выглядит примерно одинаково во многих крупных компаниях. Как правило оно проходит в два этапа. Сначала рекрутер общается с соискателем по телефону, чтобы понять, насколько он заинтересован в их компании. При успешном прохождении первого этапа, за ним следуют 1-2 технических беседы со специалистами, в течение которых ему задаются сложные вопросы и задачи, которые он должен решить на доске. Он должен показать ход своих мыслей в процессе решения проблемы, найти подходящее решение, и тогда его наймут.
Единственный способ научиться этому - практика. Все мои друзья, работающие в крутых компаниях, очень много занимаются. Смысл здесь не в том, чтобы иметь выдающийся интеллект, а в том, чтобы усердно и продуманно трудиться.
Возникает вопрос, что именно надо практиковать? У вас не будут проверять знание синтаксиса какого-либо языка. При желании можно изучить основы синтаксиса Ruby за одну ночь. Но на что ночи не хватит, так это на основы фундаментальной информатики. А ведь на собеседовании у вас будут проверять именно знания структур данных и алгоритмов.
Начните с прохождения двух курсов:
введение в структуры данных (My Code School)
введение в алгоритмы (MIT Open Courseware)
Оба они находятся в открытом доступе и идеально подходят для того, чтобы получить базовые знания по этим разделам.
После этого можно закрепить полученные знания на HackerRank и HackerEarth . Эти ресурсы содержат огромное количество задач для оттачивания навыков программирования.
Порешав по паре дюжин задачек с обоих сайтов, прочтите книги «Технические интервью как они есть» и «Ломаем техническое интервью» . Они расскажут вам о многих специфических заданиях с реальных собеседований, начиная с задач по системному дизайну и заканчивая вопросами о времени и сложности.
Проделав все вышеприведенные ритуалы, начните репетировать собеседование с кем-нибудь из своих друзей. Попросите его задавать вам вопросы и отвечайте на них, используя только маркер и белую доску и объясняя вслух ход ваших мыслей. Я рекомендую заниматься этим в течение двух-трех месяцев по два-три часа в день.
Шаг 2. Найдите компании, которые вас интересуют
Если процесс подготовки к каждому собеседованию занимает два-три месяца, то, естественно, очень не хотелось бы тратить это столь драгоценное время на компании, которые не впечатляют вас.
Отслеживание процесса подготовки и прохождения собеседований в компаниях может быть довольно стрессовым делом, но пытайтесь оставаться организованным. Составьте список интересных вам компаний и отмечайте, на какой стадии находятся ваши отношения с каждой из них. Неплохими ресурсами для этого могут служить angel.co и Hacker News .
В этом есть нечто сверхъестественное. Вам придется напрячь все свои экстрасенсорные способности, чтобы понять, как эффективнее всего применить ваши навыки в желаемой сфере и найти компании, которые позволят вам сделать это.
Шаг 3. Составьте портфолио
Крупные компании получают сотни резюме в день, поэтому им просто необходимо отсеивать массу неинтересных им посредственностей. Как же выделиться из этой серой массы? Убедитесь, что все слова вашего резюме помещаются на одной странице, а само оно лаконично, но содержательно. Осветите в нем наиболее важную работу, выполненную вами.
Неплохая идея - иметь несколько резюме: по одному на каждую специальность или для каждой компании, куда вы пытаетесь устроиться. В портфолио разделите личные проекты, проекты с хакатонов, вливания в проекты с открытым кодом.
GitHub - прекрасное место не только для хранения вашего кода, но и как еще одно портфолио, которое может сослужить вам хорошую службу.
Сделайте своим лучшим веб-проектом собственный сайт-резюме. Постарайтесь, чтобы он выглядел стильно и профессионально и мог впечатлить потенциального работодателя.
Шаг 4. Получите приглашение на собеседование
Простейший способ - откликнуться на вакансию компании на специализированном сайте. Но крупные компании получают множество таких откликов ежедневно, и среди них очень легко затеряться. Хороший вариант - послать e-mail рекрутеру компании, сделав его кратким и емким. Включите в него краткий обзор того, кто вы есть и чем хотите заниматься, ссылку на легкодоступный и актуальный проект, а также выразите желание и готовность учиться и узнавать новое.
Настало время перейти к…
Шагу 5. Пройдите собеседование
Иногда интервьюер может нервничать больше, чем вы сами, и это нормально. Просто улыбайтесь, будьте вежливы, дайте понять, что вы понимаете его и готовы сотрудничать для достижения общей цели.
Решая технические задачи, не бойтесь рассуждать вслух. Помните, что от вас хотят именно этого: правильный ответ не столь важен, как правильный ход ваших мыслей. Когда соискатель выдает первое решение, рекрутер часто просит его найти более эффективные варианты. Здесь в игру должны вступить ваши знания информатики.
И не стесняйтесь задавать вопросы. Собеседующий призван помочь вам. И несмотря на то, что его основная цель - оценить ваши навыки, ему также важно попытаться найти с вами общий язык, сотрудничать с вами и помогать вам в достижении общей цели. Поэтому если вы пришли подготовленным, все будет хорошо.
Заключение
Подготовка к собеседованию и его прохождение - ответственный и трудоемкий процесс. Никогда, н и к о г д а, НИКОГДА не позволяйте отказам выбить вас из колеи. Прохождение интервью - это тоже большой опыт, даже если вас не наняли. Поэтому со временем вы достигнете высочайшего мастерства и сможете успешно пройти любое техническое собеседование. Главное - тренируйтесь, верьте в себя и не теряйте мотивации.
Я ожидала получить достаточно много вопросов по этой теме. Однако обратных вопросов – «Как его проходить?» - на почту и на форум «Лаборатории Качества» валилось значительно больше. Следуя спросу, продолжаю цикл ответной статьёй.
Введение
2. Протестируйте лифт!
Итак, Вы рассказали, что такое классы эквивалентности и граничные значения. Пришло время проверить, умеете ли Вы их использовать. И вот, Вас просят протестировать лифт. Или карандаш. Или калькулятор, джинсы, чашку. Неважно что. Задача – скорее всего непривычная и нестандартная. Что ждёт от Вашего ответа работодатель?
Способность мыслить творчески. Для тестеров это ого-го как важно. Я неоднократно встречала соискателей, которые на вопрос «протестируйте чашку» не могут придумать ни одного теста. Скорее всего, с тестированием нового компонента у них тоже возникнут проблемы.
Структуризацию. Если тестирование калькулятора начинается с деления на ноль, то соискатель скорее всего не умеет приоритезировать тесты и не очень хорошо понимает основных задач, возлагаемых на тестирование.
Умение использовать методики, которые в теории кажутся такими простыми. Если на лифте Вы планируете ездить с каждого этажа на каждый этаж – значит, понимание классов эквивалентности не ушло дальше теории.
Умение использовать все возможные виды тестирования. Нагрузочное тестирование лифта (вызвать со всех этажей), объёмное тестирование чашки (налить в неё максимум воды), производительность калькулятора при операции сложения, юзабилити джинсов и пользовательская документация на карандаш – лучшие способы показать, что Вы «в теме».
Правильный ответ на подобный вопрос следует из описанных выше требований к ответу. Структурируйте информацию. Узнайте максимум о тестируемом объекте. Определите, что вы будете проверять в рамках функционального и нефункционального тестирования. Подумайте, как Вы можете оптимизировать набор тестов, чтобы не проверять всё подряд. И ни в коем случае не начинайте свой ответ с конкретных тестов – мартышкин труд отличается от грамотного тестирования предварительным продумыванием своих действий.
3. Расскажите, как создавать тест-кейзы
Или как написать тест-план, как создать фреймворк автоматизации тестирования или что-либо ещё. Самое худшее, что Вы можете сделать при ответе на этот вопрос – пытаться сделать вид, что Вы умеете делать что-то, когда на самом деле этого никогда не делали. Если тема Вам хорошо знакома, и Вы знаете, как отвечать – флаг в руки! Если же Вы не уверены в правильности своих мыслей – обязательно предупредите об этом собеседующего фразой вроде «Я никогда этого не делал, но мне кажется правильным следующая последовательность действий…». Искренность всегда подкупает, а ошибки в ответе не будут восприниматься строго. Если же Вы будете рассказывать «правильный» подход, не будучи в нём уверенным, и наговорите глупостей – врядли кто-то захочет брать Вас на работу.
4. Зачем вообще нужно тестирование?
Я не буду давать длительных советов по этому вопросу – или напишу отдельную статью. Просто убедитесь, что Вы знаете, как отвечать на этот философский вопрос.
5. Как определить качество продукта?
Этот вопрос, как и предыдущий, тоже распространён достаточно часто. Google поможет Вам быть к нему готовым.
Технические вопросы.
В мои планы в рамках этой статьи не входят рассказы про настройку DNS и запросы к базам данных. Но есть некие общие советы, которых стоит придерживаться:
1. Не пытайтесь сделать вид, что знаете что-то, если Вы этого не знаете.
Во-первых, нехватка технических знаний быстро компенсируется и работодатели редко уделяют очень серьёзное внимание этому вопросу. Во-вторых, неудачно скрываемое незнание всегда вызывает недоверие: можно ли верить остальным словам кандидата? А в-третьих, потенциальный работодатель может разделять моё мнение о том, что защищающие неправильную точку зрения люди чаще допускают ошибки в работе. По крайней мере, сотрудника, который хорошо разбирался в тестировании, но старательно доказывал что «в Windows нет поддержки динамических дисков», я на работу не взяла. Скорее всего, если бы он честно признался, что не знает, что это такое, решение было бы другим.
2. Если видите, что не очень удачно ответили на предыдущие вопросы – инициируйте ответы сами, но по темам, которые знаете лучше.
К примеру, если Вы неудачно ответили на вопрос про MS SQL, скажите сами, что зато Вы имеете опыт работы с Oracle и поэтому быстро сможете «перепрофилироваться».
Способность быстро и самостоятельно разобраться в незнакомой технологии или инструменте ценятся выше, чем имеющиеся знания. Не стесняйтесь хвалить себя. Если после Ваших слов о том, что Вы не разбираетесь в Rational Robot, собеседующий немного поник – гордо скажите, что зато в Silk Test Вы разобрались всего за неделю и сумели многое (конкретизируйте) в нём сделать. Естественно, здесь тоже говорить нужно правду!
Заключение
Главное – не бояться. Вы ищете работу, а работодатель ищет грамотного сотрудника. Вы оба заинтересованы в результате. Быть принятым на неподходящую работу – значительно хуже, чем получить отказ. Пробуйте, не нервничайте, учитесь! И развивайтесь для себя – а не для «галочки» на собеседовании. Удачи !
Собеседование находится на верхних позициях в рейтинге самых больших страхов большинства людей, наряду с публичными выступлениями. Вы не только выступаете перед кем-то, но вас еще и постоянно оценивают все это время... бррр!
Конечно, мы далеки от того, чтобы пытаться разобраться с вашими психологическими барьерами и преодолеть их, но совершенно точно лучше всего было бы рассматривать собеседования как шанс показать все те классные вещи, которые вы создали, и те интересные новые навыки, которые вы освоили. Лучшие собеседования - это полные энтузиазма разговоры с техническим уклоном.
Первым шагом перед всем этим будет подготовка. Вы наверняка захотите обдумать возможные вопросы (и наиболее распространенные на них ответы, которые подчеркнут вашу гениальость), а также изучить компанию-работодателя. Ваши знания о компании помогут вам преподнести себя так, что это будет соответствовать их потребностям, а также позволят вам задавать умные вопросы об их продуктах и технологиях, когда придет время. Еще раз, обратитесь к статье Happy Bear за практическими советами.
В чем заключается весь этот процесс
Просто небольшой обзор процесса, через который проходит средняя техническая компания при найме разработчиков:
- Предварительное собеседование по телефону (Phone Screen)
- Техническое собеседование
- Тестовое техническое задание
- Последующие собеседования, чтобы убедиться, что вы подходите (Fit Interviews)
- Предложение работы (Job Offer)
- Обсуждение условий предложения (Offer Negotiation)
- Принятие предложения (Offer Acceptance)
Предварительное собеседование по телефону
Поздравляем! Ваше резюме оказалось не самым катастрофичным и вас пригласили на телефонное собеседование (обратите внимание, иногда вы сначала делаете тестовое задание). Истинная цель этого этапа, которое зачастую представляет собой получасовой разговор с кем-нибудь из отдела кадров (а не с лицом, которое принимает решение о найме персонала), это удостовериться, что у вас есть неплохие шансы пройти остальные этапы собеседования. Поэтому рассматривайте его, как облегченную версию других этапов.
Возможно вас спросят о некоторых технических вещах, которые вы указали в своем резюме, но не углубляйтесь в дебри (хотя некоторые работодатели задают достаточно заковыристые задачки), а еще вам скорей всего зададут и более "легкие" вопросы о том, почему вы выбрали эту работу и что вы делали раньше. Телефонные собеседования могут сильно отличаться от компании к компании. Основная тактика здесь - это вовсе не тактика, просто будьте честным, энергичным и открытым. И не бойтесь практиковать разговоры о самом себе перед зеркалом.
ФИНАЛЬНОЕ ПРИМЕЧАНИЕ - это не универсальный метод и многие компании пропускают его, чтобы сразу же нырнуть в глубины технического собеседования, поэтому вам нужно приготовиться просто на всякий случай. Ссылка ниже на Coding Horror самая иллюстративная для этого случая.
- Добейтесь совершенства в телефонных собеседованиях от Monster
- 7 шагов на пути к достижению вершин мастерства телефонного собеседования
Техническое собеседование
Техническое собеседование - это обычно самая страшная часть процесса отбора. Это то, где будут оценивать, есть ли у вас необходимые технические навыки. Это означает, что будут не только очень подробно спрашивать о ваших работах, но также попросят решить логические задачи или прямо там написать код или набросать схему каких-то новых компонентов.
На самом деле, одна из цель такого собеседования подвести вас к самому краю ваших возможностей, чтобы просто увидеть вашу реакцию на незнакомые вещи. Если вы выполняете упражнение слишком легко, они перейдут к гораздо более сложному. Всегда найдется, где споткнуться, особенно новичкам. Самый большой ваш актив - это честность и любознательность.
Решая задачу, убедитесь, что делаете это понятным и логичным способом, вслух поясняя, почему вы делаете тот или иной шаг. Проговорите все встреченные препятствия и приведите примеры того, как вы решили бы это в "реальном мире". Зачастую ответом является "погуглить" какую-то определенную функцию. Так и скажите! Они знают, что вы не эксперт Ruby, но они должны знать и то, что вы способны находить решения проблем, с которыми неизбежно столкнетесь на работе.
Также совершенно нормально, если вы используете брутфорс (brute force) - неэффективный метод - для решения задачи на написание кода. Это часто бывает лучшей отправной точкой для того, чтобы правильно прочувствовать проблему. Скорей всего вас спросят, как можно улучшить решение, но это намного лучше, чем пытаться придумать идеальное решение и не успеть ничего написать в итоге. Еще раз, ваша задача не в том, чтобы быть выдающимся кандидатом, а в том, чтобы показать, что вы способны адптироваться и не теряете голову, встречаясь с трудностями.
А если вы чего-то не знаете, лучше честно это сказать и попробовать обдумать это вместе с проводящим собеседование. Поверьте мне, они так же, как и вы, хотят, чтобы вы добились успеха, потому что нет ничего хуже для интервьюера, чем видеть то, как кто-то молча пытается решить задачу, все больше и больше заходя в тупик, при этом не прося помощи и не давая понять, о чем он думает.
Вам придется прочитать о большом количестве вещей, на которых не было акцентировано внимание в предыдущих курсах, например, структуры данных и алгоритмы, просто потому что о них очень любят спрашивать на собеседованиях. Они не всегда хорошо отражают навыки программирования, но так уж сложилось, что вам придется отвечать на вопросы, которые относятся к более академической области компьютерных знаний.
Ссылки
- Разбиремся с собеседованием для программистов это ОБЯЗАТЕЛЬНЫЙ К ПРОЧТЕНИЮ МАТЕРИАЛ , который станет вашим лучшим другом. Он всесторонне рассматривает все виды задач, с которыми вы столкнетесь на собеседовании. Он выходит за рамки того, что мы уже изучили в этом курсе и затрагивает такие вещи, которые хорошо было бы знать, потому что скорей всего вы с ними встретитесь. Потратьте время на то, чтобы познакомиться с как можно большим количеством материала.
- Interviewing.io дает вам шанс попрактиковать анонимно и онлайн техническое собеседование.
- Как получить высшую оценку на техническом собеседовании
- Как выделиться на следующем собеседовани на должность веб-разработчика
- Прочитайте 40 ключевых концептов информатики, объясненных доступным языком
- Руководство для развития технических навыков от Google (для продвинутых)
Тестовые задачи на программирование:
- 8 королев - это классическая задача.
- Программирование на собеседоваии: знай стандартные библиотеки может оказаться перебором для начинающего, но никогда не повредит, если вы найдете на него время.
- На Project Euler вы найдете более обобщенные и сложные задачи, которые нужно эффективно решить (они могут потребовать большого объема вычислений).
- На Coding Bat опубликованы практические вопросы для Java и Python.
Обучение алгоритмам:
- Курс по алгоритмам от Udacity (несинхронизированны)
- Курс по алгоритмам от Coursera (частично-синхронизированный)
Архитектура:
Техническое тестовое задание
Тестовое домашнее задание может возникнуть как перед, так и после личного собеседования, в зависимости от компании. Вам дадут задание, которое потребует на выполнение полный день в любое удобное для вас время. Примерами такого задания могут быть создание образца веб-приложения с тестами или решение сложной алгоритмической задачи с написанием кода.
Оценка будет производиться по полноте решения и качеству вашего кода. Если это происходит до технического собеседования, то оно является хорошим методом проверить вашу заинтересованность (до половины соискателей даже не возвращаются с решением).
Финальное собеседование ("Fit")
Последним шагом перед принятием решением обычно является знакомство с командой и офисами в течение нескольких часов. Возможно, вас проверят технически, но основная цель - это удостовериться, что вы будете хорошим коллегой. Если какой-то другой член команды скажет, что вы не сработаетесь, вас скорей всего не возьмут. Совет? Не нужно быть странным или неловким, даже если вы дома:)
Это также возможность и для вас. Если вы зашли так далеко, что дошли до этого шага, велика вероятность, что в целом вы подходите. Вам нужно обдумать, хотите ли вы работать в этой компании, поэтому подготовьте список вопроов и получите на них ответы.
Немного о заработной плате
Не. Озвучивайте. Ваши. Зарплатные. Ожидания.
Вас всегда спросят "сколько вы хотели бы получать?" Ваш ответ? "Я хотел бы получать среднерыночную оплату" (если только вы не настолько наглы, чтобы просить выше рыночной. Посмотрим, как это у вас получится). Вы ничего не выиграете, назвав уровень желаемой зарплаты. Если она окажется ниже, чем они хотели вам предложить, они просто снизят этот уровень. А если выше, то они просто прервут весь процесс, решив, что вы слишком дороги для них.
Как только вы получите предложение, вы можете проверить, насколько оно соответствует среднему рыночному уровню оплаты, опросив нескольких человек (надеемся, что у вас уже есть несколько знакомых, которых можно спросить) или сходив на сайт Glassdoor (просто помните, что вы - начинающий, а значит вы не будете получать "среднюю" зарплату). Самое главное, это не навредить самому себе, когда вас спрашивают.
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. Постарайтесь убрать все, что будет мешать вам четко говорить.
Это может показаться очевидным, но я все-таки упомяну - не надо жевать жевачку во время интервью. И кушать тоже не надо. Если у вас есть пирсинг в языке, который имеет обыкновение издавать цокающий звук когда вы говорите, то на время интервью его тоже лучше достать.
Ну и самое главное - вопрос, который интервьюер себе сознательно или подсознательно задает это «Хотел бы я работать в одной команде с этим человеком?». И ответ на этот вопрос складывается не только из знаний и умений кандидата, но и из способности ясно и четко излагать свои мысли, способности слушать и еще многих других мелочей.
Не стоит ожидать, что я смогу ответить на вопрос, который остается открытым для компаний с многомиллионными бюджетами на рекрутинг. Чтобы понять, насколько сложен вопрос подбора хороших специалистов, достаточно посмотреть на разнообразие подходов, которые используют мировые гиганты разработки ПО.
Для чего мы проводим собеседование? Мы хотим найти кандидата, который бы подходил под наши требования «подходящего» разработчика. Но поскольку мы не можем взять человека и посадить его на три недели за решение наших текущих задач, мы придумываем некую модель, соответствие которой означает, что кандидат нам подходит.
При этом «модели» используются самые разные. В гугле когда-то считали, что человек, который сможет ответить на вопрос: сколько шариков для гольфа влезет в багажник 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 позиции.
Поскольку отечественный рынок является "перегретым", то интересное техническое интервью может играть дополнительную положительную роль: с его помощью вы можете показать кандидату, что он будет работать в интересном коллективе, что перевесит чашу весов в вашу сторону.
З.Ы. Если так уж случилось, что вы были на моих собеседованиях (Земля ведь квадратная;), будет интересно услышать ваше мнение о нем.
