РАБОТА · 18 ноября 2017, 10:30 · Отдел информации dev.by
Почему крутые разработчики не получают работу: четыре истории из жизни

Бывший инженер, а ныне технический рекрутер Иван Гуленко рассказал HackerNews четыре истории, в которых опытным инженерам отказывали в работе. Причины не связаны с их профессионализмом или культурными особенностями. dev.by приводит краткий перевод этих хоррор-стори.

Кандидату отказали из-за фреймворка

На роль фронтенд-разработчика я собеседовал опытного инженера, который внёс большой вклад в развитие ECMAScript и открытого исходного кода. Мне потребовались недели, чтобы его найти, и часы, чтобы оценить.

Его кандидатуру отклонил инженер компании, который около 10 минут не мог найти отправленный ему код. Этому кандидату фирма прислала стандартный ответ: «Несмотря на то, что ваше резюме и сопроводительное письмо были конкурентоспособными, наша команда по найму не выбрала вашу кандидатуру для дальнейшего рассмотрения».

Это был действительно плохой ответ. Прочитав его, я бросил всё и поехал в их офис, чтобы поговорить с человеком, который отказал лучшему инженеру из всех, кого я собеседовал в 2017 году. Инженер-интервьюер не мог чётко ответить на мой вопрос, по его мнению, «код был over-engineered», хотя на самом деле код был хорошо структурирован, и все операторы и функции были на месте. После 10-минутного разговора причина отказа стала мне более понятной: кандидат использовал фреймворк, который был неизвестен интервьюеру.

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

Что ещё хуже, после такого обращения кандидат в принципе не хотел больше иметь дело со швейцарскими работодателями.

Экс-гуглер не знал наизусть формулу Байеса

Кандидата, проработавшего в Google четыре года, собеседовали на роль Python-разработчика. Перед тем как представить инженера работодателю, коим был стартап, я переживал, что экс-гуглер может запросить зарплату выше рыночной. Но его требования оказались вполне разумными, он просто хотел работать в гармоничной команде с интересными техническими вызовами. Он прошёл несколько интервью и произвёл впечатление на большинство людей, с которыми беседовал.

Но на собрании один человек встал и сказал, что кандидат не знает и не может объяснить формулу Байеса, поэтому его не стоит нанимать. Ситуацию спас техлид — единственный человек в команде, обладающий «толстой кожей». Он дал понять, что незнание таких вещей — глупая причина, чтобы отклонять кандидатов. В итоге они взяли этого человека, и он оказался самым ценным сотрудником, которого когда-либо нанимала компания.

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

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

Pixabay

Эйчар забыл связаться с кандидатом

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

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

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

Кандидат лучше интервьюера, поэтому не подходит

У меня был случай, когда, на мой взгляд, кандидат оказался лучше, чем интервьюер. Это был 22-летний парень, гений для своего возраста, и его отклонил на этапе скрининга кода другой парень, назовём его Джон. Я был так потрясён отказом, что организовал звонок с тремя людьми: HR, Джоном и мной. Причины, по которым Джон отклонил кандидата, были смешными, и я не мог понять, говорил ли он это всерьёз. Джон указывал на некоторые проблемы в коде кандидата, которые мы могли видеть на общем экране. Всё, что он упомянул, было скорее стилистическими, а не реальными проблемами.

Другие вещи, которые он критиковал, выглядели довольно неказисто с точки зрения неопытного человека (громоздкая конструкция «try catch», с которой взаимодействовал код, блокировала API), но на самом деле у разработчика были веские основания, чтобы принять именно такие технические решения. И тут я вышел из себя, критика заставила меня упомянуть, что качество кода кандидата лучше, чем самого Джона на Github. HR остановил меня, сказав, что «мы здесь не Джона оцениваем». Было очень сложно сказать что-то в данной ситуации, поэтому я просто закончил разговор.

Отклонение кандидатов лишь потому, что они слишком хороши, неприемлемо. Тем более ужасно, когда интервьюер выбирает тактику фокусироваться сугубо на областях, в которых кандидат якобы не силён.

Вывод

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

Источник: dev.by
Новые комментарии

Обсуждение

Missing
-1

Доброго.

Исправляем, не задерживаемся: "и он оказалОсь самым ценным сотрудником"

Missing-male
+3

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

1) не назвал 3 "основные" концепции ООП, но это было скорее пре-интервью на какой-то ярмарке вакансий в БГУИР

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

3) не знал чего-то второстепенного которое учится за 2 дня

5ff4a98315c31dc46cf74865d3223f45?1400858147
+3

