Что за крысиные бега у вас там, вы не один продукт пишите, а письками меряетесь?
Бывает менеджмент специально навязывает агрессивную конкуренцию. Я тоже сперва думал, что такого почти нет, но на деле многие руководители верят, что можно устроить "королевскую битву" на выживание и у них останутся только лучшие (ну или только ипотечники, как повезет).
Тут есть противоречие, когда оценку одновременно воспринимают как capacity (оценку трудозатрат) и закладывают в нее риски. Здесь нужно два уровня оценок: оценка размеров фичи, учитывающая риски, и оценка user story, которая берется в спринт, и оценивает только трудозатраты.
С двумя оценками и риски будут видны и работу можно будет попилить на более определенные задачи, которые можно оценить и в спринт взять.
Непосредственному рукводителю и так очевидно, у кого какая производительность, не обязательно считать коммиты. Принимать решения об увольнении должен тоже непосредственный руководитель. И перед тем как это сделать, он обязан разобраться в ситуации. Потому что иначе уволив сотрудника и проигнорировав проблему вы потеряете деньги дважды. А вот такое принятие решений "через плечо" руководителя по метрикам не разбираясь в ситуации, в целом ухудшает качество решений и может в итоге стоить дороже, чем 10%.
Угадывание в 55% случаев некорректно сравнивать с броском монетки. Потому что мы не знаем, какой процент удачных кандидатов в начальной выборке. И если их было 10%, а мы получили 50%, то это намного лучше броска монетки.
Насколько я знаю, сейчас на всех местах работы требуют спланировать отпуск на год вперёд (требование законодательства).
Работать два года без отпуска скорее всего не дадут - компания сама в отпуск отправит. Проблемы с неисполнением тк не нужны никому.
Отпуск вам предоставить обязаны. А в начале года работодатель обязан составить график отпусков. Как так получилось что вы его не согласовывали и не видели, и только за месяц начали планировать отпуск - тоже не понятно.
Не спорю с выводами, но вы упускаете факт масштабируемости таких собеседований. А масштабируемость при большом найме повышается с такими практиками.
Для того чтобы проводить лайвкод собес нужно гораздо меньше подготовки, результаты более предсказуемые и меньше зависят от собеседующего. Кроме того промежуточные этапы не обязательно должны проводить члены команды.
В этом и проблема, что "просто работать" не получается. А проблемы менеджмент скидывает на исполнителей.
В примере, который привёл автор статьи, к разработчику обычно ещё приходит менеджер и говорит, что разработчик (pr'ы которого не принимаются и даже не смотрятся) не справляется. Никто не будет искать проблемы в управлении, если можно просто уволить разработчика, а начальству рассказать, что провел оптимизацию.
Ну тут обычно речь не про заучивание алгоритмов (я такого, чтобы просили красно-черное дерево реализовать или даже сортировку не видел никогда), а проверяется навык написания кода как таковой. Для меня стало открытием насколько много программистов (некоторые являются ещё и формально сеньорами) не могут закодить простую фигню типа применения скидки на товары, группировки отпусков сотрудников по месяцам и раз за разом выдают код с багами.. От таких как мне кажется проблем можно огрести больше, чем от человека, который не так хорошо знает ваш стэк.
Бывает менеджмент специально навязывает агрессивную конкуренцию. Я тоже сперва думал, что такого почти нет, но на деле многие руководители верят, что можно устроить "королевскую битву" на выживание и у них останутся только лучшие (ну или только ипотечники, как повезет).
Тут есть противоречие, когда оценку одновременно воспринимают как capacity (оценку трудозатрат) и закладывают в нее риски. Здесь нужно два уровня оценок: оценка размеров фичи, учитывающая риски, и оценка user story, которая берется в спринт, и оценивает только трудозатраты.
С двумя оценками и риски будут видны и работу можно будет попилить на более определенные задачи, которые можно оценить и в спринт взять.
Непосредственному рукводителю и так очевидно, у кого какая производительность, не обязательно считать коммиты. Принимать решения об увольнении должен тоже непосредственный руководитель. И перед тем как это сделать, он обязан разобраться в ситуации. Потому что иначе уволив сотрудника и проигнорировав проблему вы потеряете деньги дважды.
А вот такое принятие решений "через плечо" руководителя по метрикам не разбираясь в ситуации, в целом ухудшает качество решений и может в итоге стоить дороже, чем 10%.
Угадывание в 55% случаев некорректно сравнивать с броском монетки. Потому что мы не знаем, какой процент удачных кандидатов в начальной выборке. И если их было 10%, а мы получили 50%, то это намного лучше броска монетки.
Насколько я знаю, сейчас на всех местах работы требуют спланировать отпуск на год вперёд (требование законодательства).
Работать два года без отпуска скорее всего не дадут - компания сама в отпуск отправит. Проблемы с неисполнением тк не нужны никому.
Отпуск вам предоставить обязаны. А в начале года работодатель обязан составить график отпусков. Как так получилось что вы его не согласовывали и не видели, и только за месяц начали планировать отпуск - тоже не понятно.
Не спорю с выводами, но вы упускаете факт масштабируемости таких собеседований. А масштабируемость при большом найме повышается с такими практиками.
Для того чтобы проводить лайвкод собес нужно гораздо меньше подготовки, результаты более предсказуемые и меньше зависят от собеседующего. Кроме того промежуточные этапы не обязательно должны проводить члены команды.
В этом и проблема, что "просто работать" не получается. А проблемы менеджмент скидывает на исполнителей.
В примере, который привёл автор статьи, к разработчику обычно ещё приходит менеджер и говорит, что разработчик (pr'ы которого не принимаются и даже не смотрятся) не справляется. Никто не будет искать проблемы в управлении, если можно просто уволить разработчика, а начальству рассказать, что провел оптимизацию.
Ну тут обычно речь не про заучивание алгоритмов (я такого, чтобы просили красно-черное дерево реализовать или даже сортировку не видел никогда), а проверяется навык написания кода как таковой.
Для меня стало открытием насколько много программистов (некоторые являются ещё и формально сеньорами) не могут закодить простую фигню типа применения скидки на товары, группировки отпусков сотрудников по месяцам и раз за разом выдают код с багами.. От таких как мне кажется проблем можно огрести больше, чем от человека, который не так хорошо знает ваш стэк.