?

Log in

No account? Create an account
me

slonik_v_domene


Убей в себе государство


Previous Entry Share Flag Next Entry
Давайте наймем программиста...
me
slonik_v_domene
Казалось бы, как просто!

Даем объявление на сайт с вакансиями или вешаем баннер “Требуются разработчики”. Приходит кандидат с прекрасным резюме, который работает полгода, а затем сваливает в неизвестном направлении. Или через три месяца выясняется что, хотя все из запланированного сделано, но почему-то в продакшене не работает и никто при этом не виноват. Опять наняли непойми кого, а ведь как хорошо общались на собеседовании!

Знакомо? Вот об этом и пойдет речь.

Кто требуется на самом деле?


Вам кажется что необходим человек, обладающий энциклопедическими знаниями в области теории алгоритмов, досконально разбирающийся в пяти основных фреймворках минимум для двух вебтехнологий и готовый одновременно с этим верстать HTML5 и писать запросы к БД начиная от MySQL и заканчивая DB2?

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

Есть такая птица – утка. Умеет летать, плавать и ходить. И все это – одинаково плохо по сравнению с другими птицами, специализирующимися на полете, плавании и беге. Точно так же и с программистами. Вам на самом деле не нужен разработчик, умеющий все, но плохо. Ищите специалиста. Насколько узкого – зависит от того, что вы хотите ему поручить. Но в любом случае учтите, что чем шире список умений – тем хуже с глубиной знаний.

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

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

Имя им:

Обязательные качества


По моему мнению, качеств ровно два. Первое – умение доводить дело до конца. Второе – делать требуемое правильно.

Ни в коем случае нельзя брать на работу человека, не способного довести разработку до продакшена. В разработке ПО понятие “процент сделанного” есть только для отчетности перед менеджерами проекта. В реальности же либо вы запускаете проект (пусть и сырой и с глюками), либо – нет. Поэтому в команде никаких недодельщиков быть не должно. Значит, и брать на работу таких людей не надо.

Оборотная сторона медали – проекты, сделанные тяп-ляп, лишь бы отстали. Я лично был свидетелем проекта, где сложность задачи была O(1), а алгоритм, решающий задачу, был сложности O(n2). Задача несомненно была решена, но цена ее решения была неприемлема, и выяснилось это только после выкатки продукта – у тестировщикв попросту не было инструментов для моделирования реальной нагрузки. Нет никаких сомнений, что протестировать все подсистемы большого проекта невозможно. Поэтому лучше заранее сделать так, чтобы по возможности не работать с бракоделами.

Как эти качества проверить? А что если дать на собеседовании несколько технических вопросов, а лучше - дать задание и посмотреть как оно будет решено? Однако, не все так просто. Ниже я расскажу о нескольких типичных ошибках.

Вопросы, которые следует задать


Безусловно, требовать ответить на все вопросы из анкеты в 300 пунктов нет смысла. Вы же не ЕГЭ проводите, и ищете не робота-энциклопедиста. Так же и нет смысла задавать вопросы в стиле “расскажите сами что знаете”. Придумайте заранее 5 – 7 вопросов касающихся специфики работы, используемых алгоритмов и среды разработки.

Лучше всего задавать те вопросы, знание ответов на которые реально может потребоваться в работе. Если у вас нигде не используется и не будет использоваться Oracle, то и не спрашивайте про знание его особенностей. Если же у вас основная среда разработки Eclipse, и на хорошее ее знание завязана эффективность взаимодействия с коллегами, спрашивайте обязательно. И пусть это вопрос не на знание алгоритмов, поверьте, от этого он не менее важен.

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

Не забывайте, что любое собеседование - процесс обоюдный. Кандидат так же занят оценкой работодателя, как и работодатель - кандидата. Мутные, неочевидные, безграмотные вопросы вызывают отторжение. Будьте всегда готовы ответить на свой же вопрос и объяснить, почему ответ именно такой.

Решение задач на собеседованиях


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

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

