Кратко о себе. Работаю в центральном аппарате крупного банка в должности исполнительного директора.
Как руководитель, я не особо разделяю гугловскую идею превратить собеседование в восхождение на Эверест, чтобы к нему готовились по полгода и складывали легенды аргонавтов о немыслимых испытаниях на пути к заветному оферу. Гораздо ближе мне словосочетание "необходимые качества для выполнения таких-то производственных задач", и как только установлено, что кандидат ими обладает, его следует брать на работу.
Но я замечаю, как кандидаты все дальше и дальше скатываются в инфантилизм и некомпетентность, и этому способствуют статьи-пожалейки про "синдром самозванца".
Иногда авторы и комментаторы договариваются уже до того, что даже тестовые задания при приеме надо поставить под вопрос, ибо "джентльменам надо верить на слово", и вообще задания - это неуважение к кандидатам; нормальный спец даже делать их не станет, либо берите "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, партнерская программа, социальная сеть, да что угодно - не все же мне придумывать за вас!
Удачи в найме!
Видео-спич, плюс-минус на эту тему:
Комментарии (150)
bjornd
30.07.2021 10:25+52Здравствуйте, добро пожаловать на собеседование на роль исполнительного директора в центральном аппарате крупного банка. Вам предлагается тестовое задание, которое нужно выполнить за два часа. Условия следующие - вам нужно создать банк, подписать договор с первым клиентом и провести первый платеж через SWIFT. Да, платеж должен быть настоящим, нет, больших нагрузок для такого тестового задания не предполагается. Удачи, спасибо.
Areso
30.07.2021 16:26+1исполнительного директора в центральном аппарате крупного банка
пахнет Сбербанком :)
i360u
30.07.2021 10:26+57Автор совершенно не понимает сути термина "синдром самозванца". Ну и много чего еще.
mikhailian
30.07.2021 11:28+4Хочу посоветовать автору прочитать
In Praise of Idleness Бертрана Рассела
On the Phenomenon of Bullshit Jobs Девида Грабера
Именно в таком порядке.
А потом критически оценить задачи, которые выполняют его программисты. Есть подозрение, что многие задачи вдруг окажутся ненужными, бесполезными и просто вредными. И чем хуже задача, тем хуже работают программисты.
Кроме того, единственными успешными и продуктивными программистами будут те, кто нашёл себе более-менее осмысленную нишу в миграции с Java 8 на Java 11, в настройке CICD, в написании плагинов для gradle и в других мало относящихся к бизнесу задачах.
edo1h
30.07.2021 11:29+4Автор совершенно не понимает сути термина "синдром самозванца"
А разве в любой статье со словом «самозванец» должна идти речь об этом синдроме? Автор пишет об его антиподе, можно назвать «синдроме гения»: человек переоценивает свои способности и/или не замечает своих слабых сторон.
Не могу не согласиться, что такая проблема тоже есть. Правда, общий настрой автора показался несколько «людоедским» (но тут можно сказать, что тема статьи обязывает).
ledascho
30.07.2021 14:07+12классический самозванец, страдающий одноименным синдромом
Самозванец не может страдать одноименным синдромом просто по определению этого синдрома:
Despite external evidence of their competence, those experiencing this phenomenon remain convinced that they are fraudNikita001 Автор
30.07.2021 22:45-10А давайте немного отвлечемся от цитирования Википедии, и обратимся к здравому смыслу.
И коль уж мы начали считать СС некой болезнью, больных которой надо пожалеть (хотя вообще-то, даже ваша Википедия ставит это под сомнение), давайте рассмотрим ее генезис.
А генезис таков, что когда человек является дилетантом и профаном в какой-то сфере (их-то я и называю самозванцами), он испытывает беспокойство по поводу превосходства коллег. Но у некоторых это проходит - когда они набирают квалификацию, а у некоторых, вроде как, длится подольше, или иногда не проходит вообще (хотя по некоторым оценкам, это просто черта характера, типа заниженной самооценки).
Но, вот еще бывает, что у активных спортсменов, после упражнений или состязаний, болят мышцы. И если спросить тренера, что это такое, будет ответ: так это ж микротравмы и молочная кислота!
И вот некоторые спортсмены продолжают тренероваться, и мышцы у них болеть практически перестают, так как приспособились. Но представьте такого человека, который скажет: Микротравмы? Так я травмирован! Начерта тогда нужен ваш спорт, уйду-ка я на месяцок в отпуск отдохну.
Несложно догадаться, что когда этот тепличный цветок вернется, на расслабоне подлечив свой "синдром", остальные его коллеги уже уйдут вперед - и соревнуясь с ними, гораздо легче "травмироваться". Круг замкнулся.
Вот и вся суть вашего синдрома до копейки.
Думаете, остальным приятно получать задачу на неизвестном языке, фреймворке или сложной предметной области? Мы точно также испытываем дискомфорт - разница в том, что одни не спят ночами, сжимают зубы и делают дело, а остальные ходят и жалуются как им тяжело.
ledascho
30.07.2021 22:53+7Это прекрасно, что вы взяли термин, вложили в него тот смысл, который вам нравится, а потом легко решили проблему — «надо просто сжать зубы, перетерпеть и больше тренироваться». Попробуйте теперь с любым другим синдромом из, гм, Википедии. Не советую, впрочем, начинать с ПТСД — у страдающих им, говорят, встречается весьма агрессивная реакция.
Nikita001 Автор
31.07.2021 12:38-4Попробуйте теперь с любым другим синдромом из, гм, Википедии. Не советую, впрочем, начинать с ПТСД
Очень лестно, наверное, сравнивать недоучку в легкой депрессии с ветераном, рисковавшим жизнью за свою страну. Но дело в том, что (в Википедии написано):
ПТС - Посттравматическое стрессовое расстройство
в отличие от
Синдром самозванца не считается психическим расстройством и не содержится в МКБ-10 и DSM-IV ... Чтобы избавиться от синдрома самозванца, нужно превозмочь в себе определённые предрассудки
Другими словами, это просто американские психологи ввели между собой такое словосочетание, чтобы удобнее деньги было стричь с маменькиных сынков, которые не могут без посторонней помощи "превозмочь предрассудки", и подсадить их на Прозак.
Причем я вам об этом написал еще в прошлом комментарии, но вы с упавшим забралом, похоже, плохо читаете - иначе бы сами открыли Вики, куда вы меня посылаете, и разобрались самостоятельно.
Состояние моей кармы сейчас, к сожалению, не позволяет мне много отвечать на вопросы телезрителей даже под моей собственной статьей - и роскошь отвечать особо одаренным по два раза пока недоступна.
Поэтому, всего хорошего.
nApoBo3
31.07.2021 12:07+2Имхо вы решили проблему через переопределение.
Синдром самозванца, это ни когда вам тяжело. Это когда вы думаете, что не справляетесь, но ваши результаты соответствуют рынку. Очень важно, ваши результаты не хорошие или плохие, не высокие или низкие, а рыночные или не рыночные. Не рыночная оценка своих результатов приводит к многим негативным для человека последствиям:
Выбор не оптимального для рыночных условий вектора развития.
Не оптимальное распределение собственных ресурсов, вы тратите их на те задачи которые не дадут лично вам плюсов.
Демотивация.
Снижение собственной "монетизации", вы не пытаетесь получить больше на текущем месте.
Занижение собственной стоимости при выходе на рынок. Что интересно, это редко приводит к ускорению поиска работы, работодатель часто не готов взять работника на ЗП ниже рынка по целому ряду причин.
evgeniyPP
07.08.2021 15:08+1"Я знаю, что ничего не знаю"
Сократ
Синдром самозванца вызван парадоксом познания: "Чем больше ты знаешь, тем больше ты понимаешь, как много ты еще не знаешь".
Поэтому он особенно популярен у программистов. Ты просто забыл, как много тебе пришлось выучить, чтобы дойти до текущего уровня. Лучшее лечение – начать учить кого-нибудь с нуля.
Другая проблема – это то, что данной проблемой (которой страдают именно опытные работники) чересчур самоуверенные новички оправдывают свою некомпетентность.
i360u
31.07.2021 11:45+1>> А разве в любой статье со словом «самозванец» должна идти речь об этом синдроме?
Вот прямая цитата:
>> Но давайте подумаем, что лежит на другом конце "синдрома самозванца"? Нетрудно догадаться, что там находится нарастающая гора невыполненной (или имеющей явные признаки брака) работы - из-за которой, собственно, не справляющийся сотрудник и испытывает стресс и страх перед следующим рабочим днем.
bezarius
30.07.2021 11:36+26> Ведущий программист (Ваня, привет!), считающий себя звездой, внедрил данный функционал (бизнес-логика, встроенная в CRM на PHP) прямо накануне своего отпуска, протестировав его, видимо, на единичном заказе - или, может быть, в уме. И уехал в отпуск.<
Ну это совсем какая то дичь. Из разработчиков не очень тестировщики, это хорошо известный факт, и по этому существует QA. Вопрос, а где был QA, или кто так классно выстроил процессы, что кто то может вот так просто взять и залить на прод не протестированный функционал?
Ну а на счет тестовых заданий, складывается впечатление, что вы немного не в курсе того, что происходит на рынке труда. Сейчас, хороший разработчик, получает по несколько предложений в неделю. В год легко может получиться больше сотни предложений. Думаю очевидно, что разработчик сначала будет рассматривать варианты где не нужно будет выполнять тестовые. Соответственно тестовые могут себе позволить только очень "популярные" компании.
Wan-Derer
30.07.2021 23:22залить на прод не протестированный функционал
залить на прод не протестированный функционал, завязанный на деньги! :)
uhf
01.08.2021 08:49Ну это же стартап федерального масштаба, скорее всего, там вообще не было QA, а задачи ставились по мессенджеру в формате: «Вань короче клиент хочет акцию чтобы скидка на зеленое в понедельник нечетного месяца и двойные бонусы тем кто без скидки за неделю до этого только для любимых товаров».
Aziza_Tramp
02.08.2021 12:37Из-за кармы не могу плюсануть, но при прочтении тоже не поняла - как так? Без теста запустили в продуктивную среду? Не спорю, бывали случаи, когда ошибка выявлялась не сразу, а через полгода выстрелила на редкой ситуации, но это за всю практику пару раз было.
Nikita001 Автор
02.08.2021 14:11+1Посмотрите, в другой ветке комментов подробно пояснил про Ваню и как его сырой код попал в продакшн.
Aziza_Tramp
03.08.2021 06:44+1Это я прочла. Но опять же, это не вина программиста, тут явно проблема в менеджменте, и вы сами это отметили. Просто описанная ситуация не вяжется со всей статьей, поэтому она и вызывает массу удивления. Ситуация с 1С-программистом тоже мягко говоря странная, ошибки конвертации из других источников почти сразу на тесте выявляются, даже на этапе разработки. Тоже ситуация из разряда плохого менеджмента, и опять же - не вяжется со статьей. Ну и первая описанная вами ситуация это 50/50 - недостаточный тест и закон подлости, такое бывает. Я понимаю, вы выделили, что пришлось разбираться с технологией по прихоти техдира, но... это вопрос к техдиру, опять же - не вяжется со статьей. О том, что есть адекватные специалисты и неадекватные, вопрос вообще не стоит, но... это в любой специальности. Просто вы описываете такие серьезные проекты, и тут же удивляете "странностями" при полном процессе разработки, тестирования и ввода в эксплуатацию.
ganqqwerty
30.07.2021 11:38+31Автор почему-то забывает, что мы на рынке. Вас, банков с исполнительными директорами - много, а их, толковых разработчиков - мало. Вы все одинаковые, у вас средненькие задачи и средненькая зарплата. Поэтому это разработчики приходят к вам и устраивают вам экзамены, ищут красные флаги, а не наоборот. Видят какой-то не приличествующий статусу выпендреж - пожимают плечами и идут от вашего Банка1192 к Банку1193. Вы, вроде, даже картинку приложили в самое начало статьи, вы думаете, что она какая-то ироничная и не правдивая?
Если хотите развернуть ситуацию - поднимите зарплату на позиции раза в два-три. Тогда претендентов станет много, а позиций мало, и можно будет рассуждать о том, как же их отсеивать. FAANG'и изголяются как могут и ничего им за это не будет, все равно по тысяче человек на место.
Jack_Rabbit
30.07.2021 11:42+22Если вы выкатываете изменения в "стартапе федерального масштаба" без полноценного тестирования, то проблема в организации процесса разработки, а не в конкретном исполнителе.
Да, люди совершают ошибки и это маленькое обстоятельство нужно как-то учитывать. Можно ведь было нанять тестировщика, чтобы он проверил работу приложения? Можно. Можно ведь на определенном этапе озаботиться автоматизацией тестирования перед запуском в релиз? Тоже можно.
Arashi5
30.07.2021 11:42+10Любое тестовое задание - не показатель. А главное, я вас не понимаю, почему даже в заголовке статьи, вы видите разраба - как потенциального врага. Может все такие стоит пересмотреть такой подход.
А если по теме - топ задача на собеседованиях, которую я встречал - когда дают кусок рабочего кода, и просят его прокомментировать и доработать. 15-20 минут времени на анализ, и далее просто рассказываешь, что тут происходит, и что не так и что стоит переделать. Код - изначально рабочий, но написанный на коленке за 5-10 минут.
И тут:
И скилл работы с легаси.
И знание паттернов.
И знание алгоритмов.
И всякие SOLID, KISS, DRY и прочие друзья.
И знание языка.
И встречные вопросы.
И так далее и тому подобное.
PS Главное не говорите, что в вашем проекте, нет такого участка кода. И если вы говорите, что ваш проект идеале, то скиловый разраб у вас работать, разумеется, не будет.
PPS Хочешь захантить хорошего разраба. Думай как хороший разраб.Nikita001 Автор
30.07.2021 11:46-8когда дают кусок рабочего кода, и просят его прокомментировать и доработать.
Так а я же почти в точности это и предложил в конце.
Только в обратном порядке - сначала доработать, и если кандидат справится, разумеется, обсудить.
bjornd
30.07.2021 17:34+4Ну, уважаемый кандидат, так не пойдет, два часа уже прошло, а вы даже название для банка не выбрали.
mikhailian
30.07.2021 11:54+1Вы видите разраба - как потенциального врага
Между нечеловечески честной машиной и хитрым менеджментом разработчик как между молотом и наковальней. Менеджеру это не понять, даже если он вечерами играется с tensorflow.
Отсюда у менеждера постоянное напряжение: почему не делается то, что он говорит и делается что-то совсем ему не нужное.
Из напряжения возникает ненависть к программистам.
a1ex322
30.07.2021 14:11+4Вот это стояние над душой, смотрение, а что я делаю и как такой гигантский стресс вызывает. Как же я рад что меня с такого проекта убрали. Такой менеджмент не имеет ничего общего с личной заинтересованностю. Все, что им перепадает это итальянская забастовка
luckman
30.07.2021 11:44+17Охренеть у вас процессы.
Джуна по задаче работы с датами в из левых источников проверяют при помощи код-ревью, а сеньору можно сразу в прод финансовую задачу, после того, как пару тестов прогнал.
Похоже дело отнюдь не только в программистах.
CyaN
30.07.2021 11:46+9Но по опыту, самый головняк - это базы данных.
Чаще - не базы данных и их функциональность, а данные в них. Ну и data flow.
По теме: давно для себя выработал один основной критерий на собеседовании - общая адекватность претендента. Если человек неадекватен, то, каким бы идеальным по техническим скилам не был, проблемы в дальнейшем будут гарантированы. Если адекватен, то скилы подтянет, а первое время не грузить задачами, сильно выходящими за границы его компетентности. В примере с "мегазвездой" - если он не просто говорит, что все, что сделано раньше - говно, но и технически грамотно это обосновывает, уделяя внимание возможным рискам, и предлагает пути управления таковыми, то, как показывает практика, стоит
1) прислушаться к тому, что он говорит,
2) найти для него подходящие задачи и выбить, при необходимости, ставку.
Если не может обосновать - ну тогда да, неадекватные нам не нужны.
Ну и главное, о чем регулярно забывают при выборе сотрудника: лучшее - враг хорошего. В поисках идеального кандидата теряется время и пусть не идеальные, но толковые специалисты.
dom1n1k
30.07.2021 11:55+11Как у народа бомбануло-то... Автор местами перегибает палку, но тем не менее, в его словах есть изрядная доля истины.
Tyusha
30.07.2021 15:39+1Тех, кто нанимает, по определению меньше тех, кого нанимают, отсюда и перевес минусов к статье.
siziyman
30.07.2021 15:55+4А если не писать ахинею, то те, кого нанимают, не будут минусовать.
Я, программист, в диалогах с другими программистами регулярно (в некоторых контекстах) защищаю эйчаров/нанимающих и критикую программистов. Тут проблема не в "стороне конфликта", а в том, что автор в статье делает совершенно невменяемые выводы из того, что сам же описал.
Nikita001 Автор
30.07.2021 16:21-3невменяемые выводы
Например?
siziyman
30.07.2021 17:05+15Ведущий программист (Ваня, привет!), считающий себя звездой, внедрил данный функционал (бизнес-логика, встроенная в CRM на PHP) прямо накануне своего отпуска, протестировав его, видимо, на единичном заказе - или, может быть, в уме. И уехал в отпуск.
Как примерно десять раз сказали в комментариях, в такой ситуации у вас хтонический ужас невообразимых масштабов в первую очередь с процессами разработки и введения в эксплуатацию, если такое даже теоретически может произойти. Делать вывод "программист плохой и в нём проблема" - очевидная, казалось бы, ошибка.
Nikita001 Автор
30.07.2021 21:25-3Делать вывод "программист плохой и в нём проблема" - очевидная, казалось бы, ошибка.
Предрекали, что вы выведете меня на чистую воду, процитировав мои невменяемые слова, а не припишите мне какую-то свою глупость.
Вот моя цитата, полностью противоположная тому, что приписали мне вы:
Гораздо больше вины в данной ситуации лежит на плечах руководителя, который не предвидел такого развития событий, а не собственно на этом сотруднике.
Что же до звездного PHP программиста Вани, пожалуй, следует пояснить. Я тогда работал в роли старшего программиста/руководителя группы 50% разработки / 50% руководства. И на этот, хотя и смежный с нами участок, вообще никакого влияния оказать не мог.
У меня, и у Вани были разные руководители, подчинявшиеся гендиру, которые кое-как пытались выстроить процессы. Но в какой-то момент Ваню хотели перевести к нам в команду, и на это он заявил, что слишком крут, и будет подчиняться только гендиру (о таких тайных желаниях программистов быть поближе к боссам каждая вторая статья на Хабре Ивана Белокаменцева - в отличие от моей, пользуется большой популярностью).
В результате, над Ваней не осталось фактически никакого контроля (гендир не понимал в разработке и тестировании вообще ничего). Вот так его сырой код и попал в продакшн.
Что касается вины, она солидарная, Вани и Сережи: первый продемонстрировал незрелость, безответственность (выкатывать эту жесть в прод перед отпуском, не оставив заместителя, который все откатит, если что-то пойдет не так) и несоответствие заявленному уровню, а второй - некомпетентность, мягкотелость и отсутствие минимального контроля на критическом участке.
Exclipt
05.08.2021 20:58Вина не солидарная, т.к. начинается она именно с момента "над Ваней не осталось фактически никакого контроля ", виноваты тут гендир и те, кто могли (и должны были) ему указать на эту дикость, но не указали. Ваня еще нормально держался, мог без контроля и тестирования столько долговременных глубоких багов настрогать, что нагнулся бы стартап целиком даже без его отпуска.
AllexIn
30.07.2021 17:40+3Например о том, что разработчикам впадлу делать тестовые задания.
Впадлу делать бесплатно и на первом этапе отбора.
siziyman
30.07.2021 18:00+1Многим действительно впадлу, справедливости ради. Да и даже если нет, это не самое вопиющее в статье, как мне кажется. :)
dimaaannn
31.07.2021 14:10+1Особенно при учёте что таких "первых этапов" может быть десяток, делать каждому тестовое задание на 2 часа - из разряда мазохизма.
ITSolncev
12.08.2021 23:40А вы бесплатно поработаете при капитализме, особенно, если считаете себя профессионалом с хорошей квалификацией и широким бэкграундом? (не важно кем вы работаете)
barbaris76
30.07.2021 11:56+16Работаю в одном банке немношк аналитиком, немношк DS, немношк программистом, немношк аудитором. Постоянно ищем на подобные вакансии ребят со знаниями математики, питона и т.п. Зарплата на начальных позициях не очень большая, поэтому текучка большая, многие долго не удерживаются и уходят, кто удерживается — растёт в должности и в ЗП, ну, всё как обычно.
Так я к чему это. С полгода назад случился конфликт у исполнительного директора и директора нашего управления. Испдира после этого потихоньку «ушли», и… о чудо, полгода без исполнительного директора — и как-то особо разницы не замечаем. А вот ребят-аналитиков не хватает. Такая вот поучительная история.
questor
30.07.2021 12:00+8но техдиру приспичило
получил от прошлого руководителя дурацкую задачу
Так как данный программист почему-то был в прямом подчинении нашего гендира, то он был сурово наказан... устным замечанием
Рыба гниёт с головы. В этих случаях прежде чем говорить о проблемах программистов, стоило бы о проблемах руководства поговорить.
jaddd
30.07.2021 12:10+25Кратко о себе - когда-то работал исполнительным директором на производстве. А сейчас PM в IT)
В статье слишком много пассивной агрессии. Читать банально неприятно, видно что у человека подгорает... Но зачем лично мне это читать - непонятно.
Синдром самозванца - это все же про ситуацию, когда человек считает свою компетенцию НИЖЕ реальной. А не наоборот.
Это тоже может выглядеть пассивной агрессией - но есть предложение автору порефлексировать над своей собственной компетенцией как руководителя и лидера.
Все люди лажают. Кто-то чаще, кто-то реже. Кто-то во всем винит только себя, кто-то кого угодно кроме себя. Кто-то нервничает после этого, а кто-то наоборот веселится. Это нормально, все мы люди. И всем мы разные люди...и все люди лажают. С этим надо жить. А уж если у тебя твой подчиненный налажал, а ты не подстраховался через процессы, через обработку рисков, через что-угодно... То и ты налажал... Но ведь это неточно)))
Люди не шестеренки и не ресурс... Как ни странно - они именно люди. Удобнее руководить шестеренками, особенно в банке... Но это удобнее не значит правильнее
dom1n1k
30.07.2021 12:24+4Синдром самозванца - это все же про ситуацию, когда человек считает свою компетенцию НИЖЕ реальной. А не наоборот.
Да это понятно. Автор имеет в виду, что популярные сейчас статьи могут воспитывать в некоторых людях ложный СС. Когда он вроде и понимал свои пробелы, но потом его уговорили, что это СС - а на самом-то деле он огого.
edo1h
30.07.2021 12:55-5Люди не шестеренки и не ресурс… Как ни странно — они именно люди. Удобнее руководить шестеренками, особенно в банке… Но это удобнее не значит правильнее
с одной стороны, да. но профессионал, приходя на работу (не обязательно буквально), должен выполнять роль «шестерёнки»: выполнять свою работу, а не рефлексировать, например, по поводу того, как вчера поругался с женой/мужем.
понятное дело, что это не совсем реально, но это то, к чему нужно стремиться.
ganqqwerty
30.07.2021 13:44А кто такой исполнительный директор? Это типа CEO, "самый главный"?
vadlit
06.08.2021 16:31Я так понял, вы знаете смысл должности CEO. Тогда загуглите расшифровку этой аббревиатуры, и все встанет на свои места
fougasse
30.07.2021 12:37+5А ТК РФ не подразумевает испытательный срок?
Вроде как за месяц-два-тои можно всё узнать, а если не увидели, что человек неподходящий - менять нужно и остальных членов команды.
RTFM13
30.07.2021 18:20Знакомые эйчары говорят, что с испытательного срока тоже сложно уволить.
mad_nazgul
02.08.2021 08:27Сложно, если не прописаны должностные обязанности. И не указаны цели, которые следует достичь (грубо говоря когда всем пофиг и бардак).
Бардак удобен, чтобы навесить 100500 левых функций, и загрузить по полной.
Но вот уволить трудно.
Так что тут идет отрицательный отбор.
В таких условиях "выживают" те кто ничего не делает.
Т.к. доказать что ничего не делает очень трудно.
А вот кто "делает" рано или поздно уходят.
serGR1
12.08.2021 23:40да будет вам известно что с испытательного не надо увольнять. просто не подписывается прохождение испытательного листа. всё.
Acheron
30.07.2021 12:57+8Между тем, отсутствие такой паразитной активности - лучшее лекарство от выгорания, и вообще-то дисциплина для их же блага.
Как раз таки работа 8 часов в к ряду без переключения контекста это прямой путь к выгоранию . Мозгу нужно время чтобы структурировать информацию и банально передохнуть, а вот такая вот "паразитная" активность, время от времени, это отличный способ не обнаружить себя критически уставшим и не способным толком общаться на не связанные с работой темы.
Вместо четкого исполнения своих обязанностей, сотрудник занимается обсуждением/критикой задачи, решений, выбранных коллегами, настаивает на своем варианте
...
Можно попробовать объяснить сотруднику, что данная должность не место для самоутверждения, и общение не должно быть в ущерб выполнению собственных задач
А потом они говорят что software engineer это челок, который не таски закрывает, а проблемы решает и тут, внезапно, таки приходиться обсуждать задачу (и даже иногда критиковать), потому что опять таки внезапно наличие плашки руководителя еще не означает высокую компетенцию и в частности умение правильно поставить задачу. Я неоднократно и лично, и у коллег, наблюдал как постановка задачи примерно никак не сходиться с тем что ставящий задачу хочет получить. Без обсуждения, обычно это заканчивалось или полной переделкой работы или разговорами в стиле "почему сам не подумал и не предупредил".
Nikita001 Автор
30.07.2021 14:26-6Вы просто пока не столкнулись с эго-маньяком. Их 1 шт. на 50 человек.
А мне, например, доводилось разрешать конфликт, когда чуть до мордобоя не дошло - потому что видите ли джун перебил нашу рок-звезду (а по статусу не положено).
Ну и далее, регулярные обсуждения на ровном месте - не потому что есть какие-то значимые принципиальные проблемы в задаче, а потому, что, повторюсь, нужно создать дискуссию и в ней победить. Это важно, они питаются такими победами и без них работать не смогут.
А переделка всего с нуля необходима, как в прайде у львов, чтобы не осталось и следа того, то до прихода нашей звезды кто-то что-то полезное сделал. Оплатить такую переделку предполагается за счет денег, которые не получат акционеры, но презентовать ее им нужно будет вам, а как вы это сделаете - вряд ли эго-маньяка волнуют такие мелочи..
siziyman
30.07.2021 15:58+8А мне, например, доводилось разрешать конфликт, когда чуть до мордобоя не дошло - потому что видите ли джун перебил нашу рок-звезду (а по статусу не положено).
Поздравляю, ваши хайринг-процессы допустили найм неадеквата. Тюньте хайринг-процессы.
Вы б лучше сказали, зачем вы предлагаете программистам вести себя как рабы на галере с вашим "отсутствием паразитной активности".
Nikita001 Автор
30.07.2021 17:00-5Тюньте хайринг-процессы.
Эта как раз была статья про тюнинг хайринга, а не про оскорбление чести и достоинства благородных разработчиков, как кто-то мог подумать.
зачем вы предлагаете программистам вести себя как рабы на галере с вашим "отсутствием паразитной активности".
Это рекомендация на 1 конкретную ситуацию. Представьте - по задаче нет прогресса 1,2,3,4 дня - и каждый раз проходя мимо сотрудника, вы видите развлекательные сайты, то есть это его слабость - он не может сам себя здаставить заняться работой - а виноваты в этом вы, поскольку позволили это. Профессионально он, прололжая в таком духе, точно не вырастет, и поэтому, работать на работе - для его же блага.
А другая ситуация - у сотрудника на данный момент наилучшая производительность в команде, так у кого повернется язык попрекать его, кто будет высматривать, что там на мониторе? Но надо понимать, что это привилегия, она дается по заслугам, а не по дефолту.
К каждой ситуации нужен свой подход - именно поэтому там и таблица, а не совет "управляйте хорошо, и все будут работать хорошо".
siziyman
30.07.2021 17:56+6по задаче нет прогресса 1,2,3,4 дня - и каждый раз проходя мимо сотрудника, вы видите развлекательные сайты, то есть это его слабость - он не может сам себя здаставить заняться работой
А вы проходите мимо сотрудника раз в 15 минут, или как часто, что вы делаете такие выводы? Если да, раз в 15 минут - вам точно надо в погонщики рабов на галерах, а не в управленцы в IT-компании, уж извините, потому как такие процессы демотивируют работать, особенно в долгой перспективе, абсолютно всех, кого я знаю.
Если же вы не стоите за спиной разработчика буквально весь день, на что я очень надеюсь ради вашего с разработчиком ментального здоровья, то в ситуации "по задаче нет прогресса 1-2-3-4 дня" надо разговаривать с сотрудником, возможно с участием других людей с технической экспертизой и доменным знанием, а не делать скоропалительные выводы. И да, причины могут быть разные - в задаче могут быть непредвиденные сложности, которые снаружи воспринимаются как "нет прогресса". У самого сотрудника могут быть сложности какого-то вида, начиная от "приболел, голова не соображает", заканчивая "поругался с женой/мужем/девушкой/парнем, сконцентрироваться тяжело" или "продаю квартиру, 5 часов в день в банке и у юристов, не до того". А в развлекательные сайты я на работе тоже нередко смотрю, пока, например, у меня тесты сервисов гоняются (что может происходить 15 минут кряду), а параллельно в голове вертеть ту же проблему или уже следующую.
Профессионально он, прололжая в таком духе, точно не вырастет, и поэтому, работать на работе - для его же блага.
Не надо пожалуйста за других людей решать, что для их блага, а что нет, потому что у вас могут быть очень разные представления о том, что вам нужно. Например, сотруднику может быть нужно не поехать крышей или хотя бы не выгореть под надзором начальника, который каждый раз проверяет, что у сотрудника на мониторе, проходя мимо.
Nikita001 Автор
31.07.2021 15:50А вы проходите мимо сотрудника раз в 15 минут
Разумеется, реже - но проблема не во мне, а в том, что остальная часть команды тоже прекрасно видит, что они напрягаются и двигают телегу, а кто-то прилег на нее и выезжает за счет других, получая зарплату наравне со всеми.
надо разговаривать с сотрудником, возможно с участием других людей с технической экспертизой и доменным знанием
Разговаривать - разумеется, кэп. Но то о чем вы говорите - вообще другой пункт в таблице - и если человеку действительно не хватает экспертизы, и он озабочен ее набором, у него будет открыт stackoverflow.com, а не развлекалово.
Не надо пожалуйста за других людей решать, что для их блага
Не надо пожалуйста подписывать трудовые договора, а потом делать вид что ТК РФ - для дураков (но вы ЗПшечку-то платите без задержек, иначе засудим), мы с парнями на Хабре решили, что у нас от работы будет выгорание.
В ТК есть небольшой намек, что "В течение рабочего времени сотрудник должен исполнять свои должностные обязанности, установленные трудовым договором (ст. 21 ТК РФ). Это означает, что сотрудник не вправе использовать рабочее время в каких-либо других целях, кроме работы." Кстати, там в ТК же есть про паузы на отдых - которыми все постоянно пользуются, выходя покурить - но этого же мало, надо еще и на рабочем месте устроить себе отдых в пропорции к работе 50/50, а то и 95/5. Вот эта картинка, она не случайно появилась:
И да, большая часть сотрудников не контролируется и не наказывается за это все, но повторяю для особо одаренных - это привилегия за хорошую работу, с чего вы решили, что это вам подарок по умолчанию, за то что вы вкатились в ИТ? Чем другие профессии хуже?
Недавно довелось ехать между городами на коммерческом микроавтобусе. Так балбес-водитель, у которого кстати на переднем сиденье ехал ребенок, достал телефон и довольно долго смотрел каких-то женщин на скорости в 100км/ч. Да, дорога ровная и незагруженная - но очевидно же, что если будет яма или упавший с самосвала кирпич, он не среагирует и мы улетим в кювет.
Ему, разумеется, сделали замечание (через полчаса такой езды - а вдруг там что-то важное, у человека судьба решается?), плюс еще я указал это в отзыве о поездке.
А вот еще старый начальник рассказывал, на у них на плавильной печи было автоматическое управление вводом электричества, а дежурная смена на НГ приняла на грудь и решила вздремнуть (все ж само работает) - и именно в это время залип контактор. Только случайно проходивший мимо рабочий по звуку определил, что какая-то жесть творится, а то бы угробили оборудование на много миллионов, и не ровен час, люди погибли при пожаре.
Но почему бы и нет, давайте теперь все забьем на работу и будем развлекаться, пусть какой-нибудь очередной Дятлов, который вместо вдумчивого чтения инструкций сидит в телефоне, устроит еще один Чернобыль или Фукусиму.
Или вы дифференцируете - вот тем-то рабам на работе отвлекаться нельзя категорически (чтоб у нас в хате свет не гас, и батареи оставались теплыми), но мы же айтишники, высшая раса, у нас "надо к людям относиться мягше, а на вещи смотреть ширше?"
dimaaannn
31.07.2021 14:19+1каждый раз проходя мимо сотрудника, вы видите развлекательные сайты
Если работа делается - то в чём проблема?
Я могу работать 4-5 часа без перерыва в потоке, но потом остаток дня я буду в состоянии овоща.И да, буду смотреть развлекательные сайты, потому что кодить в таком состоянии означает завтра всё переписывать.
CheatEx
30.07.2021 13:00Сотрудник допускает небрежности в оформлении кода, названии переменных
На скорость за полчаса что-то существенное накодить еще и по феншую (который в каждой конторе свой)?
поэтому тестовые задачи дают решать дома, что сразу делает их практически бесполезными: к заданию немедленно подключаются друзья, знакомые, платные репетиторы.
Это какая-то параноя. Ну купит чувак себе тестовое, но то что не он его делал выяснится в течении первых 2х суток работы. Чтобы этого не понимать надо быть реально очень тупым и таких надо на других этапах собеса отсеивать.
Я за оффлайн тестовые, масштабом 10-20 часов. В качестве компенсации контора может предожить (а) деньги, по нижнему уровню фриланса в своей области, (б) реально детальное ревью архитектуры и кода, (в) зафиксированый контрибьюшн (если тестовое было привязано к какому-то опенсурсу).
mikhailian
30.07.2021 14:29-5Я за оффлайн тестовые, масштабом 10-20 часов
Можно предложить решить issue из какого-то OpenSource проекта, реально использующегося у работодателя. Просто шлёте чуток отфильтрованный `gradle dependencies` соискателю и даёте... ну скажем неделю сроку.
И не надо никаких высосанных из пальца FizzBuzz'ов.
Ilusha
31.07.2021 05:28+220 часов по нижнему уровню фриланса? Я даже за двойную часовую ставку текущей работы сначала десять раз подумаю, прежде чем браться.
Учитывая рынок, я всегда найду работодателя адекватнее: того, кто умеет в собеседования и краткие, но емкие ТЗ.
Ревью - это хорошо.
PR - ну такое. Сложно подобрать подходящую задачу.
CheatEx
31.07.2021 12:47+1Никто не умеет. По цирковому этюду на полчаса не оценить продуктивность даже на типичной скрам таске в 1-2 дня. А хочется вообще говоря поддержку и развитие систем на отрезок в пару лет.
Ilusha
03.08.2021 01:54Но собес и ТЗ не призваны оценивать продуктивность. Это вообще невозможно.
А уровень вполне себе оценивается собесом и кратким ёмким ТЗ на 2-3 часа. Плюс резюме: компании и проекты, если речь про senior-позицию. Часто оно говорит о многом и собес превращается в диалог о нетривиальных задачах, а не об умении писать код.
Там ТС заявлял о «купленых» ТЗ. Это уже похоже на паранойю.
8ll
30.07.2021 13:10+15Мне очень жаль, что ты относишься к сотрудникам как к врагам. Я бы не хотел работать у такого руководителя.
Prokky
30.07.2021 13:23+15на вопросы о переработках отвечает отрицательно
Не до конца понял формулировку, отказ от переработок - один из признаков самозванца?
igor-sheludko
30.07.2021 13:29+2Тестовое задание на 1 час еще как-то можно посчитать частью собеседования. Но тестовое задание более чем на 1 час - это уже задача/поручение от работодателя, подразумевающее возникшие договорные (трудовые или подрядные) отношения, в рамках которых ожидается оплата/вознаграждение.
Эффективность тестового задания по сравнению с собеседованием или тестом (типа ЕГЭ) - весьма сомнительная.
Лучший вариант - это собеседование (+ тест) и затем краткосрочный договор на 1-3 месяца с полноценной оплатой (испытательный срок).
mt144
30.07.2021 14:13+14Ведущий программист (Ваня, привет!), считающий себя звездой, внедрил данный функционал (бизнес-логика, встроенная в CRM на PHP) прямо накануне своего отпуска, протестировав его, видимо, на единичном заказе - или, может быть, в уме. И уехал в отпуск.
Результат: половина клиентов получила при доставке чеки, существенно превышающие сумму заказа в личном кабинете.
Настолько прекрасно, что невозможно удержаться - в компании культура разработки, тестирования и эксплуатации отсутствует, но виноват программист Ваня. Как у техдира обстоят дела с синдромом самозванца?
JediPhilosopher
30.07.2021 14:15+10Писать такие статьи на Хабре требует определенной смелости. Так как Хабр все-таки в первую очередь ресурс для технических специалистов, то их тут сильно больше чем менеджеров и управленцев. А потому взгляд на подобные темы тут довольно однобокий всегда. И за любую попытку подорвать мир, в котором айтишники - принцы на белых конях и д'Артаньяны, которых надо всячески ублажать, а менеджеры - злобные гады, спящие и видящие как бы только их унизить и оскорбить (хоть тестовым заданием, хоть отказом принимать на веру их гениальность), тут сразу прилетает куча минусов и всеобщее осуждение.
Конечно, круто жить в идеальном мире, где тебя сразу берут на работу, ничего не проверяют, не устраивают стресс на собеседовании. В идеале бы вообще никак не общаться с заказчиком и не видеть его вообще. Но так не бывает, никто так и не придумал внятного способа отделять хороших специалистов от плохих. Вот каждый и придумывает свое.
И проблема самозванцев действительно есть. Сейчас в ИТ не ломится только совсем ленивый и бесталанный. Приходят вереницей люди, которые не умеют ВООБЩЕ НИЧЕГО, но при этом просят 100+.
Я уже давно придумал "тест на зомби" - прошу написать код, разворачивающий массив. Даю ноутбук, где уже написан скелет теста (заполнение массива, вывод). Объясняю что это очень простой тест, что тут нет подвоха и не нужно никаких "олимпиадных" решений. Отхожу в сторонку, даю человеку спокойно это написать, проверить, а потом позвать меня.
Половина собеседующихся на джуна не способны это сделать.
Один раз взял таки человека, который эту задачу сделал кое-как с трудом, запутавшись в индексах - очень нужны люди были срочно, а человек описывал неплохой опыт и сыпал всякими умными словами и технологиями, с которыми якобы разбирался. Потом много раз пожалел, человек реально оказался не способен писать хоть какой-то код, выходящий за рамки "взяли объект из одного библиотечного метода и передали в другой". Причем за полгода работы никак не прогрессировал и лепил дикие ошибки, показывающие что алгоритмическое мышление вообще не про него. Зарекся с тех пор брать тех, кто этот тест не проходит.
mikhailian
30.07.2021 14:22Я уже давно придумал "тест на зомби" - прошу написать код, разворачивающий массив
Вы в курсе про FizzBuzz?
JediPhilosopher
30.07.2021 18:09В курсе, конечно. Но мой вариант мне нравится больше. Впрочем тут уже чисто вкусовщина.
tmaxx
30.07.2021 19:21+2Вот именно потому, что все в курсе про FizzBuzz, она в данном случае и не подходит - ее можно зазубрить.
Но общий принцип верен: не стесняйтесь давать элементарные задачки на кодинг - половина соискателей их не пройдёт.
Я обычно даю произвольную рекурсивную функцию. Или сумму несложного ряда. Тоже никакой «олимпиады» - просто реализовать записанную на бумажке формулу. И очень часто человек, который минуту назад уверенно сыпал умными техническими терминами, не понимает что такое «цикл» и «переменная».
distroid
30.07.2021 19:29+1Как показала практика, много кто спотыкается даже на поиске минимального\максимального числа в списке...
JediPhilosopher
30.07.2021 20:07Есть такое.
Несколько раз ходил помогал принимать экзамены по программированию у студентов своего же ВУЗа, уже будучи выпускником. Любили в качестве разминки давать задачу "напишите фукнцию, которая возвращает вашу желаемую оценку на экзамене". То есть по факту просто какой-нибудь int f() {return 5;} Даже с этим многие не могли справиться.
Но потом эти люди все равно получали диплом программиста и часть из них наверное пыталась куда-то трудоустроиться.
Именно для защиты от таких и есть все те тестовые задания, так глубоко оскорбляющие многих гуру из комментариев к этой статье и подобным ей.
distroid
30.07.2021 20:27+1Ну смотря что подразумевать под тестовым, таких можно отсеять просто задав пару задачек на 5 минут на собеседовании
JediPhilosopher
31.07.2021 15:38Судя по комментариям на хабре, многие сильно злятся и агрятся даже на такую вот задачку на написание кода. Сразу начинаются гневные вопли в духе "а что если человек гениальный программист, но в стрессе на собеседовании не может написать даже метод сложения двух чисел!?".
distroid
31.07.2021 15:44Есть такое, мы сейчас на работе проводим собеседования для джунов и даем простые задачи, в духе поиска минимального числа в списке, при том, что это удаленные собеседования, многие на этом спотыкаются. А как раз во избежание стресса, просим после собеседования прислать решение, в течение нескольких часов. Забавно, но был случай, когда один парень прислал решение одной задачи с явными ошибками в выводимом результате...
gecube
30.07.2021 21:31+1И проблема самозванцев действительно есть. Сейчас в ИТ не ломится только совсем ленивый и бесталанный.
это не "комплекс самозванца", а именно, что реальные самозванцы
Wan-Derer
31.07.2021 00:34код, разворачивающий массив
так?
int[] array = {1, 2, 3, 5}; List<Integer> list = Arrays.stream(array).boxed().collect(Collectors.toList()); Collections.reverse(list); int[] revArray = list.stream().mapToInt(x -> x).toArray(); System.out.println(Arrays.toString(revArray));или это
взяли объект из одного библиотечного метода и передали в другой
?
siziyman
31.07.2021 02:26list.stream().mapToInt(x -> x).toArray()
А зачем так сложно (или это шутка, которую я не понял)? list.toArray чем плох?
Wan-Derer
31.07.2021 09:32Ну, я заложился на int[], а List<Integer> в int[] автоматом не мапится. Поэтому приходится руками :)
Если бы в массиве были объекты, то да, так можно.
JediPhilosopher
31.07.2021 15:35+2Вы, вероятно, принадлежите к той когорте разработчиков, кто тестовые задания не любит, и поэтому пытается их всячески извратить и продемонстрировать, что вы таки умнее рекрутера и вертели вообще все эти тестовые задания.
Ваш пример, конечно, работает. Но, например, создает кучу ненужных временных объектов и вызывает кучу методов. Зачем? Чисто выпендриться?
В принципе формально поставленную задачу он выполняет, но впечатление оставляет не самое лучшее.
Wan-Derer
31.07.2021 16:03Если посмотреть мой другой комент, можно определить что к тестовым заданиям я отношусь позитивно.
Куча объектов? М... Один? List который? Ну там сама железка ещё наверно что-то создаёт. В оправдание могу предположить что стримы и коллекции работают на уровне ВМ, а значит, вероятно, быстрее. По крайней мере, на это намекают те материалы, которые я изучал по этой теме. Памяти будет съедено больше, да, но на очень коротком промежутке времени.
Ладно, в доказательство что я адеквашка, вот "обычный" код:
int[] array = {1, 2, 3, 5}; int[] revArray = new int[array.length]; for (int i = 0; i < array.length; i++) { revArray[revArray.length - i - 1] = array[i]; } System.out.println(Arrays.toString(revArray));Смотрю и вижу что читает он хуже. Надо вчитываться что я там натворил :)
siziyman
31.07.2021 16:25+1Ещё оригинальный код зачем-то боксит кучу примитивных интов. :)
Wan-Derer
31.07.2021 19:46Затем же зачем и маплю. В коллекцию нельзя закинуть массив примитивов, приходится боксить руками :)
Кстати,
list.toArray чем плох?
У Stream API своя реализация List, поэтому list.toArray даст List<Object> что нам как бы не надо, всё равно придётся мапить явно в то что нужно.
JediPhilosopher
31.07.2021 17:58Не один, вы же еще боксите все в Integer, который тоже объект. И вот это уж точно совсем лишняя операция.
Adverte
07.08.2021 22:06Зачем же так усложнили, когда можно ещё проще, быстрее и с меньшим расходом памяти?
public static void main(String[] args) { int[] array = {1, 2, 3, 5, 4}; final int len = array.length; for (int i = 0; i < len / 2; i++) { int temp = array[i]; array [i] = array[len-1-i]; array[len-1-i] = temp; } System.out.println(Arrays.toString(array)); }Wan-Derer
07.08.2021 22:10Ну, вообще, по умолчанию считается хорошим тоном не портить входные данные, а возвращать новые (если в ТЗ не указано иное).
:)
Azirel
31.07.2021 13:15Праздное любопытство - а если в "тесте на зомби" джун напишет (пример на C#):
Array.Reverse(arr); // Ну и там выше using, конечно
Как он, по вашему, будет считаться прошедшим тест? :)
JediPhilosopher
31.07.2021 15:36Поскольку такой комментарий появляется абсолютно под каждым текстом или постом о подобных тестовых заданиях, я всегда уточняю что надо написать без использования готовых библиотечных функций.
Azirel
07.08.2021 14:14Логично. В production-коде, конечно, не стоит велосипеды плодить, если есть библиотечная функция, но в рамках теста - правильно.
miksir
30.07.2021 14:35+6Интересная табличка. Если на нее взглянуть с другой стороны (с которой смотрят очень многие), то смысл получается приблизительно такой: если в компании выстроена разработка с тестированием, код ревью, планированием; если у разработчиков лид не названиям переменных обучает, а с людьми работает; если в компании построен онбординг, поэтапно оценивается прохождение испытательного, есть программы обучения, - то никакое тестовое на собеседовании не нужно.
Т.е. тестовое - это признак хаоса в отделе разработке?
edo1h
30.07.2021 14:46поэтапно оценивается прохождение испытательного
то никакое тестовое на собеседовании не нужно
ну теоретически да. но те кандидаты, что не могут написать FizzBuzz, будут отсеиваться не на тестовом задании, а на испытательном сроке. для компании это банально невыгодно.
miksir
30.07.2021 14:59Ну я же не говорю, что собеседование с техническим специалистом совсем не нужно. Граничные случаи отсеиваются и без тестового - просто глядя на то, как человек рассказывает о своем опыте, как отвечает на тех вопросы, какие знания, если спросить "чуть в сторону".
На самом деле тестовое задание - это всего лишь дополнительный этап воронки. Полезно, когда у вас столько кандидатов, что никакие устные собеседования не дают допустимого уровня фильтрации кандидатов. Или если если у вас одно место и вы готовы много месяцев искать для него "топчика". Который свалит через пол года, ибо в разработке хаос, руководители - самодуры, а тут офер на х2 пришел.
miksir
30.07.2021 15:08И опять же, тестовое не дает ответов на вопросы обучаймости, способности концентрироваться, способности работать в коллективе, разбираться в существующем коде. Т.е. оценка по испытательному нужна все-равно. Если процесс выстроен, то потеря компании - это ЗП за 3 месяца. Не взять кандидата для крупной компании - это могут быть потери побольше.
Конечно, все это верно при большом отделе разработки с постоянной нехваткой кадров. Если компания - пяток разработчиков, и неторопливо в поисках шестого (как раз как найдут - кто-то уйдет), тут совсем другие критерии.
Самое печальное, когда руководители с опытом в небольших компаниях не могут адаптироваться к новой компании с другими приоритетами и не меняют тактику отбора. А потом у всех, включая инвесторов, удивление - а где же люди, кто работать то будет?!
vadimr
30.07.2021 14:55+7Попробуйте назвать (или просто сформулируйте для себя) хотя бы одну причину, по которой квалифицированный программист пойдёт работать в банк.
Высоких зарплат в банках рядовым специалистам не платят с 90-х годов.
IT является вспомогательным подразделением фирмы и в этом плане как бы людьми второго сорта.
Ничего концептуально интересного в программировании финтеха нет, это не атомный реактор и не рокет сайенс. Честно говоря, даже какое-нибудь дожигание мусора представляет собой на порядок более интерсную в техническом плане задачу.
В телевизоре результат труда этого программиста не покажут, и Президент премию не вручит.
Безработицы, вынуждающей хвататься за любое предложение, у программистов нет.
Так откуда вы ждёте компетентных специалистов? Они могут в этом секторе появиться только случайно или задержаться с тех времён, когда там были зарплаты сильно выше рынка.
siziyman
30.07.2021 16:01+1Высоких зарплат в банках рядовым специалистам не платят с 90-х годов.
Из того, что я слышу и вижу, как раз рядовым специалистам в банках себе проще выбить зарплаты повыше, потому что крупные банки пылесосят рынок программистов и параллельно немножко перегревают им зарплаты. А вот самому топу именно исполнителей - да, проще что-то сильно более интересное и менее душепродажное найти.
Nikita001 Автор
30.07.2021 18:35-9Забавно, что вы это написали.
Проект, в котором я участвовал в качестве разработчика в банке, презентовали Президенту РФ, и это таки показали по телевизору. Соответственно, многим, и мне в том числе, вручили благодарности, и премии (хотя, конечно, и не из рук Президента).
Я не буду здесь, в кругу друзей, распространяться, что это было (одно название должности уже многих агрит) . Но те сотрудники, кто возможно узнает меня по роликам, легко поймут о каком проекте речь - и что это правда.
Вам удачи с программированием реактора и ракет.
vadimr
30.07.2021 18:47+5Ну я получал премию от Президента, и что? Мы здесь не меряемся личными достижениями, а обсуждаем состояние рынка труда. Все знакомые мне программисты, кто работал в банках, оттуда свалили. Хотя менять сферу деятельности не очень-то приятно.
Ilusha
31.07.2021 05:44+2Как легко вы съехали с темы. Выбрали один посыл, исказили его, а всё остальное - отбросили.
Да, суровая правда текущего положения вещей: при наличии достойной альтернативы в банки сейчас не идут в подавляющем большинстве случаев.
А с определённого уровня банки остаются позади: они не предлагают даже конкурентных зарплат. И не афишируют их на hh.
Вы хотите лучших? Так и нужно брать лучших: CTO, PM/PO, тим/тех лиды. И вот они уже построят вам эффективный отдел. Только платить им нужно существенно выше рынка, потому что по рынку они найдут себе работу гораздо интереснее.
Richy_2core
31.07.2021 22:08А конкурентная это сколько?
Есть у меня предположение, что Ваше представление о банках осталось примерно на уровне не 90х, но 2010-х, примерно
distroid
30.07.2021 15:11+10По примерам с факапами, выглядит не то, что программист Ваня плохой, а что у вас процесс разработки продукта плохой - выливать не проверенные задачи в прод, не писать тестов, и вы надеялись, что будет иначе?
А насчет тестовых заданий на собеседовании:
если вы собеседуете стажёра\джуна, достаточно пары простых задачек на 1-2 цикла, большое домашнее тестовое задание нет смысла им давать, все равно не решат
в случае мидлов, возможно можно дать тестовое, но если уж в ходе собеседования очень не однозначное впечатление и хотелось бы понять что из себя представляет (да и просто дать мелкую задачку, чтобы скинул в течении 1-2 дней)
а вот для сеньеров, давать тестовое задание, это как просить профессора по высшей математике рассказать таблицу умножения. В ходе собеседования, разговора, что человек делал, как делал и с какими проблемами сталкивался, можно понять что он из себя представляет, тут и за кодом ходить не надо.
sergey_prokofiev
30.07.2021 16:21Автор прекрасно понимамает проблему, но увы, не делает "еще один шаг". Тестовое задание на пару часов не покажет ничего больше чем тестовое задание на полчаса(что вполне в формат собеса укладывается). И это будут какие то базовые навыки умения писать код, и все.
Для выявления более комплексных наыков, нужно задание на 4-16 часов(причем 16 - лучше). А это достаточно много времени и далеко не все кандидаты(включая меня) готовы тратить столько времени на "еще_одно_собеседование". А если кандидат готов потратить 2 рабочих дня на тестовое задание, то тут аж целых 2 варианта:
у кандидата нет других предложений.
Ваше предложение уникально на рынке. Или з/п существенно выше среднего, или по каким то личным причинам кандидату хочется работать именно у вас.
В первом случае кандидат скорей всего вам не нужен, а второй бывает достаточно редко. Поэтому, с моей точки зрения, надо учиться оценивать умение писать код по собесу. Тут может помочь hr, который срисует психологический портрет, ну и собственно говоря небольшое тестовое задание.
ayevdoshenko
30.07.2021 16:30+4Автор, как насчет того, что вам банально не хватило компетенции разобраться с Mongo? Не является ли безответственным поручение сложных задач - джунам? Как вы прокомментируете отсутствие тестирования на проекте федерального масштаба?
Вам не кажется, что вы перекладываете ответственность и не замечаете гораздо более существенных проблем, всего лишь следствием которых уже являются описанные вами кейсы?
mad_nazgul
02.08.2021 08:38+1А что вы хотите от "чайка менеджмента"?!
Ну как бы все примеры показывают, что менеджеры не работают, от слова совсем.
neolik
30.07.2021 17:32+1Автору нужно было писать эту статью лет так 15 назад, чтобы получить одобрение.
Извините, it - уже давно не про тех. склад ума и не про какое-то там мышление в целом .
Подписываюсь практически под каждым словом, но по поводу "насильно дисциплинироавть" не согласен.
Тесты прошёл - оккей, с задачами справляется - гуд, а что он там во время работы делает - неважно.
Основная масса комментатаров просто докопались до вот таких перегибов, т.к ответы на такие "перегибы" давно заучены.
Спасибо за статью.distroid
30.07.2021 17:58Извините, it - уже давно не про тех. склад ума и не про какое-то там мышление в целом
Крайне спорное утверждение, если вы говорите про клепание сайтиков на CMS, то возможно, а если что-то более серьезное, то умение думать, анализировать, как сделать то или иное решение не только по принципу "ну работает, чо", то увы.
neolik
31.07.2021 00:02Всё верно, программирование как раз про сложные вещи, тех склад ума, и т.п.
А вот it-специалисты, чем дальше - тем хуже.
Я думаю, что для ясности и избежания недоразумений стоит снова ввести такие категории как: "компьютерщик" , "веб-мастер", добавить к ним "кодеров", "разрабов", а программистов отдельно, от всего этого маркетингового шлака.
MyraJKee
30.07.2021 18:40+1Слава богу пока что есть выбор и довольно широкий. И не нужно выполнять тестовые задания в стиле - напишите форум или интернет магазин.
Nagh42
30.07.2021 20:08+1С одной стороны, согласен с проблемой поиска и определения специалистов с нужной квалификацией.
С другой стороны статью я резюмирую следующим образом: "С водой выплеснули ребёнка".
2ANikulin
30.07.2021 21:07+1Я не против тестовых заданий. Но только если о компании всё известно на берегу. Какая зарплата. И это не 150 - 350, а 300 - 350. Сколько будет отпуска, как часто будут будить по ночам, что с переработками, и работой в праздники и выходные. Т.е эта компания и эти условия должны быть интересны и за них хотелось бы побороться. А не так что, напиши тестовое, а зп мы тебе скажем по итогам собеседования, и все подробности у девлида
Grigorenkovic
30.07.2021 21:09+2Расскажите лучше про выявление самозванцев среди исполнительных директоров :)
usbstor
30.07.2021 22:27+1Для начала я приведу весь список ситуаций, требующих внимания, а после отмечу, то, что из него волнует меня больше всего.
Узнал себя в первых шести пунктах. Хоть я и не программист.
mSnus
30.07.2021 22:37+7Минусы автор заслужил.
Во-первых, нечего ставить себя выше тех, кого нанимаешь, все же не грузчиков. А тут высокомерие в каждой фразе начиная с заголовка. Добавляют ещё дурацкие тестовые задания вроде консольных крестиков-ноликов -- вроде мода на вопросы про водопроводные люки или количество заправок в Москве уже прошли, а это из той же серии "надо что-то спросить, но не знаю что -- попробую хоть развлечься".
Во-вторых, совершенно немыслимая табличка "грехов" -- как можно настолько не понимать людей, с которыми работаешь? И тем более быть их начальником?
Сотрудник не справляется с работой, хотя явно старается и находится в стрессе - классический самозванец, страдающий одноименным синдромом
Классический случай плохого управленца, который то ли посадил человека не на то место, то ли плохо распределил или дал не те задачи... Или просто перегрузил. И при этом не готов помочь нормальному работнику дорасти до нужного уровня.
Тут сразу вопросы -- это в первый месяц выявляется? Тогда это не проблема. Через полгода? Тогда точно проблема работодателя, а не разработчика.
В-третьих, совершенно непонятно, в чём глобально проблема: у хорошего разработчика наверняка есть пара проектов на GitHub, посмотрите заранее до собеседования, что он вообще пишет и как. Если обязательно надо протестировать человека в реальных задачах -- договор ГПХ вам в руки, месяц тестируйте друг друга как угодно, без долгосрочных обязательств. Не такие уж большие риски.
В общем, высокомерие*некомпетентность= минусы.
iboltaev
31.07.2021 07:59+1Давеча один мой коллега сказал, что на его взгляд, качество джуниоров сильно упало: не каждый джун осилит
прийти на собеседованиезакодить консольные крестики-нолики. Кстати, челенж для джава-скалистов - слабо закодить их в 1 строку? ;)Iterator.continually(scala.io.StdIn.readLine).takeWhile(s => s != null && s.nonEmpty).filter(_.forall(c => c == ' ' || c.isDigit)).map(_.split(' ')).filter(_.size == 2).map(s => s.map(_.toInt)).filter(a => a.forall(v => v >= 0 && v < 3)).scanLeft((Array.fill(9)(' '), 0)) { (ap, pair) => if (ap._1(pair(0) * 3 + pair(1)) == ' ') { def search(s: Array[Char], order: Char, level: Int): (Int, Int) = { val r = (0 to 2); val x = r.exists(i => r.forall(j => s(i * 3 + j) == 'x') || r.forall(j => s(i + j*3) == 'x') || (s(0) == 'x' && s(4) == 'x' && s(8) == 'x') || (s(2) == 'x' && s(4) == 'x' && s(6) == 'x')); val y = r.exists(i => r.forall(j => s(i * 3 + j) == 'o') || r.forall(j => s(i + j*3) == 'o') || (s(0) == 'o' && s(4) == 'o' && s(8) == 'o') || (s(2) == 'o' && s(4) == 'o' && s(6) == 'o')); if (x == true) (-1, -1) else if (y == true) (1, -1) else if (s.forall(_ != ' ')) (0, -1) else { val r = (0 to 8).filter(i => s(i) == ' ').map { i => s(i) = order; val res = search(s, if (order == 'x') 'o' else 'x', level + 1); s(i) = ' '; (res._1, i) }; if (order == 'x') r.minBy(_._1) else r.maxBy(_._1) } }; val c = ap._1.clone(); c(pair(0) * 3 + pair(1)) = 'x'; val res = search(c, 'o', 1); if (res._2 > -1) c(res._2) = 'o'; (c, res._1) } else ap } .map { case (arr, res) => println("***********"); (0 to 2).foreach(i => println(arr(i*3) + " | " + arr(i*3 + 1) + " | " + arr(i*3 + 2))); println("***********"); println("Win: " + res); if (arr.forall(_ != ' ')) -1 else res }.takeWhile(_ == 0).foreach(_ => ())Только на интервью я хз, смогу или нет такое осилить. Походу, меня даже джуном не возьмут.
TheShock
08.08.2021 02:54Эмс. По такому принципу можно любую программу на любом языке в одну строчку вместить. Это не однострочник, а просто код, в котором удалены все переносы строк:
Iterator .continually(scala.io.StdIn.readLine) .takeWhile(s => s != null && s.nonEmpty) .filter(_.forall(c => c == ' ' || c.isDigit)) .map(_.split(' ')) .filter(_.size == 2) .map(s => s.map(_.toInt)) .filter(a => a.forall(v => v >= 0 && v < 3)) .scanLeft((Array.fill(9)(' '), 0)) { (ap, pair) => if (ap._1(pair(0) * 3 + pair(1)) == ' ') { def search(s: Array[Char], order: Char, level: Int): (Int, Int) = { val r = (0 to 2); val x = r.exists( i => r.forall(j => s(i * 3 + j) == 'x') || r.forall(j => s(i + j*3) == 'x') || (s(0) == 'x' && s(4) == 'x' && s(8) == 'x') || (s(2) == 'x' && s(4) == 'x' && s(6) == 'x')); val y = r.exists( i => r.forall( j => s(i * 3 + j) == 'o') || r.forall(j => s(i + j*3) == 'o') || (s(0) == 'o' && s(4) == 'o' && s(8) == 'o') || (s(2) == 'o' && s(4) == 'o' && s(6) == 'o')); if (x == true) (-1, -1) else if (y == true) (1, -1) else if (s.forall(_ != ' ')) (0, -1) else { val r = (0 to 8).filter(i => s(i) == ' ').map { i => s(i) = order; val res = search(s, if (order == 'x') 'o' else 'x', level + 1);s(i) = ' '; (res._1, i) }; if (order == 'x') r.minBy(_._1) else r.maxBy(_._1) } }; val c = ap._1.clone(); c(pair(0) * 3 + pair(1)) = 'x'; val res = search(c, 'o', 1); if (res._2 > -1) c(res._2) = 'o'; (c, res._1) } else ap } .map { case (arr, r ))); println("***********"); println("Win: " + res); if (arr.forall(_ != ' ')) -1 else res } .takeWhile(_ == 0) .foreach(_ => ())
Wan-Derer
31.07.2021 08:20Ой... А я крести-ноли не писал никогда... Ой-ой! Кажется, у меня выгорание! ;( Шоделать-шоделать?! Где же мой смузи?!!!
По теме. Тестовые задания считаю делом правильным. Программирование во время собеседования - правильно. Уточню - речь о джунах. Люди во время обучения только и делают что решают задачи, так что для них этот процесс привычен и вызовет меньше стресса чем вот эти ваши: "Перечисли методы класса Обжэкт" и "Нарисуй иерархию коллекций". Это, конечно тоже надо знать, но это, блин, справочные данные, которые всегда можно посмотреть прямо в ИДЕ. Хотя можно спросить, сидя за компом, заодно оцените навык исполнение ctrl-click :)
Когда вы задаёте задачки вместо вопросов по теории, кандидат сразу погружается в привычную для себя обстановку и перестаёт психовать, а вы имеете возможность наблюдать как он в реальности будет работать. Заодно можете поиграть в ментор-ученик, дав сначала с виду простую задачу, а потом начать накручивать подробности, вынуждая рефакторить решение. Но это сложно, да :)
По этой же причине код на бумажке или на доске - бред. Надо на компе. Можно с двумя мониторами - для удобства, можно на двух компах в режиме парного программирования, современные ИДЕ рулят. На бумажке можно (нужно!) ставить и уточнять задание. Несколько кружочков и стрелочек вместо тысячи слов, ящитаю!
И ещё. Здесь и не только рассказывают что кандидаты свободно рассуждают об архитектуре, просят сотку, но не могут написать цикл. Чё-та не верю! Тут либо задание ставится как-то совсем витиевато, либо стресс (хотя такие базовые вещи при любом стрессе пишутся на раз), либо оратор привирает :) Это как если прийти наниматься переводчиком, но не смочь перечислить первые 4 буквы алфавита. Не, не верю!
light_and_ray
31.07.2021 11:48+1Как руководитель, я не особо разделяю гугловскую идею превратить собеседование в восхождение на Эверест, чтобы к нему готовились по полгода и складывали легенды аргонавтов о немыслимых испытаниях на пути к заветному оферу.
Но ведь Гуглу принадлежит самая популярная ос в мире. Гуглу принадлежит самый популярный видеохостинг в мире. Гуглу принадлежит самый популярный поисковик в мире. Гуглу принадлежит одна из крупнейших рекламных сетей в мире. Они определенно знают себе цену
nApoBo3
31.07.2021 13:08+1Мне понятна точка зрения автора стати, но в такой ее формулировки разделить ее я не могу.
Если сместить акцент данной статьи с противопоставления менеджмента и разработчика на оценку эффективности процесса найма ее "полезность" значительно возрастет.
Зачем нужны тестовые задания, собеседования и другие подобные мероприятия? Можно же брать всех подряд и если у вас эффективно выстроены остальные процессы не подходящие люди будут отсеяны из компании. В данном случае мы рассматриваем только часть процесса найма, единственная цель которой уменьшить кол-во кандидатов. Это нужно, чтобы скомпенсировать недостаток внутренних процессов, сделать их дешевле и менее требовательными к, часто не профильной, квалификации исполнителей. Компания пытается найти людей которые к ней подходят, стандартизировать поток на входе, чтобы потом с ним было проще и дешевле работать. Копания не ищет хороших или плохих разработчиков, квалифицированных или нет, копания ищет разработчиков которыми сможет управлять и которым сможет платить. При этом не важно, что именно компания декларирует, в итого все придёт к ситуации, которыми можем управлять и которым можем платить, остальные ситуации значительно ниже по эффективности. Если берем и не можем платить, то тратим на наём, онбординг( даже если его нет ), но человек уходит не окупив затраты и мы в минусе. Если берем тех, кем не можем управлять, разваливается менеджмент, эффективность падает в разы, сотрудники начинают преследовать цели никак не коррелирующие с "целями" компании из такого болота, все кто могут "крути землю" бегут сверкая пятками.
Надо признать, все что мы хотим, убрать "лишних" кандидатов. Если вы можете себе позволить "лишних" кандидатов, то вы можете себе позволить и тестовые задания и даже не оплачиваемую стажировку. Дайте условия сеньера с требовании мидла и делайте, что хотите.
От чего же здесь "подгорает" у всех сторон процесса? Просто авто пишет про компании со слабыми процессами и утверждает, что это можно исправить процессом найма. Но вот только исправить процесс найма в компании со слабыми процессами нельзя. Нельзя построить хороший наём в компанию со слабыми процессами, он будет искать не подходящих под такие процессы кандидатов. Описанные автором примеры, это примеры хорошего и правильного найма, компания взяла кандидатов которыми может управлять и которым может платить, все сошлось, здесь нет ошибки, просто процессы в компании такие в которых выживают такие кандидаты, не плохие или хорошие, а подходящие.
Вывод? Можно перефразировать известную фразу: "Самая большая глупость — это делать тоже самое и надеяться на другой результат.", хотите получить других разработчиков, меняйте компанию, ее процессы и ее менеджмент, тестовые задания вам в этом не помогут, они приходят уже тогда, когда вы все остальное поправили и у вас все равно слишком много кандидатов.
Elena_bill
01.08.2021 12:35+1У статьи отличный посыл.
Есть руководитель с плохо выстроенными процессами, есть разработчики, которые делают ошибки - из-за плохих процессов ошибки разработки становятся критичными и происходят денежные потери. Понятно что при "хороших разработчиках" (подходящих под текущие условия) можно будет не заморачиваться и не выстраивать что-то, что будет отлавливать косяки до прода. Это долго, дорого, больно и даже нужно с управляющим директором согласовывать. И тут уже в случае косяков придется исполнительному директору часть вины на себя брать (на дураков-разработчиков не свалить).
Как быть в такой ситуации? Может посмотреть в сторону неторопливых, скрупулезных, дотошных людей? Бывших аналитиков, тестеровщиков, базистов пришедших в разработку. Чтобы применяли различные модели анализа в повседневной жизни (не знаю, регрессионную модель с риск-весами для покупки квартиры), чтобы на собеседование приходили минута в минуту, чтобы не терпели хаос в системе контроля версий, плохой нейминг, бардак на рабочем месте.
Кажется что для банковского интерпрайза не нужны прямо звезды от разработки, а нужны просто хорошие, дотошные ребята, готовые идти на контакт с бизнесом.
А вообще стало грустновато от прочтения статьи. Как будто люди от разработки, которые не подходят под условия, в которых работает автор действительно плохие (пускают слюни и в круг квадрат вставляют ага). Захотела бы я работать с человеком с настолько циничным подходом? Наверно нет. По крайней мере не в прям подчинении.
Крестики-ноли кстати считаю отличной задачей для джуна. Тут и показатель того, что работник может написать программку от начала до конца, проверить все выходы за границы и т.д. Для мидла\синьера конечно нужны другие проверки.
"Кейсы" конечно просто бомба. Настолько что захотелось поискать информацию об авторе и посмотреть несколько его видео на ютуб. Может в этом и был отчасти троллиноговый посыл - вызвать резонанс? Не хочу верить в то что единственным смыслом статьи был вопрос - как найти тех кто не ошибается.
MKMatriX
02.08.2021 11:56+1Есть мнение что у автора долго пилился какой-то проект, какими-то разработчиками. Потом оказалось что школьный/вузовский/курсовый джун из современного мира не может в этот проект сходу. Причина тут не в плохом образовании или самозванстве, а в том, что проект 2к11 + 10 лет томления в собственном соку обладает своеобразным вкусом. И освоить быстро то, что писали пять разработчиков десять лет просто нельзя. Особенно по написанной для галочки документации. Что еще хуже за 10 лет вырабатываются специфичные софт-процессы, например отсутствие тестера (а что, 10 лет назад они были опциональны), или жесткое ревью с задержкой в неделю.
Ну а теперь скажите, вот придет к вам условный разработчик пишущий на скала в одну строчку крестики нолики. Увидит легаси, большая часть из которого вообще не понятно зачем. Долго копаясь в вашем проекте он робко запушит таск, который на минуту вашим текущим разработчикам. Через неделю получит "все работает, но переименуй все переменные ибо мы не используем букву 'а', перемести все файлы, и функции пиши в формате хайку".
После этого он день поругается, еще день пересилит себя и переделает под вкус текущей команды. Запушит - переделает. Наконец его таск примут, и окажется что у вас еще есть специфичный ритуал завершения задания, который он не сделал и теперь вы думаете что он вообще ничего не сделал. И будете даже правы, ведь он занимается втиранием в команду и процессы.
Так что вероятней всего вы теперь заложник ваших разработчиков. Они так старались сделать быстро, что сделали только под себя. Хотите это исправить - готовьтесь переделать с нуля, или хотя бы потратить одну пятую от времени на разработку. Заодно оптимизируйте процессы с которыми ваш самозванец столкнется. Организуйте полноценные песочницы, после найма поставьте нормальное менторство, пусть ваш разработчик сидит с джуном и показывает как ему делать его задачи. Тогда пойдет какое-то ускорение. Да это дорого, да это долго, но выбора у вас уже нет.
Adverte
07.08.2021 20:51Как написать статью о самозванцах, ничего не понять и считать что ты лучше других знаешь как надо делать.
ChePeter
Еще бородатый анекдот
"Идет хозян по заводу и рядом директор
это вот новый станок, запустили раньше срока
это вот новый инженер, уже его чертежи в производстве
И тут хозяит видит кресло, с сигарой спит чел и рядом стакан виски
Ну и сразу крик - что такое?,кто разрешил? почему бездельник на производстве!? Уволить, сократить, выкинуть пинком под зад.
Ну и дир тут - босс, это тот парень, что придумал ту штуку, что принесла тебе 5 млн долларов за прошлый месяц. И вот ровно в этой позе он её и придумал.
Босс - тихо, тихо, не вздумайте ему мешать, и виски подлейте и отойдите от него"
Этому анекдоту больше 100 лет, это еще когда бизнес был без компьютеров,