Вот уже прошло почти полтора года, как я в поисках работы посещал собеседования в разных компаниях, после чего мною была написана статья Нужны ли логические задачи на собеседованиях?. И вот совсем недавно мне самому пришлось набирать команду программистов и проводить с ними собеседования. Как вы могли бы догадаться, собеседования без задач на логику. ;)

Так получилось, что через некоторое время в компании на проекте остался всего один программист — и это был я. Необходимо было в кратчайшие сроки воссоздать команду. Проведение собеседования доверили мне.

Цель: найти 2-х программистов, один должен быть опытным, другой начинающим.

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

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

Пришлось быстро вспомнить какие вопросы задавали мне на собеседованиях, поискать по интернету и т.д. В общем кое-как я подготовил 7 вопросов. 3 вопроса, на мой взгляд, были вообще элементарными, 2 — довольно простыми при наличии опыта, еще 2 — SQL-запросы, не из самых легких.

Итак, начали собеседование, я дал 15 минут на подготовку ответов на вопросы. По истечении этого времени кандидат дал 3 правильных ответа из 7 — 1 из категории элементарных, 2 из категории «простые при наличии опыта».

Такие ответы не давали полного понимания о знаниях человека. Вроде бы ответил на вопросы, которые должны были показать его опыт, но не ответил на 2 из 3-х элементарных вопросов. А что с SQL? Ответы были неправильными, но и вопросы не из легких.

Очевидно, что мною были неправильно подготовлены вопросы, они не позволяли понять знания кандидата. К слову сказать, в этот же день приходил еще один соискатель, с ним была примерно та же история — правильно ответил на 2 простых вопроса и 1 на проверку опыта.

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

Я решил, что все вопросы нужно разделить на несколько частей:

  1. Пара простейших вопросов, с которыми справится любой программист.

    2. Чтобы сразу же выявить тех, кто по своим знаниям нам точно не подходит. Должен сказать, что из всех собеседуемых таких оказалось 3 человека. С ними я сразу прощался, не переходя к более сложным вопросам.

  2. Вопросы, на которые ответит любой программист с опытом.

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

  3. Немного теории и вопросы по проектированию.

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

  4. Несложные SQL-запросы.

    5. Ну и немного поломать мозг. Но только совсем слегка. Эта часть вопросов на составление SQL-запросов, все запросы довольно простые и при знании операторов SQL решаются быстро. Также здесь можно понять на сколько правильно человек выбирает методы решения — при незнании каких-то возможностей SQL, некоторые начинали составлять мегазапросы с огромным количеством подзапросов, join’ов и т.д.

  5. Вопросы не для всех.

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

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

По началу после 1-2 собеседований я корректировал часть вопросов — некоторые вопросы были не понятны соискателям (криво составлены мной), некоторые я просто заменял, считая, что новые лучше подойдут для собеседования. В результате у меня сформировался список вопросов, с которым я ходил на каждое собеседование.

Для начала человек должен был ответить на 2 простых вопроса из 1-й части:

  1. jQuery
    • выбрать элементы с атрибутом id=”myID”
    • выбрать элементы с атрибутом class=”myClass”
    • выбрать все input’ы с атрибутом id=”myID”, которые находятся внутри <div class=”myClass”>
  2. Javascript

    Необходимо выполнить команду alert(’!’) перед отправкой данных формы нажатием кнопки “ОК”.

    Какой из перечисленных фрагментов кода позволит решить поставленную задачу?

    • 1
2
3
4

       <FORM ACTION="test.pl" onSubmit="alert(’!’)">
<INPUT TYPE="text" NAME="txt">
<INPUT TYPE="submit" VALUE="OK">
</FORM>
    • 1
2
3
4

      <FORM ACTION="test.pl">
<INPUT TYPE="text" NAME="txt">
<INPUT TYPE="button" VALUE="OK" onClick="alert(’!’);this.submit()">
</FORM>
    • 1
2
3
4

      <FORM ACTION="test.pl">
<INPUT TYPE="text" NAME="txt">
<INPUT TYPE="submit" VALUE="OK" onSubmit="alert(’!’)">
</FORM>
    • 1
