вимоги можуть змінюватись або бути нелогічними на перший погляд. дуже допомагає описувати вимоги у таск трекері (джира чи будь що) — як на етапі планування, так і підчас змін посеред ітерації. а потім лінкувати таск трекер до пулреквестів чи коммітів.
в мене в самого були не раз ситуації, коли дивишся на код і думаєш «що це таке», потім знаходиш таску 3річної давності, яку добра людина детально описала і одразу «а ось воно що»

намагаємось байдужих не наймати :)

да, каждый performace review process часть команды может получить 500-1000+ прибавку к компенсации.
после ревью у всех компенсация соответствует текущему уровню навыков и дополнительной ответсвенности. при пересмотре мы больше ориентируемся на то, что каждый человек должен получать на текущий момент, а не на разницу в прибавке.

(без зміни рівня девелопера)

мы не используем отдельно прописанные уровни или тайтлы. нет разбиения команды на junior-mid-senior, etc. рост внутри компании осуществляется за счет экспертизы, опыта, или фактического лидерства в отдельной команде.

пример — вы решили лидить часть проекта или разработку отдельной большой фичи, взять ответственность за планирование и релиз. Помимо прямого написания кода, вы больше остальных участвует в организации планирования, помогаете другим разбить фичу на подзадачи и приоритизировать, координирует несколько команд, выстраиваете архитектуру проекта и тд.

в итоге вы занимаете роль Lead Engineer (или техлид) в команде по факту и по уровню своей экспертизы, а не по тайтлу. после performance review это напрямую отражается на компенсации.

Читай «определённые персонажи в группе могут сдвинуть оценку группы, используя убеждение/положение, или просто факт того, что кто-то голосует солидарно с персонажем, в сторону своей собственной предубежденности».

Такой риск всегда есть, собственно я поэтому и описывал отдельно возможную предвзятость.
Чтобы избежать этого, голосование в каждой группе модерируется engineering management командой. Предубежденность, как и развитый навык убеждения обычно сразу заметны.

Будут ли более сложные системы работать «лучше» и как это «лучше» вообще можно оценить?

Можно сравнить время, затраченное на весь процесс ревью, проанализировать результаты за несколько лет для одних и тех же людей, собрать фидбек команды о процессе ревью и их согласие с результатами.
Мы так и эволюционировали в течении 7 лет в сторону упрощения с сохранением качества/справедливости.
Фидбек должен быть полезен инженеру, для которого проводится ревью, это не процесс ради процесса.

Все-таки незрозуміло, як це оцінюється? У балах (за 10-бальною або 100-бальною школі)?
Як оцінити стабільність і якість всієї роботи, виконаної за рік? Це можуть бути десятки і навіть сотні завдань на проекті.Як це все запам’ятати?

Субъективная общая оценка за весь период по шкале средняя/выше/ниже среднего или сильно выше/ниже среднего. Под оценкой понимается значение с достаточным уровнем аргументации и описанием произошедших ситуаций.
Ревью оценки в группе, фидбек, подкрепляющий оценку и общая шкала минимизируют субъективность.

Само понятие «Продуктивность» включает в себя несколько категорий, о которых выше писал.

Як оцінити стабільність і якість всієї роботи, виконаної за рік?

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

Часть регулярного фидбек процесса. Понимание зон роста, навыков, на которые стоит обратить внимание, дополнительные ответственности/инициативы, которые на себя можно взять.

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

Якщо ні, який сенс до них готовитись і проходити

Это не тот процесс, к которому нужно «готовиться и проходить», это ведь не экзамен.
Суть в том, чтобы фокусироваться на развитии своих навыков и успешности продукта, над которым работаешь — при этом быть уверенным, что компенсация будет справедливо и соответственно развиваться.
При такой модели пропадает смысл менять компанию только ради $500 прибавки.

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

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

PR помогает:
1. определить справедливый уровень компенсации
2. выйти на общее понимание зоны роста
можно конечно рандомно зарплаты выставлять, но как то не честно.

мы проводим регулярные one-on-ones с каждым инженером, система performance review прозрачна для всех и по окончанию performance review процесса проводим со всеми отдельные feedback сессии. это помогает в том числе видеть недовольство.
мне кажется, эти процессы легче проводить в компании с меньшим кол-вом сотрудников (<200).

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

схему объясняем каждому новому инженеру в компании.
инженеры — основные участники процесса, т.к. peer review.
после каждого review проводим ретроспективу с теми же инженерами, чтобы обсудить потенциальные улучшения.
отдел маркетинга в проведении performance review не участвует :)

каждая компания строит тот процесс, который работает для неё в данный момент времени.
мы не руководствовались опытом компании Deloitte при выборе своего процесса.

да, это входящий фильтр хайринг процесса. а массив с нулями — это скорее пример того, что задача несложная и абстрактная.

если вам интересно, мы можем выслать вам тест таск, а вы можете его пройти в любое удобное для вас время. это несколько относительно простых задач, которые нужно решить на платформе www.qualified.io. в среднем прохождение занимает около 2х часов.

после тест таска мы проводим два основных этапа интервью:
1. сессия парного программирования на 1.5 часа, во время которой мы пишем решение одной абстрактной задачи
2. FullDay — полный рабочий день в одном из наших офисов. вместе с нашим инженером кандидат реализует настоящую задачу с одного из продуктов. FullDay проводится в обычном рабочем режиме, что позволяет кандидату посмотреть на процесс работы изнутри, а нам лучше понять, сможем ли мы сработаться с кандидатом в дальнейшем. Как и в вашем примере с Basecamp — это большая инвестиция времени с двух сторон, поэтому этот этап проводится последним.

Если у вас будет время и желание, мы с удовольствием проведем с вами все эти этапы интервью.

1. тестовое задание это первый этап процесса. тест таск не должен быть сложным/длинным, но в тоже время должен иметь возможность отфильтровать кандидатов
2. вы ведь понимаете, что Сергей привёл абстрактный пример ?

инженерный тест таск — это несколько коротких задач на www.qualified.io. сервис показывает время прохождения.
сами пробовали, да, 1.5 — 2 часа.

среднее время прохождения тест таска от всех кандидатов (инженеров) за последние пару лет

спасибо за уточнение.
именно так — насколько мы заинтересованы в кандидате, настолько и у кандитата должны быть причины попасть именно в Railsware. процесс настроен на двустороннее сотрудничество.
конечно, он не подойдет для тех, кто ищут работу по принципу «кто первый ответит».