Профсообщества в больших компаниях

Появилась запись встречи канала "безвотэтоговсего" про профессиональные сообщества в Росбанке, где я дискутировал на прошлой неделе. Во встрече помимо меня участвовали следующие замечательные люди:
- Сергей Щербинин, автор канала "безвотэтоговсего" и организатор встречи
- Паша Соломин, лидер разработки и сопровождения СБОЛ
- Саша Денисов, Директор департамента ит поддержки пользователей и клиентов цифровых сервисов Росбанка
- Макс Морозов, СЕО Астон

В дискуссии мы обсуждали много вопросов и вот несколько из них
- Как и зачем корпорации строят профсообщества и как они измеряют их эффективность?
- Как выстраивать лидеронезависимые сообщества?
- Как вовлекать в них людей, пробуждая интерес, а не выставляя ненужные KPI?

Если суммировать мою точку зрения на основе опыта Тинькофф, то у нас проффсообщества логично называются профессиями и выстроены примерно так
- У профессий есть свои лидеры, что исполняют эту роль, совмещая с участием в продуктах/проектах
- Професии являются точкой синхронизации людей, объединенных вокруг чего-то общего: профессии (продакт менеджер, системный аналитик, qa-инженер, разработчик), языка разработки в случае разработчиков(golang, kotlin/java/.net, etc), функции (архитектура, процессы разработки) и так далее
- У каждой профессии есть ее лидеры, которые ее развивают как во всей организации, так и внутри крупных подразделений
- Лидеры профессий помогают определять ожидания от специалистов, которые входят в определенную профессию - это так называемые матрицы компетенций
- Лидеры профессий участвуют в рассмотрении заявок на повышение, что идут через наш процесс Т-Рост, про который я рассказывал в своей статье
- Лидеры профессий помогают улучшать найм сотрудников в рамках своей профессии (это наши стримы найма, например я когда-то курировал и рассказывал про system design и troubleshooting)
- В рамках профессии вырабатываются стандарты и часто реализовывается общий инструментарий, который помогает всем в рамках профессии быть эффективным
- Также лидеры профессий часто ведут публичную деятельность по освещению своей профессии как внутри, так и снаружи компании (aka devrel)

Для меня концепция профессии звучит классно и позитивно, но возникает вопрос а почему не выделить это в отдельную должность?
Ответ в том, что при выделении сотрудников на fulltime мы получаем сломанную ситуацию, когда крутой представитель профессии постепенно теряет
- Экспертизу в ней, так как перестает работать руками
- Связь с землей и уходит в абстракции, так как перестает работать руками
В итоге, лидер профессии вынужден сидеть на двух стульях.

Но тогда возникает вопрос, а зачем ему это делать?
Ответ в том, что это улучшает карму сотрудника и повышает вероятность успешного повышения в рамках процесса Т-Рост, причем для высоких грейдов это становится необходимым, но недостаточным критерием:)

#Management #Leadership #Engineering #Staff #Software #Devrel

Leetcode - прогресс за первый месяц

Я уже рассказывал как купил себе Premium подписку на LeetCode на день рождения (3 января ) и парочку курсов оттуда ("Data Structures and Algorithms" и "System Design for Interviews and Beyond"). А теперь пришло время отчитаться за этот месяц:
- Оказалось, что руки забыли примерно одинаково как писать на всех языках, поэтому я решил вспоминать Python для алгоритмических задач
- После того, как я вспомнил синтаксис python и чуток набил руку, то easy задачки я стал решать где-то за 5-10 минут, а вот задачки уровня medium идут у меня с переменным успехом (и пока они скорее побеждают)
- У нас в компании есть чатик любителей leetcode, которые решают Daily Challenge вместе и обсуждают задачки - я туда тоже записался, но отрешал только около половины ежедневных задачек
- Зато SQL у меня как будто не забывался - тут в среднем easy задачки идут за пару минут, medium обычно минут 5 и даже hard задачки решаются относительно просто (правда, сегодня ночью решал порядка часа последнюю hard задачку из набора "Advanced SQL 50")

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

