Дякую за детальний опис свого досвіду

Уявімо 2 ситуації:
1. Навколо тебе люди які офігенно перформлять, ви один у одного чомусь вчитеся. Думаю люди більш схильні в такій ситуації погодитися на 80%.
2. Навколо тебе є (навіть якщо небагато) люди які начебто не дуже працюють — або скілів не вистачає, або досвіду, або старанності. Тоді ймовірно не погодишся на 80%, бо будеш відчувати несправедливість цього по відношенню до себе.

Думаю що більшість людей в більшості компаній так чи інакше відносять свою ситуацію до варіанту 2 і тому не обирають підхід 80%.
Походу лідер має бути дійсно крутим щоб зібрати компанію в якій нормою буде обрати 80%.

У мене в команді 9 сервісів на 7 інженерів. Деякі з них чисті мікросервіси які мають дуже маленьку кодову базу і міняються вкрай рідко. Інші міняються часто. Сервіси які переростають з мікросервісу в макросервіс більш схильні накопичувати гівнокод. І велика частина в моноліті іншої команди (з історичних причин). Частину сервісів вже хочеться викинути і переписати код заново, але це непросто поєднувати зі швидкістю імпелементації фіч і комплаєнсом вимог різних стейкхолдерів. Звісно багато проблем в кодовій базі, але всі виправити нереально. Тому підходи описані в статті застосовуються і допомагають.

Норм підходи. Не знаю наскільки вони доречні малим командам в 9 людей, але великі інженерні організації постійно використовують такі підходи.

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

Щодо статті — мені відчувається дисонанс заголовку (тягне на велику кількість структурованого контенту) і контент (тягне на опис пари підходів до специфічної проблеми).

Всі ці практики і менторінг є. І списки перевірки компетенцій.
Але це не відміняє того що досвідчені інтервʼювери вміють робити дещо інше — вони можуть всього за декілька запитань докопатися до причин і мотивацій. І виглядає це дуже природньо і кандидат себе не відчуває на допиті.
Це лише один приклад таких скілів.

Щодо ризиків і тому подібному.
Саме через це така практика і відсутня. Особливо західних компаніях які хочуть впевнитися що зберігання і використання даних кандидатів не призведе до судових позовів.

До речі, не бачу причини чому ви застосовуєте зверхню позицію в останній частині свого коментаря. Пасивно агресивні формулювання думок не є ознакою якісної комунікації.

Я б хотів щоб HR відділ надавав приклади співбесід топових інтервʼюверів на фірмі. Де HR чи інтервьювер підкреслював як аналізувати відповіді (особливо на складні позиції як лід). Або погані пантерни в поведінці інтервюверів, і т.п.
Це б дуже допомогло підняти рівень інтервʼюверів і залишати топові враження про фірму у кандидатів.

Ще можливо ті з них хто отримували найбільше перейшли у мідлів — статистика це не може ні підтвердити ні спростувати.
Тоді падіння було б не справжнім падінням, може вони навіть стали отримувати більше.

Може бути корисним для зростання в Ліда. Для команди з бекенд і фронтенд і native інженерами просто сеньйора фронтенда можуть не дуже брати бо як він буде оцінювати і ревьювити роботу бекендерів.

Хочу зазначити що сеньйор це дуже широка категорія. Часто люди можуть підвищувати свою цінність в рамках цієї лички без отримання іншої посади. В деяких компаніях існують свої внутрішні рівні сенсорів — типу SWE1, SWE2.
Деякі компанії не мають офіційного рівня staff — такі інженери тоді теж попадають в сенйори. Те саме з тех лідами і архітектами — люди що де факто роблять схожу роботу можуть офіційно мати позицію сеньйора.

Але ж лід може керувати більш ніж однією командою/проектом. Їхня загальна кількість менша. Окрім того, іноді, позиція Ліда дуже сильно відрізняється від сенйора очікуваннями і конкретними задачами які виконуються кожен день (дуже залежить від специфіки компанії).

таке пояснення цілком можливе, хоч і може вимагати достатньо часу щоб ось таким чином обернутися

