Здравствуйте!

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

Преамбула

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

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

Тестовое задание

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

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

Проверка софт скиллов

«Расскажите о себе?» — вопрос, вводящий в ступор человека с глубоко-техническим складом ума (будем в дальнейшем называть его конструктор). Конструктор может немного покопавшись в памяти вывалить своё имя, возраст, рост и вес, национальность и цвет глаз, но при этом не поймет какое это все имеет отношение к делу, ведь он пришел продавать свой технический скилл, а не себя. «Что конкретно вы хотите обо мне узнать?» — обычно отвечаю я и наблюдаю разочарование в глазах босса, босс редко любит когда ему отвечают вопросом на вопрос, ведь теперь мячик на его стороне и думать приходится ему. Если бы я мыслил по другому, то конечно, я бы вывалил на него заранее подготовленную смачную историю меня любимого с детальными подробностями того насколько я клёвый, классный и, что самое главное, лучше чем остальные. Но если бы я мыслил по другому, я вряд ли стал бы программистом. Поэтому на ответ «что хотите то и рассказывайте» я начинаю тупо перечислять где я работал и какими проектами занимался, плюс какие технологии использовал, чем совершаю очередную ошибку, поскольку всё это уже расписано в резюме и не вызывает ничего кроме скуки. Ведь словами невозможно донести тот объем, вес и значимость, которые я ощущаю в своей голове.

И здесь я делаю допущение: допустим, что программист НЕ ДОЛЖЕН обладать сильными софт-скиллами.

Пойдем от обратного: допустим, что программист ДОЛЖЕН обладать сильными софт-скиллами, тогда — зачем нужен менеджер? Зачем тогда вообще нужна фирма, если я могу пойти на биржу фриланса и найти себе там самостоятельно заказчика? Господин Форд — великий изобретатель прошлого века, он изобрел конвеер, невероятно эффективную вещь, которую, видимо, еще не все научились использовать. В некоторых фирмах просекли эту фишку и вставили между программистами и заказчиками особое звено — менеджеров, по сути являющихся переводчиками с «человеческого» на «программисткий». Задача менеджера — договориться с программистом и заказчиком, задача программиста — «договориться» с кодом. Ожидая от программиста дополнительного повышенного скилла договариваться и коммуницировать, вы отсекаете тех программистов, которые за счет отсутствия этих софт-скиллов освободили в своей голове достаточно места чтобы прокачать скилл разработки гораздо глубже.

Представим себе что мы попали на собеседование в фирму, которая понимает эту идею. Тем не менее оценить общую коммуникабельность она всё равно желает, просто для того чтобы отсеять совершенно неспособных к командной работе людей. Каким образом это можно сделать эффективно за 1-2 часа разговора? Никаким. Я не видел ни одного человека на собеседовании, который вел бы себя распутно, неуважительно или неприемлемо выражался, и это естественно, ведь на собеседовании мы все максимально открыты, дружелюбны и адекватны. Поэтому, пропустив через себя тысячи собеседующихся, собеседующий начинает больше обращать внимание на другие детали: как человек одет, какая у него прическа, как от него пахнет, какие гримасы строит, какие эмоции проявляет, какие жесты использует, как долго смотрит в глаза, как часто отводит взгляд, как быстро отвечает на вопросы. И формирует своё заключительное «экспертное» решение, по сути, на голой интуиции. Ведь перед ним стоит задача «выбрать лучшего на текущий момент», а не «отсеять подходящих от неподходящих», и он не может пойти против этой задачи.

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

Проверка технических скиллов

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

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

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

Особенно мной нелюбимое — инспектирование очень мелких и сверх-специфичных деталей, место которым в Гугле, а не в моей голове. За что отвечает третий параметр в функции пузырьковой сортировки? Организуйте очередь двумя стеками. Как сделать выборку так чтобы не так, а вот так? Конечно, хорошо когда эти детали находятся в голове, программист экономит время, а фирма экономит деньги. Но чего вы никогда не узнаете задавая подобные вопросы — это что лежит у кандидата в голове ВМЕСТО этих знаний, знаний такой низкой ценности. Быть может там глубокое понимание асинхронности, а может навык подката к девочкам на вечеринках, но вопрос задан, время потрачено, собеседование на очередной шаг приблизилось к своему завершению, а вы разведали мало значимого.

Про просьбы скомпилировать с бумаги код в голове даже говорить не хочется. Вы на позицию ищите программиста или компилятор\интерпретатор? В повседневной рабочей рутине программист привык полагаться на среду, использовать ее возможности по максимуму, экономя своё «процессорное» время там, где это возможно. Поэтому неудивительно что такого рода задания выполняются медленно и часто не правильно. Вместо них было бы лучше спросить какими средами он пользуется и что ему в них нравится, быть может найдете для себя что-то новое, вкусное.

Есть ли выход?

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

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