P.S.
Купленные курсы я пока не прошел (и даже особо не начинал), но планирую в феврале их заботать. Особенно интересно будет изучить system design курс.

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment

Code of Leadership - Episode ? - Антихрупкость в IT от Саши Бындю

Я подумал, что в рамках моего подкаста было бы интересно не просто звать гостей и обсуждать их любимые книги. Круто иногда звать и самих авторов книг и обсуждать их творчество вместе с ними. Именно такую серию мы запишем с Сашей Бындю на следующей неделе по книге "Антихрупкость в IT". Договориться получилось достаточно легко
- Мы с Сашей уже были знакомы где-то с 2019 года, когда он выступал на ArchDays 2019 года с докладом про Inner source (я в ПК этой конференции с самого начала)
- Саша с большим интересом делится своим подходом к антихрупкости (он рассказывал про это на Codefest 2023)
- Я недавно прочитал его книгу и уже рассказл про нее раньше
- Когда я предложил Саше прийти в гости, то он легко согласился, а также написал небольшой ответ на мой обзор
- Когда мы обсуждали план на выпуск, то поняли, что интересно будет поговорить про "карты гипотез", продуктовый и проектный подход, работу в модели заказчик/исполнитель или внутри организации, архитектурные вопросы и так далее

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

#Management #Software #Architecture #Processes #Project #ProductManagement #Engineering #Processes #Consulting

Тренды геймификации - эфир South HUB

Меня достаточно часто зовут пообщаться и что-то пообсуждать. И я особенно люблю, когда я могу прийти не сам, а посоветовать кого-то более релевантного из моих коллег. И с этим эфиром на South Hub про геймификацию так и получилось - я порекомендовал позвать моего коллегу, Вадима Гончарова, который руководит разработкой игр и спецпроектов. Кстати, Вадим недавно на YaTalks рассказывал про то, как ребята делали игру "Ряд наград". Кстати, отдел Вадима теперь входит в управление разработки соцплатформ, про чью вакансию SRE лида я писал недавно.

В эфире будут участвовать
- Кирилл Буртный - СТО Х5 Tech, модератор дискуссии и январский соведущий канала South Hub.
- Вадим Гончаров, руководитель разработки спецпроектов и игр в Тинькофф.
- Антон Лямин, руководитель продукта опыта покупателей Авито.
- Олег Афанасьев, CPO RuStore | VK.

Обсуждать эти замечательные люди будут следующие вопросы
- Совместимы ли игры и большие корпорации?
- Что такое игровые механики, где сейчас их применяют и для чего?
- Какие выгоды они приносят при работе с клиентами и сотрудниками?
- Стоит ли вкладывать в геймификацию и к каким эффектам она приводит?
- Какое будущее у геймификации: чего хочет рынок?

#Software #GameDesign #Engineering

GraphQL: The Documentary

Полтора года назад я посмотрел эту документалку в рамках изучения whitepaper "Continuous Deployment of Mobile Software at Fb (Showcase)", на которую я написал краткое саммари в своем блоге. Если кратко суммировать, то где-то до 2012 компания, что создала GraphQL шла в сторону веба в мобилке, но стало ясно, что HTML5 в мобиле тогда не работал. Дальше они решили переобуться на нативную разработку и стало ясно, что старые APIшки не очень помогают в разработке нативных приложений. Дальше вместо проектирования API ребята изобрели свой способ через выставление query language прямо в потребителей и назвали это GraphQL. Несмотря на мое отношение к GraphQL рекомендую глянуть эту документалку и понять откуда растут ноги у этого подхода.

Кстати, я уже рассказывал про другие документалки
- How A Small Team of Developers Created React at Facebook | React.js: The Documentary
- Ruby on Rails: The Documentary
- Inside Envoy: The Proxy for the Future [OFFICIAL FILM]
- eBPF Documentary: eBPF’s Creation Story – Unlocking The Kernel
- AlphaGo - The Movie
- Kubernetes: The Documentary

#Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment

Алгоритмы: построение и анализ (Introduction to Algorithms)

Я купил этот кирпич за авторством Кормена, Лейзерсона и Ривеста еще в 2002 году, когда думал, что смогу стать мастером в алгоритмах. Это было еще первое издание книги с белой обложкой и тогда соавторов было еще трое. Мне тогда нравилось изучать эту книгу, но на первых курсах университета у меня еще не было личного компьютера, поэтому приходилось писать псевдокод на листочке и дебажить в голове. Такая схема работы не слишком помогала в изучении computer science, но основы вроде бы я тогда уловил (заодно понял, что в этой области я звезд с неба не хватаю:) иначе бы и в голове мог все это отрешивать без компа).

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

Прошло много лет и теперь можно вернуться к книге, а алгозадачи решать не в голове, а на leetcode:)

Структура книги достаточно логичная и состоит из следующих частей
1) Математические основы анализа алгоритмов - скорость роста функций (нотация O(n)), рекурентные соотношения, множества, комбинаторика и вероятность
2) Сортировка и порядковые статистики - сортировка с помощью кучи, quick sort, медианы и порядковые статистики
3) Структуры данных - стеки, очереди, связанные списки, хеш-таблицы, деревья
4) Методы построения и анализа алгоритмов - динамическое программирование, жадные алгоритмы
5) Более сложные структуры данных - b-tree, биномиальные кучи, фиобаначчиевы кучи, системы непересекающихся множеств
6) Алгоритмы на графах - поиск в ширину и глубину, минимальные покрывающие деревья, кратчайшие пути, максимальный поток
7) Дополнительные главы - матрицы, быстрое преобразование Фурье, NP-полнота и многое другое

В общем, фундаментальная книга с крутыми темами и устрашающими размерами:)
Кстати, а стоит заказывать четвертое издание книги, если у меня уже есть первое?

#Software #Algorithm #Engineering #SelfDevelopment

The Most Powerful Software Development Process Is The Easiest • Dave Farley • GOTO 2024

Это короткое видео Дэйва Фарли посвящено дизайну идеального процесса разработки софта. Интересно, что сам Дейв - тертый калач, который в давние времена написал книгу Continuous Delivery (я про нее рассказывал), а недавно - "Modern Software Engineering: Doing What Works to Build Better Software Faster", которая стоит у меня на полке и ждет своего часа. В этом видео Дэйв предлагает отринуть текущие практики и попробовать придумать процесс разработки софта from the first principle. В конце он предлагает модель идеального процесса, как видится ему. Интересно, что этот процесс позволяет размышлять не просто про идеал, а про вашу конкретную ситуацию и понять что не так с вашим процессом или вспоминая Льва Толстого понять в чем ваше несчастье:)

Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по своему

Ну а теперь кратко про мысли Дэйва
- Фиксирует цели разработки софта как решение проблем других при помощи софта. Для этого надо:
-- Понять проблему - отсюда появляются requirements
-- Решить проблему - тут мы пока пишем код, но некоторые говорят, что скоро будет писать только промпты
-- Проверить, что она решена - отсюда появляются тесты
- Так как мир вокруг изменчив, то нам надо уметь меняться - меняются требования и нам надо уметь делать изменения - отсюда появляется желание двигаться вперед маленькими шагами
- Нам надо понимать, что мы двигаемся в нужную сторону, поэтому нам надо верифицировать результаты и разрабатывать софт инкрементально
- Одновременно нам нужно, чтобы наша система работала с первой версии и на протяжении всех инкрементальных изменений - она же решает задачи пользователей, как мы определились в самом начале (а для этого она должна быть up & running)