На самом деле совершенно понятно, что в состоянии стресса, за шесть часов глядения в ЭЛТ (это был 2001 год, тогда ЖК мониторов не было) нельзя написать вменяемый код. Что-то изобразить “на отстаньте” – да, возможно. Но не более.

В том же Долгопрудном была другая, очень немаленькая, кстати, фирма, где формальное собеседование строилось на дружеском разговоре и до вопросов “по существу” дело вообще не доходило.

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

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

Мало того что постороннему человеку показывают куски кода из продакшена, да еще и требуют вот прямо здесь и сейчас помочь забесплатно исправить кривой код! Черт с ней, с моралью. Собеседующие просто заранее рассказывают что: a) работать придется с кусками никому непонятного кода; b) переписать по-человечески не дадут, и вся работа сведется к бесконечной постановке заплаток на заплатки; и c) люди сами не знают, что им делать со своей же системой. Конечно же, все это очень стимулирует будущего коллегу.

Выходит, и давать задачу и не давать ее одинаково плохо? Да, это так. Давать решать объемные задачи на собеседовании так же плохо, как и не давать их вовсе. Что же делать?

Необходимо...

Домашнее задание


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

Что именно задавать на дом? Задача может быть любой, важно лишь чтобы ее результатом являлся готовый к запуску продукт. Как пример – новостная лента или несложный сервер (HTTP или FTP). Совсем хорошо, если претендент напишет краткую инструкцию по запуску своего проекта.

Проверка в таком случае очень проста: проект не запустился – прощаемся. Запустился – смотрим код и оцениваем, хотим ли мы это видеть в продакшене. Если да – принимаем на работу, если нет – увы. В качестве исключения можно дать одну попытку исправить проблему с незапуском проекта. Но - ровно одну.

Что еще спросить на собеседовании


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

Кто не нужен


Лентяи, адепты фреймворков, фанатики технологий, знатоки только одной технологии.

С лентяями все понятно. Остальное требует комментариев.

Чем плохи адепты фреймворков? Здесь, разумеется, идет речь не о людях, использующих фреймворки (это как раз достойно всяческих похвал), а граждане, ничего кроме заданного фреймворка принципиально не использующие. Любая задача выходящая за рамки их мирка решается, как правило, ужасно неэффективно, либо к задаче всеми силами прикручивается набор “стандартных” модулей, делающих похожие, но не те же самые вещи.

Фанатики технологий и знатоки только одной технологии чем-то похожи на предыдущих. Разница лишь в том, что чуть больше пространства для маневра. Но в любом случае такие люди – потенциально рискованное приобретение. Фанатик технологии использует технологию не ради результата, а ради процесса. Нет ничего более нелепого чем холивор “любителей языка” против “пользователей языка” на предмет правильности подхода, правомерности использования ”синтаксического сахара” и т.п. Почему-то особенно этим грешат любители Perl. Единственным критерием правильности подхода является соответствие результата ожиданиям заказчика. Поэтому и не нужны те, кто работают только ради процесса, а не на результат.

А будет ли счастье?


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

Выводы



  1. Определитесь, кто вам на самом деле нужен.

  2. Собеседование – не тест ЕГЭ, но и не дружеский разговор коллег. Всегда проверяйте соответствие кандидата заявленным в анкете умениям.

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

  4. Домашнее задание наглядно демонстрирует умение решать поставленные задачи в срок и качественно.

  5. Не экономьте на людях. Универсальных солдат не существует. Всегда ищите необходимого вам специалиста.

  6. Не берите на работу лентяев, религиозных фанатиков и ограниченных незнаек.

  7. Будьте готовы к неудаче. Всегда есть возможность ошибиться в своем выборе. Относитесь к этому философски и дальше ищите людей в свой dream team.


Update: Следующий по теме пост о том, что говорят и пишут собеседуемые и что на самом деле слышат и видят работодатели. Оставайтесь с нами (с) :)


Очень толково! :)

Как пример – новостная лента или несложный сервер (HTTP или FTP)

Не, FTP сервер в рачестве ДЗ не надо. Во-первых, сам протокол очень мутный (канал данных, управляющий канал, пассивный vs. активный режимы), а во-вторых, задача ну очень уж не жизненная в современных реалиях.