2
3
4

      <FORM ACTION="test.pl" onBeforeSubmit="alert(’!’)">
<INPUT TYPE="text" NAME="txt">
<INPUT TYPE="submit" VALUE="OK">
</FORM>

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

  3. Memcached. Что это такое? В каких случаях применяется?

    4. Здесь я также просил рассказать соискателя вообще о кэшировании: как устроена система кэширования? Что обычно кэшируют? Когда кэширование не применимо?

    Подавляющее большинство было знакомо с кэшированием, но никогда не слышали про memcached, и рассказывали о хранении кэша в файлах. В основном соискатели использовали кэширование только результатов SQL-запросов.

  4. Что такое паттерн проектирования singleton и как он реализуется?

    5. Стандартный ответ на этот вопрос был такой: «Я слышал про singleton, применяется в ООП, но как реализуется и для чего нужен не помню». Примерно каждый 4-й полностью отвечал на этот вопрос.

  5. Командная строка *nix. Напишите команду, которая убьет все процессы, начинающиеся на «proc».

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

  6. Зачем нужен HAVING в SQL?

    7. Для меня это было удивительно, но на этот вопрос правильно ответили лишь человека 2-3. Когда я включал этот вопрос в свой список, у меня были сомнения нужен ли он вообще, но, как оказалось, очень даже нужен и показывает опыт работы с SQL.

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

  7. Что такое нормализация БД? Что такое денормализация БД? Для чего она нужна?

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

  8. Расскажите о способах хранения деревьев в таблице? Например, когда нужно реализовать древовидные комментарии к статье.

    9. Большинство отвечали стандартно — у каждого комментария есть поле parent_id и т.д. Некоторые были знакомы с различными методами хранения деревьев, а были люди, которые прямо на собеседовании придумывали эти методы.

    Далее следовали вопросы по составлению запросов SQL. Я не задавал ни одного сложного запроса, все они были простые, для правильного ответа требовалось только знание SQL.

  9. Имеется таблица пользователей следующей структуры: 
    1
2
3
4
5

    CREATE TABLE users ( 
id INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY ,
username CHAR(16) NOT NULL,
city_id INT(11) NOT NULL 
);
    • id – целочисленный первичный ключ последовательной нумерации
    • username – логин пользователя
    • city_id – город проживания пользователя

    Необходимо выбрать города, в которых проживает не менее n пользователей

  10. Имеется таблица для хранения информации о посещениях страниц пользователями: 
    1
2
3
4
5
6
7

    CREATE TABLE `page_visit` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,
`page` varchar(200) NOT NULL,
`date` datetime DEFAULT NULL,
PRIMARY KEY  (`id`)
)

    Необходимо вывести:

    1. последних 10 пользователей, посетивших страницу «/about/»
    2. всех пользователей, посетивших страницу «/about/», с указанием следующих данных:
      • ID пользователя
      • Количество посещений страницы
      • Время первого посещения страницы
      • Время последнего посещения страницы
  11. Есть 2 таблицы: 
    1
2
3
4

    CREATE TABLE users (
id INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY,
username CHAR(16) NOT NULL
);
    1
2
3
4
5

    CREATE TABLE user_email (
id INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY ,
user_id INT( 11 ) NOT NULL,
email CHAR(16) NOT NULL
);

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

    12. Далее был вопрос для тех, кто без особых проблем справился со всеми предыдущими:

  12. Пользовались telnet? Напишите, как при при помощи telnet обратиться к главной странице example.com.

    13. На этот вопрос ответил только один человек из всех соискателей. Кстати, он был сисадмином и решил переквалифицироваться в web-программиста.

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

Помимо этих вопросов, некоторых соискателей по ходу собеседования я спрашивал о том, с какими фреймворками они работали, работали ли с системами контроля версий (svn, cvs, git), смогут ли настроить web-сервер (nginx, apache).

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

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

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

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

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

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

А что вы думаете о простых и сложных собеседованиях для программистов? Каким оно должно быть?