Дальше автор показывает процесс:
- Смутное желание от бизнеса
- User story, где важно выразить потребности пользователя, а не конкретное решение
- Тут же важно привести примеры (из которых можно сделать test cases)
- А дальше уже идет design & implement часть, которую автор описывает подробнее
-- Про commit stage, упоминая continuous integration - на этой фазе проверяется техническая корректность изменений
-- Про acceptance stage - на этой стадии идут проверки, а можно ли релизить это изменение: acceptance test, security, performance, etc

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

P.S.
В общем, в этом видео нет ничего нового, но оно краткое, понятное и дает хорошую базовую модель процессов разработки.

#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE

Become an Effective Software Engineering Manager • James Stanier & Gergely Orosz • GOTO 2023

Интересное интервью с James Stanier, автором книги "Become an Effective Software Engineering Manager" и отдельно расшифровка.

Интересные моменты
- The real stories behind the book - каждая глава начинается с истории, которая легко позволяет представить себя на месте главного персонажа (пример с менеджером команды, что не поставялет нужный результат). Эти части написаны по мотивам реальных историй:)
- Journey to become an engineering manager - про треки развития внутри разработки, а также как легко расти естественно вместе с компанией на растущем рынке:)
- Prescriptions vs tools: Why this book is different - в этой книге нет описания как нужно поступать в каждой конкретной ситуации. Вместо этого тут описываются ситуации и возможное поведение в их рамках. А дальше читатели уже сами могут решать как им поступать:) Ну кроме гигиенических правил бытия менеджером, что идут в начале книги
- Getting into management: How to make it happen - тут обсуждается как можно дорасти до engineering manager в рамках растущей компании ... и как сейчас это сложно сделать в текущем контексте, где часть компаний скорее не растут, а сжимаются. Плюс тут обсуждается как сделать так, чтобы попытка стать менеджером была безопасной (чтобы можно было вернуться на роль individual contributor, если роль менеджера не подошла)
- Trends in engineering management - история про удаленную работу, про волны сокращений в tech компаниях, а также как часть engineering managers могут возвращаться в разработку по причинам уменьшения штата. Ну и про увольнения
- Must-have tools in management - тут ребята говорят про делегирование/контроль, а также про стоицизм
- Book recommendations - рассказ про другие книги - "Effective Remote Work" и "The Software Engineer's Guidebook", где первая книга гостя, а вторая - интервьюера.

#Management #Leadership #Software #Engineering #SoftwareDevelopment #Career

Канбан Метод. Базовая практика

Дочитал ночью эту книгу Леши Пименова, которая посвящена оптимизации процессов нематериального производства. Сразу, начиная с обложки, Алексей опрокидывает все базовые представление о Канбане

- его изобрели на "Тойоте"
- в нем есть доски и стикеры
- там ограничивают количество незавршенной работы

И дальше идет отстройка от старого канбана к новому, который придумал David J Anderson и превратил это в Kanban Univerysity (с курсами и сертификациями). Оставим в стороне сам подход к выбору уже используемого слова, а дальше объяснению всем, что это слово теперь значит что-то другое на совести David J Anderson. А рассмотрим саму книгу, которая состоит из четырех разделов.

1. Нематериальное производство
В этой части дается краткая отсылка к истории, когда производство было материальным и можно было видеть как материалы и незаконченное производство двигается по стадиям процесса (как в "Тойота"). А вот в условной разработке мы это движение уже не видим и нам нужно делать приседания для визуализации (откуда и растут ногу у знаменитых досок с тикетами)

2. Введение в Канбан Метод
Здесь все начинается с разбора принципов управления изменениями
- Начните с того, что есть сейчас (если задуматься над фразой, то сложно начать с чего-то другого)
- Договоритесь об эволюционном развитии (нет революциям и да постепенным улучшениям)
- Поощряйте проявление лидерства на всех уровнях
Дальше автор переходит к рассмотрению принципов поставки ценности
- Начиная с определения, что такое сервис поставки ценности
- Продолжая развитием правил для улушения показателей
- Отмечая важность понимания и фокуса на ожиданиях заказчика
- Говоря про важность управления работой, а не людьми
Завершает автор разбором базовых практик
- Визуализация
- WIP лимиты
- Управление потоком
- Явные правила
- Использование петель обратной связи
- Совместное развитие на основе моделей и научного подхода