А мне тут недавно одна крупная российская компания (не будем тыкать пальцем), на очередном собеседовании, втирала, что FTP у них используется очень активно, да и более того является мессией для их компании. В противном случае их распределенный бизнес не смог бы существовать.

К чему пустые умствования?

Я спрашивал задачу про сотрудников и отделы. Если человек писал с exists и не производил впечатления какого-то безумца или маниака - мне он нравился. Результат, собсвенно, был если и не жуть каким хорошим, то и не жуть каким плохим.

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

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

Ха, в Москве, недалеко от м. Парк Культуры есть компания, в которой и по 15 часов бывает, без перерыва. И кстати вполне успешно функционирует. :)


Домашнее задание это мягко говоря перебор. Более-менее стоящий разработчик пошлет в лес, т.к. время - деньги. Или подразумевается что время потраченное на выполнение задания будет оплачено?

Простите, а поход на собеседование - это же ведь тоже трата времени. Не начать ли оплачивать еще и время, проведенное на собеседовании?

Если я правильно идентифицировал первую компанию из Долгопрудного, то там дело было в специфике тестового задания.) Начинаешь делать его правильно - сделаешь за час максимум, делаешь неправильно - уйдет очень много времени.) Ну, и выгонять из-за компа никто не собирался, давали шанс передумать и начать делать правильно. А если просидел 8 часов, сделал задачу неправильно, "в лоб", она работает, но способ - неверный, то тест все равно не считался пройденным.

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

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

rails scaffold Post text:string user_id:integer
rails scaffold User nick:string email:string password:string

Тестовые задания, которые я видел, не имели ТЗ необходимой степени подробности. Поэтому потратишь время, а окажется от тебя хотели какой-то специальной штуки и ты в пролете.

А какой степени подробности вам нужно ТЗ, например, для написания новостной kенты?

(no subject) (Anonymous) Expand

Мое восхищение

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

Re: Мое восхищение

Скандалы, интриги, расследования :D

некотороые соображения

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

Два соображения.

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

2) Даже если человек не ярый фанатик используемой технологии при специализации он все равно будет думать с сильным уклоном в сторону своих специальных знаний. И задачи решать он будет так же исходя из них. Я в итоге о том, что решаемые задачи всегда будут в контексте специализации и адекватный специалист тут тот, кто ознакомивший с задачей может сказать, что используемая им технология не подходит или решение будет неоптимальным. В конце концов разработчик, "как человек к проекту приставленный", будет эффективен если его умения будут правильно и по месту использоваться (вспоминается шуруп, молоток и отвертка). В этом случае эффективно может сработать и фанатик.

а я энтузиаст - мне нужно - я это сделаю
мне интересно - я это выучу

и во всём надо находить свои плюсы

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

не люблю когда лень проявляется в стандартных случаях - когда нужно всего навсего прочитать документацию - многие бегут на стек оверфлоу искать ответы

лень искать самому, добиваться самому, строить свой велосипед


ещё один пример

есть довольно таки известная компания где фанатически требуется только программисты на джаве (допустим), а ты говоришь я знаю c++ и что он круче и мощнее

что делать в таких случаях ?

и как вы относитесь к сотрудникам которые пытаются изминить принциаы компании ? (в оправданных случаях)

и стоит ли изменять своим принципам ради денег ?

>есть довольно таки известная компания где фанатически требуется только программисты на джаве (допустим), а ты говоришь я знаю c++ и что он круче и мощнее

Мало ли что кто говорит. Человек не знает java? А что он тогда забыл в компании, которой нужны программисты java?

>и как вы относитесь к сотрудникам которые пытаются изминить принциаы компании ? (в оправданных случаях)

Лично я - с одобрением.

>и стоит ли изменять своим принципам ради денег ?

Каждый решает сам.

В тестовых заданиях на дом полезно указывать ограничение по времени.

Реализуйте простой HTTP сервер, ориентировочное время выполнения задания - 1,5 часа. И все - все вопросы по 100% поддержке RFC снимаются сами собой.