Комментарии 158
Еще бородатый анекдот
"Идет хозян по заводу и рядом директор
это вот новый станок, запустили раньше срока
это вот новый инженер, уже его чертежи в производстве
И тут хозяит видит кресло, с сигарой спит чел и рядом стакан виски
Ну и сразу крик - что такое?,кто разрешил? почему бездельник на производстве!? Уволить, сократить, выкинуть пинком под зад.
Ну и дир тут - босс, это тот парень, что придумал ту штуку, что принесла тебе 5 млн долларов за прошлый месяц. И вот ровно в этой позе он её и придумал.
Босс - тихо, тихо, не вздумайте ему мешать, и виски подлейте и отойдите от него"
Этому анекдоту больше 100 лет, это еще когда бизнес был без компьютеров,
Здравствуйте, добро пожаловать на собеседование на роль исполнительного директора в центральном аппарате крупного банка. Вам предлагается тестовое задание, которое нужно выполнить за два часа. Условия следующие - вам нужно создать банк, подписать договор с первым клиентом и провести первый платеж через SWIFT. Да, платеж должен быть настоящим, нет, больших нагрузок для такого тестового задания не предполагается. Удачи, спасибо.
Автор совершенно не понимает сути термина "синдром самозванца". Ну и много чего еще.
Del
Автор совершенно не понимает сути термина "синдром самозванца"
А разве в любой статье со словом «самозванец» должна идти речь об этом синдроме? Автор пишет об его антиподе, можно назвать «синдроме гения»: человек переоценивает свои способности и/или не замечает своих слабых сторон.
Не могу не согласиться, что такая проблема тоже есть. Правда, общий настрой автора показался несколько «людоедским» (но тут можно сказать, что тема статьи обязывает).
классический самозванец, страдающий одноименным синдромом
Самозванец не может страдать одноименным синдромом просто по определению этого синдрома:
Despite external evidence of their competence, those experiencing this phenomenon remain convinced that they are fraud
А давайте немного отвлечемся от цитирования Википедии, и обратимся к здравому смыслу.
И коль уж мы начали считать СС некой болезнью, больных которой надо пожалеть (хотя вообще-то, даже ваша Википедия ставит это под сомнение), давайте рассмотрим ее генезис.
А генезис таков, что когда человек является дилетантом и профаном в какой-то сфере (их-то я и называю самозванцами), он испытывает беспокойство по поводу превосходства коллег. Но у некоторых это проходит - когда они набирают квалификацию, а у некоторых, вроде как, длится подольше, или иногда не проходит вообще (хотя по некоторым оценкам, это просто черта характера, типа заниженной самооценки).
Но, вот еще бывает, что у активных спортсменов, после упражнений или состязаний, болят мышцы. И если спросить тренера, что это такое, будет ответ: так это ж микротравмы и молочная кислота!
И вот некоторые спортсмены продолжают тренероваться, и мышцы у них болеть практически перестают, так как приспособились. Но представьте такого человека, который скажет: Микротравмы? Так я травмирован! Начерта тогда нужен ваш спорт, уйду-ка я на месяцок в отпуск отдохну.
Несложно догадаться, что когда этот тепличный цветок вернется, на расслабоне подлечив свой "синдром", остальные его коллеги уже уйдут вперед - и соревнуясь с ними, гораздо легче "травмироваться". Круг замкнулся.
Вот и вся суть вашего синдрома до копейки.
Думаете, остальным приятно получать задачу на неизвестном языке, фреймворке или сложной предметной области? Мы точно также испытываем дискомфорт - разница в том, что одни не спят ночами, сжимают зубы и делают дело, а остальные ходят и жалуются как им тяжело.
Напротив, пусть именно с них и начнёт. Есть шанс, что на них же и кончит.
Попробуйте теперь с любым другим синдромом из, гм, Википедии. Не советую, впрочем, начинать с ПТСД
Очень лестно, наверное, сравнивать недоучку в легкой депрессии с ветераном, рисковавшим жизнью за свою страну. Но дело в том, что (в Википедии написано):
ПТС - Посттравматическое стрессовое расстройство
в отличие от
Синдром самозванца не считается психическим расстройством и не содержится в МКБ-10 и DSM-IV ... Чтобы избавиться от синдрома самозванца, нужно превозмочь в себе определённые предрассудки
Другими словами, это просто американские психологи ввели между собой такое словосочетание, чтобы удобнее деньги было стричь с маменькиных сынков, которые не могут без посторонней помощи "превозмочь предрассудки", и подсадить их на Прозак.
Причем я вам об этом написал еще в прошлом комментарии, но вы с упавшим забралом, похоже, плохо читаете - иначе бы сами открыли Вики, куда вы меня посылаете, и разобрались самостоятельно.
Состояние моей кармы сейчас, к сожалению, не позволяет мне много отвечать на вопросы телезрителей даже под моей собственной статьей - и роскошь отвечать особо одаренным по два раза пока недоступна.
Поэтому, всего хорошего.
Имхо вы решили проблему через переопределение.
Синдром самозванца, это ни когда вам тяжело. Это когда вы думаете, что не справляетесь, но ваши результаты соответствуют рынку. Очень важно, ваши результаты не хорошие или плохие, не высокие или низкие, а рыночные или не рыночные. Не рыночная оценка своих результатов приводит к многим негативным для человека последствиям:
Выбор не оптимального для рыночных условий вектора развития.
Не оптимальное распределение собственных ресурсов, вы тратите их на те задачи которые не дадут лично вам плюсов.
Демотивация.
Снижение собственной "монетизации", вы не пытаетесь получить больше на текущем месте.
Занижение собственной стоимости при выходе на рынок. Что интересно, это редко приводит к ускорению поиска работы, работодатель часто не готов взять работника на ЗП ниже рынка по целому ряду причин.
"Я знаю, что ничего не знаю"
Сократ
Синдром самозванца вызван парадоксом познания: "Чем больше ты знаешь, тем больше ты понимаешь, как много ты еще не знаешь".
Поэтому он особенно популярен у программистов. Ты просто забыл, как много тебе пришлось выучить, чтобы дойти до текущего уровня. Лучшее лечение – начать учить кого-нибудь с нуля.
Другая проблема – это то, что данной проблемой (которой страдают именно опытные работники) чересчур самоуверенные новички оправдывают свою некомпетентность.
>> А разве в любой статье со словом «самозванец» должна идти речь об этом синдроме?
Вот прямая цитата:
>> Но давайте подумаем, что лежит на другом конце "синдрома самозванца"? Нетрудно догадаться, что там находится нарастающая гора невыполненной (или имеющей явные признаки брака) работы - из-за которой, собственно, не справляющийся сотрудник и испытывает стресс и страх перед следующим рабочим днем.
> Ведущий программист (Ваня, привет!), считающий себя звездой, внедрил данный функционал (бизнес-логика, встроенная в CRM на PHP) прямо накануне своего отпуска, протестировав его, видимо, на единичном заказе - или, может быть, в уме. И уехал в отпуск.<
Ну это совсем какая то дичь. Из разработчиков не очень тестировщики, это хорошо известный факт, и по этому существует QA. Вопрос, а где был QA, или кто так классно выстроил процессы, что кто то может вот так просто взять и залить на прод не протестированный функционал?
Ну а на счет тестовых заданий, складывается впечатление, что вы немного не в курсе того, что происходит на рынке труда. Сейчас, хороший разработчик, получает по несколько предложений в неделю. В год легко может получиться больше сотни предложений. Думаю очевидно, что разработчик сначала будет рассматривать варианты где не нужно будет выполнять тестовые. Соответственно тестовые могут себе позволить только очень "популярные" компании.
А некоторые требуют тестовое, а потом даже его не смотрят. Как в Яндексе.
залить на прод не протестированный функционал
залить на прод не протестированный функционал, завязанный на деньги! :)
Из-за кармы не могу плюсануть, но при прочтении тоже не поняла - как так? Без теста запустили в продуктивную среду? Не спорю, бывали случаи, когда ошибка выявлялась не сразу, а через полгода выстрелила на редкой ситуации, но это за всю практику пару раз было.
Посмотрите, в другой ветке комментов подробно пояснил про Ваню и как его сырой код попал в продакшн.
Это я прочла. Но опять же, это не вина программиста, тут явно проблема в менеджменте, и вы сами это отметили. Просто описанная ситуация не вяжется со всей статьей, поэтому она и вызывает массу удивления. Ситуация с 1С-программистом тоже мягко говоря странная, ошибки конвертации из других источников почти сразу на тесте выявляются, даже на этапе разработки. Тоже ситуация из разряда плохого менеджмента, и опять же - не вяжется со статьей. Ну и первая описанная вами ситуация это 50/50 - недостаточный тест и закон подлости, такое бывает. Я понимаю, вы выделили, что пришлось разбираться с технологией по прихоти техдира, но... это вопрос к техдиру, опять же - не вяжется со статьей. О том, что есть адекватные специалисты и неадекватные, вопрос вообще не стоит, но... это в любой специальности. Просто вы описываете такие серьезные проекты, и тут же удивляете "странностями" при полном процессе разработки, тестирования и ввода в эксплуатацию.
Автор почему-то забывает, что мы на рынке. Вас, банков с исполнительными директорами - много, а их, толковых разработчиков - мало. Вы все одинаковые, у вас средненькие задачи и средненькая зарплата. Поэтому это разработчики приходят к вам и устраивают вам экзамены, ищут красные флаги, а не наоборот. Видят какой-то не приличествующий статусу выпендреж - пожимают плечами и идут от вашего Банка1192 к Банку1193. Вы, вроде, даже картинку приложили в самое начало статьи, вы думаете, что она какая-то ироничная и не правдивая?
Если хотите развернуть ситуацию - поднимите зарплату на позиции раза в два-три. Тогда претендентов станет много, а позиций мало, и можно будет рассуждать о том, как же их отсеивать. FAANG'и изголяются как могут и ничего им за это не будет, все равно по тысяче человек на место.
Приковывать рабов цепями не пробовали?
Любое тестовое задание - не показатель. А главное, я вас не понимаю, почему даже в заголовке статьи, вы видите разраба - как потенциального врага. Может все такие стоит пересмотреть такой подход.
А если по теме - топ задача на собеседованиях, которую я встречал - когда дают кусок рабочего кода, и просят его прокомментировать и доработать. 15-20 минут времени на анализ, и далее просто рассказываешь, что тут происходит, и что не так и что стоит переделать. Код - изначально рабочий, но написанный на коленке за 5-10 минут.
И тут:
И скилл работы с легаси.
И знание паттернов.
И знание алгоритмов.
И всякие SOLID, KISS, DRY и прочие друзья.
И знание языка.
И встречные вопросы.
И так далее и тому подобное.
PS Главное не говорите, что в вашем проекте, нет такого участка кода. И если вы говорите, что ваш проект идеале, то скиловый разраб у вас работать, разумеется, не будет.
PPS Хочешь захантить хорошего разраба. Думай как хороший разраб.
Охренеть у вас процессы.
Джуна по задаче работы с датами в из левых источников проверяют при помощи код-ревью, а сеньору можно сразу в прод финансовую задачу, после того, как пару тестов прогнал.
Похоже дело отнюдь не только в программистах.
Но по опыту, самый головняк - это базы данных.
Чаще - не базы данных и их функциональность, а данные в них. Ну и data flow.
По теме: давно для себя выработал один основной критерий на собеседовании - общая адекватность претендента. Если человек неадекватен, то, каким бы идеальным по техническим скилам не был, проблемы в дальнейшем будут гарантированы. Если адекватен, то скилы подтянет, а первое время не грузить задачами, сильно выходящими за границы его компетентности. В примере с "мегазвездой" - если он не просто говорит, что все, что сделано раньше - говно, но и технически грамотно это обосновывает, уделяя внимание возможным рискам, и предлагает пути управления таковыми, то, как показывает практика, стоит
1) прислушаться к тому, что он говорит,
2) найти для него подходящие задачи и выбить, при необходимости, ставку.
Если не может обосновать - ну тогда да, неадекватные нам не нужны.
Ну и главное, о чем регулярно забывают при выборе сотрудника: лучшее - враг хорошего. В поисках идеального кандидата теряется время и пусть не идеальные, но толковые специалисты.
Как у народа бомбануло-то... Автор местами перегибает палку, но тем не менее, в его словах есть изрядная доля истины.
Тех, кто нанимает, по определению меньше тех, кого нанимают, отсюда и перевес минусов к статье.
А если не писать ахинею, то те, кого нанимают, не будут минусовать.
Я, программист, в диалогах с другими программистами регулярно (в некоторых контекстах) защищаю эйчаров/нанимающих и критикую программистов. Тут проблема не в "стороне конфликта", а в том, что автор в статье делает совершенно невменяемые выводы из того, что сам же описал.
невменяемые выводы
Например?
Ведущий программист (Ваня, привет!), считающий себя звездой, внедрил данный функционал (бизнес-логика, встроенная в CRM на PHP) прямо накануне своего отпуска, протестировав его, видимо, на единичном заказе - или, может быть, в уме. И уехал в отпуск.
Как примерно десять раз сказали в комментариях, в такой ситуации у вас хтонический ужас невообразимых масштабов в первую очередь с процессами разработки и введения в эксплуатацию, если такое даже теоретически может произойти. Делать вывод "программист плохой и в нём проблема" - очевидная, казалось бы, ошибка.
Делать вывод "программист плохой и в нём проблема" - очевидная, казалось бы, ошибка.
Предрекали, что вы выведете меня на чистую воду, процитировав мои невменяемые слова, а не припишите мне какую-то свою глупость.
Вот моя цитата, полностью противоположная тому, что приписали мне вы:
Гораздо больше вины в данной ситуации лежит на плечах руководителя, который не предвидел такого развития событий, а не собственно на этом сотруднике.
Что же до звездного PHP программиста Вани, пожалуй, следует пояснить. Я тогда работал в роли старшего программиста/руководителя группы 50% разработки / 50% руководства. И на этот, хотя и смежный с нами участок, вообще никакого влияния оказать не мог.
У меня, и у Вани были разные руководители, подчинявшиеся гендиру, которые кое-как пытались выстроить процессы. Но в какой-то момент Ваню хотели перевести к нам в команду, и на это он заявил, что слишком крут, и будет подчиняться только гендиру (о таких тайных желаниях программистов быть поближе к боссам каждая вторая статья на Хабре Ивана Белокаменцева - в отличие от моей, пользуется большой популярностью).
В результате, над Ваней не осталось фактически никакого контроля (гендир не понимал в разработке и тестировании вообще ничего). Вот так его сырой код и попал в продакшн.
Что касается вины, она солидарная, Вани и Сережи: первый продемонстрировал незрелость, безответственность (выкатывать эту жесть в прод перед отпуском, не оставив заместителя, который все откатит, если что-то пойдет не так) и несоответствие заявленному уровню, а второй - некомпетентность, мягкотелость и отсутствие минимального контроля на критическом участке.
Вина не солидарная, т.к. начинается она именно с момента "над Ваней не осталось фактически никакого контроля ", виноваты тут гендир и те, кто могли (и должны были) ему указать на эту дикость, но не указали. Ваня еще нормально держался, мог без контроля и тестирования столько долговременных глубоких багов настрогать, что нагнулся бы стартап целиком даже без его отпуска.
Например о том, что разработчикам впадлу делать тестовые задания.
Впадлу делать бесплатно и на первом этапе отбора.
Многим действительно впадлу, справедливости ради. Да и даже если нет, это не самое вопиющее в статье, как мне кажется. :)
Особенно при учёте что таких "первых этапов" может быть десяток, делать каждому тестовое задание на 2 часа - из разряда мазохизма.
А вы бесплатно поработаете при капитализме, особенно, если считаете себя профессионалом с хорошей квалификацией и широким бэкграундом? (не важно кем вы работаете)
Так я к чему это. С полгода назад случился конфликт у исполнительного директора и директора нашего управления. Испдира после этого потихоньку «ушли», и… о чудо, полгода без исполнительного директора — и как-то особо разницы не замечаем. А вот ребят-аналитиков не хватает. Такая вот поучительная история.
но техдиру приспичило
получил от прошлого руководителя дурацкую задачу
Так как данный программист почему-то был в прямом подчинении нашего гендира, то он был сурово наказан... устным замечанием
Рыба гниёт с головы. В этих случаях прежде чем говорить о проблемах программистов, стоило бы о проблемах руководства поговорить.
Очень интересная статья, но ещё интереснее реакция на неё. Заходя в комменты, я совсем не ожидал, что у разрабов ТАК подгорит.
Кратко о себе - когда-то работал исполнительным директором на производстве. А сейчас PM в IT)
В статье слишком много пассивной агрессии. Читать банально неприятно, видно что у человека подгорает... Но зачем лично мне это читать - непонятно.
Синдром самозванца - это все же про ситуацию, когда человек считает свою компетенцию НИЖЕ реальной. А не наоборот.
Это тоже может выглядеть пассивной агрессией - но есть предложение автору порефлексировать над своей собственной компетенцией как руководителя и лидера.
Все люди лажают. Кто-то чаще, кто-то реже. Кто-то во всем винит только себя, кто-то кого угодно кроме себя. Кто-то нервничает после этого, а кто-то наоборот веселится. Это нормально, все мы люди. И всем мы разные люди...и все люди лажают. С этим надо жить. А уж если у тебя твой подчиненный налажал, а ты не подстраховался через процессы, через обработку рисков, через что-угодно... То и ты налажал... Но ведь это неточно)))
Люди не шестеренки и не ресурс... Как ни странно - они именно люди. Удобнее руководить шестеренками, особенно в банке... Но это удобнее не значит правильнее
Синдром самозванца - это все же про ситуацию, когда человек считает свою компетенцию НИЖЕ реальной. А не наоборот.
Да это понятно. Автор имеет в виду, что популярные сейчас статьи могут воспитывать в некоторых людях ложный СС. Когда он вроде и понимал свои пробелы, но потом его уговорили, что это СС - а на самом-то деле он огого.
Люди не шестеренки и не ресурс… Как ни странно — они именно люди. Удобнее руководить шестеренками, особенно в банке… Но это удобнее не значит правильнее
с одной стороны, да. но профессионал, приходя на работу (не обязательно буквально), должен выполнять роль «шестерёнки»: выполнять свою работу, а не рефлексировать, например, по поводу того, как вчера поругался с женой/мужем.
понятное дело, что это не совсем реально, но это то, к чему нужно стремиться.
А кто такой исполнительный директор? Это типа CEO, "самый главный"?
А ТК РФ не подразумевает испытательный срок?
Вроде как за месяц-два-тои можно всё узнать, а если не увидели, что человек неподходящий - менять нужно и остальных членов команды.
Знакомые эйчары говорят, что с испытательного срока тоже сложно уволить.
договор ГПХ и прочее для этого есть, который можно на время ИС использовать
Сложно, если не прописаны должностные обязанности. И не указаны цели, которые следует достичь (грубо говоря когда всем пофиг и бардак).
Бардак удобен, чтобы навесить 100500 левых функций, и загрузить по полной.
Но вот уволить трудно.
Так что тут идет отрицательный отбор.
В таких условиях "выживают" те кто ничего не делает.
Т.к. доказать что ничего не делает очень трудно.
А вот кто "делает" рано или поздно уходят.
да будет вам известно что с испытательного не надо увольнять. просто не подписывается прохождение испытательного листа. всё.
Между тем, отсутствие такой паразитной активности - лучшее лекарство от выгорания, и вообще-то дисциплина для их же блага.
Как раз таки работа 8 часов в к ряду без переключения контекста это прямой путь к выгоранию . Мозгу нужно время чтобы структурировать информацию и банально передохнуть, а вот такая вот "паразитная" активность, время от времени, это отличный способ не обнаружить себя критически уставшим и не способным толком общаться на не связанные с работой темы.
Вместо четкого исполнения своих обязанностей, сотрудник занимается обсуждением/критикой задачи, решений, выбранных коллегами, настаивает на своем варианте
...
Можно попробовать объяснить сотруднику, что данная должность не место для самоутверждения, и общение не должно быть в ущерб выполнению собственных задач
А потом они говорят что software engineer это челок, который не таски закрывает, а проблемы решает и тут, внезапно, таки приходиться обсуждать задачу (и даже иногда критиковать), потому что опять таки внезапно наличие плашки руководителя еще не означает высокую компетенцию и в частности умение правильно поставить задачу. Я неоднократно и лично, и у коллег, наблюдал как постановка задачи примерно никак не сходиться с тем что ставящий задачу хочет получить. Без обсуждения, обычно это заканчивалось или полной переделкой работы или разговорами в стиле "почему сам не подумал и не предупредил".
Вы просто пока не столкнулись с эго-маньяком. Их 1 шт. на 50 человек.
А мне, например, доводилось разрешать конфликт, когда чуть до мордобоя не дошло - потому что видите ли джун перебил нашу рок-звезду (а по статусу не положено).
Ну и далее, регулярные обсуждения на ровном месте - не потому что есть какие-то значимые принципиальные проблемы в задаче, а потому, что, повторюсь, нужно создать дискуссию и в ней победить. Это важно, они питаются такими победами и без них работать не смогут.
А переделка всего с нуля необходима, как в прайде у львов, чтобы не осталось и следа того, то до прихода нашей звезды кто-то что-то полезное сделал. Оплатить такую переделку предполагается за счет денег, которые не получат акционеры, но презентовать ее им нужно будет вам, а как вы это сделаете - вряд ли эго-маньяка волнуют такие мелочи..
А мне, например, доводилось разрешать конфликт, когда чуть до мордобоя не дошло - потому что видите ли джун перебил нашу рок-звезду (а по статусу не положено).
Поздравляю, ваши хайринг-процессы допустили найм неадеквата. Тюньте хайринг-процессы.
Вы б лучше сказали, зачем вы предлагаете программистам вести себя как рабы на галере с вашим "отсутствием паразитной активности".
Тюньте хайринг-процессы.
Эта как раз была статья про тюнинг хайринга, а не про оскорбление чести и достоинства благородных разработчиков, как кто-то мог подумать.
зачем вы предлагаете программистам вести себя как рабы на галере с вашим "отсутствием паразитной активности".
Это рекомендация на 1 конкретную ситуацию. Представьте - по задаче нет прогресса 1,2,3,4 дня - и каждый раз проходя мимо сотрудника, вы видите развлекательные сайты, то есть это его слабость - он не может сам себя здаставить заняться работой - а виноваты в этом вы, поскольку позволили это. Профессионально он, прололжая в таком духе, точно не вырастет, и поэтому, работать на работе - для его же блага.
А другая ситуация - у сотрудника на данный момент наилучшая производительность в команде, так у кого повернется язык попрекать его, кто будет высматривать, что там на мониторе? Но надо понимать, что это привилегия, она дается по заслугам, а не по дефолту.
К каждой ситуации нужен свой подход - именно поэтому там и таблица, а не совет "управляйте хорошо, и все будут работать хорошо".
по задаче нет прогресса 1,2,3,4 дня - и каждый раз проходя мимо сотрудника, вы видите развлекательные сайты, то есть это его слабость - он не может сам себя здаставить заняться работой
А вы проходите мимо сотрудника раз в 15 минут, или как часто, что вы делаете такие выводы? Если да, раз в 15 минут - вам точно надо в погонщики рабов на галерах, а не в управленцы в IT-компании, уж извините, потому как такие процессы демотивируют работать, особенно в долгой перспективе, абсолютно всех, кого я знаю.
Если же вы не стоите за спиной разработчика буквально весь день, на что я очень надеюсь ради вашего с разработчиком ментального здоровья, то в ситуации "по задаче нет прогресса 1-2-3-4 дня" надо разговаривать с сотрудником, возможно с участием других людей с технической экспертизой и доменным знанием, а не делать скоропалительные выводы. И да, причины могут быть разные - в задаче могут быть непредвиденные сложности, которые снаружи воспринимаются как "нет прогресса". У самого сотрудника могут быть сложности какого-то вида, начиная от "приболел, голова не соображает", заканчивая "поругался с женой/мужем/девушкой/парнем, сконцентрироваться тяжело" или "продаю квартиру, 5 часов в день в банке и у юристов, не до того". А в развлекательные сайты я на работе тоже нередко смотрю, пока, например, у меня тесты сервисов гоняются (что может происходить 15 минут кряду), а параллельно в голове вертеть ту же проблему или уже следующую.
Профессионально он, прололжая в таком духе, точно не вырастет, и поэтому, работать на работе - для его же блага.
Не надо пожалуйста за других людей решать, что для их блага, а что нет, потому что у вас могут быть очень разные представления о том, что вам нужно. Например, сотруднику может быть нужно не поехать крышей или хотя бы не выгореть под надзором начальника, который каждый раз проверяет, что у сотрудника на мониторе, проходя мимо.
А вы проходите мимо сотрудника раз в 15 минут
Разумеется, реже - но проблема не во мне, а в том, что остальная часть команды тоже прекрасно видит, что они напрягаются и двигают телегу, а кто-то прилег на нее и выезжает за счет других, получая зарплату наравне со всеми.
надо разговаривать с сотрудником, возможно с участием других людей с технической экспертизой и доменным знанием
Разговаривать - разумеется, кэп. Но то о чем вы говорите - вообще другой пункт в таблице - и если человеку действительно не хватает экспертизы, и он озабочен ее набором, у него будет открыт stackoverflow.com, а не развлекалово.
Не надо пожалуйста за других людей решать, что для их блага
Не надо пожалуйста подписывать трудовые договора, а потом делать вид что ТК РФ - для дураков (но вы ЗПшечку-то платите без задержек, иначе засудим), мы с парнями на Хабре решили, что у нас от работы будет выгорание.
В ТК есть небольшой намек, что "В течение рабочего времени сотрудник должен исполнять свои должностные обязанности, установленные трудовым договором (ст. 21 ТК РФ). Это означает, что сотрудник не вправе использовать рабочее время в каких-либо других целях, кроме работы." Кстати, там в ТК же есть про паузы на отдых - которыми все постоянно пользуются, выходя покурить - но этого же мало, надо еще и на рабочем месте устроить себе отдых в пропорции к работе 50/50, а то и 95/5. Вот эта картинка, она не случайно появилась:
И да, большая часть сотрудников не контролируется и не наказывается за это все, но повторяю для особо одаренных - это привилегия за хорошую работу, с чего вы решили, что это вам подарок по умолчанию, за то что вы вкатились в ИТ? Чем другие профессии хуже?
Недавно довелось ехать между городами на коммерческом микроавтобусе. Так балбес-водитель, у которого кстати на переднем сиденье ехал ребенок, достал телефон и довольно долго смотрел каких-то женщин на скорости в 100км/ч. Да, дорога ровная и незагруженная - но очевидно же, что если будет яма или упавший с самосвала кирпич, он не среагирует и мы улетим в кювет.
Ему, разумеется, сделали замечание (через полчаса такой езды - а вдруг там что-то важное, у человека судьба решается?), плюс еще я указал это в отзыве о поездке.
А вот еще старый начальник рассказывал, на у них на плавильной печи было автоматическое управление вводом электричества, а дежурная смена на НГ приняла на грудь и решила вздремнуть (все ж само работает) - и именно в это время залип контактор. Только случайно проходивший мимо рабочий по звуку определил, что какая-то жесть творится, а то бы угробили оборудование на много миллионов, и не ровен час, люди погибли при пожаре.
Но почему бы и нет, давайте теперь все забьем на работу и будем развлекаться, пусть какой-нибудь очередной Дятлов, который вместо вдумчивого чтения инструкций сидит в телефоне, устроит еще один Чернобыль или Фукусиму.
Или вы дифференцируете - вот тем-то рабам на работе отвлекаться нельзя категорически (чтоб у нас в хате свет не гас, и батареи оставались теплыми), но мы же айтишники, высшая раса, у нас "надо к людям относиться мягше, а на вещи смотреть ширше?"
каждый раз проходя мимо сотрудника, вы видите развлекательные сайты
Если работа делается - то в чём проблема?
Я могу работать 4-5 часа без перерыва в потоке, но потом остаток дня я буду в состоянии овоща.
И да, буду смотреть развлекательные сайты, потому что кодить в таком состоянии означает завтра всё переписывать.
Сотрудник допускает небрежности в оформлении кода, названии переменных
На скорость за полчаса что-то существенное накодить еще и по феншую (который в каждой конторе свой)?
поэтому тестовые задачи дают решать дома, что сразу делает их практически бесполезными: к заданию немедленно подключаются друзья, знакомые, платные репетиторы.
Это какая-то параноя. Ну купит чувак себе тестовое, но то что не он его делал выяснится в течении первых 2х суток работы. Чтобы этого не понимать надо быть реально очень тупым и таких надо на других этапах собеса отсеивать.
Я за оффлайн тестовые, масштабом 10-20 часов. В качестве компенсации контора может предожить (а) деньги, по нижнему уровню фриланса в своей области, (б) реально детальное ревью архитектуры и кода, (в) зафиксированый контрибьюшн (если тестовое было привязано к какому-то опенсурсу).
20 часов по нижнему уровню фриланса? Я даже за двойную часовую ставку текущей работы сначала десять раз подумаю, прежде чем браться.
Учитывая рынок, я всегда найду работодателя адекватнее: того, кто умеет в собеседования и краткие, но емкие ТЗ.
Ревью - это хорошо.
PR - ну такое. Сложно подобрать подходящую задачу.
Никто не умеет. По цирковому этюду на полчаса не оценить продуктивность даже на типичной скрам таске в 1-2 дня. А хочется вообще говоря поддержку и развитие систем на отрезок в пару лет.
Но собес и ТЗ не призваны оценивать продуктивность. Это вообще невозможно.
А уровень вполне себе оценивается собесом и кратким ёмким ТЗ на 2-3 часа. Плюс резюме: компании и проекты, если речь про senior-позицию. Часто оно говорит о многом и собес превращается в диалог о нетривиальных задачах, а не об умении писать код.
Там ТС заявлял о «купленых» ТЗ. Это уже похоже на паранойю.
Мне очень жаль, что ты относишься к сотрудникам как к врагам. Я бы не хотел работать у такого руководителя.
на вопросы о переработках отвечает отрицательно
Не до конца понял формулировку, отказ от переработок - один из признаков самозванца?
Тестовое задание на 1 час еще как-то можно посчитать частью собеседования. Но тестовое задание более чем на 1 час - это уже задача/поручение от работодателя, подразумевающее возникшие договорные (трудовые или подрядные) отношения, в рамках которых ожидается оплата/вознаграждение.
Эффективность тестового задания по сравнению с собеседованием или тестом (типа ЕГЭ) - весьма сомнительная.
Лучший вариант - это собеседование (+ тест) и затем краткосрочный договор на 1-3 месяца с полноценной оплатой (испытательный срок).
Ведущий программист (Ваня, привет!), считающий себя звездой, внедрил данный функционал (бизнес-логика, встроенная в CRM на PHP) прямо накануне своего отпуска, протестировав его, видимо, на единичном заказе - или, может быть, в уме. И уехал в отпуск.
Результат: половина клиентов получила при доставке чеки, существенно превышающие сумму заказа в личном кабинете.
Настолько прекрасно, что невозможно удержаться - в компании культура разработки, тестирования и эксплуатации отсутствует, но виноват программист Ваня. Как у техдира обстоят дела с синдромом самозванца?
Писать такие статьи на Хабре требует определенной смелости. Так как Хабр все-таки в первую очередь ресурс для технических специалистов, то их тут сильно больше чем менеджеров и управленцев. А потому взгляд на подобные темы тут довольно однобокий всегда. И за любую попытку подорвать мир, в котором айтишники - принцы на белых конях и д'Артаньяны, которых надо всячески ублажать, а менеджеры - злобные гады, спящие и видящие как бы только их унизить и оскорбить (хоть тестовым заданием, хоть отказом принимать на веру их гениальность), тут сразу прилетает куча минусов и всеобщее осуждение.
Конечно, круто жить в идеальном мире, где тебя сразу берут на работу, ничего не проверяют, не устраивают стресс на собеседовании. В идеале бы вообще никак не общаться с заказчиком и не видеть его вообще. Но так не бывает, никто так и не придумал внятного способа отделять хороших специалистов от плохих. Вот каждый и придумывает свое.
И проблема самозванцев действительно есть. Сейчас в ИТ не ломится только совсем ленивый и бесталанный. Приходят вереницей люди, которые не умеют ВООБЩЕ НИЧЕГО, но при этом просят 100+.
Я уже давно придумал "тест на зомби" - прошу написать код, разворачивающий массив. Даю ноутбук, где уже написан скелет теста (заполнение массива, вывод). Объясняю что это очень простой тест, что тут нет подвоха и не нужно никаких "олимпиадных" решений. Отхожу в сторонку, даю человеку спокойно это написать, проверить, а потом позвать меня.
Половина собеседующихся на джуна не способны это сделать.
Один раз взял таки человека, который эту задачу сделал кое-как с трудом, запутавшись в индексах - очень нужны люди были срочно, а человек описывал неплохой опыт и сыпал всякими умными словами и технологиями, с которыми якобы разбирался. Потом много раз пожалел, человек реально оказался не способен писать хоть какой-то код, выходящий за рамки "взяли объект из одного библиотечного метода и передали в другой". Причем за полгода работы никак не прогрессировал и лепил дикие ошибки, показывающие что алгоритмическое мышление вообще не про него. Зарекся с тех пор брать тех, кто этот тест не проходит.
В курсе, конечно. Но мой вариант мне нравится больше. Впрочем тут уже чисто вкусовщина.
Вот именно потому, что все в курсе про FizzBuzz, она в данном случае и не подходит - ее можно зазубрить.
Но общий принцип верен: не стесняйтесь давать элементарные задачки на кодинг - половина соискателей их не пройдёт.
Я обычно даю произвольную рекурсивную функцию. Или сумму несложного ряда. Тоже никакой «олимпиады» - просто реализовать записанную на бумажке формулу. И очень часто человек, который минуту назад уверенно сыпал умными техническими терминами, не понимает что такое «цикл» и «переменная».
Как показала практика, много кто спотыкается даже на поиске минимального\максимального числа в списке...
Есть такое.
Несколько раз ходил помогал принимать экзамены по программированию у студентов своего же ВУЗа, уже будучи выпускником. Любили в качестве разминки давать задачу "напишите фукнцию, которая возвращает вашу желаемую оценку на экзамене". То есть по факту просто какой-нибудь int f() {return 5;} Даже с этим многие не могли справиться.
Но потом эти люди все равно получали диплом программиста и часть из них наверное пыталась куда-то трудоустроиться.
Именно для защиты от таких и есть все те тестовые задания, так глубоко оскорбляющие многих гуру из комментариев к этой статье и подобным ей.
Ну смотря что подразумевать под тестовым, таких можно отсеять просто задав пару задачек на 5 минут на собеседовании
Судя по комментариям на хабре, многие сильно злятся и агрятся даже на такую вот задачку на написание кода. Сразу начинаются гневные вопли в духе "а что если человек гениальный программист, но в стрессе на собеседовании не может написать даже метод сложения двух чисел!?".
Есть такое, мы сейчас на работе проводим собеседования для джунов и даем простые задачи, в духе поиска минимального числа в списке, при том, что это удаленные собеседования, многие на этом спотыкаются. А как раз во избежание стресса, просим после собеседования прислать решение, в течение нескольких часов. Забавно, но был случай, когда один парень прислал решение одной задачи с явными ошибками в выводимом результате...
Мысли практически совпадают с моими.
И проблема самозванцев действительно есть. Сейчас в ИТ не ломится только совсем ленивый и бесталанный.
это не "комплекс самозванца", а именно, что реальные самозванцы
код, разворачивающий массив
так?
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));или это
взяли объект из одного библиотечного метода и передали в другой
?
list.stream().mapToInt(x -> x).toArray()
А зачем так сложно (или это шутка, которую я не понял)? list.toArray чем плох?
Вы, вероятно, принадлежите к той когорте разработчиков, кто тестовые задания не любит, и поэтому пытается их всячески извратить и продемонстрировать, что вы таки умнее рекрутера и вертели вообще все эти тестовые задания.
Ваш пример, конечно, работает. Но, например, создает кучу ненужных временных объектов и вызывает кучу методов. Зачем? Чисто выпендриться?
В принципе формально поставленную задачу он выполняет, но впечатление оставляет не самое лучшее.
Если посмотреть мой другой комент, можно определить что к тестовым заданиям я отношусь позитивно.
Куча объектов? М... Один? 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));Смотрю и вижу что читает он хуже. Надо вчитываться что я там натворил :)
Ещё оригинальный код зачем-то боксит кучу примитивных интов. :)
Не один, вы же еще боксите все в Integer, который тоже объект. И вот это уж точно совсем лишняя операция.
В результате работы список останется неизменным.
Зачем же так усложнили, когда можно ещё проще, быстрее и с меньшим расходом памяти?
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));
}
Праздное любопытство - а если в "тесте на зомби" джун напишет (пример на C#):
Array.Reverse(arr); // Ну и там выше using, конечно
Как он, по вашему, будет считаться прошедшим тест? :)
Интересная табличка. Если на нее взглянуть с другой стороны (с которой смотрят очень многие), то смысл получается приблизительно такой: если в компании выстроена разработка с тестированием, код ревью, планированием; если у разработчиков лид не названиям переменных обучает, а с людьми работает; если в компании построен онбординг, поэтапно оценивается прохождение испытательного, есть программы обучения, - то никакое тестовое на собеседовании не нужно.
Т.е. тестовое - это признак хаоса в отделе разработке?
поэтапно оценивается прохождение испытательного
то никакое тестовое на собеседовании не нужно
ну теоретически да. но те кандидаты, что не могут написать FizzBuzz, будут отсеиваться не на тестовом задании, а на испытательном сроке. для компании это банально невыгодно.
Ну я же не говорю, что собеседование с техническим специалистом совсем не нужно. Граничные случаи отсеиваются и без тестового - просто глядя на то, как человек рассказывает о своем опыте, как отвечает на тех вопросы, какие знания, если спросить "чуть в сторону".
На самом деле тестовое задание - это всего лишь дополнительный этап воронки. Полезно, когда у вас столько кандидатов, что никакие устные собеседования не дают допустимого уровня фильтрации кандидатов. Или если если у вас одно место и вы готовы много месяцев искать для него "топчика". Который свалит через пол года, ибо в разработке хаос, руководители - самодуры, а тут офер на х2 пришел.
И опять же, тестовое не дает ответов на вопросы обучаймости, способности концентрироваться, способности работать в коллективе, разбираться в существующем коде. Т.е. оценка по испытательному нужна все-равно. Если процесс выстроен, то потеря компании - это ЗП за 3 месяца. Не взять кандидата для крупной компании - это могут быть потери побольше.
Конечно, все это верно при большом отделе разработки с постоянной нехваткой кадров. Если компания - пяток разработчиков, и неторопливо в поисках шестого (как раз как найдут - кто-то уйдет), тут совсем другие критерии.
Самое печальное, когда руководители с опытом в небольших компаниях не могут адаптироваться к новой компании с другими приоритетами и не меняют тактику отбора. А потом у всех, включая инвесторов, удивление - а где же люди, кто работать то будет?!
Попробуйте назвать (или просто сформулируйте для себя) хотя бы одну причину, по которой квалифицированный программист пойдёт работать в банк.
Высоких зарплат в банках рядовым специалистам не платят с 90-х годов.
IT является вспомогательным подразделением фирмы и в этом плане как бы людьми второго сорта.
Ничего концептуально интересного в программировании финтеха нет, это не атомный реактор и не рокет сайенс. Честно говоря, даже какое-нибудь дожигание мусора представляет собой на порядок более интерсную в техническом плане задачу.
В телевизоре результат труда этого программиста не покажут, и Президент премию не вручит.
Безработицы, вынуждающей хвататься за любое предложение, у программистов нет.
Так откуда вы ждёте компетентных специалистов? Они могут в этом секторе появиться только случайно или задержаться с тех времён, когда там были зарплаты сильно выше рынка.
Высоких зарплат в банках рядовым специалистам не платят с 90-х годов.
Из того, что я слышу и вижу, как раз рядовым специалистам в банках себе проще выбить зарплаты повыше, потому что крупные банки пылесосят рынок программистов и параллельно немножко перегревают им зарплаты. А вот самому топу именно исполнителей - да, проще что-то сильно более интересное и менее душепродажное найти.
Забавно, что вы это написали.
Проект, в котором я участвовал в качестве разработчика в банке, презентовали Президенту РФ, и это таки показали по телевизору. Соответственно, многим, и мне в том числе, вручили благодарности, и премии (хотя, конечно, и не из рук Президента).
Я не буду здесь, в кругу друзей, распространяться, что это было (одно название должности уже многих агрит) . Но те сотрудники, кто возможно узнает меня по роликам, легко поймут о каком проекте речь - и что это правда.
Вам удачи с программированием реактора и ракет.
Ну я получал премию от Президента, и что? Мы здесь не меряемся личными достижениями, а обсуждаем состояние рынка труда. Все знакомые мне программисты, кто работал в банках, оттуда свалили. Хотя менять сферу деятельности не очень-то приятно.
Все знакомые мне программисты, кто работал в банках, оттуда свалили.
А куда, если не секрет?
Потому что я наоборот, вижу, что в банках есть деньги и они готовы пылесосить рынок. И было бы интересно узнать, у кого денег еще больше, чтобы к ним пойти.
Потому что я наоборот, вижу, что в банках есть деньги и они готовы пылесосить рынок. И было бы интересно узнать, у кого денег еще больше, чтобы к ним пойти.
точно - в этом случае имеет смысл идти не к российским работодателям. Какой бы крутой российский банк не будет, но при сравнении с зарубежным работодателем (нормальным, конечно), банк проиграет. Я уж не говорю про волатильность российской валюты и все исходящие из этого риски.
В банках, очень много неадекватных "эффективных" менеджеров, поэтому дело даже не в деньгих зачастую.
Я не наблюдаю общего правила, но очень многие опытные специалисты идут, например, в строительство цифрового концлагеря разработку инфраструктуры информационной безопасности.
>Президента
Ого, да у нас тут особа, приближенная к Императору!
Как легко вы съехали с темы. Выбрали один посыл, исказили его, а всё остальное - отбросили.
Да, суровая правда текущего положения вещей: при наличии достойной альтернативы в банки сейчас не идут в подавляющем большинстве случаев.
А с определённого уровня банки остаются позади: они не предлагают даже конкурентных зарплат. И не афишируют их на hh.
Вы хотите лучших? Так и нужно брать лучших: CTO, PM/PO, тим/тех лиды. И вот они уже построят вам эффективный отдел. Только платить им нужно существенно выше рынка, потому что по рынку они найдут себе работу гораздо интереснее.
А конкурентная это сколько?
Есть у меня предположение, что Ваше представление о банках осталось примерно на уровне не 90х, но 2010-х, примерно
По примерам с факапами, выглядит не то, что программист Ваня плохой, а что у вас процесс разработки продукта плохой - выливать не проверенные задачи в прод, не писать тестов, и вы надеялись, что будет иначе?
А насчет тестовых заданий на собеседовании:
если вы собеседуете стажёра\джуна, достаточно пары простых задачек на 1-2 цикла, большое домашнее тестовое задание нет смысла им давать, все равно не решат
в случае мидлов, возможно можно дать тестовое, но если уж в ходе собеседования очень не однозначное впечатление и хотелось бы понять что из себя представляет (да и просто дать мелкую задачку, чтобы скинул в течении 1-2 дней)
а вот для сеньеров, давать тестовое задание, это как просить профессора по высшей математике рассказать таблицу умножения. В ходе собеседования, разговора, что человек делал, как делал и с какими проблемами сталкивался, можно понять что он из себя представляет, тут и за кодом ходить не надо.
Автор прекрасно понимамает проблему, но увы, не делает "еще один шаг". Тестовое задание на пару часов не покажет ничего больше чем тестовое задание на полчаса(что вполне в формат собеса укладывается). И это будут какие то базовые навыки умения писать код, и все.
Для выявления более комплексных наыков, нужно задание на 4-16 часов(причем 16 - лучше). А это достаточно много времени и далеко не все кандидаты(включая меня) готовы тратить столько времени на "еще_одно_собеседование". А если кандидат готов потратить 2 рабочих дня на тестовое задание, то тут аж целых 2 варианта:
у кандидата нет других предложений.
Ваше предложение уникально на рынке. Или з/п существенно выше среднего, или по каким то личным причинам кандидату хочется работать именно у вас.
В первом случае кандидат скорей всего вам не нужен, а второй бывает достаточно редко. Поэтому, с моей точки зрения, надо учиться оценивать умение писать код по собесу. Тут может помочь hr, который срисует психологический портрет, ну и собственно говоря небольшое тестовое задание.
Автор, как насчет того, что вам банально не хватило компетенции разобраться с Mongo? Не является ли безответственным поручение сложных задач - джунам? Как вы прокомментируете отсутствие тестирования на проекте федерального масштаба?
Вам не кажется, что вы перекладываете ответственность и не замечаете гораздо более существенных проблем, всего лишь следствием которых уже являются описанные вами кейсы?
Как здорово, что эта статья в минусах.
Говорил, говорю и буду говорить, что проблема этой индустрии не в рядовых кадрах, а в руководителях и их вопиющей некомпетентности, как в работе с технологиями, проектами, так и с людьми.
Извините, it - уже давно не про тех. склад ума и не про какое-то там мышление в целом
Крайне спорное утверждение, если вы говорите про клепание сайтиков на CMS, то возможно, а если что-то более серьезное, то умение думать, анализировать, как сделать то или иное решение не только по принципу "ну работает, чо", то увы.
Слава богу пока что есть выбор и довольно широкий. И не нужно выполнять тестовые задания в стиле - напишите форум или интернет магазин.
С одной стороны, согласен с проблемой поиска и определения специалистов с нужной квалификацией.
С другой стороны статью я резюмирую следующим образом: "С водой выплеснули ребёнка".
Я не против тестовых заданий. Но только если о компании всё известно на берегу. Какая зарплата. И это не 150 - 350, а 300 - 350. Сколько будет отпуска, как часто будут будить по ночам, что с переработками, и работой в праздники и выходные. Т.е эта компания и эти условия должны быть интересны и за них хотелось бы побороться. А не так что, напиши тестовое, а зп мы тебе скажем по итогам собеседования, и все подробности у девлида
Расскажите лучше про выявление самозванцев среди исполнительных директоров :)
Для начала я приведу весь список ситуаций, требующих внимания, а после отмечу, то, что из него волнует меня больше всего.
Узнал себя в первых шести пунктах. Хоть я и не программист.
Минусы автор заслужил.
Во-первых, нечего ставить себя выше тех, кого нанимаешь, все же не грузчиков. А тут высокомерие в каждой фразе начиная с заголовка. Добавляют ещё дурацкие тестовые задания вроде консольных крестиков-ноликов -- вроде мода на вопросы про водопроводные люки или количество заправок в Москве уже прошли, а это из той же серии "надо что-то спросить, но не знаю что -- попробую хоть развлечься".
Во-вторых, совершенно немыслимая табличка "грехов" -- как можно настолько не понимать людей, с которыми работаешь? И тем более быть их начальником?
Сотрудник не справляется с работой, хотя явно старается и находится в стрессе - классический самозванец, страдающий одноименным синдромом
Классический случай плохого управленца, который то ли посадил человека не на то место, то ли плохо распределил или дал не те задачи... Или просто перегрузил. И при этом не готов помочь нормальному работнику дорасти до нужного уровня.
Тут сразу вопросы -- это в первый месяц выявляется? Тогда это не проблема. Через полгода? Тогда точно проблема работодателя, а не разработчика.
В-третьих, совершенно непонятно, в чём глобально проблема: у хорошего разработчика наверняка есть пара проектов на GitHub, посмотрите заранее до собеседования, что он вообще пишет и как. Если обязательно надо протестировать человека в реальных задачах -- договор ГПХ вам в руки, месяц тестируйте друг друга как угодно, без долгосрочных обязательств. Не такие уж большие риски.
В общем, высокомерие*некомпетентность= минусы.
Давеча один мой коллега сказал, что на его взгляд, качество джуниоров сильно упало: не каждый джун осилит
прийти на собеседованиезакодить консольные крестики-нолики. Кстати, челенж для джава-скалистов - слабо закодить их в 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(_ => ())Только на интервью я хз, смогу или нет такое осилить. Походу, меня даже джуном не возьмут.
Эмс. По такому принципу можно любую программу на любом языке в одну строчку вместить. Это не однострочник, а просто код, в котором удалены все переносы строк:
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(_ => ())
Ой... А я крести-ноли не писал никогда... Ой-ой! Кажется, у меня выгорание! ;( Шоделать-шоделать?! Где же мой смузи?!!!
По теме. Тестовые задания считаю делом правильным. Программирование во время собеседования - правильно. Уточню - речь о джунах. Люди во время обучения только и делают что решают задачи, так что для них этот процесс привычен и вызовет меньше стресса чем вот эти ваши: "Перечисли методы класса Обжэкт" и "Нарисуй иерархию коллекций". Это, конечно тоже надо знать, но это, блин, справочные данные, которые всегда можно посмотреть прямо в ИДЕ. Хотя можно спросить, сидя за компом, заодно оцените навык исполнение ctrl-click :)
Когда вы задаёте задачки вместо вопросов по теории, кандидат сразу погружается в привычную для себя обстановку и перестаёт психовать, а вы имеете возможность наблюдать как он в реальности будет работать. Заодно можете поиграть в ментор-ученик, дав сначала с виду простую задачу, а потом начать накручивать подробности, вынуждая рефакторить решение. Но это сложно, да :)
По этой же причине код на бумажке или на доске - бред. Надо на компе. Можно с двумя мониторами - для удобства, можно на двух компах в режиме парного программирования, современные ИДЕ рулят. На бумажке можно (нужно!) ставить и уточнять задание. Несколько кружочков и стрелочек вместо тысячи слов, ящитаю!
И ещё. Здесь и не только рассказывают что кандидаты свободно рассуждают об архитектуре, просят сотку, но не могут написать цикл. Чё-та не верю! Тут либо задание ставится как-то совсем витиевато, либо стресс (хотя такие базовые вещи при любом стрессе пишутся на раз), либо оратор привирает :) Это как если прийти наниматься переводчиком, но не смочь перечислить первые 4 буквы алфавита. Не, не верю!
Как руководитель, я не особо разделяю гугловскую идею превратить собеседование в восхождение на Эверест, чтобы к нему готовились по полгода и складывали легенды аргонавтов о немыслимых испытаниях на пути к заветному оферу.
Но ведь Гуглу принадлежит самая популярная ос в мире. Гуглу принадлежит самый популярный видеохостинг в мире. Гуглу принадлежит самый популярный поисковик в мире. Гуглу принадлежит одна из крупнейших рекламных сетей в мире. Они определенно знают себе цену
Мне понятна точка зрения автора стати, но в такой ее формулировки разделить ее я не могу.
Если сместить акцент данной статьи с противопоставления менеджмента и разработчика на оценку эффективности процесса найма ее "полезность" значительно возрастет.
Зачем нужны тестовые задания, собеседования и другие подобные мероприятия? Можно же брать всех подряд и если у вас эффективно выстроены остальные процессы не подходящие люди будут отсеяны из компании. В данном случае мы рассматриваем только часть процесса найма, единственная цель которой уменьшить кол-во кандидатов. Это нужно, чтобы скомпенсировать недостаток внутренних процессов, сделать их дешевле и менее требовательными к, часто не профильной, квалификации исполнителей. Компания пытается найти людей которые к ней подходят, стандартизировать поток на входе, чтобы потом с ним было проще и дешевле работать. Копания не ищет хороших или плохих разработчиков, квалифицированных или нет, копания ищет разработчиков которыми сможет управлять и которым сможет платить. При этом не важно, что именно компания декларирует, в итого все придёт к ситуации, которыми можем управлять и которым можем платить, остальные ситуации значительно ниже по эффективности. Если берем и не можем платить, то тратим на наём, онбординг( даже если его нет ), но человек уходит не окупив затраты и мы в минусе. Если берем тех, кем не можем управлять, разваливается менеджмент, эффективность падает в разы, сотрудники начинают преследовать цели никак не коррелирующие с "целями" компании из такого болота, все кто могут "крути землю" бегут сверкая пятками.
Надо признать, все что мы хотим, убрать "лишних" кандидатов. Если вы можете себе позволить "лишних" кандидатов, то вы можете себе позволить и тестовые задания и даже не оплачиваемую стажировку. Дайте условия сеньера с требовании мидла и делайте, что хотите.
От чего же здесь "подгорает" у всех сторон процесса? Просто авто пишет про компании со слабыми процессами и утверждает, что это можно исправить процессом найма. Но вот только исправить процесс найма в компании со слабыми процессами нельзя. Нельзя построить хороший наём в компанию со слабыми процессами, он будет искать не подходящих под такие процессы кандидатов. Описанные автором примеры, это примеры хорошего и правильного найма, компания взяла кандидатов которыми может управлять и которым может платить, все сошлось, здесь нет ошибки, просто процессы в компании такие в которых выживают такие кандидаты, не плохие или хорошие, а подходящие.
Вывод? Можно перефразировать известную фразу: "Самая большая глупость — это делать тоже самое и надеяться на другой результат.", хотите получить других разработчиков, меняйте компанию, ее процессы и ее менеджмент, тестовые задания вам в этом не помогут, они приходят уже тогда, когда вы все остальное поправили и у вас все равно слишком много кандидатов.
У статьи отличный посыл.
Есть руководитель с плохо выстроенными процессами, есть разработчики, которые делают ошибки - из-за плохих процессов ошибки разработки становятся критичными и происходят денежные потери. Понятно что при "хороших разработчиках" (подходящих под текущие условия) можно будет не заморачиваться и не выстраивать что-то, что будет отлавливать косяки до прода. Это долго, дорого, больно и даже нужно с управляющим директором согласовывать. И тут уже в случае косяков придется исполнительному директору часть вины на себя брать (на дураков-разработчиков не свалить).
Как быть в такой ситуации? Может посмотреть в сторону неторопливых, скрупулезных, дотошных людей? Бывших аналитиков, тестеровщиков, базистов пришедших в разработку. Чтобы применяли различные модели анализа в повседневной жизни (не знаю, регрессионную модель с риск-весами для покупки квартиры), чтобы на собеседование приходили минута в минуту, чтобы не терпели хаос в системе контроля версий, плохой нейминг, бардак на рабочем месте.
Кажется что для банковского интерпрайза не нужны прямо звезды от разработки, а нужны просто хорошие, дотошные ребята, готовые идти на контакт с бизнесом.
А вообще стало грустновато от прочтения статьи. Как будто люди от разработки, которые не подходят под условия, в которых работает автор действительно плохие (пускают слюни и в круг квадрат вставляют ага). Захотела бы я работать с человеком с настолько циничным подходом? Наверно нет. По крайней мере не в прям подчинении.
Крестики-ноли кстати считаю отличной задачей для джуна. Тут и показатель того, что работник может написать программку от начала до конца, проверить все выходы за границы и т.д. Для мидла\синьера конечно нужны другие проверки.
"Кейсы" конечно просто бомба. Настолько что захотелось поискать информацию об авторе и посмотреть несколько его видео на ютуб. Может в этом и был отчасти троллиноговый посыл - вызвать резонанс? Не хочу верить в то что единственным смыслом статьи был вопрос - как найти тех кто не ошибается.
Есть мнение что у автора долго пилился какой-то проект, какими-то разработчиками. Потом оказалось что школьный/вузовский/курсовый джун из современного мира не может в этот проект сходу. Причина тут не в плохом образовании или самозванстве, а в том, что проект 2к11 + 10 лет томления в собственном соку обладает своеобразным вкусом. И освоить быстро то, что писали пять разработчиков десять лет просто нельзя. Особенно по написанной для галочки документации. Что еще хуже за 10 лет вырабатываются специфичные софт-процессы, например отсутствие тестера (а что, 10 лет назад они были опциональны), или жесткое ревью с задержкой в неделю.
Ну а теперь скажите, вот придет к вам условный разработчик пишущий на скала в одну строчку крестики нолики. Увидит легаси, большая часть из которого вообще не понятно зачем. Долго копаясь в вашем проекте он робко запушит таск, который на минуту вашим текущим разработчикам. Через неделю получит "все работает, но переименуй все переменные ибо мы не используем букву 'а', перемести все файлы, и функции пиши в формате хайку".
После этого он день поругается, еще день пересилит себя и переделает под вкус текущей команды. Запушит - переделает. Наконец его таск примут, и окажется что у вас еще есть специфичный ритуал завершения задания, который он не сделал и теперь вы думаете что он вообще ничего не сделал. И будете даже правы, ведь он занимается втиранием в команду и процессы.
Так что вероятней всего вы теперь заложник ваших разработчиков. Они так старались сделать быстро, что сделали только под себя. Хотите это исправить - готовьтесь переделать с нуля, или хотя бы потратить одну пятую от времени на разработку. Заодно оптимизируйте процессы с которыми ваш самозванец столкнется. Организуйте полноценные песочницы, после найма поставьте нормальное менторство, пусть ваш разработчик сидит с джуном и показывает как ему делать его задачи. Тогда пойдет какое-то ускорение. Да это дорого, да это долго, но выбора у вас уже нет.
Как написать статью о самозванцах, ничего не понять и считать что ты лучше других знаешь как надо делать.
Выявление самозванцев среди программистов