09.07.2016

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

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

Чит-коды для победы 4 боссов, которых вы, возможно, встретите в квесте на получение должности нового разработчика программного обеспечения

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

Конечно, если вы очень талантливый и творческий человек, вас могут принять быстрее, чем обычно. Процесс может ускориться и в том случае, когда компании срочно нужен сотрудник.

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

Секундочку, что за супер-квест? Что за уровни? Похоже на компьютерную игру, не так ли?

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

Главному игроку (например, Марио, Зельде или Дюку Нюкему) нужно победить всех боссов в игре, чтобы пройти на следующий уровень: совсем как менеджеров в IT-компаниях.

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

- специалист по набору персонала;
- старший разработчик;
- менеджер по программному обеспечению;
- CTO.

Готовы? Отлично! Начинаем со схватки со специалистом по набору персонала из отдела кадров на первом уровне.

1 уровень: Босс, специалист по набору персонала

Босс из отдела кадров обладает следующими характеристиками:

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

Дженифер Лоффус, региональный директор компании Astron Solutions, бывший президент ассоциации специалистов по работе с персоналом Нью-Йорка.

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

Существует мнение, что у кадровиков только одно желание - заваливать кандидатов на новую должность. Помните Тоби из сериала «Офис»? Так вот, его образ специалиста отделов кадров сильно приукрашен.

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

Чтобы пройти на первый уровень собеседования с сотрудником отдела кадров избегайте следующих ошибок:

Не высылайте резюме с ошибками

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

Не высылайте слишком длинное резюме

Вы многого добились в карьере и хотите об этом рассказать. А кадровик хочет понять, подходите ли вы на конкретную позицию, при этом у него очень мало времени на знакомство с вашим резюме. Отредактируйте свое резюме так, чтобы оно подходило именно на ту вакансию, на которую вы его подаете. Резюме должно содержать 500 - 1000 слов и быть длиной максимум в две страницы. Используйте 12 шрифт, чтобы текст было удобно читать (а не 8 или 9).

Не высылайте общих резюме и мотивационных писем

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

Вас пригласили на собеседование с сотрудником отдела кадров!

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

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

Приходите заранее и хорошо подготовленным

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

Оденьтесь в официальном стиле

Для мужчин обязателен деловой костюм с галстуком, для женщин брючный костюм или пиджак с юбкой. Если вы претендуете на творческую позицию в молодой фирме, классический стиль может не подойти. Уточните дресс-код у кадровика.

Приведите себя в порядок

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

Сосредоточьтесь!

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

Почти 2 уровень!

Проверьте, что вы правильно одеты, приятно пахнете и полностью настроились на собеседование. И вот вы на финишной прямой 1 уровня! Помимо того, что вы обладаете всеми навыками и опытом, нужными для данной должности, необходимо…

Поддерживать зрительный контакт

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

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

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

Приготовьтесь рассказать о прошлых работодателях

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

Говорите понятными словами

Программные разработчики используют много аббревиатур: ASP, CAO, GAC, IIS и т.д. Во время беседы с кадровиком (возможно, без технического образования), расшифровывайте каждую аббревиатуру, когда будете называть ее в первый раз. Убедитесь, что вы говорите понятным для собеседника языком, чтобы не провоцировать новые вопросы.

Задавайте вопросы

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

- Что вам больше всего нравится в организации?
- Почему вы здесь работаете? Люди любят рассказывать о себе!
- Каким образом информационные технологии поддерживают планы компании по развитию?
- Какие ошибки обычно допускают новые сотрудники?

Скажите «спасибо»

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

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

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

Тэги:

Привет всем, Джаварашовцы! Так уж случилось, что недавно я проходил собеседование и хотел бы рассказать, какие вопросы мне задавали предполагая, что идет позиция Junior++. Т.е. еще не мидл, но уже и не зеленый джун. Так вот, собеседование проходило по такому плану

1. JavaCore
2. Базы данных.
3. Инструменты, которыми пользуешься.

JavaCore

