Комментарии 316
Вы угадали одну из наших идей. Мы научились отбирать реально классных специалистов, но иногда они просто не подходят в наши проекты — нужно знание джанго, например, а у кандидата его нет (да, с примерами у меня туго). При этом он крутой специалист, за которого компании готовы драться.
Сертификация — нет, но отбор кандидатов как side project — почему бы и нет
Думаю есть аналоги такой программы, но по сути это и есть оценивание реальных навыков кандидатов.
Боюсь эта история работает только для (вчерашних) студентов. Специалисты с реальным опытом уже вряд-ли будут тратить недели времени чтобы получить "оценивание реальных навыков"
Теперь вам осталось совсем чуть-чуть, — добавить возможности по отбору кандидатов на другие ЯП и профессии.
И ещё есть одна проблема, работодатель должен быть адекватным, и точно знать чего хочет от кандидата, для того чтобы вообще граничные условия были, и уметь эти условия как минимум чётко изложить. Т.е.система сможет исключать работодателей, которые хотят швейцарский нож, но незнают зачем он им.
А потом уже человеческое общение. Вот там и софт-скилы и всё остальное.
Вы вот такой из себя богатый и успешный готовы рыться в компаниях, как в сору, выбирая ту, которая вам «интересна».
Но подавляющее большинство людей — это нищие голодные люди, которым нужно получить хоть какую-то работу, чтобы хлебушка себе купить на зарплату.
Именно эти люди в основном и приходят на собеседование, на них направлена вся деятельность по отбору. А такие, как вы, в целом особенно в работе и не нуждаетесь, поэтому ваши пожелания относительно процесса отбора не так уж и важны.
Едут довольно живенько, но поток пока что не иссякает.
Да что там, в Москве видел людей, которые не знают себе цену.
Человек — даже сеньор программист — это не только знания в голове, но и большой набор прочих параметров: мнения о себе, мнения о рынке, представления о справедливом и должном и т.д. и т.п.
Самые лучшие и добросовестные специалисты обычно держат средние по рынку цены, ну или чуть-чуть выше среднего. А самые дорогие — это не самые лучшие, а банально самые наглые. Сталкивался много раз.
Я сейчас не даю оценок, насколько это хорошо или плохо, просто констатирую факт.
Я лично лучше буду работать с не очень специалистом чем с не очень человеком.
Вы прям из сотрудников HR делаете супергероев, способных пробраться в человеческие мысли :). К сожалению, если бы это было так, то собеседовать человека вовсе не пришлось бы. А в реальности, никакой специалист не расскажет свои «не очень» человеческие стороны на собесе. Да и в вообще они могут проявиться в самый неподходящий момент — например, при сдаче проекта с горящими дедлайнами.
Всегда очень удивляюсь, когда компания отвергает кандидатов по признаку "не знал фреймворк Х". Ну не знал, и что?
Фреймворков тысячи и все примерно одинаковые. Знание от незнания отделяет в лучшем случае пара дней изучения, а чаще пара часов.
Так вот: вы действительно готовы оказать сеньору (то есть человеку с огромным опытом решения задач и глубокими познаниями в разных технических областях) только из-за того, что он не знает свистелку Х?
Мне казалось, что сеньор на то и сеньор, что способен эффективно решить (или научиться эффективно решать) в целом любую задачу любым инструментом.
Знание от незнания отделяет в лучшем случае пара дней изучения, а чаще пара часов.Написать hello world или to do — да, не вопрос. Но чтобы действительно погрузиться в экосистему, писанные и неписанные правила/практики/грабли и научиться осознанно рулить ситуацией — нужны как минимум пара недель. Это в идеальном случае, когда человек опытный и уже хорошо владеет аналогами.
За два часа — это либо гений, либо фантазёр-самозванец.
В итоге эти 2 часа вы потратите на то, чтобы в целом изучить архитектуру фреймворка и набор его компонентов, а потом сможете сравнительно легко нагуглить нужный рецепт.
Также не очень понятно, чем «осознанно рулить ситуацией» в проекте на Х будет отличаться в «осознанном рулении ситуацией» в проекте на Y. Набор подходов везде примерно один и тот же, проблемы и методы их решения тоже (даже не упоминая волшебного слова «паттерн»).
Наверное, вызубривать наизусть все хитрости и какие-нибудь особенно тонкие тонкости (кстати, какие?) вы будете немного дольше, но для большинства задач этого просто не требуется.
Но даже допустим вы правы и изучение фреймворка до уровня неписанных правил/практик/etc и полной осознанности занимает пару недель и вам необходим именно такой уровень. В такой ситуации, вы действительно откажете сеньору, который за всего полмесяца способен стать идеальным сотрудником? При том, что он скорее всего несет в себе многолетний багаж пользы? Звучит по-прежнему странно.
Ну не знал, и что?
Фреймворков тысячи и все примерно одинаковые. Знание от незнания отделяет в лучшем случае пара дней изучения, а чаще пара часов.
Не знал — и прошел мимо вакансии. А на дворе октябрь 2008 года, город Нью-Йорк, сокращения этажами, а ты на H1B. Как Вам такой расклад? В Москве тоже массовые сокращения, и контора, где работал перед отлетом, уже не существует, а у всех коллег заморожен найм. Это к чему — Вы показываете поведение в ситуации, когда Вам дико фартануло и рынок Ваш. Но бывают в жизни ситуации противоположные, когда упоминание в резюме фреймворка 7.1 вместо ожидаемого 7.2 — это вопрос будет ли у тебя зарплата на ближайшие пару месяцев или нет.
А теперь скажите, за сколько я должен разобраться с новой читалкой конфигов, роутером или ормкой, если я их видел уже штук 20 и они делают примерно одно и то же? Вы вероятно скажете «ну полчаса, документацию глянуть и несколько примеров посмотреть».
То же самое и в целом. Нет ничего в этих ваших веб-фреймворках такого уж сложного, всё везде у всех одинаковое, только методы по-другому называются и внутренняя структура немного разнится. И нормальный опытный разработчик, сев за очередной такой фрейморк через пару часов (если тот прям очень сильно похож на остальные) в лучшем случае и пару дней (если где-то много магии наворотили) в худшем вполне сможет выдавать нормальный код с приемлемой скоростью.
Так что нет, ничего поверхностного здесь нет, как и ничего сложного в обсуждаемом вопросе.
Вы так говорите, будто фреймворк — это что-то особо сложное, что нужно прям учить.
Ну, зависит от ожиданий рекрутера и состояния рынка. Когда рынок на подъеме, сокращений нет, конкурентов гугла не найти днем с огнем — то да, не особо сложное т.к. никто не ждетчуда от кандидата. А когда пошли массовые увольнения и кандидатов как грязи, то там уже требования к идеальности их знаний будут показываться на каждом интервью. Я в жизни видел вторую ситуацию, и там подход «освоить за полчаса» может не фартануть — там могут ждать фреймворков знания от зубов, как Отче Наш.
Каждый фильтр может приводить как к ложноотрицательным (офер людям, которые потом покажут себя плохо), так и к ложноположительным срабатываниям (когда отсеяли того, кто отлично бы себя показал).
Если мы тюним фильтр только на базе одного рода ошибок, то это, вероятно, приведет к росту ошибок другого рода, если на них не тестировать. Т.е. если мы вводим новые правила сразу же, как взяли на работу неудачного кандидата, то тем самым мы повышаем число ошибок первого рода, т.е. отказа хорошим кандидатам. Ибо никак не тестируем на это.
На проблему такого рода намекает и указанное в статье 1400:1. Вести себя так могут позволить крупные компании с большим притоком канидатов. Но всем поменьше это уже черевато не закрыть вакансию вообще. А в конкретном случае, судя по тому, что используется еще и трекер в работе, это похоже на какую-то галеру. Набор джунов?
Простите, наверно надо было уточнить контекст: у нас только сеньоры и ищем только сеньоров.
В компании 3 разраба (ещё 2 недавно ушли после 2 лет работы, решили открыть свою фирму), СЕО — он тоже сеньор, но кодить не успевает, и agile мастер для всего организационного. Плюс девушка копирайтер, плюс девушка ассистент.
Апдейт происходит не после успешного найма, а примерно раз в месяц. За это время могут вообще все кандидаты отфильтроваться — такое было.
Господи, я думал у вас хотя бы сотня-две разработчиков, что бы столько усилий тратить на такую фильтрацию потока...
Пожалуйста, объясните, в чем принципиально разница? Я бы сказал наоборот: если у вас маленькая компания, вам нужен фильтр жёстче, потому что влияние одного человека на компанию выше.
Больше позиций нужно закрыть (банально на счет естественной убыли), больше кандидатов нагоняют рекрутеры и их качество хуже. Много людей участвует в техническом, им нужно как-то синхронизироваться между собой и тут автоматизация помогает. Ну и, увы, меньше возможностей искать индивидуальные подходы работнику, т.е. некое "усреднение" важно.
Влияние одного человека на компанию больше, но этот человек "на виду" и больше возможностей влиять на этого человека встраивая в компанию, причем напрямую от топов компании.
В большой компании вводят строгий алгоритм найма в том числе для того что бы нивелировать субьективность отдельных нанимателей. Иначе когда уходит лид — нужно всю команду распускать и нанимать под нового заново. В вашем случае если уходит лид — компания считай закрылась.
Еще одна причина — для того что-бы помочь отдельным командам набрать хороших кандидатов даже если среди них никто этого делать не умеет. В вашем случае, опять же, это неприменимо.
Зато это объясняет фильтр сдвинутый в сторону ошибок первого рода, если нужно найти одного кандидата, можно себе позволить потерять 100 других хороших. Крупные компании себе таких потерь позволить не могут.
Могут позволить или нет, это скорее функция от потока входящих кандидатов и числа вакансий, а не от величины компании. Если их компания смогла обеспечить поток кандидатов, что бы так активно отсеивать и при этом закрыть вакансию в реальные сроки, то можно позволить. Но откуда такой поток? Если закрыть хотя бы за 3 месяца (что дофига), это по 15 кандидатов в день должно входить на тестовое...
2) Пропускаем >90% подходящих кандидатов и всё хорошо. Принципиально могущих выполнять имеющуюся работу, но зачем посредственности, если в очереди много кандидатов и выше среднего. Продукту драйвовые разработчики идут на пользу.
Просто у вас другое определение "подходящих" кандидатов вот и всё. "Посредственности" не подходят.
Насколько я понимаю рынок, сейчас у всех кадровый голод, и готовы брать всех подходящих.Насколько я вижу, готовы только на словах, а на деле отсеивают и не подходящих и подходящих. Не 99%, но 95% подходящих легко могут теряться.
Я считаю, что кадрового голода нет. Нет возможности достаточно длительной и качественной проверки навыков, из-за чего создается иллюзия кадрового голода.
За традиционный короткий экзамен на час ни подходящий кандидат не может показать свои реальные навыки, ни интервьюер не может определить примерный уровень кандидата. Для этого нужно месяц-другой поработать вместе. Совсем слабых кандидатов конечно можно вычислить, но за час отличить подготовленного или болтливого джуна от сеньора довольно сложно. По 100 строчкам кода тестовых заданий тоже не понять, что он напроектирует, если доверить проект на 100 тыс. строк кода.
«Посредственности» не подходят.Что же такое «подходящий» разработчик или «посредственность»?)
Ну и в тех же компаниях работают люди с такими же навыками или даже с меньшими навыками, чем у некоторых не прошедших «посредственностей», и справляются со своей работой. Конечно, у всех по разному, но обычно на повседневных задачах сильно больших знаний не нужно и заметить «посредственность» сложно.
Кучу вчерашних студентов работающих в галерах «продают» как мидлов и сеньоров в том числе в крупные проекты в известные компании. И ведь те справляются с задачами, хотя и навыки низкие и опыта мало!
Я сейчас не про все проекты говорю, но наверное 99.9% проектов — это прикладное ПО, которое делается на готовых фреймворках. И каких-то сверх знаний не нужно, чтобы нормально сделать на них проект. А супер оптимизировано и без множества багов все равно не напишет даже крутой разраб. Ему на это времени не выделят. А не выделят, так как это не нужно, так как продукт надо выпустить пораньше и денег на «вылизывание» продукта не хватит, не говоря уже о том, что большинство проектов «не выстреливают». Так что много хороших разработчиков имеет смысл нанимать на уже «живущие» проекты, а таких проектов меньше, чем всяких стартапов.
Если голода нет, то почему практическому каждому из нас несколько раз в год приходят с предложениями работы, даже если на текущей все ок, а любому мидлу среднего уровня достаточно сказать, что он открыт рассматривает вакансии и его тут же похоронят под предложениями работы?
Или почему у любой развивающейся компании всегда есть открытые вакансии?
Подходящий для всех разный. Зависит от требований. Кому-то подавайте рокстара не меньше, а кому-то и вчерашний студент сойдёт.
Полностью поддерживаю. Абсолютно аналогичная проблема — найти вменяемого разработчика и убедить его устроиться к нам (говорю не от лица своего работодателя, а в целом) — почти нереально.
а на деле отсеивают и не подходящих и подходящих. Не 99%, но 95% подходящих легко могут теряться.
Нет возможности достаточно длительной и качественной проверки навыков, из-за чего создается иллюзия кадрового голода.
Похоронят предложениями пройти собес, но не офферами. В большинстве случаев разработчика отсеят, особенно если он давно не ходил на собесы и плохо готовился к ним. И не важно, какой он «герой» в текущей компании.
В общем, суть такая, что вместе огромной толпой неподходящих кандидатов отсеивают столько подходящих кандидатов, что большинство компаний по несколько раз смогли бы закрыть все свои вакансии. Иначе по какой причине те же кандидаты, провалившие с десяток собеседований, получают оффер и проходят испытательный срок в 11-ой эквивалентной компании на эквивалентную позицию?
В большинстве случаев разработчика отсеят, особенно если он давно не ходил на собесы и плохо готовился к ним.
Я нашел работу за месяц (вернее: меня нашли за месяц, сам я ничего не искал) весной этого года, не готовясь к собеседованиям и не ходя на собесы (до этого — 2 места работы за 12 лет). Just sayin.
В общем, суть такая, что вместе огромной толпой неподходящих кандидатов отсеивают столько подходящих кандидатов, что большинство компаний по несколько раз смогли бы закрыть все свои вакансии. Иначе по какой причине те же кандидаты, провалившие с десяток собеседований, получают оффер и проходят испытательный срок в 11-ой эквивалентной компании на эквивалентную позицию?
Но если разработчики на 11-й раз куда-то таки нанимаются, а компании всё равно продолжают заваливать офферами — значит таки голод объективно существует. Если бы в итоге все вакансии закрывали, пусть и только теми, кто уже 10+ собеседований в других конторах прошел — в итоге не было бы такого вала предложений о работе.
Я нашел работу за месяцИсключения бывают. Вы же не всегда будете с первой попытке получать оффер. В этом вашем комменте вы уже как раз пишите о неудачном опыте прошлых собесов.
Но если разработчики на 11-й раз куда-то таки нанимаются, а компании всё равно продолжают заваливать офферами — значит таки голод объективно существует. Если бы в итоге все вакансии закрывали, пусть и только теми, кто уже 10+ собеседований в других конторах прошел — в итоге не было бы такого вала предложений о работе.Все вакансии в принципе не могут закрыться, т.к. постоянно новые открываются. И вакансии же не годами открыты, а обычно закрываются за несколько недель/месяцев. То есть в итоге проинтервьюировав десятки кандидатов, находят кого-нибудь.
Ну и я как-то не логично написал. Часть с N-ой попытки видимо закрывает эти вакансии, часть остается на текущей работе, часть на более низкую ставку уходит, часть стек меняет, часть во фриланс уходит, часть в другой город/страну.
Вы же не всегда будете с первой попытке получать оффер.
Так поэтому и "за месяц", а не за день. Но суть в том, что уже несколько лет мне не нужно делать ничего особенного для поиска работы: меня заваливает предложениями просто если я открываю резюме. Естественно, мне не обязательно выкатят оффер первые же встречные, но как показывает практика, оффер таки выкатывают быстро, даже в самые форсмажорные календарные периоды. При этом я не делаю (и даже не пытаюсь) никаких действий, чтоб как-то "особо" нравиться конторам, так как считаю, что пока нет недостатка в предложениях — лучше даже и не пытаться подстраиваться под таких собеседующих, которые я сочту не вполне адекватными.
И вакансии же не годами открыты, а обычно закрываются за несколько недель/месяцев.
Это потому, что иначе эти вакансии вообще никто смотреть не будет. На том же hh часто можно увидеть, как контора закрывает и открывает заново одну и ту же вакансию каждую неделю по нескольку месяцев.
Если честно не знаю никого, кто провалил бы десяток собесов за раз. А случаев перехода на ту же позицию без выхода в заметный плюс я знаю всего один среди всех моих знакомых.
Если честно не знаю никого, кто провалил бы десяток собесов за разНу я, например в течение нескольких месяцев (пассивно принимая предложения в линкедине). Не знаю, почему так, вменяемый фидбэк почти никто не дал даже после нескольких собеседований и домашнего задания. При этом и совсем унылые шарашки, и что-то более среднее.
Вас одного маловато для нормальной выборки. Ещё с десяток примеров найдётся?
Мой знакомый недавно долго искал работу, хоть в итоге и получил пару офферов на 200к.
Второй мой знакомый в прошлом, с опытом работы сеньором в нескольких компаниях, долго не мог устроиться сеньором. В итоге ушел из фуллстека во фронт на миддла, сейчас снова сеньором работает.
Десяток я для примера написал. 5 возьмите, тоже не так мало.
не знаю никого, кточто вовсе не про репрезентативные выборки. =)
Потому что если в компании не будет висеть постоянно открытая вакансия — будет сложно запугивать уже работающих людей разговорами о том, что за забором на их место сто человек стоят.
Потому что с той стороны не сидят волшебные существа из страны мудрецов — и когда один соискатель веером рассылает 100 резюме, где-то точно такой же один HR-менеджер веером рассылает 100 приглашений на собеседование. У него это в KPI прописано.
А кадрового голода — нет.
А то я тут искал знаете на среднюю по рынку в Новосибирске и ка кто задолбался просто в дым.
Это где же вы работали, что вас запугивали очередью за забором? Я, слава богу, такого даже в кино не видел. Я возможно слабо представляю работу HR-ов, но у них обычно в KPI количество приведённых людей или вообще прошедших испытательный срок, а не прочто количество собеседований.
Продукту драйвовые разработчики идут на пользу.
С учетом того, что процентов 90 проектов (видел где-то статистику от KPMG лет 10 назад) — это CRUDная опердень и ее поддержка, не совсем понимаю о каких «продуктах» идет речь.
То, что это какая-то маленькая компания было понятно по тому, как автор статьи несколько раз сказал, насколько им дорого проводить этапы отбора и найма.
Это дорого должно быть независимо от размера. Просто на большом масштабе идёт сглаживание эффекта от одного человека...
Это дорого должно быть независимо от размера.
Дорого/дешево — это же относительные величины. Скажем, $5 за обед — это дорого или дешево? Ответ на этот вопрос будет разным для человека с ЗП в $300 и в $3000 в месяц.
Так же и здесь. Если на проекте работает всего 2 разработчика и один из них тратит на собеседования по 5 часов в неделю, то вклад в накладные расходы на стоимость работ одни. Если же на проекте работает 20 разработчиков и один из них тратит по 10 часов в неделю на собеседования, то вклад в накладные расходы будет уже другим. Скорее всего существенно ниже.
Да, это долгий процесс — может занимать 3 часа у кандидата. Как сделать, чтобы он не бросил эту затею? Мы заранее говорим, что все работы будут оценены вручную, и по каждой из них будет сделан детальный code review. И мы делаем, причём каждый такой ревью занимает в среднем 40 минут — но тем не менее мы не игнорируем ни одного кандидата. Это мотивирует, потому что даже если кандидата завернут, он точно будет знать, почему и над чем нужно работать.
Какая причина может заставить сеньора делать тестовое задание на 3 часа, тем более в маленькую компанию?
Ревью кода? Джуну может быть. Но я уверен что большинству опытных программистов ваше ревью просто не интересно.
Метод хороший, но не для компании в 3 разраба. 1:1400 это не потому, что компании нужен именно этот один, а остальные не смогут. Это для того чтобы удовлетворить ЧСВ автора процесса. Следует допустить, что процесс отметёт 1200 крутых кандидатов, 199 посредственных и останетесь вы.
Стоит ли говорить, что объявление постоянно улучшается на основе статистики — мы смотрим, что работает, а что нет, меняем параграфы, что-то уточняем итд — и это действительно работает, описание вакансии сильно влияет на то, кто и в каком количестве будет подавать заявки.
А можно вот прям до мозга костей подробнее про «как именно это работает»? Как оценивается релевантность отдельных параграфов? Как решается что изменение привело к лучшим результатам?
Первый вопрос кандидату — его стаж. Это не какое-то число из головы — напротив, мы взяли статистику и нашли такое число N, что кандидаты со стажем меньше N лет никогда не проходили все этапы.
А какова статистическая выборка для этого N?
статья как будто не учитывает то что люди способны обучаться… если нормальный менторинг на работе то любой с софт скилами за месяц станет уверенным мидлом, зачем такие сложности, это же не форт баярд
Это достаточно глубокий вопрос. Если джуна посадить рядом с сеньором — да, это будет буст джуна. Если как у нас — у каждого сеньор разраба свой проект — то я сомневаюсь. Плюс очень важно, чему именно обучать — если человек не знает какой-то библиотеки или каких-то паттернов, то это вообще не проблема — сел и изучил; но если кандидат не может правильно понять требования тестового задания, то это уже другая тема, и я боюсь, что этому придётся учиться уже дольше.
Так или иначе, обучение разработчика стоит компании денег, и тут нужно просто прикинуть, что выгоднее: отфильтровать или обучить. У нас не жёсткие границы, то есть мы допускаем некоторое обучение, но это очень индивидуально для компаний имхо.
Это, в общем, неверно, хотя часть навыков, типа клепать формы или верстать можно получить очень быстро. Умение решать специфические задачи, которые возникаю во время написания и отладки нетривиального кода, тренируются годами. Все как в спорте — совершенно нормально потратить лет 10 для достижения мастерства. Ни ментор ни любая магия не смогут сформировать нужные нейронные связи в голове затрату месяцев.
Валар моргулис
И спасибо за статью))
4) задание «fuzzy» — сказано, что должно быть в итоге, но как это получить — кандидат решает сам; мы оцениваем, насколько кандидат умеет здраво мыслить и понимать требования клиентов
Каждый раз когда я встречаю задание в таком стиле, я извиняюсь что оно слишком сложное для меня и иду гулять. Потому что задания с открытыми вопросами обычно проверяют не вашу здравость мышления, а то насколько вы мыслите также как и автор задания. Я могу всрать 5 часов на идеальное выполнение задания с линтером, тестами, комментариями, только для того чтобы выяснить что здесь обязательно должен быть применен такой вот паттерн а не этот. А применен он должен быть потому что на проекте автора задания это сработало, и по-другому и быть не может. И от подробного фидбэка толку ноль в таком случае, потому что суть фидбэка — мы в нашей компании работает вот так, но как — заранее не скажем.
Даже лайвкодинг и построение иерархии классов на словах проще пройти(при условии что вы не испытываете стресс в таких ситуациях в принципе). Потому что на это потребуется полчаса и фидбэк будет мгновенным. На тестовое задание потребуется день, даже если на словах оно на 3 часа, потому что его нужно оформлять лучше чем 90% кода, что пишется для реальных проектов.
Буду конкретнее: есть задание написать программу, которая собирает данные и рендерит html табличку.
Что ожидается: разработчик напишет программу, которая собирает данные и рендерит html табличку.
Что случается: разработчик настраивает django-приложение с нуля, с авторизацией и админкой, туда встраивает view, который собирает данные и рендерит html табличку.
У нас нет строгого требования, чтобы это не было django-приложение — то есть это не критерий отбора — но практически все, кто связывается с django, тратят существенно больше времени на задание. Максимальная разница — в 10 раз.
Соответственно, если вы (не)использовали какой-то паттерн или (не)воспользовались какой-то либой — это ваш выбор, главное, чтобы код был рабочий и вы "всрали" на него 5 часов, а не 25. Да, код ревью есть, но это не придирки, а аргументированные комментарии, если найден какой-то косяк. Какого-то эталонного решения, с которым будет сравниваться ваше, нет.
Как это происходит в других собеседованиях — я не знаю. Если везде заворачивают за несоответствие каким-то жёстким скрытым параметрам — то это грустно.
А почему они должны нанять именно Вас?
Те кто не понимают, им скорее всего просто не нужны такие люди, они оверквалифайд. Потому что в мире нормальных синьоров не трэкают время. У синьоров обычно голова болит по более глобальным задачам, чем спарсить данные и создать html табличку.
Вот тут все правильно написано
habr.com/ru/company/skillfactory/blog/532410
Вакансия: senior python developer (django, remote only)
И вы удивляетесь что люди вам пилят проект на этом фреймворке? Вам в голову приходило что это будет иметь непосредственное влияние на выбор инструмента?
Я конечно могу ошибаться, и вы слишком упростили описание тестового задания, и на самом деле всё по другому, но если дело реально обстоит так, что в вакансии написано «джанго сеньёр» а в тестовом задании «собери данные, сделай табличку», то я удивляюсь с удивления результату с джанго.
У нас нет строгого требования, чтобы это не было django-приложение — то есть это не критерий отбора — но практически все, кто связывается с django, тратят существенно больше времени на задание.
Раз многие так делают, возможно стоит понятнее сформулировать этот момент.
С тестовыми всегда сложность в том, что не понятны требования и критерии оценки.
Буду ли оценивать, что решение работает, или красивость кода или паттерны или наличии тестов или что применен какой-то специфический инструмент или применение специфического алгоритма.
А уточнять это через HR, как правило, мертвое дело.
Условно ваш пример с переворачиванием данных из файла.
Джун думает, ну вроде все понятно все просто. Пишет 2 строчки за 2 минуты и готово.
А сеньор начинает думать, а что если файл не влезет в память, а что если файл текстовый, а что если бинарный, а что если файл занимает больше половины свободного места на диске, а может быть нужно как-то оптимизировать по скорости. Ну не просто же так на сеньорскую позицию дали такое задание, наверняка там куча проблем. В итоге решает, что на это надо 3 дня потратить и закрывает вашу вакансию.
Т.е. нужно быстро склепать скрипт на питоне, которые сделает что надо, пусть там будет некрасивый код, без тестов и прочее?
Всё ещё думаете, что это не качнет ваши, конечно же объективные критерии выбора, в пользу одного из кандидатов? Кстати независимо от ваших критериев и их объективности чьи-то потреченные часы уйдут на свалку. Второго кандидата я добавил, чтобы вам не пришло в голову сказать, что мол из-за таких-то мелочей не брать человека.
Аналогично.
Если уж выше было видно желание обрабатывать людей как мешки с ...., то на словах трекер я потерял всякий интерес, а увидев в комментариях что у них компания из 3 разрабов, сео и копирайтера стало все совсем печально.
P.S. трекер это унижение человеческого достоинства, имхо так работают только плохие компании, с плохим менеджментом, хороший менеджер в состоянии оценивать результат, а не количество протертых штанов.
Но как там у них дела обстоят в реальности — кто знает…
Всем, кто трэкает время, надо бы сходить в школу/универ на экзамен «а я учил».
Результат определяется не затраченным временем, а как бы результатом. Поэтому с точки зрения бизнеса гораздо логичнее ставить задачи так — эта фича будет нам стоить X, но через n месяцев принесет нам Y чего-то.
Люди, у которых есть время трэкать чем занимались другие люди — либо бездельники, либо авторитарны.
Всем, кто трэкает время, надо бы сходить в школу/универ на экзамен «а я учил».Я трекаю своё время (помидорами). Рабочее и не. У вас квантификатор поломался, наверно.
Для самоконтроля трекер может быть полезен, иногда забавно наблюдать, как меняется собственная производительность в зависимости от внешних обстоятельств.
Но если "часики-то тикают" у работодателя, то я всегда буду выбирать проверенное решение, а не рисковать в пользу поиска лучшего. В целом я думаю это тупиковый путь, завтрашнее легаси уже сегодня)
Мне и самому это не нравится, но если они приперлись на рынок вот с такими правилами, то куда они денутся.
Ну гипотетически это могут быть 3 плотно сработавшиеся рок-звезды
В этом случае им тем более не нужен трекер. И не нужен трекер, чтоб контролировать четвертого.
Iliya_karin к вам тот же вопрос
Тут видимо имеется ввиду трекер, который "мониторит" ваш монитор на предмет того, что он показывает, на основании чего кто-то делает вывод о том, что вы делали в рабочее время, сколько была открыта IDE, YouTube и прочее)
Против записи времени работы над таской в Jira не имею ничего против.
Я даже не мог подумать о таком «трекинге», когда каждый чих за тобой записывают. Осталось ошейник с GPS крепить к сотруднику, чтобы проверять, сколько он в туалете время провел.
Про тот же "crossover for work" погуглите отзывы.
Вроде как бы ЗП обещают большую, в перспективе, но на право и на лево штрафуют, не доплачивают, постоянно делают перформанс ревью и конечно же ты вечно недоперформер, и с трекера тыкают статистику, мол вон Вася вообще не спит и за день в 3 раза больше делает (Васю правда в живую ни кто не видел).
То сфоткал когда ты встал, то мышку видите ты мало водил…
Ну и так далее, не нашлось тебе работы на все 160 часов в месяц, вот только 80 выполнил, дальше заданий не было, получи ЗП за 2 недели и распишись.
На рынке как водится один дурак, а тут три стороны: клиент, компания, и разработчик, угадайте кто будет дураком.
Возможно, тут парочка найдётся: upwork.com
Кажется, это извечная война двух лагерей: за и против трекеров. Я работаю с оплатой за час, и мне удобно, что когда я начинаю работать, я включаю трекер, когда заканчиваю — выключаю. Наработанные часы отправляются работодателю, с него снимаются денежки, я их получаю, всё автоматически, все довольны. Меня лично не напрягают снимки экрана (типа я работаю и если заказчик любит смотреть на свой код — пожалуйста), но кого-то может раздражать. На ублюдском апворке это, кажется, нельзя отключить, но на хабстаффе можно.
Для работодателя это тоже очень полезная штука (я имею в виду трекинг часов), потому что он сразу видит, сколько времени было потрачено на задачи, и можно увидеть, когда разраб залип на задаче, или во сколько суммарно обошлось введение фичи итд. Насчёт скриншотов экрана — я хз, по моему опыту всем пофиг (и разрабам, и клиентам), только пару раз меня они спасали — я забывал выключить трекер и записывал личные дела как работу. Потом по скриншотам смог восстановить хронологию и отменить.
Если вы имеете в виду снимки с фронтальной камеры, то это вообще чернуха, которую я даже обсуждать не хочу. Никто так не делает.
Мое имхо, что трекер — это просто ярко выраженное недоверие работодателя к сотруднику, что он будет врать проставляя время на задачу. И в общем это все аргументы. Для апворка — логично, откуда там доверие. Для компании, которая тщательно отбирает себе сотрудника на постоянную работу — немного странно. Если ваша компания просто берет заказы с апворка, то в целом понятно откуда трекер.
Простите, вы мешаете в кучу задачу трекинга времени и верификацию деятельности сотрудника. Когда работодатель не доверяет и следит за вами — нахрен такого работодателя. Когда он платит вам за рабочие часы и просит указывать, сколько времени ушло на каждую задачу — это разумно.
Я могу, например, вообще ручками добавлять рабочие часы через дэшборд хабстаффа, тогда там не будет скриншотов, и трекер можно не ставить. Вроде по-честному, где тут недоверие работодателя?
На апворке даже если вам доверяют (а там я почти не встечал неадекватных клиентов), то скриншоты делаются автоматически, то есть не доверяет вам сам апворк.
Я то как раз не мешаю в кучу, а вот вы скорее да. Трекер времени — это то, что трекает активность и учитывает время. Указание же руками затраченного времени — это не трекер, это обычная система задач. Если у вас использование автоматического трекания не обязательно, а лишь ваша инициатива, и можно указать руками затраченное и ни у кого вопросов не возникнет — не понятно к чему на тестовом "кандидату разобраться с трекером, который используется в компании"
рассматривайте трекер как пропуск через турникет/двери. Это вас же не напрягает?
По своему опыту скажу:
- За 2 года к контролю по hubstaff мне пришлось прибегнуть несколько раз к скринам и ни разу это не были сотрудники, которые делали свои задачи вовремя или с аргументированным сдвигом сроков.
- Не желают ставить трекер только те, кто работу не работает.
Но здесь важна честность в оба направления.
скрины можно не отключать, но блюрить — не нарушается приватная зона сотрудника, но и ± видно работу работал или киношки смотрел. При этом и не требовать отключать трекер, если пошёл в туалет/перекурить — те же 20 минут неактивности hubstaff нормально запишет, а у сотрудника не будет такое же равенство, как и у сотрудников в офисе в плане учёта времени
Сотруднику честно писать время — тогда будут видны переработки и можно анализировать причины. Так же, как вы, как руководитель, начали бы анализировать причины задержек сотрудника в офисе
потом, трекер облегчает ввод затраченного времени по задаче — вам не надо потом сидеть и вспоминать сколько, потом бегать по TSM и проставлять время у задач. А местами так и вовсе автоматизация доходит до уровня, когда запустив трекер по задаче, задача в TSM автоматически переходит в статус "В работе", а переключившись на другую задачу через трекер, задача ставится "В паузе".
ЗЫ: в общем, использование трекера может быть "здоровым", а не в позициях "работодатель мне не доверяет" и "да сотрудники все меня обманывают"
OK, допускает ли у вас система возможность добавить время в задачу в обход трекера — неважно почему, забыл включить, думал на кухне или ещё там что случилось? Если нет — то это
Не желают ставить трекер только те, кто работу не работает.
автоматически становится лицемерной ложью.
допускает, но через руководителя (вот из последнего):
если нельзя добавлять было бы, то я сюда в паблик не писал бы что трекер можно нормально использовать.
Больше того — на всяких там Linux бывают проблемы и тогда, пока разбираемся с проблемой, так и решаем — вручную заносили время. Так, у одного сотрудника при выходе на работу несколько дней разбирались в причинах того, что трекер не писал время автоматически и всё это время вручную добавляли тайминги.
больше скажу. у того же Hubstaff есть какой-то плавающий баг, что иногда на почту сотруднику он присылает время меньше, чем затрекал. В этом случае, сравниваем время, что было у сотрудника в клиенте и что в отчёте показывается, чтобы не было ощущения что с него "откусываем" кусочек времени — обычно достаточно "не верить" почте, а спустя день зайти в профиль и проверить время там
А один раз был кейс, когда сотрудник складывал часы/минуты, а в отчёте показывались доли часа и потому у него не сходились цифры — созвонились, сравнили, переключили настройки у него в профиле и всё встало на места. Разница между "8:05" и "8,05" (условно) не сразу бросалась в глаза
Не желают ставить трекер только те, кто работу не работает.
Угу, а не желают отмечаться в околотке только те, кто в бегах. Так, гражданин начальник? Мысль о том, что не стоит превращать жизнь в помесь ИТУ и казармы (в чем и так преуспевают лица из телевизора) Вам не приходила?
Почасовая работа на апворке это конечно хорошо, но, IMHO, это более-менее адекватно либо для манкиджоба по 5-10 баксов, где не предусмотрено фоновой мозговой активности, либо для ребят которым все равно как, лишь бы заработать стартовое портфолио и кусок хлеба. Для остальных — это лишь способ занизить оплату их труда нанимателем.
Вот я прям я сплю и вижу как такие вот штуки рраз и запросто учитываются. Вот только что учитывать совершенно непонятно, оставить включенным 24/7? Почему нет7 Увлеченный разработчик именно так и работает. Трекать только рабочее время? Во первых непонятно почему, во вторых там запросто могут быть котики 80% времени и еще 15% теоретические материалы. Трекать только написание кода? Тогда вы не понимаете суть работы разработчиков.
На всякий случай: этот патч ускоряет построение gist индексов в 5-10 раз и уменьшает объем индекса вплоть до 50%. Полезность его чудовищна, но я не представляю как бы он мог родится в компаниях с трекером.
И да, я как разработчик не желаю даже думать о всех вышеперечисленных вопросах. Нужно трекать время? Трекайте автоматически на основе перемещения по столбцам на доске.
Я когда-то проходил собес в кроссовер как раз-таки, общался с разработчиками оттуда, спросил «ну блин, как же вы с эти живете? Ну вдруг ты сидишь и думаешь, не печатаешь ничего, как это будет работать-то?». В ответ я услышал гениальное «Ну, ты просто берешь, открываешь блокнот, начинаешь одной рукой по клавишам рандомно бить, а другой мышкой по экрану возить...» У меня просто челюсть отвисла. Но не успел я прийти в себя, как он решил меня успокоить, добив фразой «Ну ты, это, не переживай, через месяц-другой вообще замечать перестанешь». Такие дела.
«Ну ты, это, не переживай, через месяц-другой вообще замечать перестанешь».
Зато какая прекрасная иллюстрация стокгольмского синдрома, а!
И тут на сцене появляется Ардуина с усб-хид, в которой уже накодили идеального разработчика для энтой лавки :)
Это если программного "разработчика" в комп подсадить не удаётся.
Там одновременно с этим скриншотилка + снимок с вебки одновременно. Так что придется попотеть, чтобы обойти это да ещё и незаметно.
Ондурина может набирать вполне разумный код, например что-то что живой разраб делал вчера. Подсунуть вэбке картинку сложно, но можно. А если ты в это время собственно работаешь (читаешь статью, например), то и подсовывать ничего не надо.
Хотя вот эта задача:
«Ну, ты просто берешь, открываешь блокнот, начинаешь одной рукой по клавишам рандомно бить, а другой мышкой по экрану возить...»
одной дуринкой решается
Первый вопрос кандидату — его стаж. Это не какое-то число из головы — напротив, мы взяли статистику и нашли такое число N, что кандидаты со стажем меньше N лет никогда не проходили все этапы.
Так ведь это просто готовый пример систематической ошибки выжившего. Вы на каких-то данных получили результат, но отказались от притока новых данных, способных его опровергнуть.
ИМХО правильным решением было бы добавить пару дополнительных автоматических этапов отсеивания для людей с опытом ниже вашей планки, если так хочется экономить время живых сотрудников, но жёсткий блок это как-то такое себе.
P.S. не удивлюсь если из отсечных 1.5к существенное количество занимали отсеченные по стажу.
Если кандидат врет на входе, зачем такой нужен в реальной работе? Доверие в команде — это всё.
Тут вроде как враньё взаимно. Или научно. Как только булевы "да/дет" превращаются в некое рациональное число матстатистики (те, кто указали стаж больше N — подходят, те кто меньше — пролетают), так и соискателю ничего не мешает (даже морально) перейти на тот же уровень, и начать подкручивать это число, чтобы пройти.
В конце концов, если тесты на кодинг тоже автоматические, а формула стажа верна — именно он в конечном итоге потеряет больше своего собственного времени и таки не пройдёт, если базовая оценка его знаний, подтверждённая задачками, оказалась релевантной оценке по числу опыта.
Если не нравится работодатель — не надо взламывать его систему, надо просто туда не ходить.
Хотя если и Вам хочется врать, и работодателя это устраивает — то вы друг друга стоите и вполне возможно, что сработаетесь ;)
Зачастую там вилка, где нижняя граница определяет подготовку, а верхняя — закоснелость или чаще готовность/желание перейти в начальники как можно скорее.
Человека без претензий стать начальником найти трудно, но это идеальные работники. С места не сдвинешь, работают усердно, кайфуют от процесса кодинга и дебаггинга и не доставляют никаких проблем кроме, иногда, непрезентабельного внешнего вида или других странностей в поведении, что с лихвой компенсируется качеством и количеством сделанной работы.
Вы не нанимали китайцев или индусов. Резюме одних следует делить на 10, других — на 3.
Хотя, конечно, это слегка в других географиях
Это не "верхнее" число, но тем не менее ваш комментарий справедлив. Спасибо.
Для конкретики — у всех в компании от 7 лет стажа, но N=4. Есть ли вероятность появления сеньора за 4 года? Может быть, особенно если он перешёл в python с другого языка, то есть не с пустым багажом. Есть смысл понизить N и посмотреть, что будет.
Отбрасывая сопутствующие факторы типа деплой опыты в других языках итп, т.е. если смотреть только на питон.
Как быть со стажем писать стаж если 1,5года питона для обработки данных, потом 3 года джанга/гае, потом 2 года перерыв с вебом, но работа в обработке научных данных, где питон только для себя. Далее плотных 1,5 года джанги/фласка, потом снова уже 2 года обработка научных данных. Если пойду в веб снова то потрачу 0,5-1год для мелких проектов для освежения данных. Если кратко условно: 1,5питон + 3джанга + 2питон + 1,5джанга + 2питон+ ??
Мне какой опыт писать после этого? 1.5, 2, 3, 4?
ты тут вот пройди 10 этапов заочно и потрать на это 2 дня
- Тест на стаж — 1 минута
- Тест на кодинг — 15 минут
- Тест на отладку — 2 часа
— С этого момента кандидат получает фидбэк ----- Тестовое задание — 3 часа
— С этого момента кандидат получает деньги ----- Пробный период
То есть мы начинаем общаться с кандидатом после 2,5 часов работы (в реале эти часы могут быть раскиданы на неделю, то есть нет какой-то жёсткой спешки). Да, возможно, это много, но если вакансия понравилась, то я считаю это допустимым.
Опять же, как я и сказал, все шаги сугубо индивидуальны для компаний, и святой грааль — это не адская воронка, которую я вам тут в статье описал, а сам подход — каждое задание имеет смысл, оно появилось не просто так, и мы улучшаем процесс каждый месяц, анализируя предыдущие итерации.
Ответил про трекеры тут: https://habr.com/ru/post/534902/#comment_22463766
Но статья не про трекер, и мне жаль, что он действует как красный флаг.
Людей, которые не понимают как работают трэкера и когда их уместно использовать — надо избегать практически любой ценой.
Это вам говорит человек, который занимается разработкой автоматизированного тайм трэкера в том числе для коммреческих компаний.
Вы ведь понимаете, что уже нарушили свои же правила — не быть мудаком, не работать с мудаками? Причём нарушили их ОБА.
В целом, инструмент о котором я говорю лежит в OS, можно оценить его функциональность.
В нем нет инструментов для слежки и он создан для персонального использования. То есть не предполагает сборки скриншотов или еще чего-то такого.
С другой стороны в нём есть механизмы для автоматической отсылки данных на сервер, которые хоть и создавались с совершенно другими целями — могут использоваться для автоматического отслеживания активности.
Ну вобщем мотивы у меня были благие, а если кто-то использует результат моего труда во зло — нельзя в этом винить меня.
Процитирую себя из комментов к статье об этом трэкере:
С работодателем никак не обговаривался учет времени. И в договоре не фигурирует почасовая оплата. Оплата каждый месяц с учетом 8 часового рабочего времени. Инструмент создавался чисто для себя.
ИМХО инструмент совершенно не пригоден для контроля со стороны работодателя, как раз из-за излишней детализации. Это инструмент для разработчиков, которые хотят чуть получше контролировать своё время и понимать — куда оно делось.
P.S>
Я согласен с вами насчет «добровольного рабства». Собственно, если бы работодатель предложил мне как быто нибыло контролировать мое время и вести отчеты на эту тему — я бы не согласился.
P.S. Простите за длинное офтопное сообщение. Очень уж не хочется оставаться в чьих-то глазах мудаком.
Мне кажется, для большой компании это не прокатит. Во-первых, нужны специалисты всех категорий, во вторых, вы совершенно не оцениваете психологический портрет.
Человек может быть Перельманом. Супер ум, супер гений, но работать в команде не сможет в принципе. Он пройдет через все ваши фильтры и дальше будет делать только то, что считает нужным и интересным, а ваши задачи будут идти лесом.
Поэтому первым делом отсеивать нужно тех, кто не подходит команде. Это трудно сделать через авто фильтры, нужен специалист, психолог. Конечно можно замутить психологический тест. Но так вы просто погрязнете в этих работах по созданию "идеального" фильтра и нужно общаться с человеком.
Кроме того вы можете отфильтровать реальных хороших кандидатов. Да они могут не знать вещей, которые вам нужны сейчас, но всего знать и невозможно. Нужно, чтобы человек был обучаемым и самостоятельным. Как это понять по фильтрам?
работать в команде не сможет в принципе
Именно для этого есть пробный период. Работает в обе стороны: команда не сможет сработаться с кандидатом, или ему может что-то не понравиться. Если все всем довольны, то пробный период заканчивается и начинается обычная работа.
вы можете отфильтровать реальных хороших кандидатов
Первые фильтры жёсткие, то есть если человек вообще не умеет кодить — то он отсеивается автоматически. Всё остальное происходит с участием компании, и там мы более гибкие, то есть нет прям жёстких критериев — всё рассматривается индивидуально, и очень часто человек проходит даже если были какие-то недочёты, но кандидат хорошо себя показал.
Для нас это всё ещё рекрутинг, но с точки зрения кандидата он уже отбил всё время, потраченное на все этапы, и вполне себе нормально зарабатывает.
… но с точки зрения кандидата, он уже скоро может быть выставлен на мороз. После чего он не сможет встать и, например, уйти обратно в компанию, из которой перешёл к вам. Или принять чьё-то другое предложение, которое ранее отклонил, выбрав вас (вероятно, туда уже кого-то взяли, пока он ваш тестовый период проходил). Следовательно, пойдёт он на рынок труда, и (опять?) будет сидеть несколько недель или месяцев без зарплаты. И опять Натальи, Натальи, тридцать пять тысяч одних Наталий… Не берусь судить, правы вы или неправы с проведением тестового периода, но не надо тут рисовать бледно-розовые идиллии «уже всё отбил, уже нормально зарабатывает».
Все это понимают. Как правило, кандидаты заходят на триал, попутно работая где-то ещё — и на них никто не давит — даже после успешного найма.
Я начал работать фулл тайм только когда убедился, что не подставляю прошлого работодателя — критические таски закрыты и у него есть замена.
Наверно, это больше не про рекрутинг, а про адекватных работодателей
Нет.
Параллельная фулл-тайм работа не влияет на скиллы.
Параллельная фулл-тайм работа не влияет на чистое время выполнения задания — если человек потратил 1 час сегодня и 1 час через неделю из-за занятости, то это всё равно 2 часа.
Нет. На триал могут попасть кандидаты, работающие в другой компании. Было бы нелогично бросать старую работу и кидаться с головой в омут. Поэтому тут нет никаких ограничений и всё происходит, как вы сказали, "в свободном режиме". Кто-то свободен и может работать фуллтайм, а у кого-то есть несколько часов в неделю. Даже после триала спрашивают — сколько ты сейчас можешь работать с учётом перехода со старой работы, и когда планируешь фулл-тайм.
Есть два избыточных задания "в стол", как тут выразились, после них есть текущие задачи, но это уже индивидуально. Оплата почасовая, команда общается с кандидатом, он не в вакууме, так что работа на FizzBuzz в течение 10 часов маловероятна, но если вы их проработали, то вам за них заплатят.
Из описанного следует, что происходит жесть. Сеньор не может работать полноценно, если он работает час в неделю, у него не будет погружения в проект. Поэтому он либо 8 часов пашет, либо нет. И не может быть второй параллельной работы. Иначе все это профанация, и все эти ацкие тесты коту под хвост.
— Не протер 5 лет на тупой работе? Иди лесом. А может парень лучший на потоке, Google Intern и прочее. Отправная точка и скорость роста важнее записи в трудовой
— куча этапов лайвкодинга, трекер в 2020! после которых тебя удостоят общением с человеком
— тестовый период после которого человека могут выкинуть на улицу
Позитивный момент: 1399 разработчикам повезло не попасть в такую контору
Громкие заявления. Я могу всё инвертировать, и тоже будет правда.
Не протер 5 лет на тупой работе? Иди лесом
Не прогали на питоне хотя бы 4 года? Извните, попробуйте подать заявку попозже. Здесь про трудовую ни слова, можете хоть пет проджект пилить 4 года.
куча этапов лайвкодинга
Лайвкодинга нет. Сидите дома, пейте кофеёк и проходите тесты в удобное время, если вам интересна вакансия.
трекер в 2020!
https://habr.com/ru/post/534902/#comment_22463766
тестовый период после которого человека могут выкинуть на улицу
Тестовый период, за который платят, кандидат работает сколько хочет и когда хочет может просто уйти
Ну, тут хозяин барин.
Есть испытательный срок (тестовый период), есть задачи на него, вероятно есть и критерии приёмки этих задач.
Причем тут задачи уже отточены, критерии приёмки тоже.
Увольнение после испытательного зависит от законов страны, в которой происходит действие.
это всё ничто, это только bias
словно слушаешь интересный рассказ, закрыв глаза для большего погружения и тут тебе ВНЕЗАПНО прилетает удар в челюсть
Читалось на одном дыхании. Пишите ещё.
И в итоге прихожу к: вот мой опыт, вот ваши задачи, давайте пообщаемся. Нет? Тестовое? Спасибо, вы мне не подходите.
Значит так, если нам в год нужно 1000 вакансий закрыть, то нужно «всего» 1 млн. 400 тыс кандидатов. Ну изи.
Ну и если совсем честно. Я реально не представляю, что это должна быть за компания из 10 человек, чтобы я был готов потратить несколько дней на собеседования туда. Наверное там должны работать Билл Гейтс, Стив Джобс и Ларри Эллисон одновременно. Ну или зарплата хотя бы в 3 раза больше рынка.
Хотя нет, 3 раза мало, чтобы терпеть неадекватного ЦЕО.
Неужели нельзя было остановиться на меньшей цифре? Вы о людях подумали? Хотя кого я спрашиваю? человека, который выиграл от такого положения дел…
У меня вообще подозрение, что когда компании ищут кандидата так тщательно, то здесь другие причины. Есть семейная обстановка и не хочется приглашать чужака, который, к примеру, не будет обувь снимать при входе. Я просто не верю, что до вас не было достойных кандидатов на вашу позицию. Просто искали не только профессионала, но и «члена семьи» с которым общие взгляды на жизнь.
Только вот платить за такой комфорт приходится другим. Если бы люди знали, что их шанс меньше одной тысячной, то ни за что не стали бы делать тестовое задание, чтобы не тратить время.
import math1399 x 0.8 = 1119 потратили 1 минуту, чтобы отфильтроваться по стажу
279 x 0.7 = 195 потратили 5-10 минут, чтобы отфильтроваться на простых тестах
Осталось уже 89 человек.
С каждым шагом всё меньше и меньше людей тратит на это своё время. Пусть я потратил 5 часов, но кто-то потратил минуту. Какие тысячи часов?
Если вакансия нравится кандидату, то он сам решает, сколько он готов потратить своего времени. Если бы никому это не нравилось, никто бы и не проходил всё это, верно?
Откуда вообще взялись эти 1119? Может у вас проблема в вакансии или рекрутерах?
300:1 еще более-менее адекватно для компании, которой неспешно нужно 1-2 человека, компания не может позволить себе рисковать и хочет минимизировать затраты на онбординг. Такой своеобразный поиск сеньора среди мидлов, считающих себя сеньорами.
У меня брат недавно решил пойти в IT, по образованию робототехник, но в силу того, что в Ростове с этим грустно, решил начать с джуна QA. И попал он на местечковую компанию, возомнившую себя чем-то на уровне FAANG, а может и выше. Собеседование в 10 этапов, из которых 4 или 5 это разной степени бредовости тестовые задания. Но в силу того, что брат очень хочет в IT, поучаствовать все же решил. Получал задания, выполнял их достаточно оперативно, быстрее чем было обговорено в сроках. А интервьюер с той стороны пропадал на неделю в среднем. Потом возвращался, и давал очередное задание, и так эта история продолжалась больше месяца. В итоге 4 или 5 задание дали ссылку на сайт их разработки и нужно было оценить, какие элементы bootstrap там используются. Брат задание сделал, отправил интервьюер опять пропал, а потом появился через неделю, с обвинениями, что все плохо и ужасно, и что вообще тестировался не тот сайт.
Я ради интереса решил проверить задание, что там ужасного, но с моего более пятилетнего опыта разработки и взаимодействия с QA, для Джуниор вполне адекватно решеное тестовое и ссылка правильная. В итоге после того как брат переслал письмо полученное от интервьюера, ему же с вопросом «Прошу прощения а какая ещё может быть ссылка, если тут только одна?» Через пару дней получил обвинения в некомпетентности и что интервьюеру так тяжело жить и работать. И какие-то съезды на то что он вообще про другое задание говорил, хотя другие задания были связаны не с сайтами. А по поводу ссылки так никакого ответа и не последовало:) Морали никакой, брату опыт
Но в компаниях попроще, если от вас требуют задание сложнее обхода дерева — бегите. Эти компании не уважают ваше время как соискателя, а следовательно, если вы будете работать, не будут уважать вас как работника.
Каждую смену работы, я для формы беру вакансию с тестовым заданием и выполняю его довольно глубоко — с расширяемой архитектурой, рефлексией и т.д. Хоть бы раз кто-то вообще обсудил его. На следующем собеседовании мы опять начинаем с вопросов что такое SOLID
А вот банальность вопросов это боль конечно, очень редко бывают действительно интересные интервью
Каждую смену работы, я для формы беру вакансию с тестовым заданием и выполняю его довольно глубоко — с расширяемой архитектурой, рефлексией и т.д. Хоть бы раз кто-то вообще обсудил его. На следующем собеседовании мы опять начинаем с вопросов что такое SOLID
Кстати да, все "продуманные многоэтапные собеседования", которые мне попадались (не очень много, т.к. я на подобное сам обычно не хожу) — заканчивались тем, что контора гордо и молча уходила в закат. Или просто отпадали без какой-либо связи, или один раз получил "отзыв", суть которого сводилась к тому, что я неправильно протелепировал желания экзаменующего по ТЗ (потому что уточнять ТЗ явно запрещалось). Или укатывались в лютый неадекват на последних этапах — так, один раз мне на разговоре с CTO всерьез предложили детально и в подробностях пообсуждать структуры данных в Яве (вакансия фронтэнда, если что, в компанию с техстеком C#+Веб).
Чем дальше, тем больше у меня оснований полагать, что чем больше контора говорит о том, как офигенно и продуманно они собеседуют — тем меньше адекватности в этих самых собеседованиях. Обратных примеров не встречал, во всяком случае.
С другой стороны, когда у меня будет свой АйТи бизнес, я (уже как бизнесмен) скорей всего поступлю так, как описано в сабже — выстрою конвейер, который сведет риски от качества рабочей силы к минимуму, резко снизит требования к умственным/творческим способностям работников (достаточно будет навыков) и соответственно снизит стоимость рабочей силы. И подобный фильтр чем будет хорош? Он отфильтрует не только снизу (кандидатов с отсутствием требуемых навыков), но и сверху — талантливых дорогостоящих Программистов (с большой буквы).
Подпишусь под каждым словом, разве что про "удешевить рабочую силу" как-то грубо — как будто мы получаем хороших разрабов за бесценок, а это не так.
Мы оптимизируем процесс рекрутинга, чтобы тратить на него меньше. Стараемся ничего не тратить на отсев совсем неподходящих кандидатов, но чем больше кандидат нам подходит, тем больше мы тратим, под конец уходя в минус.
И да — нам нужны опытные кодеры с известным набором скиллов (плюс-минус скидка на обучаемость). Талантливые программисты, нетривиальные решения не пройдут, но мы их и не ищем — это бизнес, мы знаем, кто нам нужен, и мы их ищем. Если бы это была большая компания, то глупо игнорить талантливых разрабов — у них огромный потенциал — но нам это не подходит.
А цель конвеера — резко удешевить рабочую силу
Вот только на конвейере из статьи разработчик — продукт, а не работник. А работники на основных этапах — компьютеры, самая дешёвая рабочая сила для этой задачи.
The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you actually just get back a reference to the existing object. So it should be possible to change the value of 1. I suspect the behaviour of Python in this case is undefined. :-)
Весьма неожиданно. Возможно, хорошо что я не пошёл в питон.
Причём это, насколько я помню, только в интерактивном режиме, то есть при запуске из REPL и как отдельной программы поведение может отличаться.
Python 3.7.9 (7e6e2bb30ac5, Nov 18 2020, 12:05:16)
[PyPy 7.3.3-beta0 with MSC v.1927 32 bit] on win32
>>>> a = 200
>>>> b = 200
>>>> id(a), id(b)
(3201, 3201)
>>>> b = 300
>>>> a = 300
>>>> id(a), id(b)
(4801, 4801)
>>>> a = 500
>>>> b = 500
>>>> id(a), id(b)
(8001, 8001)
Ну я вот например знаю эту фишку (где-то давно прочёл), но чтобы она реально на что-то влияла — нет, не влияет. Как было бессмысленно сравнивать числа или строки через is или id для обычного прикладного кода, так и осталось.
мы запилили формочку, где кандидат тыкает своё число и либо проходит дальше, либо мы вежливо отказываем
И что мешает кандидату вернуться на эту формочку, и ткнуть другое число? Кого-то такой фильтр конечно отсеет, но тех ли кого надо?
Да и вообще, стаж — весьма относительная метрика. Работать можно по разному. Если речь о сеньоре, то соотношение кодинг/менеджмент может быть сильно разным. Если речь о джуне, то на прошлой работе этого джуна мог обучать толковый сеньор, а могло быть и так, что ему дали задачу, на которую всем плевать, и он год занимался копипастом со StackOverflow. Да и сами люди могут по разному свой стаж оценивать. Кто-то включит весь стаж, а кто-то только с целевым фреймвёрком.
Итак, задание на написание кода нужно
Вам, а не кандидату. Он с вами ещё даже не пообщался, а вы уже предлагаете ему потратить на вас время.
Наши задания простые, на их решение хватает и 15 минут, но мы даём 1.5 часа.
А кандидат об этом предупреждён? Человек может увидеть время 1,5 часа, и уйти, решив что выполнение заданий займёт означенное время.
например, инвертировать содержимое в маленьком файле, типа data[::-1], без подводных камней. Вы не поверите, но это отсекает 80% народа, серьёзно — хотя они претендуют на место senior python developer.
А человек, перед тем как ему дали это задание, предупреждён, что это фильтр от дурака? Опытные разработчики часто негативно реагируют, когда на сеньёрском собеседовании, начинают задавать джунирские вопросы.
Я это всё к тому, что ваш фильтр может отсеивать кандидатов вовсе не по тем причинам, по которым вы думаете.
На это задание тратится порядка 2 часов, но, к счастью, кодить не надо — нужно подумать и написать ответ.
Какая мне разница, как кандидату, надо кодить, или нет? Потраченное время, есть потраченное время.
Итак, после этого шага перед нами есть сеньор помидор, и мы ничего на это не потратили.
А кандидат потратил. А вы у него тоже не единственные, не стоит об этом забывать.
Далее уже сложнее — тестовое задание. Кандидат ставит трекер и логгирует время, потраченное на решение задания. Оно тоже классное по нескольким причинам:
1) позволяет кандидату разобраться с трекером, который используется в компании
Просто идите уже к чёрту. Самые лучшие идеи в голову приходят, когда я хожу пешком. А когда надо продумать детали, наибольшей концентрации я достигаю, делая наброски на листе бумаги. Как вы собрались это трекать своей поделкой? Трекеры ущербны по своей сути. Если вашим менеджерам хочется оценивать трудоёмкость задач, то ок, я могу скидывать им примерную статистику, сколько и на что я потратил времени. А автоматический трекер — удел параноиков, которые не доверяют людям. Тем более, что у вас программистов по пальцам одной руки можно пересчитать. Какой смысл в таком обезличенном, бездушном подходе?
Вот тут уже случается разговор с СЕО компании. Это не интервью в классическом смысле — скорее знакомство и ответы на вопросы. На этом этапе никакого отсева
Вот прямо совсем никакого отсева? То есть вам действительно всё равно, кем по жизни является будущий сотрудник, лишь бы кодить умел?
Далее кандидат попадает на пробный период.
Он прекрасен для кандидата
Вы в этом уверены?
У нас есть пара реальных и уже решённых задач (то есть с точки зрения реальной работы в них нет смысла) — но всё равно даём их кандидату.
По своему опыту скажу, что нет ничего более невыносимого и деморализующего, чем работа в стол. Осознание того, что твоя работа не имеет смысла — это прямой путь к выгоранию.
Если избыточные задания пройдены успешно (а многие заваливают), то кандидату даются какие-либо реальные, но некритичные задачи — то есть это ещё не работа над проектами клиентов, но уже полезная деятельность — например, добавить функционал на сайт или написать несколько скриптов для улучшения процесса рекрутинга
Вы набираете сеньоров, чтобы заставлять их играться в песочнице? Незначительная работа чуть лучше абсолютно не нужной, но не намного.
И так, что мы имеем в итоге? Максимально обезличенный процесс найма. Попытка дистанцироваться от кандидата, и оттянуть по максимуму момент живого общения с ним. Люди рассматриваются, прежде всего, как набор скиллов. То как этот процесс воспринимается кандидатом, не учитывается. Кандидату не дают возможности пособеседовать компанию в ответ, пока он не пройдёт семь кругов собеседования. Личное общение, не принимается во внимание, т.к. на этом этапе не подразумевается никакого отсева (серьёзно?). По мнению компании, для человека важны только деньги. До такой степени, что за них он готов выполнять бессмысленную работу. И ему совершенно не важно, реализует ли он свой потенциал. На испытательном сроке, ему даже не дают пощупать серьёзный проект (эй, испытательный срок вообще-то обоюдный, работнику тоже нужно попробовать работу на вкус). На работе используется автоматизированный трекер времени, ведь так надёжнее. Доверять людям, с которыми работаешь — это не ваш метод. Я ничего не упустил? Создаётся ощущение, что эту систему придумал социопат.
Самые лучшие идеи в голову приходят, когда я хожу пешком.
У меня аналогично: когда гуляю в парке, еду в метро, лежу на диване… когда угодно, но только не за рабочим местом :)
Однако, как я понимаю, суть такого фильтра и заключается в том, чтобы отсеять в том числе и людей с идеями. Цель таких фильтров — нанять недорогих исполнителей (кодеров), обладающих определенным набором навыков. Генерация идей здесь не нужна. Разрабатывать что-то принципиально новое и нетривиальное не нужно.
сантехник — не сотрудник. А вот если Вы УК (управляющая компания) и сантехник это сотрудник. Вам очень важно какой это человек. Вам с ним работать возможно долгие годы.
Не важно какой он, важно как вольётся в коллектив. Если вся команда мизантропы не умеющие слушать, но при этом эффективны то им нужен ещё один такой же токсик.
Может человек редкостный поганец, но с развитыми софт скилами
Это, наверное, самый мерзкий случай. Очень быстро такой станет Начальником и превратит жизнь нижестоящих в адок. Отклонений от такого направления развития ситуации я не видел.
Что касается «сантехников», вот вам пример из жизни. Сломался у меня магнетрон в микроволновке. Я стал искать объявления в Интернете. Позвонил. Оказалось агентство. Дали номер ближайшего мастера. Звоню мастеру, объясняю симптомы, мол крутит, но не греет. Он спросил модель, назвал цену — 2 тысячи рублей. Я подумал пару секунд, начал уже было отвечать, что-то в духе «Ну, в принципе, цена ок...» Фразу свою я закончить так и не успел. Персонаж на меня огрызнулся, сказал что у него «дохрена заказов», и ему некогда ждать пока я «раздуплюсь», после чего, повесил трубку. Когда я немного обтёк, я решил ему не перезванивать. И в агентство это тоже не стал перезванивать. Казалось бы, главное, чтобы мастер качественно всё починил. И это, действительно, важнее всего. Но это не значит, что всё остальное не важно. Даже в случае с мастером, которого нанимаешь на один раз. А уж когда выбираешь с кем тебе работать ближайшие несколько лет…
Ого… По пунктам
И что мешает кандидату вернуться на эту формочку, и ткнуть другое число? Кого-то такой фильтр конечно отсеет, но тех ли кого надо?
Ничто не мешает, но не доверять кандидатам с самого начала — такое себе.
Кто-то включит весь стаж, а кто-то только с целевым фреймвёрком.
Мы спрашиваем просто стаж кодинга на питоне. Разумеется, есть звёзды, которые в короткий срок могут стать сеньорами, и тут они отсеются, но если не делать этот базовый фильтр, то вместе со звёздами придёт ещё 700 кандидатов с начальными знаниями, и мы будем тратить их время на тесты — стоит ли оно того? Напиши я статью без этого фильтра, вы бы пожаловались, что мы тратим время людей на тесты.
Он с вами ещё даже не пообщался, а вы уже предлагаете ему потратить на вас время.
Есть компании, где вам звонит HR и вы вместе тратите время друг на друга. Есть компании, которые дают вам тестовое. Если вам компания нравится, вы смотрите на тестовое, и если оно небольшое и адекватное, то почему нет?
Насчёт общения — я уже писал, как я час потратил на общение с HR и всё завалил потом. Зачем это было? Я, как кандидат, не хочу HR, а хочу текстовый файл с описанием вакансии, где описано всё что мне нужно. Я трачу 5 минут вместо 60 и решаю, впёрлась мне компания или нет. Всё.
А кандидат об этом предупреждён? Человек может увидеть время 1,5 часа, и уйти, решив что выполнение заданий займёт означенное время.
Конечно. Так и пишем — вот тесты, лимит 1.5 часа, но вообще-то в среднем они занимают 10-15 минут. Кандидат это знает заранее.
А человек, перед тем как ему дали это задание, предупреждён, что это фильтр от дурака
Он пишет data[::-1], жмёт кнопочку RUN, запускаются тесты, всё становится зелёненьким и кандидат переходит к следующему тесту.
А кандидат потратил. А вы у него тоже не единственные, не стоит об этом забывать.
Если кандидат считает, что вакансия того не стоит — он просто не станет тратить на это время. Если человек предупреждён, что это занимает в среднем 2 часа, то он может решить, надо оно ему или нет.
Самые лучшие идеи в голову приходят, когда я хожу пешком
Окей. Добавьте эти часы в админке. Про трекер я написал тут https://habr.com/ru/post/534902/#comment_22463766
Вот прямо совсем никакого отсева? То есть вам действительно всё равно, кем по жизни является будущий сотрудник, лишь бы кодить умел?
Это проверяется на тестовом периоде при взаимодействии с командой. А вы предлагаете добавить ещё один фильтр при разговоре с СЕО?
Кандидату не дают возможности пособеседовать компанию в ответ
Я очень надеюсь, что вся инфа, которую компания выкладывает в объявлениях и репозитории, исчерпывающа и, наоборот, экономит время кандидату. Но после каждого шага кандидату прилетает email, и там есть кнопочка "ответить" — она работает, там сидят живые люди.
Окей. Добавьте эти часы в админке. Про трекер я написал тут habr.com/ru/post/534902/#comment_22463766
И сидеть вспоминать когда сколько чего и почем? А зачем? Почему вы вообще требуете этого от разработчиков? Что за мания такая у менеджеров? Задача переползла из беклога в работу, потом уползла из рабочей колонки, бац у вас есть время, интерпретируйте как вам угодно. Это уже менеджерские заботы целиком и полностью.
— в компании 3 активных разработчика
— на найм одного из них ушли ресурсы по разработке и апгрейду методологии найма
— в компании используется тайм-треккер, чтобы контролировать продуктивность 3х разработчиков
— 1400 разработчиков отсеялись, из чего сделали вывод, что они не прошли фильтр и не подходят компании. Хотя, можно предположить, что не каждый из 1400 человек готов тратить свое время на решение тестовых заданий под контроллем тайм-треккера.
Возможно, это очень крутая компания с высокими зарплатами, но, после прочтения статьи, я ожидал, что они там как минимум сотню разработчиков наняли таким образом. Иначе все эти инжинерные замуты выглядят как написание кучи бойлерплейта с разработкой фреймворка, когда можно было написать скрипт на баше.
Вы пишите, что до стадии дебаггинга (включительно) вы ничего не потратили и это хорошо. А что по поводу кандидата?
Многие компании стараются нанять лучшего, в то время как нужно искать наиболее подходящего.
Как вы думаете, как лучше действовать, если требуется набор навыков, редко встречаемый на рынке (например, одновременно знать react и autocad)? По моим ощущениям, проще найти человека с частиным набором навыков, и доучить оставшемуся.
Что-то проще, действительно, доучить. А что-то проще получить сразу, отфильтровав кандидатов, потому что обучить дольше / дороже.
Касаемо нашего процесса я тут уже где-то писал, что "жёсткие" только базовые тесты, всё остальное рассматривается индивидуально и мы решаем, что нам важнее и с чем мы готовы смириться.
И смысл в том, что каждая компания должна иметь свои собственные критерии
Это правильно, с одним замечанием — все критерии должны быть сразу донесены до человека.
Как вам тут совершенно верно пишут в комментариях — нужно сразу сказать про трекер, и тогда останутся только те, кто к нему готов. И так далее. В этом смысле очень верным выглядит действительно «самое подробное описание вакансии», в котором указаны все существенные детали. Причём не мусор про «миссию», а реальные условия.
Проблема в том, что на самом деле большинство компаний просто не знает, кто им нужен, и поэтому чудит при отборе — в мире безработица, люди всегда найдутся.
Я полностью согласен. У нас подробное описание вакансии, но процесс рекрутинга описан довольно коротко (хотя и полностью) — и если так много людей написало про трекер, то глупо это игнорировать — как и длительность заданий, от которых у людей бомбит. Если всё это добавить в описание, то это сэкономит кучу времени соискателям (если им что-то из этого не нравится), так что переделаем.
Потом мы узнали, что он не очень в гите, не умел отлаживать, код был так себе, а ide была atom, и он, например, не мог jump to definition или search class напримерЧем вам редактор atom не угодил, тем что там кликами мыши нельзя черрипикать? Зачем кого-то пересаживать насильно на pycharm, если человеку нравится работать, например с vs code?
Обычно PyCharm любят за его статический анализатор кода, и если человек его не использует — значит, либо у него есть другая ide, которую он классно настроил, либо он гений, который пишет без ошибок, либо всё плохо. Так что отсутствие PyCharm — это просто сигнал проверить, не гений ли кандидат или может всё плохо?
Эффективны тесты.
Если ваши тесты не обнаруживают проблемы, которые находит статический анализ, значит у вас плохие тесты и статический анализ вам не поможет.
Вот это какое-то деление на белое/черное. Стат анализ прекрасно работает с динамическими языками, если нормально писать и указывать типы, которые вы ожидаете. Это банально качество программирования. В этом случае стат анализ помогает решать некоторые проблемы еще до тестирования — в процессе написания кода, что банально экономит время. Это как дебаг без дебагера путем проставления точек логирования и выхода в коде. Вполне можно дебажить. Но не так эффективно.
В моём мире логирование + тесты работают эффективнее дебага в большинстве случаев.
В этом случае стат анализ помогает решать некоторые проблемы еще до тестирования — в процессе написания кода, что банально экономит время.
Какие, помимо опечаток? Потому что если это экономия на опечатках, то это экономия не в том месте.
Зайти с другого конца и предложить внести в стэк хотя бы Rust — бесперспективно со всех сторон.
Работать надо эффективно, если можно отлаживать принтами это не значит что так нужно делать.
Нда, вот что случается, когда компания с 3-мя разрабами считает себя круче Гугла.
Тратить часы чтобы получить право поговорить с живыми людьми, и в результате с вероятностью 1/1500 к вам устроится ...
Хорошо, что лично у меня есть набор своих "фильтров". И подобная компания отсеялась бы сразу, потратив не более 10 минут моего времени.
А в вашей «максимально полной» вакансии указано, что кандидат должен сначала потратить несколько часов на прохождение скрининга, прежде чем получит шанс пообщаться с живым человеком?)
Если нет — то вы фильтруете не только тех кандидатов, которые не могут пройти ваш отбор, но и тех, которые в процессе решили, что ну вас нафиг с вашими правилами отбора)
Иными словами, ваш результат, «куча отсеянных кандидатов» может свидетельствовать о том, что вы построили настолько ужасную систему отбора, что до ее конца доходят лишь сверх-мотивированные на работу именно у вас люди — а остальные просто успевают получить оффер от другой компании после чего сливаются с вашего отборочного конвейера)
Что, конечно может быть и неплохо конкретно в вашем случае, но врятли оптимально в других.
И да, помимо того, чтобы просто использовать статистику — стоит предусматривать то, что ваш процесс отбора может искажать выборку. Например, так, как я описал выше. И тогда, различные ваши тесты, основанные на статистике (вроде опыта работы) будут:
а) просто неверны
б) давать цикл негативной обратной связи еще больше искажая выборку и заставляя вас делать еще более фиговые тесты.
Короче, статистика — это не только среднее, медиана и 95% персентиль, но и всякие ошибки первого/второго рода и еще куча интересных вещей, которые надо учитывать Прежде чем начинать ее применять)
Мне в Yahoo Japan очень система понравилась.
- Кодинг тест (три задания от легкого к сложному)
- Психологический тест
- Само собеседование в виде видеозаписи. Т.е в любое свободное время открываете ссылку о отвечаете на установленные вопросы на видео.
Из минусов:
- Эффективность психологических тестов, конечно, как у астрологии. Но в Японии это любят, ничего не поделать.
- Пришлось пройти все три этапа, хотя началось все с кодинга, и я не уверен, что хорошо себя там показал. Так что после этого этапа могли бы и не напрягать дальнейшими. К тому же отказали, вроде как, из-за того что уровень низкий.
- Нулевой фидбек.
Но вот собеседование которое можно записать в любое удобное время мне понравилось. Хотя и очень непривычно говорить в компьютер.
Вообще все эти собеседования выглядят очень издевательски. Как зоопарк наоборот, когда не ты диковенных зверушек смотришь, а они сами к тебе приходят и частями тела вертят. Иногда создается впечатление, что HR просто потрепаться охота. Для них часы насобеседовать, как для фермера поле засеять.
Ну а насчёт перевода человекочасов в деньги, уж если подсчитывать, то давайте подсчитывать. Вы не боитесь обанкротить компанию пока кофе наливаете? Да даже пока чашку одной рукой держите кодить не получится. Про смартфон, наверное, говорить не стоит, думаю в рабочее время вы его выключаете. Ну и с туалетом проблем быть не должно. Пить-то можно только в обеденный перерыв. А курильщики -это просто денежные ямы.
Я конечно понимаю, что эффективность есть эффективность, и смысл в автоматизации есть, но дико бесят все эти подсчёты продуктивных минут.
А потом автор снова хайрит через 5 кругов собеседований в говностартап из 3х человек (!!!!!!!!), где их перформанс меряется трекером… Все же мне кажется, что это биполярочка.
а ide была atom, и он, например, не мог jump to definition или search class например
Ну так себе претензия.
Я ещё в 2010 сознательно отказался от IDE, особенно от умного автодополнения. И в целом не пожалел: структура проекта запоминается лучше, код становится понятнее, печатать сильно медленнее не начал.
Кто-то тут на Хабре писал, что тестовые задания фу-фу-фу, но я-то знаю, что задания на кодинг как старый добрый кольт: уравнивают всех. Много опыта, мало опыта, красивое CV или его отсутствие — покажите мне свой код, и я скажу, кто вы.
Давайте все же сделаем важное разделение:
- Оценивать кандидата по коду на github — да, это отлично
- Оценивать кандидата по способности писать код на самом собеседовании, это такое себе, потому что:
- Кандидат может стрессовать (обычный рабочий день и собеседование это не одно и тоже)
- Кандидат может быть не выспавшимся, уставшим, и т.д.
- Даже если кандидат выспался и здоров, но собеседование вечером — представляете, но до вашего собеседования у него могли быть другие. Где такие же умники как вы — выносили ему мозг алгоритмами и кодом
- Любые 100500 причин, по которым именно в этот момент кандидат не в лучшей рабочей форме
Конечно, как организовывать подбор дело личное, вот только не надо после этого разводить сопли «какие все никчемные, и при этом хотят 100500 миллионов.
Заголовок не врёт — до меня компания забраковала 1400 кандидатов.
Ну да, ну да, компания забраковала 1400 кандидатов. И конечно же все они жаждали в ней работать.
Напомнило:
— Здравствуйте, предлагаем работу в компании Рога и Копыта
— Авто-тесты пишите? Ревью кода делаете? Зарплата белая?
— Вы нам не подходите!
Так я же и пишу, что live coding это стресс и мы от этого отказались. Он ничего не показывает работадателю и угнетает кандидата.
Но кодинг нужен. Обязательно. В спокойной обстановке, дома, с горячим напитком, и (обязательно) с адекватными временными рамками — то есть не 1 день на выполнение задания, а, например, неделя. Так делают ребята из Revolut — они кинули мне задание и написали — вот у вас есть неделя, но если не уложитесь, то просто напишите и продлим срок.
Ну это вообще от компании зависит. В прошлой был достаточно свободный график, там просто работодатель ожидает, что ты будешь работать, скажем, 25 часов в неделю — и раскидывай как хочешь, хоть ночами работай, хоть по выходным, а в будни гуляй — когда удобно. На новой работе примерно так же: ты просто говоришь, сколько планируешь работать и когда, и всё. Удалёнка подразумевает, что сотрудник умеет в тайм-менеджмент и отвечает за своё рабочее время, понимает дедлайны итд. Может где-то строже, но у меня нет такого опыта.
Насчет соотношения 1400:1 я до конца не понял: это общее количество аппликантов или их всех интервьюировали лично? Как последнее возможно без армии спецов и соответствующего количества человеко-часов свободного времени, сложно представить. В первом же случае, когда это просто количество заявок, то несколько сотен в первые часы после публикации на ЛИ — это нормально. 99% там будут крайне низкоквалифицированные кадры, которые просто нажали на Apply надеясь на непонятно что. Поэтому я уже не удивляюсь, что на вакансию, например, директора по ИБ в местное правительство будет 200 откликов в первый день, хотя подавляющее большинство плохо говорит на гос.языке. Реальных же спецов до интервью обычно добирается весьма немного, но как бы там ни было, вы были лучшим.
Вот такой сниппет на питоне:
a = 400
b = 400
id(a) == id(b) # true or false?
Я затрудняюсь понять, что ж Вы ответили. С моей точки зрения, очевидно, что false. Вот уже на частный случай, когда -5 <= a, b <= 256, тут уже можно бы было и ошибиться...
Я залип, потому что там все вопросы были с подвохом типа этого, и я пытался прикинуть, почему может быть не false :( Про -5 и 256 я не знал, разумеется.
А что Вы скажете на:
➜ python
Python 3.9.1 (tags/v3.9.1:1e5d33e, Dec 7 2020, 17:08:21) [MSC v.1927 64 bit (AMD64)] on win32
>>> a = 400
>>> b = 400
>>> id(a) == id(b)
False
>>> ^Z
➜ cat .\test.py
a = 400
b = 400
print(id(a)==id(b))
➜ python .\test.py
True?
Вот тут есть и на эту тему и много другого интересного...
Я скажу, что это очень дурацкий вопрос для собеседования. Ссылка огонь, спасибо
Спасибо за ссылку — изучу на досуге.
Согласен с kesn — нафига мне вообще это знание надо — насчёт хранения integer в питоне? В каждом языке есть масса нюансов и узких мест, вылезающих при очень специфичных применениях
Вообще ваш опыт впечатляет.
учту.
что из плюсов- это реально круто, когда люди понимают на что идут.
К примеру, когда я только окончил университет, я думал, Что могу пойти работать начальником. но отработав немного в отрасли, Я понял, что это совсем не то, что я себе представлял. т.е сейчас я людей, которые собеседуются в нашу компанию я просматриваю реальные знания- конкретный софт, конкретные знания. и это работает.
Таким образом, Чем детальнее описание вакансии, тем реально эффективнее будет отбор и более подходящие люди будут участвовать изначально:) а то что вы ещё даете обратную связь- очень круто. Как-то помню, пришлось чуть ли не пытать коллег из PHW чтобы понять, на чем я провалился в собеседовании)
Респект за информацию.
Классная у вас компания, раз столько кандидатов можете позволить себе отсеить. Единственное, остро не понравилось — это делать на испытательном не пойми что и ради чего — ушел бы от вас)) Не дать нормальной работы — это как зарплату не заплатить, демотиватор очень серьезный.
Да, это долгий процесс — может занимать 3 часа у кандидата. Как сделать, чтобы он не бросил эту затею?Оплатить тестовое задание)
Трекеры и учеты времени любят всякие аутсорсы, директор как правило сидит в европе или сша, разрабы в регионе СНГ-страны. Все проекты и зп под мифическим dna. Бррр… Ниразу не встречал в продуктовой разработке такого.
— Как долго в итоге компания сидела без этого сеньора (1 из 1400)?
— На сколько по времени задержан выход продукта? Как понтери для бизнеса и доли рынка?
— С приходом еще одного сеньора как выросла производительность труда в компании?
— С приходом именно этого сеньора (1:1400) как выросли акции компании?
Очевидно же, что автор оценивает найм как промысел, а вы тут чуть ли не npv считать собрались. Это разные Вселенные.
Тут в топиках про найм разрабов часто создается такое ощущение, что единственная цель компаний в ИТ — это нанимать сеньоров/мидлов/и.т.п. Продукт же выпускаемый, капитализация компании — это такое ну… дело менеджеров, сеньоров это никак не касается.
Вы пишете, что работаете(ли) в Америке, а HR от Recruiter не отличаете.
Всё время до интервью, во время и до получения job offer со стороны компании с вами работает рекрутер, иногда он сторонний. HR это отдел, который попросит у вас "бумажки" типа паспорт/ИНН/разрешение на работу, диплом,… и добавит вас в систему, поможет разобраться с разными мед.страховками и пр.
2. Отсеивать кого-то потому, что у него нет знания какой-то технологии — так себе затея. Есть, конечно, глобальные вещи, на освоение которых могут уйти годы, но речь не о них. Если пришёл классный парень, который работал на Pyramid+SQLAlchemy, а вам нужно Django, то отказывать, по меньшей мере, глупо.
Во-первых, он не какой-то там зелёный джун, а вполне себе взрослый дядька-senior. Мы и так постоянно учим что-то новое. Начать писать на новом языке можно уже за один день, плюс ещё пару недель, чтобы привыкнуть
Во-вторых, у вас и так есть этап, в который новый человек не занимается ничем значимым. Так почему бы не использовать его более продуктивно? Если есть какой-то мелкий проектик на требуемых технологиях, то они осваиваются мгновенно. Как по мне, даже отсутствие знания языка не может являться причиной отказа, если кандидат писал на чём-то не сильно отличающемся. Разве что всякие Rust или Elixir могут вызвать сложности (хотя Elixir простой, на самом деле, там больше трудностей с OTP)
Просто кидается ссылка на тест, а потом можно забрать результаты по API.
Скажите, вы как-то проверяете, что именно кандидат заполняет тест, а не кто-то за него? Или это неважно, потому что всплывет на следующих этапах?
Нет, я не думаю, что это как-то возможно проверить. Так же как и со стажем, если человек считерил, он всё равно отсеется, просто потратит чуть больше своего времени.
Я просто пока не могу понять, как это работает. Допустим, мне важно, чтобы кандидат умел пользоваться отладчиком. Я в анкете спрашиваю «какой у вас опыт отладки». Кандидат что-то пишет. Если я доверяю, то могу взять человека без опыта отладки (обманул меня). Если не доверяю, то спрашиваю об этом на интервью, и тогда непонятно, зачем вообще нужна анкета. Разве что отсеять тех, кто не имеет опыта и честно об этом скажет.
FAANGи обладают огромными ресурсами, в т.ч. трекингом прогресса сотрудников, чтобы построить такую систему. А в итоге Амазон, похоже, сдался: набирает почти всех, но и увольняет с такой же лёгкостью. Т.е. это фактически признание того что нет никаких предикторов «качества» соискателя. Остаётся только дать ему поработать, и уволить если «не срастётся».
А в итоге Амазон, похоже, сдался: набирает почти всех...Что, даже без тестовых заданий?
Попробуйте, ради опыта, написать в видном месте вакансии и везде, где надо, что у кандидата шанс пройти к вам равен 1/1400.
Я думаю, кандидаты дадут вам понять, что они думают о такой замечательной системе своим числом, и это будет весьма объективный показатель, кстати.
у кандидатов не должно быть истории, просто берите и проверяйте их на то, что ценится на данной вакансии, без оглядки на прошлое.
Удачи Вам в таком случае взять в банк в отдел антифрода человека, чалившегося по 158 или 272. Ну или просто психопата учетного в период между обострениями, который по осени просто прийдет в серверную комнату с канистрой бензина и сожжет ее. Или просто крадуна обыкновенного, который будучи приглашенным в офис и оставленный без пригляда, пройдется по офису и унесет 6 телефонов и 2 пачки бумаги в принтере.
ide была atom, и он, например, не мог jump to definition или search class например.
Дичь какая-то. Я тоже не мог этого в PyCharm где-то семь минут назад. Сейчас могу.
Тут нет HR. Зачем? Мы постим объявление на разных площадках и имеем постоянный поток кандидатов. Есть подозрение, что это даже дешевле HR.
Хорошо вам, но
Я единственный из 1400, или самый крутой рекрутинг, что я проходил