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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HR-команда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сирадж Равал, разработчик, писатель и видеоблоггер, рассказывает как успешно пройти любое техническое собеседование в 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 Вы разобрались всего за неделю и сумели многое (конкретизируйте) в нём сделать. Естественно, здесь тоже говорить нужно правду!

Заключение

Главное – не бояться. Вы ищете работу, а работодатель ищет грамотного сотрудника. Вы оба заинтересованы в результате. Быть принятым на неподходящую работу – значительно хуже, чем получить отказ. Пробуйте, не нервничайте, учитесь! И развивайтесь для себя – а не для «галочки» на собеседовании. Удачи !