Вначале меня попросили нарисовать иерархию интерфейсов у Коллекций (это было не сложно, там всего их несколько (Collection , List , Set , Queue , Map).

В чем различие ArrayList и LinkedList (это один из самых заезженных вопросов и ответов в инетах просто тьма).

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

Вопрос про класс Object . Какие у него методы, что они делают.

Рефлексия. Что делает метод getClass() . Очень интересный вопрос, разберите его. Особенно про то, как получить всё про класс, пусть даже там приватные методы или переменные.

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

Что можешь сказать про Stream . Это имеется в виду не про Java 8. Имеется в виду потоки ввода и вывода. Как базовые интерфейсы, какие они (символьные и байтовые). На понимание, никакой конкретики.

• Исключения. Здесь опять-таки попросили нарисовать иерархию исключений, какие бывают, какие из них checked , а какие unchecked . Что нужно делать с Runtime исключениями. Назовите самое часто попадающее (NullPointerException).

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

ООП

Что такое ООП в двух словах?

Какие еще есть парадигмы программирования? В чем их различие от ООП

Какие основные принципы ООП (наследование,полиморфизм и инкапсуляция)? Рассказать про каждый из них. Пока всё абстрактно, не привязываясь к какому-то языку.

Задача на понимание проектирования систем: есть Лошадь и Птица. Нужно получить Пегаса. принцип "has a" и "is a"

REST

Что такое REST. В Википедии об этом говориться очень круто. Реально статьи из Википедии для ознакомления хватит.

HTTP. Здесь тоже общие фразы. Его методы, для чего каждый из них.

Коды состояния HTTP. На какие пять частей делиться, расскажите про самые известные (200,204,404,500,501). Зачем они. Спросили еще про 401 и 403. Но я не знал их. Сказали они важные.

Базы данных

Здесь я рассказал, что знаю MySQL. Рассказал про три нормальные формы. Рассказал про Join"ы, какие бывают и нарисовал пересечение областей, в котором используются разные джоины. Рассказал про то, как я понимаю реляционную БД. Не забыл еще о про MongoDB - это NoSQL база данных. Через некоторе время я напишу и про это.

Другие инструменты

Здесь мы прошлись по моем резюме. У меня было написано, что использую Maven/Gradle для сборки, использую JIRA для тасков, git, Docker, Swagger. Для Continuous Integration - Stash, Bamboo, Puppet. Для тестирования JUnit , Mockito, JMeter. Я мог что-то забыть, поэтому если интересно - спрашивайте в комментариях постараюсь ответить. Это была первая часть собеседования. Теперь жду результаты и если да, то будет вторая часть. Напишу о ней как только так сразу. Всем кому статья понравилась и была полезна - ставьте "+". Пишите в комментариях. См. также мои другие статьи: 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. Постарайтесь убрать все, что будет мешать вам четко говорить.
Это может показаться очевидным, но я все-таки упомяну - не надо жевать жевачку во время интервью. И кушать тоже не надо. Если у вас есть пирсинг в языке, который имеет обыкновение издавать цокающий звук когда вы говорите, то на время интервью его тоже лучше достать.

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

Фахима Уль Хоку, одного из учредителей платформы Educative.

Подборка нескольких наиболее распространённых ошибок, совершаемых кандидатами при прохождении технического интервью.

Как не провалить техническое собеседование

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

Основываясь на собственном опыте, я выделил 5 самых распространённых ошибок, которые совершают кандидаты при прохождении интервью.

1. Вы тратите слишком много времени на описание своих прошлых и текущих проектов

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

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

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

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

Запомните два момента:

• Как бы вы ни хитрили, задачу на собеседовании вам всё равно придётся решать, но теперь у вас на 10 минут меньше времени на её решение.
• Почти не считается. Вас не наймут, если вы не успели решить задание, но вам «осталось совсем чуть-чуть». Такого попросту не бывает.

Куда бы вы ни шли на интервью, всегда будьте готовы сказать пару слов на следующие вопросы:

1. Над каким проектом вы работаете в данный момент?
2. Какой аспект вашего текущего проекта вызвал у вас наибольшие затруднения?
3. Расскажите о самом сложном баге, с которым вам приходилось иметь дело, за последние полгода.

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

2. Вы неправильно поняли формулировку задачи

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

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

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

Я попытался обратить всё в шутку и сказал, что сейчас напечатаю полученный список, и затем ещё раз поменяю порядок на обратный. Я объяснил ему, почему я так бурно отреагировал на эту задачу, и мы оба рассмеялись. Если я не ошибаюсь, в итоге я всё-таки прошёл на следующий этап отбора.

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

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

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

А теперь попробуйте выйти к доске и написать 20 строчек кода. Это займёт у вас минуты 2-3, не больше. Следовательно, даже если вы и потратите 30 минут на решение задачи, у вас ещё останется пара минут для написания готового решения.

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

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

4. Сначала вы находите наиболее очевидное решение, а затем начинаете оптимизировать алгоритм

Суровая правда. На собеседованиях от вас ожидают вполне конкретных знаний, поэтому при решении задач подразумевается, что вы уже неплохо знакомы с этой темой и знаете оптимизированный алгоритм. Все вышеперечисленные пункты указывали на то, что не в ваших же интересах тратить время. Поэтому как следует подумайте над решением и над тем, как его можно было бы оптимизировать. Если требуется решение с линейной временной сложностью и требуемым объёмом памяти О(1), то любое решение ниже по производительности приведёт к тому, что вас не возьмут.

5. Вы не проверяете своё решение

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

Бонус: Спрашивать, как вы прошли интервью

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

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

У Вас есть продукт, устоявшаяся команда и финансирование. Вы (команда) хорошо работали, и руководство готово заплатить еще денег чтобы нанять человека, чтобы, соответственно, ускорить разработку, повысить качество и иметь возможность тратить ресурсы на технологическое развитие продукта. Вы уже разместили на hh объявление с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать. Знакомая ситуация? Тогда добро пожаловать под кат.

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

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

Итак, Вы набросали несколько портретов «идеальных» кандидатов. Настала пора провести техническое собеседование. Кстати, надеюсь в Вашей компании именно техническое собеседование влияет на решение о найме сотрудников? Часто говорят о компании как о «семье» или о «коллективе где приятно проводить время». Так вот, компания это все таки не семья. И не друзья с которыми вы ходите в боулинг. Конечно, если человек болен клептоманией или проказой то брать его на работу опасно, даже если он лучше всех прошел техническое собеседование. Но не стоит слишком зацикливаться на личных качествах. В принципе, до или после технического собеседования необходимо выяснить, не выкинет ли человек какой-то фокус, и в этом смысле такое «не техническое» собеседование будет иметь роль «порога» - тот кто его не пройдет в компании точно работать не будет, а если пройдет - то не имеет значения будет ли он «душой компании» или просто добросовестным работником. Но это и все, собственно, все остальные решения должны определяться именно техническим собеседованием. Если в вашей компании HR донимают кандидатов вопросами об их карьерных устремлениях и «кем они видят себя через 10 лет» или «почему компания должна нанять вас», то вам еще рано искать технических специалистов. Для начала вам надо найти нового HR.

Но что же спросить на техническом собеседовании? Составить тест? Выяснить что человек делал на прошлом месте работы? Задать каверзный вопрос? Дать задачку с braingames.ru?
Давайте рассмотрим эти варианты по порядку.

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

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

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

Итого - что мы узнали? Да ничего. Какой-то сложный проект. Толком не понятно что за проект, что именно делал этот сотрудник, что он в итоге научился делать хорошо. Мы промотали 5 минут на то, чтобы не выяснить о человеке ничего. Конечно, можно потратить полчаса и разобрать все по полочкам. Но есть два «но».
Во-первых, цените время. Если на каждого кандидата будете тратить по 4 часа, то вы можете просто «не дойти» до действительно стоящего. Вообще, на мой взгляд, собеседование стоит жестко ограничить временными рамками, скажем одним часом. И постараться вытрясти за этот час из человека все, что Вам необходимо для принятия решения.
Во-вторых, не зацикливайтесь на том, кем человек был. Попробуйте оценить, кем бы он мог стать в вашей компании. Ваш кандидат говорит, что на прошлой работе сделал за неделю модуль, который Вы делали месяц? Так может на прошлой работе крутые бизнес процессы и гора готового кода, а у вас он бы делал этот модуль ровно столько же, сколько и Вы? Или Вам показалось, что на прошлой работе кандидат не сделал ничего сколько-нибудь примечательного? Очень может быть. Но может это талантливый человек, прозябавший в третьесортных «рогах и копытах», а у Вас раскроется весь его потенциал! Поверьте, во многих ситуациях за такого человека стоит побороться даже больше, чем за состоявшегося специалиста.

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

- Ну это адрес объекта

И второй вариант:

Что такое Object.hashCode()?
- Да там генератор случайный чисел, вот он и возвращает.

Вы потратили 3 минуты на этот вопрос. Как вы сравните первого и второго кандидата? Можно ли сказать, что один из них лучше другого? Может быть второй листал на досуге grepcode. Или читал хабр вместо работы. А может и не вместо. Но вам-то это что-то говорит?

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

Так что же спросить?

Мне кажется, лучше всего вести беседу, в ключе того чем Вы обычно занимаетесь и смотреть, как кандидат решает задачки которые Вы часто решаете.
Скажем в Вашем приложении есть UI-логика и серверный код. Спросите у кандидата, что, как ему кажется, интереснее.
Серверный код? Отлично. Давайте представим какой-нибудь типичный кусок кода в Вашей программе. Нам интересно, какие вопросы возникают у кандидата, и как увязывает он теоретические знания с практическими потребностями.
Скажем такая задачка:

Есть фрагмент кода

void x(List a)

…Some processing

Вопрос кандидату - предположим в этом коде нам надо перед «Some processing» отсортировать список в алфавитном порядке. Что будете делать? Кстати да, тут же можно сказать кандидату про Collections.sort - мы же не «словарный запас» проверяем.
Положим наш кандидат написал что-то типа

void x(List a)

List b = new ArrayList(a);

Collections.sort(b);

…Some processing with b

(надеюсь наш кандидат именно так решил эту задачу а не начал сортировать a).

Однако решение задачи тут не главное. Главное дискуссия.
Почему он создал новый список а не использовал старый? Всегда ли это правильно?
Почему использовал ArrayList а не что-то еще? А знает ли он что еще есть?

Самое интересное что дискуссия тут может быть почти бесконечная. Кандидат скажет что ArrayList лучше тем что он random access, а Вы скажите что sort все равно копирует перед сортировкой данные в массив, а потом возвращает обратно. Стал ли ArrayList лучше теперь, по мнений кандидата? Как, уже нет? Или все равно лучше?

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

Или скажем другой пример.

Не спрашивайте «что такое garbage collector». Не спрашивайте «сколько там поколений». Какая разница сколько. Какая разница может или нет человек рассказать как устроен gc - для вашей работы может быть важно только то, сможет ли человек исправить performance проблему если таковая возникнет, а не может ли он поведать душещипательную историю про сборку поколениями или там про concurrent mark sweep gc.
Я не говорю, что кто-то может решать сколько-нибудь интересные проблемы с GC не зная, как он работает. Один раз, конечно, может и повезет. Но на практике знание чрезвычайно важно. Проблема в другом - не каждый, кто может рассказать как что-то работает, может исправить проблему с этим чем-то. И, вообще говоря, интуиция, общая техническая подкованность часто для решения задачи важнее прочитанного где-то описания алгоритма.
Например, для gc хорошо будет привести опять же какую-нибудь практическую задачку.
Скажем, «вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?».

Увеличу хип

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

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

• Подбор и отбор, Оценка, Рынок труда, Адаптация