3. Начиннаем использовать канбан
Здесь автор рассказывает про то, как изучать и улучшать процессы на практике, а точнее про
- Метрики производственного процеса
- Жизненные циклы
- Классы обслуживания
- Как строить канбан систему: про обязательства в такой системе, ее составные части, как дизайнить тикеты и саму доску.
Отдельно разбирается STATIK (System Thinking Approach To Introducing Kanban)

4. Улучшение канбан-системы
В этом разделе предполагается, что у нас уже есть канбан-система и мы дальше начинаем ее файн-тюнить, используя
- Накопительную диаграмму потока (cumulative flow diagram)
- Работу с узкими звеньями (как их выявить и что с ними делать)
- Работу с ресурсами непостоянной доступности (что это такое и как с ними быть)
- Что делать с вариативностью и как использовать теорию вероятности и массового обслуживаня (очень интересна часть про работу с рисками)
- Отдельно разбираются типы встреч и их ритмичность в канбан системе

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

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

Про улучшение процессов разработки софта я тоже как-то уже рассказывал и про kanban я там говорил по книге "Making Work Visible", на которую я как-то написал краткое саммари.

#Processes #Management #Leadership #Software #Kanban

Вакансия TPM (technical product manager) в IDP (internal developer platform) @ Tinkoff

Большие технологические компании в какой-то момент времени приходят к созданию своих платформ разработки, которые должны консолидировать общие инструменты и предоставить их консистентно всем продуктовым командам. За счет этого компании стремятся к упрощению разработки продуктовых вещей, сокращению time-to-market, а также к экономии на масштабе. В Тинькофф это произошло 4 года назад с приходом в компанию Игоря Маслова, вокруг которого стала собираться core-команда, которая потом превратилась в coretech. На заре становления к этой команде присоединился и Дима Гаевский, который когда-то начинал работать у меня, потом руководил несколькими командами в coretech, а теперь исполняет роль CPO (chief product officer) нашей внутренней платформы. И сейчас Дима ищет себе технического продакта на направление "Code & Build" (Version Control + CI домен).

Вот как Дима сам описывает то, чем занимаются ребята в IDP

Что мы делаем:
- Собираем воедино все сценарии разработки, тестирования и сопровождения приложений в Tinkoff, создавая централизованную application-centric PaaS платформу Spirit.
- Платформа представляет собой консоль в стиле gcp/aws, построенную вокруг SSO с тесной интеграцией в общие сценарии инфраструктурных сервисов (БД), систем непрерывного запуска нагрузочных тестов, DevSecOps, VCS (Gitlab CE), движок квот, браузерные и мобильные фермы, хранилище артефактов, и multi-cloud runtime платформу.
- Продукт включает более 15 систем, объединенных вокруг различных этапов производственного цикла, с постоянным расширением числа систем.

Spirit включает в себя продуктовые направления:
- Discover - Inner Source, поиск, маркетплейс решений
- Code & Build - VCS (сейчас форк community Gitlab), CI, Artifact management (свое registry)
- Configure & Deliver & Operate - централизованная система конфигурации и деплоя приложений, а также рантайм платформа

Наша глобальная цель:
- Создать экосистему глубоко интегрированных инжиниринговых продуктов для разработчиков закрывающих все потребности на всем цикле производства. Экосистема объединяет в себе платформу для разработки Spirit, управления инцидентами FineDog и Observability - SAGE.
- Мы - часть Core Technologies, подразделения, созданного для повышения продуктивности разработки в Tinkoff, в IT которого трудится уже более 10 тысяч инженеров.
Мы придерживаемся идеологии you build it - you run it, пишем качественный код, самостоятельно покрываем все unit и интеграционными тестами. Задачи в команде варьируются от решения багов до написания сложных RFC по продуктовым требованиям и декомпозиции на задачи.