Вся проблема в последнем пункте. У каждого свое понимание, что второстепенно, а что нет.

Missing-male
panchesman
– Software Engineer в XB Software

Во-первых, я не говорил о проблеме, это просто констатация факта без моего личного отношения к этому

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

Missing-male
Dzmitry Martavoi
– Chief Software Engineer (.NET Primary) в Oxagile

+2

Какие-то небылицы Вы нам втираете, уважаемый: ни один интервьювер в РБ не откажет сильному JS разработчику из-за отсутствия опыта в TypeScript. И уж тем более, если речь идет об альтернативном опыте с фреймвоками из Вашего примера.

Тем не менее, кислая мина на лице, малопонятная речь и снобизм - может быть очень вероятной причиной отказа - и не важно как там микропроцессоры работают.

Missing

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

Missing-male
panchesman
– Software Engineer в XB Software

Отказывают.

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

Picture_5070?1356409952
-1

1) Вполне может быть, что сильный кандидат не использует ООП в своей практике (иначе назвать три основные концепции не составило бы для него никакого труда). Можно программировать в функциональном стиле или использовать классическое процедурное программирование. Но если кандидат ищет место в команде, ему нужно принимать общие правила игры. И ООП -- не та вещь, которую, не имея практики, можно освоить за 2 дня на достаточном для промышленной разработки уровне.

2) Если корпоративные правила предполагают работу в офисе, то "домосед" теряет всякую ценность. Компании в меньшей степени нужны амбициозные гении , нежели трудолюбивые нишевые сотрудники.

3) То, что "учится за 2 дня" для сдачи зачёта или экзамена, грозит серьёзными проблемами на реальном проекте. Если есть выбор кандидатов, то зачем рисковать?

Missing-male
panchesman
– Software Engineer в XB Software

+3

Доброго дня. Я так понимаю что это ответы на мои пункты. Тогда должен пояснить

1) мне было помоему тогда 19 лет, я учился в БГУИР и ООП мы просто не проходили

2) речь не шла о работе с дома, а просто сказал между прочим что живу тут буквально в 3 минутах пешком

3) ну, как я уже сказал, оценка происходит субъективно. Тем не менее факты имеют место быть. Конечно при прочих равных выгоднее смотрится кандидат с нужным BG. Ну и кроме того я не знаю случаев когда бы кандидатов после 2-х дней уже бросали в бой, в любом случае испытательный срок + начинают с более простых заданий. Даже самому опытному сениору нужно время чтобы разобраться в незнакомом проекте.

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

Бывают случаи что просто звёзды не сошлись.

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

Missing
-1

1) Вам было 19 лет, не проходили.. Интервьюер в чём виноват?

2) Ну "нахмурился", и что? Может что-то болеть, быть плохое настроение, да и вообще сложно сказать, о чём он там вдруг вспомнил из далёкого детства. Такая вот сложная штука люди, не стоит развивать в себе СПГС

3) И правда весьма субъективно

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

И да, это всё игра вероятностей, рисков, стоимостей. На испытательный срок всех не возьмёшь, к примеру. И к каждому не приведешь СЕО или СТО для оценки драйверов и скрытых ресурсов кандидата. И то и другое дороговато обойдётся. Поэтому навыки самопрезентации - тоже не пустой звук. Помогите людям по другую сторону стола вас услышать и правильно понять, не делайте из них оппонентов.

Missing
-1

Не стоит считать, что ООП - некое секретное знание, для понимания которой будет недостаточно нескольких дней. Лично мне было достаточно одного недельного занятия MITx 6.0.0.1x (https://www.edx.org/course/introduction-computer-science-mitx-6-00-1x-11) и 20-25 часов потраченного времени. Хватило даже на множественное наследование (оно конечно в питоне куцее, но есть). Врезалось в память намертво.

Короче говоря, важно 1) как подходишь к занятиям и 2) качество преподавания - Эрик Гримсон конечно на высоте, в тч по сравнению Джоном Гуттагом во второй части курса.

Picture_3860?1356409918
-1

Во везет, я вот запомнить не могу. Несмотря на то что изучал все эти концепции и в рамках обучения С, и далее в рамках изучения новой вышедшей версии ПХП 5, и в рамках визуал С позже. При этом я активно использую ООП даже в JS. Для меня в принципах ООП как бы нет никакого открытия, они как бы следуют из самой логики ООП. Поэтому для их использования мне не нужно знать какие то формулировки. Вообще я больше всего запомнил слова препода с универа "Вы не обязаны все это помнить, но вы обязаны знать где и что можно найти"


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси