Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть
  • Как измерить программиста

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

    Аргументация простая, как двери, в статье есть выши же мысли по этому поводу.

    В профессиях, имеющих дело с материальными объектами, оценить работника относительно просто — измеряешь количество и качество продукции, которую он произвёл.

    Ключевая ошибка, из-за которой лишаются смысла все дальнейшие логические построения — не «в профессиях, имеющих дело с материальными объектами», а «в профессиях, в которых в результате действий получается типовый результат». Работа программиста — это использование большого количества (чем больше, тем лучше) приобретенных разнообразнейшим образом (вузы, курсы, опыт, курилка) знаний и навыков как делать надо, и как делать не надо, для того, чтобы максимизировать business value морфируя заданным (или не очень) образом программный продукт(ы). Это плохо формализуется, и плохо оценивается и меряется с точки зрения процесса.

    Вы скажете: «но постойте, как же бизнесу принимать решения без цифр, какой программист эффективный, а какой — нет?»
    Ответ простой — никак, если бы все было просто и измеримо, айти контор было бы как мафов — легион на каждой станции метро. Весь хардкор ведения технологичного бизнеса в том, что нужно из***нуться и понимать свою эффективность без понимания индивидуальных метрик своего R&D персонала. Проданные часы, ревенью vs стоимость разработки, зависимость процента 5хх от фазы луны — каждый выдумывает свои индивидуальные, контекстные и плохо переносимые метрики.

    TL;DR; Разработчики имеют дело не (не только) с типовыми задачами, измерения их эффективности с точки зрения кода сродни измерения средней температуры по больнице. Обязательно покажут на коронавирус, и что в морге эффективность лечения выше.

  • Как я работаю: Петр Коренев, iOS Team Lead в Sigma Software

    Прочитайте ещё раз внимательно название и описание рубрики.

  • Навіщо розвивати українську мову в ІТ-секторі

    Именно так! В условиях гибридной войны, любой русскоязычный продукт вызывает подозрение (хоть этикетка на туалетной бумаге, хоть статья на википедии). При этом важно не дискриминировать право людей разговаривать или писать на любом языке. Потому что именно языковая дискриминация — верный путь к разделению общества. Совок оставил в Украине жуткий легаси с русскоязычными школами, 23 февраля, 9 мая, колорадскими лентами и прочими злоебучими атрибутами «русского мира». Его невозможно быстро победить — можно только грамотно возглавить.

  • Что вам нравится в текущей стране пребывания?

    Про одежду и еду очень спорно.

    Качественные продукты в Украине стоят дороже, чем в большинстве европейских стран (сравнивал чеки с Португалия, Испания, Германия, Венгрия); ± также с (Италия, Франция); дешевле (Швеция, Норвегия).

    Половина львовских бутиков сидит на том, что хозяин на туареге мотается в польские и австрийские аутлеты. Шмот практически везде дешевле, чем в Украине (если не секонд / контрабас).

    Жилье — да, если ты хомяк и собираешь кэш. Зато в Дании, например запустили ипотеку −0.5% год. Да, именно «минус пол процента годовых».

  • Нужны ли программисту алгоритмы и структуры данных

    С посылом статьи полностью согласен. А в примере с Ахо-Корасик... это как бы типичная задача для ELK-стэка?

    Поддержали: Denys Tsomenko, Dmitry Gurinovich
  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    И ни разу не ошибался?

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Ланфрен ланфра!

    Поддержал: Aleksandr Bogush
  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Так а при чем тут начальник.

    Судя по твоей статистике, ты — дартаньян идеальный специалист, который никогда не ошибается. Ну или хотя бы в вопросах оценки и найма инженеров.

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    В таком случае, чем бы вы не занимались сейчас, вы сильно недооценены.

    Умение безошибочно отбирать подходящих технических специалистов — это киллер-способность, которую с руками и ногами оторвет любая крупная техническая компания. Сеньоры из долины по 200к в год будут числиться у вас секретарями. Дерзайте покорять этот мир.

    Поддержал: Aleksandr Bogush
  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Ну, смотря что для компании дороже.

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Ну так а сколько из нанятых оказалось «неудачных»?

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Где связь? Не улавливаю.

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Так что ТС всего-лишь описала свой опыт

    И сделала вывод о том, что тесты не работают. Мой же поинт в том, что
    1) их, скорее всего, просто неверно готовят / используют в неподходящих ситуациях.
    2) вывод сделан на основании неполного разбора проблемы — проблема освещена только со стороны «тесты рубили воронку», т.е. рассмотрен только негативный сценарий. Позитивный же, «тесты экономили время наших инженеров» и «тесты помогали нам не нанимать некомпетентных» — не рассмотрен.

    И он в общем совпадает с моим с этими всеми тестами. ну и по обсуждению ниже видно, что совпадает с опытом многих других отписавшихся.

    ИЛИ совпадает с опытом людей, которые не любят / не умеют решать time bound алгоритмические проблемы. Мы не знаем бэкграунда этих людей поэтому это может быть истолковано как экспертная оценка, так и cognitivity bias.

    Я, например, дважды не прошел behavioural intervirew в одну из FAANG компаний. Значит ли это, что behavioural interview sucks? Мой же опыт говорит именно об этом, и аргументов я могу привести массу, и даже показать, что я могу лучше справиться с теми же задачами, которые решают инженеры компании на основании опенсорса.

    К чему это я все — зачастую «статистика» (70% отсев) и аналитика (большинство наших сеньоров не справлялись, а европейские справлялись, джуны не бросали, а сеньоры бросали) служат для подтверждения заранее сформированного вывода, а не для формирования вывода. Если анализировать ситуацию непредубежденно — нет оснований для вывода «это не работает». Это скорее «у меня не получилось, поэтому это не работает», что, в целом, совершенно неплохо, и тоже очень полезная информация — но статья и обсуждение настаивают именно на том, что просто «это не работает».

    Поддержал: Volodymyr Yatsevsky
  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Вообще-то все логично. Рекрутеры (особенно внешние) против всего что может помешать им получить бонус за найм.

    100%

    Тесты — это творчиство 23-летних лидов: человек просто не умеет проводить собеседования, не хочет учится, а хочет как амазон.

    Нет, это тесты курильщика. Тесты здорового человека как раз есть потому, что любой self-aware специалист исходит из того утверждения, что он может ошибаться, в том числе и при проведении собеседования и хочет снизить процент ошибок.

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Гораздо важнее отсеять поток сеньоров, чем поток джунов...

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Вячеслав, а поделитесь, пожалуйста, своей воронкой:

    — Кандидаты, которые пришли на собеседование (100%)
    — Наймы (x%)
    — из них удачные (y%)

    Почему спрашиваю — мне кажется, что

    Мне не нужны тесты, чтобы оценить навыки инженера — как в общении, так и технические.

    ведет к тому, что у вас x == y, что невозможно на более-менее продолжительной дистанции :)

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Спасибо, очень интересная статья.

    Но, на мой взгляд, в ней есть одна фундаментальная ошибка относительно технических тестов.

    Берем факты:
    — В течение одного года собиралась статистика по компании, которая использовала Codility
    — 70% кандидатов не прошли тест
    — Был один случай, когда настояли на игнорировании теста и кандидат выполнил тестовое, прошел собеседование и испытательный срок.

    Берем вывод:
    — Codility плохо работает

    Вывод и факты логически не связаны. Но такой вывод, безусловно, напрашивается. Почему?

    Когда вы входите во взаимоотношения с клиентом, вы начинаете работать над общей целью — нанимать подходящих (а в идеале, супер-крутых, talents, a-players, бла-бла) людей для открытых позиций клиента. Применяются разные инструменты, которые помогают достичь эту цель. Codility действительно не помогает в достижении этой цели. Потому что он, как раз наоборот, помогает не нанимать неподходящих людей vs нанимать подходящих людей

    Помимо стоимости простоя (к примеру, потери компании в случае, если вакансия не закрывается слишком долго) есть стоимость найма (частично состоящая из стоимости человеко-часов сотрудников, занятых в отборе) и потери от ошибочного найма. Как правило, размер потерь от ошибочного найма значительно превышает все остальные возможные косты.

    Нна вкус и цвет все фломастеры разные, поэтому решение применять или не применять Codility, Hackerrank и т.д. — исключительная прерогатива компании, в идеале основанная на понимании структуры своих расходов на хайринг. Аргументация вида «но он же отсеивает 70% кандидатов» не очень валидна, потому что это как раз то, что этот инструмент и должен делать: )

    Как можно иначе истолковать приведенные факты?

    — 70% кандидатов не прошли тест? Окей, есть несколько возможных причин:
    1. Они уже не кодят каждый день (так часто бывает у сеньоров/лидов), поэтому не способны за ограниченное время решить задачу, в которой нужно писать код. Как с этим быть? Четко прояснять взаимные ожидания. Если позиция предполагает кодинг каждый день, и кандидат это делает (и хочет делать дальше) — он без проблем справится с codility
    2. Кандидаты не способны фокусироваться на конкретной проблеме (так часто бывает у сеньоров/лидов). Они просто по колено завязли в облаках, бигдатах, архитектурах и привыкли мусолить вопросы и решения по несколько недель. Как с этим быть? Четко прояснять взаимные ожидания. Если позиция предполагает уметь фокусироваться и быстро решать конкретные проблемы, и кандидат это делает (и хочет делать дальше) — он без проблем справится с codility
    3. Кандидаты просто некомпетентны. Стоит признать, большой опыт «интересных проектов», к сожалению, не всегда гарантирует компетентность кандидата.
    4. У компании слишком сложный тест. На кодилити множество вариантов тестов и их кастомизации, если в тесте есть задачи на жадные алгоритмы или динамическое программирование — ну как бы, надо понимать цель, зачем проверять именно такие навыки кандидатов.
    5. У компании слишком высокий проходной балл. Нужно понимать, какой реальный балл теста позволит отсеять большинство некомпетентных и «слишком компетентных архитекторов», и использовать именно его. Также можно иметь определенное окно (Например, 70 проходной, 55 — 70 — смотрим в случае наличия каких-то дополнительных положительных факторов)

    — Был один случай, когда настояли на игнорировании теста и кандидат выполнил тестовое, прошел собеседование и испытательный срок?
    1. Вообще ничего не говорит о том, насколько это хороший найм. Он мог быть уволен через 6 месяцев или через год.
    2. В большинстве компаний испытательный срок — это формальность. «Покупают» человека именно на интервью, и, далее, держат в компании даже если он/она не совсем оправдывает ожиданий. Чтобы не пройти испытательный срок, зачастую, нужно быть злостным вредителем.

    Ну и на закуску, из моего опыта работы в организациях 100+ человек, самый высокий уровень подготовки инженеров был именно в той единственной компании, которая использовала Codility как один из этапов. Существует ли корреляция? Каждый пусть решает сам для себя :)

  • Зе: ФОПам податок 20%

    Прочитал.
    Три раза.
    Не осилил.
    Связи содержания и заголовка не усмотрел.

    Вы, батенька, вместе с Зе-командой употребляли?

  • Перед и после инаугурации

    Владимир Александрович, перелогиньтесь.

    Вот не дает вам покоя слава Кличко...

  • Hertz подаёт в суд на аутсорсера Accenture. Требуют возместить $32M за проваленные проекты

    Да ну, бредни.

    С гребцов в Украине ничего не взыщешь.

    а) ФОПы контратакуют через мин соц.политики
    б) Массовое бегство гребцов — еще большие потери
    в) Огромные операционные расходы на суды с ФОПами
    г) Акты выполненных работ, подписанные галерой играют против нее.

    Самый максимум — это прокинуть гребцов на последнюю зарплату.

    Так что с точки зрения бизнеса пытаться что-то взыскать с гребцов бессмысленно, разве что из принципа попробовать почесать ЧСВ.

← Сtrl 1234 Ctrl →