Мабудь там складність проектів невелика і таски гарно розписані до деталей. Інакше це буде не продуктивно.

Яким чинов entry level конкуруть з сенйорами за позиції?

Окремий випадок ніяк не відміняє статистику. Сподіваюся що більшість тут не стане витрачати всі кошти на лотерею якщо раптом сусід виграє 100 мільйонів.

Коли ти наймаєш людину і бачиш що користі від неї в декілька разів більше має закрастися питання нахіба тобі ті старі що знають проект, але нічого не роблять.

Що це за сенйори такі що їх половиною джуна можна закрити?!

Згоден. Зауважу що я не кажу що принцип неправильний. Просто зазвичай так не відбувається у стартапі.

Щодо опису культури розробки до яких ви прийшли. Ось цей пункт мене здивував:

There should be no black box in architecture or code. Architecture and code should be transparent and understandable to anyone. Kludges are unacceptable. Any exceptions must have substantial justification and be approved at the highest level. «I made a kludge coz someone rushed me» is a mortal sin, not an excuse.

Стартап який змінює бекендера, який має лише пару бекендерів хоче щоб інженери не пояснювали гівнокод тим що у них дедлайн занадто скоро і немає часу на чисту архітектуру. Не віриться що ви цього досягаєте. З мого досвіду ви якраз на етапі коли такого технічного боргу створюється багато. Як на мене баланс досягається не декларуванням що ми всі в білому пальті, а наступним:
— описом в коді або документації як ти нагівнокодив і чому/як треба переробити.
— відповідальністю переробити це бо ти ж це створив
— хорошою документацією як все працює

Мені здається що у більшості уявлення про продуктових інженерів не вірне. Продуктовому інженеру не обовʼязково вміти в UX, або аналітику. Але мати бажання покращувати продукт для користувачів обовʼязково.
Продуктовий інженер має сказати продукту що ідея херня. Бо вкладемо кучу ресурсів в реалізацію (ну бо продукт менеджер не може цього знати не розуміючи архітектури і не знаючи кодової бази). А замість цього запропонувати щось схоже і примітивніше, але те що легко кладеться на архітектуру і тому займе не так багато часу.
Продуктовий інженер має вміти декомпозувати проблему. І іноді приходити і казати що через підводні камені те як ми хотіли зробити швидко не виходить. І UX вийде не той, і технічного боргу створимо багато, і фіча зможе бути використана лише 10% користувачів для яких фіча першочергово планувалася (це часто стає відомо в процесі розробки коли достатньо контексту про технічну реалізацію). Давайте відмінимо фічу.

Продуктовий інженер має розуміти свій домен. Не просто як сервіс Х викликає сервіс У, а чому фіча так побудована. Чому вона така складна (регуляції, застарілість системи подачі звітності в податковій, тощо). Це дає можливість знаходити продуктові інсайти поки ти розробляєш код. І це дає змогу бачити що маленька фіча не така вже і маленька, бо щоб нею користувалися доведеться ще декілька інших фіч змінити щоб в країні користувачів це було адекватним рішенням.

Чому класно розуміти аналітику чи UX. Бо інженер має додаткові інструменти в своїй роботі. Бо він може проаналізувати чи його реліз працює так як він задумував в архітектурі. Бо більша кількість ролей це більші витрати на комунікацію.

Ну є і зворотня сторона ролі продуктового інженера. Оскільки на продумування і декомпозицію фічі не витратили час то продуктовий інженер буде набагато повільніше деліверити адже він має все це проробити самотужки.
Та й естімейти зазвичай не працюють бо задачі широкі і невизначені, а отже часто не ясно що саме треба зробити щоб їх запровадити. Взагалі скрам в таких умовах не ефективний і краще застосовувати agile.

Я думаю що вас bias помилка того хто не вижив. Є дуже багато успішних компаній з опціонами. Часто VC змушують давати опціони ключовим співробітникам.
Але кейсів коли опціони так нічого і не коштували набагато більше. Інакше це було б не лотерея, а інвестиція.