Если вам понравилась эта позиция, то вы можете написать Диме (@drwatsno)

P.S.
Работа с Димой очень хорошо прокачивает навыки - он глубоко шарит во многих комплексных вещах, поэтому это хороший вариант для тех, кто готов ботать новое и разбираться глубоко:)

#Vacancy #Software #ProductManagement

Ну и картинка из брендбука нашей внутренней платформы разработки Spirit к предыдущему посту

UpTeam @ Tinkoff

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

1. Были ли в карьере кризисные моменты, когда хотелось бросить все? За счет чего удалось выйти из кризиса?
Да, у меня были кризисные моменты. Раньше это часто заканчивалось уходом из компаний, где я работал до этого. В Тинькофф у меня тоже были кризисы, но я их успешно проходил через нахождение новых смыслов и изменения зон ответственности. Например, когда я от онлайн привлечения перешел к развитию мобильного банка или уже стал отвечать за "Клиентские интерфейсы, маркетинг и вовлечение". Часть из этого я рассказывал в докладе на YaTalks
2. Какие ошибки в своем развитии вы совершали? (как карьерном, так и в рамках обучения)
У меня была ошибка в развитии на втором курсе МФТИ, когда я слишком расслабился, начал играть в онлайн-игры и чуть не вылетел из универа. Эта ситуация научила меня двум вещам:
- онлайн-игры - это зло (персонально для меня)
- нельзя останавливаться в своем развитии
С тех пор я не играю в компьютерные игры и постоянно занимаюсь самообучением
3. На что разрешаешь себе отвлекаться во время рабочего дня?
На общение с коллегами, изучение новых технологий, чтение whitepapers:)
4. Лидерам тоже свойственно постоянно сравнивать себя с другими и страдать от расстройства? С кем себя сравниваешь?
Я считаю, что человеку надо сравнивать себя с самим собой, но более ранней версией. Суть в том, чтобы увидеть diff и понять, а растешь ли ты как специалист, руководитель и просто человек:) Также можно найти примеры крутых ребят, на которых хотелось быть похожим. Например, мне персонально импонирует Jeff Dean
5. Какой самый нестандартный способ развития у тебя был?
Лучше всего я помню фейлы - неудавшиеся экзамены, собеседования, выступления. С учетом моей склонности к саморефлексии я вынес из этих моментов достаточно много.
6. Какой у тебя был самый большой факап в карьере и чему он научил?
До Тинькофф я вышел на роль исполняющего обязанности CTO в один стартап, который на бумаге выглядел красиво. Но под капотом все оказалось совсем не так как рассказывали фаундеры. Из этого я вынес то, что обязательно надо спрашивать на собеседовании "А что произошло с человеком, который был до меня на этой должности?":)
7. Как бороться с ленью? Когда вроде знаешь, что нужно развиваться, но все время откладываешь тот же курс или проект
Надо просто заниматься тем, что тебе нравится. Тогда лень приходит не так часто. Плюс отдельно надо уметь ловить work/life баланс и если энергии сейчас недостаточно, то заниматься задачами попроще.

P.S.
Кое-что из этого я рассказывал в подкасте с Андреем Смирновым "Как и зачем профессионалу сохранять мотивацию учиться всю жизнь"

#SelfDevelopment #Management #Leadership #Career

Найм в компанию и promotion внутри

Я достаточно много рассказываю про процессы найма в нашу компанию, а также роста внутри нее. Но кажется, что раньше я не писал подробнее про diff между ними, а стоило бы ... Основная разница между этими процессами в количестве информации для принятия решения и стоимости ошибки. А теперь давайте копнем глубже.

Найм
При найме в большую компанию часто существуют отдельные интервью на разные темы, которые кандидат проходит по очереди, а дальше ему выставляется грейд и зовут на фит интервью с командами. Разные этапы интервью дают разные сигналы, которые можно использовать для предсказания того, как кандидат будет работать после выхода на работу. Условно, если у нас есть три этапа:
- Алгоритмы и стрктуры данных
- Интервью по языку и платформе вокруг него
- Интервью по проектированию распределенной системы
То мы можем понять насколько хорошо у кандидата с hands-on experience по написанию кода, наколько хорошо он знает свой инструмент (язык и платформу) и может ли он дизайнить какое-то решение или ему надо специфицировать задачи до уровня напиши метод в этом классе, который будет забирать данные из вот этого API. Все эти сигналы позволяют снизить false positive ошибки (мы нанимаем слабого человека), которые в большой компании достаточно дорого стоят:
- С точки зрения потраченного времени - кандидату обычно требуется много времени вникнуть во внутреннюю специфику платформ, инструментов, процессов, систем, за которые отвечает его команда. Это приводит к тому, что обратная связь о том, что человек не тянет может приходить с запозданием
- С точки зрения вклада кандидата - иногда такие новички, находясь в состоянии неосознанной некомпетентности пишут такой код, который потом долго приносит "радость" другим членам команды
- С точки зрения бренда работадателя - никто не любит уходить с испытательного срока, а негативный фидбек распространяется лучше позитивного

В итоге, для повышения точности оценки и снижения false positive требуется проводить несколько секций. И если мы хотим минимизировать false positive мы получаем некоторое количество ошибок false negative (мы не нанимаем сильного человека) - и с этим приходится мирится (или уметь делать исключения по дополнительной информации).

Promotion внутри компании
Здесь уже история другая - для понимания стоит промотировать человека или нет есть очень много информации:
- Результаты его работы за предыдущие периоды времени (в виде оценок по performance review)
- Отзывы коллег (условный 360 если они собираются)
- Промо пакет (у нас это заявка в рамках нашего процесса Т-рост, про который я рассказывал подробнее здесь)
В итоге, тут информации для принятия решения достаточно много и его можно сделать взвешенно, опираясь на результаты работы и демонстрируемое поведение, а не прокси-метрики (как результаты интервью при найме). Поэтому мы при росте внутри профессии обычно и используем не аттестации с проведением интервью как при найме, а ориентируемся на результаты работы. Плюс если все сделать правильно, то сотруднику внутри можно подкидывать задачки посложнее и смотреть как он с ними справляется - этакая адаптивная сложность как в некоторых играх. Если он справляется с ними хорошо на протяжении некоторого времени, то promotion не заставит себя долго ждать, а если нет, то сотдник ничем особо не рискует.

P.S.
Если подводить итоги, то в этом посте я постарался объяснить почему
- Найм в крупную компанию выглядит как набор отдельных интервью
- Promotion в крупной компании выглядит как оценка результатов работы человека (а не ассемент)

Материалы на тему найма и промо
- Как нанимать технических руководителей
- Эволюция роли технического руководителя от инженера до CTO
- Как и куда развиваться, если ты уже Senior Software Engineer
- Варианты роста инженера, если он уже Senior
- Как развиваться, если ты уже Senior System Analyst
- Про performance review в командах разработки
- Как мотивировать разработчиков
- Трансформация роли CTO по мере роста компании

#HR #Career #Management #Software

Технологии @ Тинькофф

Мои коллеги сделали отличный раздел на нашем сайте, в котором рассказывается о технологиях внутри Тинькофф. Сейчас там уже есть развернутый рассказ про
- Sage - наша observability платформа, которая используется для централизованного сбора и анализа телеметрии всех сервисов компании. Предшественником был Splunk
- Kora - наш фреймворк для написания приложений на Java и Kotlin с упором на производительность, эффективность, прозрачность.
- Taiga UI - наша библиотека компонентов, возглавившая целое семейство проектов для комфортной и быстрой разработки приложений на Angular.
- Helicopter — вычислительная платформа с расширенными возможностями для совместной работы команд, которые занимаются исследованиями и операционализацией данных: построением аналитики, ETL-процессов, отчетов и data-приложений. Предшественником был Zeppelin

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

#Software #DistributedSystems #Engineering