Константин Евгеньевич Борисов
Брать или не брать? или Как собеседовать разработчика
2.6 Технический проект
Во многих компаниях обязательной частью приёма на работу программиста является выполнение большого технического проекта. Такой проект похож на реальные проекты компании и включает бизнес-логику, UI, backend, и часто состоит из нескольких отдельных модулей.
Объём требуемых от кандидата усилий различается от компании к компании и иногда достигает полноценной рабочей недели. Многие кандидаты, возмущенные объёмом работы, отказываются продолжать собеседование и пишут негативные отзывы о компании.
Когда проект требует выделения всего лишь одного дня (4-6 часов) реакция кандидатов, в основном, положительная. Люди готовы потратить столько, если они действительно заинтересованы вакансией.
Кроме потери кандидатов, включение такого этапа в процесс затягивает найм[4]. Даже если проект требует всего лишь 4 часов работы, то, скорее всего, кандидат сможет выделить это время только на выходных. А значит, вам придётся просто ждать.
Проверка сделанного проекта тоже занимает время. Просмотреть большой объём кода ничуть не проще, чем провести интервью. Да, к тому же, выполненный проект всё равно нужно обсудить с кандидатом, иначе трудно понять, почему он реализовал его так, а не иначе. То есть нужно будет потратить время ещё и на дополнительную встречу с кандидатом.
Причём многие справедливо указывают на то, что этот дополнительный этап практически бессмысленен. Хороший технический интервьюер может довольно точно определить уровень кандидата с помощью интервью, без таких изматывающих упражнений на кодирование. Так почему же этот этап вообще используется на практике?
В первую очередь, это нужно компаниям, где нет технических экспертов, умеющих проводить интервью. Вы можете сэкономить вашей компании время и деньги, которое она тратит на неэффективные методы оценки кандидатов, просто качественно проводя собеседования вместо ненадёжного и долгого этапа реализации технического проекта.
Другой причиной является желание проверить, насколько сильно кандидат хочет работать на вас. Если он готов потратить несколько дней на проект для вашей компании, значит, он точно серьёзно рассматривает вашу вакансию. И это правда. Но тоже самое может проверить интервьюер на менеджерской части интервью.
К сожалению, такая популярность технических проектов на собеседованиях объясняется тем, что большинство компаний не имеют специалистов, способных качественно провести технические и менеджерские интервью. Оценить готовое приложение и проревьюить код гораздо проще, чем грамотно провести собеседование. Это неэффективно, это отпугивает многих хороших кандидатов, но компания, которая не умеет проводить интервью, не имеет никакой альтернативы.
Есть ли ситуации, когда действительно имеет смысл давать кандидату технический проект? Да, конечно. Один из случаев описан в главе 4.2 «Разработчик, который не хочет менять работу ». Если кандидат не уверен, что он хочет работать в вашей компании, он может быть заинтересован в том, чтобы попробовать «реальную работу» без всяких обязательств.
Другая ситуация, где технический проект полезен – это найм junior-разработчика. Если разработчик никогда не писал коммерческий код, то имеет смысл дать ему попробовать свои силы. Для него это будет не нудная часть приёма на работу, а полезное упражнение. Но в любом случае проект не должен требовать больше 6 часов работы. Такой объём уже достаточен для «серьёзного» кода, но не вымотает кандидата.
Кроме этих двух перечисленных случаев я не вижу достаточной ценности в техническом проекте. Недостатки этого этапа найма слишком значительны. Я рекомендую использовать технический проект при найме как можно реже и с очень чётким пониманием, зачем вам нужен этот этап.
2.7 Проверка знания английского
Во многих международных компаниях знание английского необходимо и это знание проверяется при приёме на работу в обязательном порядке. И также в обязательном порядке делаются одни и те же две ошибки.
Первая ошибка.
Многие компании заявляют, что английский критически важен, но берут кандидатов, которые английский не знают и, что хуже, не хотят знать. Это кажется безумием, но кадровый голод в сфере IT очень высок, поэтому очень обидно бывает, когда попадается превосходный специалист, единственным минусом которого является недостаточное знание английского.
Часто такому кандидату после некоторых сомнений молча высылается офер. Ведь английский реально легко подучить. А кандидаты обычно говорят, что они усердно учат английский и, конечно, хотят подтянуть его уровень[5].
Потом кандидат принимает офер и выясняет, что с его уровнем владения языком работать ему плохо. Он не может выполнять свои прямые обязанности. У него проблемы с заказчиком. Он не может двигаться по карьерной лестнице. Требуемый уровень языка часто кажется такому кандидату нереально высоким.
Кандидат либо покидает компанию сам, либо его приходится увольнять. Кандидат возмущается, так как с его точки зрения от него требуют невозможного. Вы недовольны, так как с вашей точки зрения кандидат не приложил достаточно усилий. Всем плохо, а компания несёт убытки.
Что же делать? Надо очень чётко проговорить с кандидатом, какой уровень знания языка и за какое время нужно получить, а также какие проблемы будут у кандидата, если он этого уровня не достигнет. И до офера нужно получить согласие кандидата с такими условиями (а вы должны поверить в искренность этого согласия). Более детально этот процесс расписан в главе 4.1 «Офер». А необходимость проговорить с кандидатом уровень языка, который он должен достигнуть, ведёт нас к обсуждению второй ошибки.
Вторая ошибка.
Часто вся тема английского языка отдаётся на откуп преподавателям, к которым, совершенно заслуженно, в IT большое уважение. И они определяют, например, что рядовые сотрудники должны иметь уровень Basic, старшие – Intermediate, а остальные – Advanced[6].
Для этих уровней составляются тесты (или берутся готовые), и все сотрудники, новые и имеющиеся, эти тесты проходят.
Звучит логично? Нет. По очень простой причине: преподаватели не могут знать, какие реально знания нужны в работе, и, соответственно, не могут эти знания проверить.
Например, я видел разработчиков, которые легко читают документацию на английском, грамотно называют методы и даже вменяемо комментируют код, но совершенно теряются, если текст нетехнический. Они могут описать проблему в письме, но не могут грамотно спросить заказчика, что с этой проблемой делать. Они не хотят учить английский, так как в их работе им ничего не мешает. Любое тестирование покажет, что их уровень не дотягивает до Basic, но это не совсем так.
Или вот другая тоже распространённая ситуация. Специалист может общаться с заказчиком на упрощённом и ломаном языке. Он не употребляет Third Conditional и Past Perfect. Он игнорирует дифтонги и межзубные θ и №. Но заказчик может прекрасно его понимать.
Я видел даже менеджеров высокого уровня, которые имеют весьма плохое произношение, но их опыт и знание большого количества стандартных оборотов позволяет им успешно вести переговоры и заключать многомиллионные контракты.
Если предполагается, что кандидат будет устно общаться с заказчиком, то интервьюеру достаточно просто попросить его рассказать на английском о текущем проекте. Это будет достаточно технический разговор, и по нему будет легко понять будут ли у кандидата проблемы в общении. Не пытайтесь сгрузить эту проверку на преподавателей английского. Вы же не приглашаете преподавателя программирования, чтобы определять уровень разработчиков? Умение пользоваться английским такой же навык.
Если текущая команда английский знает плохо, и вы хотите это изменить, то категорически нельзя брать кандидатов с плохим английским. Они не будут улучшать свой язык, они будут ориентироваться на коллег. Вы просто будете увеличивать массу людей с плохим английским. Исправление такой ситуации – это отдельная тема, далеко выходящая за рамки этой книги.
