Кратко о себе. Работаю в центральном аппарате крупного банка в должности исполнительного директора.
Как руководитель, я не особо разделяю гугловскую идею превратить собеседование в восхождение на Эверест, чтобы к нему готовились по полгода и складывали легенды аргонавтов о немыслимых испытаниях на пути к заветному оферу. Гораздо ближе мне словосочетание "необходимые качества для выполнения таких-то производственных задач", и как только установлено, что кандидат ими обладает, его следует брать на работу.
Но я замечаю, как кандидаты все дальше и дальше скатываются в инфантилизм и некомпетентность, и этому способствуют статьи-пожалейки про "синдром самозванца".
Иногда авторы и комментаторы договариваются уже до того, что даже тестовые задания при приеме надо поставить под вопрос, ибо "джентльменам надо верить на слово", и вообще задания - это неуважение к кандидатам; нормальный спец даже делать их не станет, либо берите "as is", либо я обижусь и уйду на следующее собеседование.
Но давайте подумаем, что лежит на другом конце "синдрома самозванца"? Нетрудно догадаться, что там находится нарастающая гора невыполненной (или имеющей явные признаки брака) работы - из-за которой, собственно, не справляющийся сотрудник и испытывает стресс и страх перед следующим рабочим днем. Гораздо больше вины в данной ситуации лежит на плечах руководителя, который не предвидел такого развития событий, а не собственно на этом сотруднике. Статей-пожалеек в пользу Синдрома Нанимателя Самозванца ("вы не виноваты! это у всех так!") пока никто не пишет, а вот за невыполненную работу, в итоге, по шапке получите именно вы.
Какие меры к просочившемуся к вам на работу самозванцу можно применить? Теоретически, можно уволить его "в связи с несоответствием занимаемой должности вследствие недостаточной квалификации". Но давайте будем честными, вряд ли кто-то из читающих делает это регулярно - и это неспроста. Необходимо идеально оформить непрохождение аттестации сотрудника, иначе через год оно будет оспорено в суде - кстати вместе с увольнением, и за этот год незаконно уволенному нужно будет заплатить. Так как большинство споров в суде решаются в пользу работника, любые силовые меры к нему - достаточно рискованное и дорогое удовольствие, и об увольнениях обычно договариваются по соглашению сторон, т.е. оплатив работнику отступные.
В связи с этим, в условиях российского ТК, собеседование имеет огромное значение; как фундамент для будущего дома (отдела), это самый ответственный этап, ошибка на котором дороже всего обойдется. Небрежность на этом этапе недопустима, и именно поэтому многие серьезные компании предпочитают работать c BodyShop`ами - чтобы не иметь таких проблем, ценой переплаты посредникам.
Почему я выступаю за обязательные тестовые задания? Давайте представим, что вы проводите собеседование в формате устного экзамена, как это было в ВУЗе. Как известно, экзамен - беседа двух умных людей. В ходе беседы, эти умные люди, внезапно, умничают (демонстрируют технические знания, кругозор, остроумие, логическое мышление), и соглашусь, что это весело и здорово - лично я все время бы этим и занимался. Но выходит, что именно этот навык (умничать) вы и проверили на собеседовании. Когда же сотрудник начинает умничать вместо выполнения поставленной задачи, мы расстраиваемся и понимаем, что как раз навык выполнения задач мы проверить и забыли. А ответы на вопросы легко можно заучить, и люди (какое коварство!) именно так и поступают.
В аспекте тестовых задач для программистов, во времена, когда я не занимался продуктами на Java/Scala и Python, все было отлично в 1С:Предприятии. Дело в том, что тестовое задание по созданию некоего учетного контура как раз укладывалось в час-два, что позволяло более-менее точно установить профессиональные качества человека, причем как технического характера, так и мотивацию, инициативу, клиентоориентированность, soft skills.
Но считается, что создание законченного мини-решения (хотя бы того же интернет-магазина) на JVM в сжатые сроки собеседования 1-2 часа нереально, поэтому тестовые задачи дают решать дома, что сразу делает их практически бесполезными: к заданию немедленно подключаются друзья, знакомые, платные репетиторы. В условиях короновируса, конечно, нужно искать выход - с опцией включенной фронтальной камеры и записи экрана, конечно, можно снизить этот риск подмены программиста.
Но нарастает нежелание кандидатов делать эти задачи в принципе, потому что их возьмут и так, без задач - в другое место. Лично я это вижу так: когда человек пришел в офис или подключился по ВКС, можно попросить его при вас выполнить какую-то задачу, но давать ему ее с собой на дорожку (особенно, если она часов на 30) - такое себе.
Давеча один мой коллега сказал, что на его взгляд, качество джуниоров сильно упало: не каждый джун осилит прийти на собеседование закодить консольные крестики-нолики. Кстати, челенж для джава-скалистов - слабо закодить их в 1 строку? ;)
Но положа руку на сердце, задача с крестиками-ноликам вообще не решила бы самых серьезных проблем, которые случались со мной и моими коллегами на протяжении карьеры.
Для начала я приведу весь список ситуаций, требующих внимания, а после отмечу, то, что из него волнует меня больше всего.
Ситуация | Как выявить на этапе собеседования? | Как исправить после приема на работу? |
Сотрудник не справляется с работой, хотя явно старается и находится в стрессе - классический самозванец, страдающий одноименным синдромом | Не ограничиваться типовыми вопросами, ответы на которые могут быть (и будут) зазубрены. Не пренебрегать тестовым заданием, дифференцировать его так, чтобы решение к нему нельзя было зазубрить без понимания смысла | Порекомендовать сотруднику список литературы для самостоятельного обучения + онлайн курсы, провести обучение на рабочем месте. Либо сотрудник наберет квалификацию, либо стресс вынудит его поискать работу попроще |
Сотрудник выполняет работу слишком долго, потому что занят развлечениями | Кандидат выполняет тестовое задание с неохотой, как будто делая одолжение; не может сфокусироваться; ставит под сомнение, что его вообще можно сделать быстро; на вопросы о переработках отвечает отрицательно. Кандидата не особо волнует карьера и денежное вознаграждение. | К сожалению, сейчас условие "на рабочем месте работать, развлекаться - дома" необходимо обговаривать отдельно при приеме; отсутствие доступа к развлекательным сайтам отпугнет многих кандидатов. Между тем, отсутствие такой паразитной активности - лучшее лекарство от выгорания, и вообще-то дисциплина для их же блага. |
Сотрудник выполняет работу слишком долго, потому что занят посторонними проектами либо своим стартапом | Кандидат явно слишком квалифицирован (overqualified) для вашего места, причем расти у вас особо некуда и задачи не столь уж для него интересные. У кандидата большие кредиты и/или большие амбиции. | Необходимо договориться о том, что ваши задачи в приоритете (хотя есть компании которые контролируют экран ПК и штрафуют за подобное); следует зафиксировать риск увольнения в случае, если альтернативные проекты перевесят ваш по интересности/прибыльности. |
Сотрудник допускает небрежности в оформлении кода, названии переменных, использует не совсем подходящие типы объектов и не производительные алгоритмы | Тестовое задание будет содержать все вышеперечисленное. Интерполируйте его на всю последующую работу, и прикиньте, устроит ли она вас | Существуют QG (в т.ч. встроенные в IDE), которые уберут хотя бы формальные проблемы - форматирование и стиль. Дисциплинарными мерами решается остальное. С другой стороны, всегда руководствуйтесь здравым смыслом - произойдет ли катастрофа от наличия переменной с неочевидными именем, если область ее видимости - 10 строчек? Если нет - это даже не техдолг. |
Сотрудник делает явные/грубые ошибки ошибки в коде | Тестовое задание будет выполнено небрежно, потребуется несколько раз уточнить условия и вернуть на доработку | Нужно детализировать задачи путем написания тестов, причем тест должен быть не формальным, а содержать условия приемки (TDD) - чтобы неверное решение просто не попадало на след. стадию тестирования и не отвлекало людей. Ввести стимулирование за отсутствие найденных (не собственноручно) багов |
Сотрудник допускает сложнообнаруживаемые ошибки, но их наличие уверенно отрицается, пока весь отдел не соберется вместе и не ткнет носом | Будут пробелы в знаниях в части многопоточности, конкурентного доступа, блокировок, управления памятью и потоками | Выполнять нагрузочное тестирование, анализировать блокировки и утечки памяти. Обучить этому сотрудника. |
Вместо четкого исполнения своих обязанностей, сотрудник занимается обсуждением/критикой задачи, решений, выбранных коллегами, настаивает на своем варианте и предлагает себя на роль Верховного Архитектора в Великом Проекте Переделки Всего с Нуля | На собеседовании кандидат излишне общителен, старается продемонстрировать высочайшую квалификацию (фактическую или мнимую), цепляется за малейшую двусмысленность в задаваемых вопросах и в условии тестового задания для создания дискуссии и победы в ней. Кандидат неохотно дает контакт прежнего руководителя, который сообщает, например, о попытке подсиживания и/или психологической несовместимости. | Можно попробовать объяснить сотруднику, что данная должность не место для самоутверждения, и общение не должно быть в ущерб выполнению собственных задач, отвлечение других сотрудников от их задачи неприемлемо, а "Проект переделки всего с нуля" в планах не значится. Но вообще-то, наличие эго-маньяка в коллективе, это очень плохо, лечится лишь увольнением. В аутсорсе есть риск попытки увода клиентов! |
Сотрудник не понимает ни поставленных задач, ни в кодовой базе проекта разобраться не может | Видимо, вы в отчаянии взяли лишь бы кого-нибудь | Придется очень долго растолковывать сотруднику каждую мелочь. Тем обиднее будет, если он решит, что набрался опыта и пора перепрыгнуть в другое место с повышением, а вы только что сумели переложить на него мелкие рутинные задачи. |
Сотрудник отлично выполняет свою работу, придраться не к чему | Накануне собеседования сильно везло в карты - удача частично перешла и на найм | Просто ничего не трогайте, но не забывайте индексировать з/п, и отмечать заслуги сотрудника на формальных мероприятиях |
Кто-то скажет, что самая большая проблема - сильно умничающий и переманивающий клиентов эго-маньяк. Но во-первых, я больше не владею 1С:Франчайзи, поэтому мне наплевать на увод их клиентов, а во-вторых, таких людей не так уж сложно выявить и просто не нанимать на работу.
Что на самом деле доставляет беспокойство - сложнообнаруживаемые ошибки, и пофигизм к ним. Появляются они, в основном, из-за недопонимания аспектов конкурентного доступа к разделяемым ресурсам, а также от недостатка аналитических способностей и квалификации, разумеется, начиная от уровня мидла.
Java программисты немедля скажут, что все это ерунда - у нас есть volatile, ConcurrentHashMap, Atomic - бдыщ, и все что хоть отдаленно напоминало проблему здесь, больше не существует. Скалисты добавят, что Akka позволяет еще и потоки не блокировать.
Но по опыту, самый головняк - это базы данных. Расскажу про несколько кейсов.
1. Однажды мне довелось пилить на Java систему управления транспортными конвейерами - на основе распознанной этикетки посылки или письма, определялась нитка конвейера, по которой предмет поедет дальше. В качестве хранения сканов был выбран (еще до моего прихода на проект) кластер MongoDB, причем воркеров-распознавальщиков было много, а контроллер конвейера работал на протоколе Modbus, датированном 1979г.
Как же я нахлебался с конкурентным доступом воркеров к задачам на распознавание! С одной стороны, MongoDB не давала простого, как в SQL, способа управления транзакциями, а давал compare-and-set (что крайне все усложняет, и наделать ошибок гораздо легче), с другой, сам кластер работал нестабильно, и норовил зафризиться; а за пару секунд посылка успевала уехать по конвейеру довольно далеко, и такой роскоши позволить было нельзя. Вдобавок, монгист в команде решил, что овладел эксклюзивными знаниями, без него все развалится, и потребовал удвоить з/п, после чего его с треском уволили, и с Монгой стало совсем кисло. Мораль: не пользоваться экзотическими инструментами, по которым нет отчуждаемой экспертизы. Иронично, что рядом стоял наготове оплаченный Oracle, но техдиру приспичило использовать вот это (по-моему, тогда на Хабре была мода на Монгу).
Но самое главное, что когда ценой ночных авралов Java-часть заработала как часы, и на презентацию нашего ИИ пришел заместитель руководителя Почты России, глюканул контроллер конвейера (чтоб вы понимали, у него внутри была установлена спец-версия Windows, а ответственность за настройку лежала на совершенно другом юрлице), и примерно треть посылок поехала вообще не туда; но так как никто из приглашенных не понимал, куда им было нужно ехать, презентации это не повредило.
2. Кейс про 1С:Предприятие, в котором, вроде бы, не особо много премудростей, но некоторые разработчики способны удивить и тут. В общем, прихожу на проект, а там помимо прочего, такая симптоматика - периодически адски нагружается SQL сервер, иногда на 10 минут, а иногда - на несколько часов, причем если транзакцию срубить посередине, то она и откатываться будет столько же времени, сколько прошло до этого. Мистика какая-то.
Оказалось, что молодой специалист получил от прошлого руководителя дурацкую задачу: заменить дату движения регистра с даты документа, на дату, указываемую в строке этого документа - и точно так же по-дурацки четко ее выполнил. А она, сюрприз, загружалась юзерами из какого-то левого Экселя. В результате вместо 01.01.2015, часто устанавливалась 01.01.15, что для 1С немного не то же самое (это 15 год от Рождества Христова). Фактически, это означало пересчет (в транзакции!) итогов складского регистра остатков на каждый долбанный месяц в течении 2 000 лет - и хорошо, если в документе было 2 строчки (5 минут), а иногда туда иногда грузили документы и по тысяче строк (5 часов на проведение 1 документа с полной блокировкой проведения в остальных клиентах 1Ски).
Самое забавное, что этот дрим-тим - руководитель и молодой специалист, не то, что не смогли расследовать проблему (я и сам раскопал этот кусок кода не в первую минуту, т.к. даже не представлял, что такое можно накодить в здравом уме), они умудрялись НЕ ПРИЗНАВАТЬ ПРОБЛЕМУ несколько месяцев, кивая на "тупого DBA"! Ряд офисных работников даже уволились из-за этого разгильдяйства, но руководство смотрело на ИТшников, как на священную корову, и даже не наказывало (а смысл тогда напрягать нервные клетки?).
Есть, конечно, эмигрировавшие снобы, которые скажут - ну лапотная Россия же, что вы хотели, на Благословенном Западе этот порок давно изжит, тут багрепортеров кормят с ложечки и награждают как героев, а баги мгновенно исправляют. Но:
...Но посмотрите на мой багрепорт в tensorflow, по поводу падения производительности в 10 раз на десериализованной (для дообучения) нейросети. Точно также как в лапотной России, всем плевать - мы не смогли воспроизвести на colab'е (с тех пор как я выбрал лимиты colab, у меня свой RTX дома), да и черт с ним с багом - ты, скорее всего, врешь, тупой юзер.
Если вы знаете, как отбирать людей, с гарантией 100% не ведущих себя так - поделитесь, пожалуйста.
3. Кейс вообще за гранью добра и зла. Мы работали в стартапе федерального масштаба, который иногда проводил некие акции, дающие скидки клиентам при определенных условиях. Ведущий программист (Ваня, привет!), считающий себя звездой, внедрил данный функционал (бизнес-логика, встроенная в CRM на PHP) прямо накануне своего отпуска, протестировав его, видимо, на единичном заказе - или, может быть, в уме. И уехал в отпуск.
Результат: половина клиентов получила при доставке чеки, существенно превышающие сумму заказа в личном кабинете. Разумеется, люди либо отказывались от заказов (а мы попадали на доставку), либо оплачивали превышение, но рассказывали об этом беспределе 10 своим знакомым, добавляя от себя, что мы занимаемся тупым обманом (а что-то тупее вряд ли можно придумать) и иметь дел с нами не следует никогда .
Другая половина клиентов, наоборот, благодаря щедрости нашей рок-звезды, получила заказы с уменьшенной (иногда вдвое) суммой. Разумеется, эти-то с радостью забирали товар, и в будущем получить с них недостачу было невозможно.
Так как данный программист почему-то был в прямом подчинении нашего гендира, то он был сурово наказан... устным замечанием, то есть фактически ему вытерли слюни и поправили соску. Насколько мне известно, примерно в таком же стиле он и продолжает создавать свои нетленные шедевры, а гендир (Сережа, привет!), после бесславного сокращения своего направления, устроился в Amazon - и нормально продолжает свою карьеру.
Обратите внимание, основные проблемы возникают отнюдь не с джунами (да, кейс №2 делал джун, но дурацкую задачу ставил и ревьюил сеньор) - с мидлами, сеньорами и техлидами. Пока программисты не начнут просчитывать последствия своих действий для бизнеса, и для их творчества не будет настроен обязательный и тщательный процесс тестирования, такого рода проблемы на продакшене продолжат возникать.
И вы таки спросите, а как же ты предлагаешь проверять прямо на собеседовании, в одной тестовой задаче, и SQL, и конкурентность/многопоточность, и бизнес/клиентоориентированность + софтскилы?
А я вам отвечу: в прошлой своей статье я как будто нарочно для вас накарябал скелет трехзвененого приложения, с SQL и всем необходимым для проверки программистов! Уж в 80-то строках кода за час любой сумеет разобраться!
Наиболее циничным заданием для романтизированного джуна, который ляпнет на собеседовании, что пошел в программисты, потому что хотел делать игры, будет предложение запилить на этом скелете многопользовательскую игру в стиле Interactive Fiction, в которые играли наши отцы и деды, у которых даже не было компьютера:
Но вообще, различных задач для тестового задания на этой базе можно придумать ни один десяток, особенно если вы нанимаете fullstack, и клиент все-таки будет Web.
Это может быть CRM, партнерская программа, социальная сеть, да что угодно - не все же мне придумывать за вас!
Удачи в найме!
Видео-спич, плюс-минус на эту тему:
