Всем привет!

Предыдущие серии: серия-1

Автор: sanchez911
Дата: 17.09.15

, серия-2

Автор: sanchez911
Дата: 15.10.15

.

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

Итак. Сначала — о поиске разработчиков.

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

Критики данной позиции делятся на 2 части:
— те, кто против выполнения каких-либо тестовых заданий вообще;
— те, кто против выполнения ТЗ на дому (а на собеседовании — ок).

Наиболее часто встречается мнение, что тестовое задание — это зверство по отношению к кандидату, что это говорит непрофессионализме работодателя, и много-много других мнений, сходящихся в том, что ТЗ — это плохо и "я бы ни за что не пошел туда, где дают тестовое задание". Мол, вот пусть кандидаты показывают свой код из реальных проектов; код говорит о многом, по коду можно понять, что за человек. И я возьму на себя смелость возразить.

Нет, друзья, нихрена код не показывает. Код позволяет увидеть стиль программирования, но не личные качества. Я много раз встречал примеры аккуратно, хорошо оформленного кода, который работал неправильно. Причины могли быть разные: либо ошибка на системном уровне, либо более мелкие ошибки из-за невнимательности (а это важно!). Вникать же в представленный код настолько глубоко, чтобы находить подобные ошибки — у меня просто банально нет на это времени. Как вы думаете, если на объявление на каком-нибудь hh.ru приходит более 100 откликов за неделю, реально ли подробно и детально изучить код каждого из них? Неважно, кому это делать: мне, или тимлиду — времени уйдет очень много, и реальная работа на это время встанет. И еще раз хочу напомнить: красиво оформленный код нередко работает плохо!

У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой. Для начала можно даже несильно вникать в код. Достаточно просто прогнать различные тестовые ситуации. На них можно отсеить 80-90% человек. И если кто-то из них начнет доказывать, что это я сам осел, что не оценил такую хорошую программу, то на это можно смело забить: у тебя есть 10%, которые выполнили задание хорошо, а значит задание адекватно, и твои тесты — тоже.

Если же мне дают посмотреть код, то сравнивать людей между собой гораздо сложнее. Допустим, один показал код простой задачи (и он сделан хорошо), другой — код сложной задачи — и он сделан средне. Как понять, хорошо ли покажет себя программист 1 на сложной задаче? А может программист 2 хорошо себя покажет на более простых задачах и не стоит его сразу отфутболивать? Другими словами, если давать одинаковое тестовое задание всем программистам, то на выходе я получаю нормированный результат, а если сравнивать их продакшн-код — то нет, и у меня понятия нет, как его нормировать.

Еще один пример удобства сравнения людей по ТЗ. Когда я разработчику говорю в отказе, потому что в таком-то случае программа повела себя неправильно, мне порой отвечают — да, но это же тестовое задание. Но у меня есть люди, которые и в тестовом задании эту ситуацию обрабатывают правильно. Если один поленился, а другой нет, разве это не помогает сделать выбор? Да и откуда мне знать, человек действительно знал, но не сделал из-за объема, или не догадался протестировать одну из возможных ситуаций? А это ведь важно в работе.

Другими словами: 100 человек получили задание, 99 сделало плохо и обосрало тебя и твой подход, а 1 просто взял и молча сделал хорошо. Да и плевать тогда на мнение этих 99 — оставшийся 1 получает работу, делает ее хорошо, я и он получаем деньги от заказчика и положительный отзыв. У нас в стране так часто: один работает, остальные трендят. Меня в общем-то несильно волнует мнение остальных 99, которые не умеют работать хорошо.

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

Но все же мне очень интересно обсудить — а на что вы бы смотрели в коде?

Теперь по поводу "тестовое задание при собеседовании — ок, на дом — не ок". Здесь уж ближе к истине. Но я все же практикую задачку именно на дом. Во-первых, в основном я ищу удаленщиков, а там и вариантов нет. Но даже в случае москвичей я сначала даю задачку на дом. Это позволяет, опять же, отсеить большую часть людей и не тратить время на очное собеседование (которое несомненно отнимет гораздо больше времени). Здесь можно сказать, что я, такой гад, думаю о себе, но не думаю о разработчиках — свое время экономлю, а их — нет. Ну, что поделать — бизнес есть бизнес.

Кроме того, я считаю, что реальные очные собеседования чаще ошибаются, чем сколь-либо серьезное тестовое задание. Очень часто человек общается уверенно, у него вроде как большой опыт, о котором он интересно рассказывает... А в реальной работе оказывается "пшик". Сколько у меня было кандидатов с отличным резюме и уверенным общением, но ужасно выполненным заданием... А ведь взял бы я их, проблем бы потом было ого-го. Печальный опыт в самом начале моего пути уже был Человек, которого я взял, имел хорошее резюме, и особенно много уделял внимания тестированию (по его словам это была его фишка). Но в реальном проекте кол-во багов просто зашкаливало. Когда я наконец расстался с ним — ощущения были как гора с плеч.

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

Кстати, еще ремарка. У успешных и известных компаний подход аналогичен. Скажем, тестовые задания на дом есть у яндекса, есть у студии Лебедева. И нельзя сказать, что они очень маленькие (хотя зависит от должности). Можно возразить, что я — не студия Лебедева, но значит ли это, что нельзя брать пример с лучших компаний? А может быть они не просто так стали лучшими?

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

Так вот, там нужно было взять несколько человек непрограммистской направленности, а именно: руководителя IT-службы, руководителя отдела обучения, менеджера сопровождения. Руководитель IT должен сформировать свой отдел, т.е. набрать сисадминов, и обеспечивать нормальное функционирование инфраструктуры у наших клиентов (клиник). Отдел обучения должен обучать юзеров нашей программе. Менеджер сопровождения — ну что-то типа личного менеджера у каждого клиента, хорошо знает нашу программу, помогает им в сложных вопросах, передает нам их хотелки.

В общем, разместили вакансии на хедхантере. На IT-директора пришло 300 откликов, на остальные должности — около 50. Я решил для начала дать людям тоже простенькую "домашку".

Для IT руководителя задал 3 вопроса: как бы вы объяснили девушке-гуманитарию три вещи: ARP, облако (чем отличается от сервера-кластера), отличия винды от линукса. Смысл именно таких вопросов в следующем. Во-первых, по характеру объяснения будет понятно, понимает ли человек реально термин, который он разъясняет. Например, далеко не все правильно понимали ARP. Во-вторых, по тому, насколько человек внятно умеет объяснять, насколько он сможет "транслировать" пояснение для гуманитария, можно судить, насколько он адекватен в целом. Например, многие, кто знал суть ARP, пытались его объяснить техническими терминами, что было бы непонятно стороннему человеку. Ну ведь написано же в задании: девушка-гуманитарий!

Руководитель обучения получил 1 вопрос — просьбу объяснить врачу "что такое компилятор". Опять же, доступную аналогию проводили немногие, на четверку считался ответ "это переводчик с языка человека на язык компьютера". На четверку, потому что в общем-то суть правильна, но ответ похож на отмазку. Что значит "язык компьютера"? Мне больше нравится, когда человек проводит понятную для слушателя аналогию. Например, кто-то объяснял на примере расшифровки медицинского рецепта пациенту.

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

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

Эти вопросы имели цель проверить общий уровень мышления человека. Вопрос с катастрофами — на системность мышления. С яндексом — просто на догадливость (правильный ответ — пешеходы никогда не превышают определенной скорости, дан самим яндексом).

Ну, про катастрофы вообще никто правильно не ответил. Некоторые вообще отвечали что-то в духе "безопасность надо мерить количеством происшествий, где меньше там и лучше". Впрочем, заставлял задуматься мой вопрос "за месяц 100 самолетов перевезло 10000 человек, 2 разбилось; за тот же месяц 2 автомобиля перевезло 4 человека, 1 разбился — значит автомобиль безопасней?". Ну и все в таком духе. Кстати, была у меня в кандидатах на обучателя одна девушка, которая пишет диссертацию с активным использованием аппарата матстатистики, и она тоже бредово ответила.

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

Еще, что меня поразило — это крайне низкий уровень технических знаний у IT-директоров. Почти никто не знал отличия BIOS от UEFI, никто не знал что такое GPT-диск, на вопрос "чем fat32 отличается от ntfs" наиболее распространенный ответ — "у ntfs размер раздела может быть больше", как реально работает маска подсети почти никто не знает, ну а wildcard-маска — это вопрос-fatality У меня была еще задачка из недавней реальной практики. У нас толстый клиент, который коннектится к WCF. Несколько клиник в Москве. Сервер в Москве. Клиники коннектятся к серверу через инет. В одной из клиник жалуются на медленную работу программы, в остальных все нормально. Все условия идентичны: одно железо, одни компы, один набор прикладного софта. Скорость инета в "медленной" клинике — даже больше, чем в других — скачивали большой файл с сервера и замеряли время. В чем может быть причина? Правильный ответ, до которого нынешняя IT-служба (сторонняя контора) дошла только через 2 месяца жалоб — долгие пинги (а скорость уже установленного соединения — нормальная). Там какой-то странный провайдер, у которого линк идет через Канаду. Отсюда и все проблемы. На этот вопрос большинство кандидатов тоже не смогло ответить. И ведь это люди из шорт-листа, на приличную зарплату!

Когда я осмелился дать им обратную связь — мол, господа, ну нельзя же так, — стал получать ответы "а я же руководитель, я буду руководить, а разбираться в этом должны мои сисадмины!". На что я сразу задавал следующий тестовый вопрос: вам нужно набрать себе в штат 2 сисадмина. Разместили вакансию, пришло 500 откликов. Как вы будете выбирать? Первое, что отвечали — по резюме. Ну ок, говорю я, выбрали 100, с идеальными резюме. Дальше? Дальше ответы варьировались (но мало какие мне понравились). Наконец, дошли до истины: как вы будете собеседовать людей себе в подчинение, если сами не разбираетесь ни в чем? Все это я спрашивал со свойственной мне прямотой и заработал некоторые обиды на себя)))) В общем, печально.

В итоге из 25 прособеседованных человек мне понравился один IT-директор, 3 руководителя обучения и 2 менеджера. Пригласил их на еще одно собеседование — со вторым учредителем (он более бизнесовый, чем технарский, поэтому взгляд со стороны очень полезен). И в общем-то по результатам я мысленно похвалил себя за правильный выбор: IT-директор понравился, руководители обучения понравились все (пришлось выбирать), и только менеджеры оба не понравились — их не взяли. А так моя методика оказалась пока что успешной Посмотрим, как эти люди будут вести себя в работе, но пока мне их деятельность нравится.

Ну все, пора заканчивать, а то целую поэму уже накатал. Как всегда, на правах рекламы — если вас не отпугивает мой подход, то приглашаю к себе разработчиков dotNet. Нам нужны и фултайм в офис (м. 1905 года), так и на удаленку. Проекты — разные, в основном интересные Пишите мне на mailbox at nevlabs dot ru с темой письма "Разработчик на удаленку (код rsdn-dev)". В письме расскажите о себе: из какого вы города, сколько вам лет, кратко-кратко о своем опыте, сколько есть свободного времени на мои проекты. Как я писал выше, я оцениваю кандидатов в первую очередь с позиции тестового задания — поэтому оно обязательно. Жду вас!

See you!