Собес в Сберздоровье

На прошлой неделе пропустил пост - на этой неделе искупляюсь длинным постом.

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

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

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

• САР теорему и ее расширение PACELC
• чем отличаются система с доступностью 90% и система с доступностью 99,99%
• гейты и бфф - в чем суть, в чем отличия
• персистентные хранилища на бфф - с аргументацией за и против
• bpm движки
• как выбираем техстек для продукта
• как подойти к обновлению архитектуры продукта, с какой стороны
• как разрулить две команды, когда работа одной влияет на работу другой
• модульный монолит

Дальше решали задачку на систем дизайн - приложу в комментариях. Традиционно приложу и решение, если хотите - за скромные 80 истуканов 🗿

Из деталей про рабочие процессы. Задачи солюшен архам приходят или от СТО, или от команд, или от корпоративного архитектора. Работа идет по канбану. Из артефактов - ADR с использованием С4 на уровнях С1 и С2, тут все стандартно. Также имеются артефакты по собственным шаблонам - реестр потоков (..данных, скорее всего примерно как в Альфе реестр интерфейсов, кто работал тот знает) и варианты решения (тут, к сожалению, уже не помню, что это такое). Архсовет собирается при добавлении нового потока данных или изменении существующего, а также при появлении нового сервиса в ландшафте системы. В случае кросс-продуктового взаимодействия - все то же самое, только в несколько подходов. На момент февраля 2024 было 4 архитектора - 1 корпоративный, 2 солюшена и 1 системный. И на них - примерно 12 продуктовых команд.

По результату - отказ через несколько дней после технички, без фидбека. Я действительно не очень уверенно говорил на этапе систем дизайна, поэтому все вполне закономерно 🤷‍♂️