Skip to content

Instantly share code, notes, and snippets.

@rigidus
Created September 13, 2012 03:12
Show Gist options
  • Save rigidus/3711594 to your computer and use it in GitHub Desktop.
Save rigidus/3711594 to your computer and use it in GitHub Desktop.
* Цель
...этого документа - максимизировать вероятность успеха при найме
программистов, подходящих для наших задач. Это не про то, как
нанимать гениев, скорее про то, как не нанимать тех, кто нам не
подходит. В ряде случаев в эту категорию могут попадать и гении - и
это, возможно, является нашей проблемой, но рассмотрение ее выходит
за рамки этого документа
* Основные принципы
Для успешного выполнения целевой задачи правом принятия решения
о найме должен обладать человек, который будет непосредственно
работать с соискателем. Он должен обладать квалификацией
программиста, чтобы адекватно оценить навыки кандидата. Если эти два
условия не совпадают, размывается зона ответственности и можно сразу
переходить к найму подбрасыванием монетки.
Худшее, что может произойти - найм человека, который будет мешать
процессу. В эту категорию попадают как неопытные или тупые
программисты, которые отнимают время на подтягивание их до общего
уровня, так и специалисты-теоретики, которые решают не ту задачу,
которая им поставлена. По этой же причине нанимать специалистов,
которые более квалифицированны, чем уже имеющийся ведущий
программист считается бесперспективным. Но можно нанять его ведущим
программистом другого проекта.
* Портрет
В большинстве случаев кандидат должен будет работать в небольшой
группе программистов, разделяющий общий код. В этих условиях на
первый план выходят не личные способности, а навыки взаимодействия и
поддержки процесса разработки и обеспечения предсказуемости
результата.
Как правило, это человек с опытом 1-3 года работы в похожей компании
с похожими задачами, знакомый с процессом и используемыми
инструментами и знающий основные идиомы языка.
* Объявление о вакансии
...имеет смысл создавать по следующей схеме:
Описание проекта
Круг обязанностей
Технологии
Компенсационный пакет
** Основные ошибки:
*** Нужен специалист широкого профиля.
Программист, дизайнер, верстальщик, с опытом работы с базами
данных и навыками сисадмина. Воспринимается как неадекватность.
*** Несоответствие компенсации реалиям рынка
Стремясь сэкономить на специалисте легко получить невостребованных
рынком проблемных сотрудников и внушить себе, что вменяемых
разработчиков на рынке нет.
*** Неуказание зарплатной вилки
Вменяемые разработчики любят определенность и не любят
торговаться - они не отправляют резюме на такие вакансии
*** Банальности
Отличный коллектив, возможность самореализации и карьерного роста,
возможность поучаствовать в интересных и сложных проекта и прочее.
*** Самореклама
Не нужно помещать в объявление о вакансии содержимое
корпоративного сайта. Достаточно ссылки.
* Скриннинг резюме.
Тут все просто - отсеиваем:
** Специалистов по всему
Количество абреввиатур зашкаливает при малом опыте работы - не наш
клиент.
** Без опыта работы и выполненных проектов
Обучением занимаются профильные компании
** Непрофильные
Они не прочли вакансию, но отправили резюме? - Нам тоже бывает лень
читать
** Неадекватов
Он работал в КГБ, ЦРУ и был уволен за гениальность? Это не к нам.
* Тестовое задание
...бесполезно. Его будут выполнять только очень мотивированные
кандидаты. При прочих равных нужно отдавать себе отчет, что хороший
специалист пойдет по пути меньшего сопротивления при прочих равных
Лучше дать ссылку на тест из пяти вопросов, проверяющих, знаком ли
человек с синтаксисом языка (и отдельно указать, что этот тест - не
оценка, а просто минимальный фильтр, чтобы кандидат не
обиделся). Если ответил верно хотя-бы на три - можно приглашать, две
ошибки из пяти могут быть вызваны невнимательностью или
неправильностью понимания вопроса. В том числе и у задающего вопрос :)
* Собеседование
В среднем на одно собеседование можно потратить 20 минут. Как
правило кандидаты опаздывают в пределах 10 минут.
Имеет смысл записывать впечатления о кандидатах, обычно прямо на
распечатке резюме. Иногда лучше это делать после окончания интервью,
чтобы не создавать излишнее напряжение.
** Вступительная часть (создаем комфортную среду для общения)
Предложение кофе/чая, чтобы снять напряжение. Рассказ о компании
(кратко), о проекте (суть) и о используемых технологиях
(подробно). На этом этапе можно отследить заинтересованность.
Распросить о образовании, бакгроунде, интересах в профильной
области. Узнать о профессиональных интересах, целях, используемых
технологиях, амбициях.
** Основная часть (повышаем мотивацию)
Подробный рассказ о том, чем придется заниматься в случае
найма. Между делом, уточнить, как кандидат оценивает свой уровень в
интересущих нас технологиях.
Рассказать об условиях работы. Отметить, какие из них вызывают
заинтересованность. Квалифицированные специалисты ценят минимизацию
отвлекающих факторов, юниоры - возможность изучить неизвестные
технологии.
** Проверка знаний
Легко нагуглить наборы типичных вопросов на собеседовании,
кандидаты о них знают, поэтому их использование не приносит
профита. Понимание, в отличии от правильного ответа
заучить невозможно, поэтому следует оценивать его и умение
приходить к решению. Если человек моментально отвечает на вопрос -
это лишь значит что он знал на него ответ - то же касается типичных
вариантов заданий, если они выполняются не впервые. Часто вопрос в
стиле "почему ты выбрал этот путь решения задачи" приносит больше
информации чем только что написанный код.
Не стоит также задавать вопросы по редкоиспользуемым "хакерским"
возможностям языка, таким, например, как выполнение кода внутри
регулярного выражения - нет смысла нанимать кандидата за то, что он
знает те же редкие финты что и нанимающий.
Идея, что программер должен в уме выполнять код как машина - это
киберпанк или издевательство. В реальной работе интерпретацию кода
выполняет машина.
*** Задаем простые задачки на знание идиом языка.
Например FuzzBuzz. Оцениваем, знает ли кандидат типичные
сценарии. Умеет ли он использовать в типичных ситуациях
применяемые нами технологии, например обеспечить взаимодействие
между базой данных с реляционными отношениями и объектами
классов. Какие инструменты или паттерны он для этого использует.
*** Задаем задачки на знание использумых технологий (ООП, VСS, HTTP, AJAX) и фреймворков
...если они заявлены в резюме. Спрашиваем про впечатления,
полученные при изучении фреймворков. Оцениваем, правильно ли
кандидат рассуждает о сильных и слабых идеях и реализациях, в
какой мере он знаком с технологиями, нет ли у него мнения - "я
неосилил, значит оно не нужно".
*** Задаем вопросы по алгоритмам и структурам данных.
Попросим описать разницу между массивом и списком, вспомнить
асимптоматическую сложность операций с хеш-таблицей, очередью и прикинуть
реализацию.
Просим отсортировать массив, перевернуть строку на месте, найти
цикл в односвязном списке.
*** Задаем теоретичекие вопросы о програмировании в целом и архитетуре.
Спрашиваем, как писать код, который будет легко поддерживать.
Выясняем различия динамической и статической, сильной и слабой
типизации, преимущества и недостатки аннотаций типов, алгоритмы
выведения типов. Явное и неявное приведение типов.
Спрашиваем про стек и кучу, время жизни переменной и сборку
мусора.
Просим написать нерекурсивный обход дерева, поиск в глубину, в
ширину, поиск с возвратами.
*** Спрашиваем про паттерны проектирования.
Интересуемся, зачем они нужны, когда полезны и когда
вредны. Просим поподробнее рассказать про MVC, как повсеместно
используемый.
*** ООП
Просим рассказать, как сделать ООП фреймворк на процедурном
языке. Если человек сможет рассказать - значит понимает. Если он
считает что ООП must die - пусть аргументирует и предложит замену
в типичных сценариях.
Не стоит выяснять различия, к примеру, между абстрактным классом и
интерфейсом, кандидат может знать более одного языка - и тогда
вопрос о тонкостях реализации ОПП заведет в страшные дебри без
всякой практической пользы
*** SQL
Просим написать пару запросов с джойнами. Спрашиваем, что общего у
реляционной алгебры и теории множеств.
Просим привести датасет к третьей нормальной форме
Спрашиваем зачем нужны индексы и как они работают.
Просим рассказать про разные виды репликации и шардинга
*** Админство
Просим рассказать о том, что такое unix-way, как работает пакетный
менеджер и как организована файловая система прав
файлов. Интересуемся о том, как написать ее с использованием ACL.
*** Задаем сложные "нерешаемые" задачи. Следим за ходом рассуждения
"Вам дан 1 миллион целых чисел, как их эффективно отсортировать?"
"Как сделать фэйсбук на коленке"
** Что оцениваем:
После того как кандидат справился с задачей - меняем граничные
условия, чтобы решение стало невалидным. К примеру, если кандидат
набросал систему комментирования постов - предлагаем увеличить
нагрузку, масштабировать, распаралеллить, кешировать, вынести на
вычислительно ограниченное устройство и.т.п. Оцениваем ход
рассуждений, умение отказаться от решения, кажущегося хорошим и
перепроектировать все на других принципах. Проверям способность
абстрагировать полученное решение.
Хороший программист как правило категоричен и умеет обосновать свою
позицию. Даже если неправ :) Имеет любимые языки и технологии и
уверен что конкурирующие вещи - полное гавно. Недавно читал
такой-то мануал и по этому поводу может сказать то-то и то-то. Если
нет - то может быть он интересуется футболом а не
программированием?
Пробуем спровоцировать холивар. Умение аргументированно спорить
коссвенно положительно характеризует.
* Ожидаемый результат и выбор сотрудника
После всех интервью у нас на выходе должно быть несколько приемлимых
кандидатур, устраивающих нас по уровню знаний, мотивации и умению
абстрагировать.
При прочих равных предпочтение стоит отдать тем, кто способен
чему-то научить команду - знает перспективную технологию, имеет опыт
внедрения фреймворка или успешного проектирования архитектуры.
О решении лучше сообщать возможно быстрее - хороший программист
находит работу через день после увольнения. Потому что на следующий
день - он отмечает :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment