Нет, это мое оценочное суждение по поводу причины, ради которой вы высказались в обсуждении.

Ну не, я не на столько плохой. Меня скорее удивила эта история, ну и теперь у меня есть две вещи которые я знаю от революте. 1. У них много своих либ(они не катируют спринг и других) 2. Она любят тдд так сильно что готовы не брать людей с ними не согласных

С этим расширенным контекстом гораздо приятнее вникать в ситуацию.

Скажите, пожалуйста, каким количеством сотрудников вам ранее довелось управлять непосредственно в течении хоть сколько-нибудь продолжительного времени?

Был опыт с 45 но я был молод неопытен и туп. В среднем 11 человек

первый пункт - лютый п-ц.
А второй - скорее просто они ищут “единомышленника”, а не того, который будет ложкой дёгтя в их бочке их варева

Понятно, спасибо. Значит, вам есть чем обсуждать мое предложение.

У нас же тут “Техдирские обсуждения”, т.е. собрались люди, так или иначе связанные с регулярным решением управленческих задач. У вас любопытные вводные, давайте с вами попробуем сыграть за Револют при неполных вводных, реконструировав из вашей байки их уже разрешенную проблемную ситуацию?
Допустим:
– У вас есть непрерывно развивающаяся организация;
– По историческим причинам у вас много своего кода, сделать инвестиции в замену на существующие на рынке решения пока не позволяют условия (динамика развития рынка как пример) и cost of delay у вас высокий.
– У вас есть требования регулятора, внутренний compliance и вам необходимо обеспечивать юридические гарантии, которые могут нарушить ошибки кода одного конкретного разработчика (GDPR, например).
– У вас большая организация, сотни разработчиков, вам важно:
а) поддерживать масштабируемость организации;
б) обеспечивать интегрированность отдельно взятой команды и команд между собой;
в) контролировать техдолг: ваши неверные решения могут поставить вас в ситуацию, когда вы не можете что-то сделать, а ваши конкуренты (N26, bunq) уже сделали и вы теряете в PR-пространстве и бьете по бренду.
– Вы непрерывно нанимаете новых людей с их собственной культурой работы, уходят старые и уносят с собой знания;
– Не все ваши разработчики хотят писать документацию, им ближе код;
– У каждого вашего тимлида есть свой список головных болей (неполный):
контроль проектируемых решений, приемка работы и проблема разного уровня навыков проектирования у разработчиков.

Револют как-то научился в этих ограничениях существовать, TDD одна из видимых граней их организационных решений.

Вы бы как за них сыграли и что бы предложили для решения этих проблем из позиции управленца?

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

Таким образом, шанс, что неиспользование кандидатом какого-то конкретного buzzword врядли может служить причиной отказа.
То, каким тоном и в каком контексте оно высказано - да, может.

Ну да.  Например фраза «это мой код, не лезьте в него, я сам за него отвечаю, буду писать как мне виднее» уже может быть таким звоночком, что непонятно стоит ли дальше общаться с человеком.

По поводу своего кода и невозможности его заменить чем то другим, на сколько я помню отказ от спринга конкретно было сознательное решение в компании, я в целом сам уже на него смотрю как jee 10 лет назад) есть более интересные штуки типа кваркуса или микронавта, да там нет магии «подключи один стартер и все само заработает» но частенько оно и к лучшему. Но не о том разговор.
Имхо чем крупнее компания тем больше приходится вводить разделения обязанностей. Грубо говоря когда команда из 15 человек варит сервис то каждый тимлид (пускай их будет 3-4) знает что там коллега делает. И в таком ключе часто архитектор кажется избыточным звеном. Когда у вас 150 команд, то чисто теоретически уже невозможно знать кто чем занят, контракты, роадмепы и т.д. И здесь на мой взгляд уже проще вводить системных аналитиков, архитекторов и других людей которые кажутся бесполезными когда команда маленькая(я отталкиваюсь от мысли маленькая команда ==  маленький продукт). Загоняя людей в регламент уровня «хочешь разработать новый сервис для чего-то? Вот тебе инструкция из 10 шагов» где шаги «пойти у архитекторам с неким техническим решением и описать что  и как» дядьки там посовещаются, решат, закажут вопросы. Дальше иди к там то людям, утрясай вопросы безопасности например. Весь этот обмен разумеется через конфдюенс например. В таком подходе в конце этой инструкции у микросервиса  должна получится  документация которая опишет какую боль решает сервис? Как он это делает? Схемы движения данных для pci dss, архитектура, схема развёртки и все такое.
Это конечно мое идеальное виденье(от части сформированное тем что я сам видел за свой опыт) и да здесь есть проблема закисания этой документации, ведь сервис может развиваться а документация нет. Как тут быть? Хороший вопрос и сходу ответить на него я не могу.
В общем мой ответ «ставим все на рельсы какого то четкого процесса и живем по нему»
Так же встаёт вопрос синхронного развития когда команде А нужна Фитча от команды Б, и сроки есть, а у команды Б эта фича запланирована на конец года ведь у них свой роадмеп, получается нам так и так надо заворачивать все на какого то человека(группу людей) которые будут этот самый роадмеп рисовать и решать кто, что, когда сделает.

А что конкретно сломалось в нашем процессе и почему конкуренты нас догоняют? Нужно разбираться, это могут быть наши велосипеды или низкое качество которое задерживает time to market из-за 10 итераций разработка-тестирование

Это типичная картина только для контор, созданных в 90-х и ИТ в которых делаются теми же людьми, что начинали бизнес.
У меня примерно  год сын "стажировался" в такой компании (без имен) - уровень зрелости процессов - 0, bus factor 1 и т.д. Git? Нет, не видели)
В современном мире человек с таким подходом выше джуна не продвинется никогда.

Я исхожу из того, что мир большой и я далеко не все знаю. Про xsolla узнал две недели назад.


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

Тимлид из банка (забыл название, но на слуху) мне рассказывал что тесты и ревью не нужны, да и в гите смысла мало.

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

"Тимлид из банка" - это как раз скорее всего из той же оперы. Люди сделали бизнес в 90-е и корпоративная культура в их ИТ так и тянется.  
"Солнце всходит и заходит? Ничего не трогай сынок".

Ну а что касается бизнеса, то это следствие низкой конкуренции (а то и явных сговоров) во многих отраслях.
Если прибыль 20% на оборот, то можно ничего не делать для роста эффективности. Была бы 3-5%, они бы давно повылетали с рынка.

Тесты уж точно не порешали бы проблему эффективности/неэффективности. Крупные банки настолько эффективны как структура, что выживают с 80% корп.паразитов и "прилипал" на борту, тесты точно погоду не поменяли бы.

А вообще, это разновидность техно фашизма:
- как можно работать без юнит-тестов?
- как можно работать без кубернетес?
- как можно работать без реакта?
- как можно работать без статически типизированного языка?
- как можно работать без того, чтобы диаграммы в enterprise architect сперва рисовать?
- как можно работать без докера?
- как можно не писать комментарии в коде?
- как можно работать без миграций в БД?
- как можно работать без девопса и IaaC?
Да вот так, берешь и работаешь, если задачи делаются, результат отгружается пользователям, пользователи платят

Эффективны не сами банки (они же банкротятся и теряют лицензии не так уж и редко), а та финансовая система (модель) в целом, которая позволяет им так себя вести.

Есть разница?

Конечно. Пока банк соблюдает правила игры, эффективность его внутренних процессов (в разумных пределах) мало влияет на результат. Результат определяет ставка ЦБ, наличие заемщиков на рынке и т.д.

Так я ровно это и написал. "Задачи делаются, результат отгружается пользователям, пользователи платят"

Считаете, что кубернетес/тесты/whatever это сильное преимущество? Отлично. Идите и выжмите всех с этого рынка. Не выжимаются? Ну тогда это все ради искусства и ЧСВ программистов

Только пользователи платят не от того, что задачи делаются, а потому что система так работает.
Если в банке уволить весь development и оставить поддержку, то при статичности законодательства первые 5 лет все также будут платить, никто не заметит потери бойца.