Привет, Хабр! На полях конференции Yandex.Talks взял интервью у Александра Поломодова, который за 7 лет вырос в Тинькофф до технического директора. Александр рассказал про технологический бум компании благодаря вовремя принятым решениям, возможностям роста, упомянул о важных качествах инженера.

Пользуясь возможностью задать любой вопрос я наконец-то узнал зачем директору, в подчинение которого под тысячу человек создавать, популяризировать и лично проводить System Design Интервью.

---

Главная конференция Яндекса Yandex.Talks проходила 2 дня в начале декабря в центре Москвы. Первый был больше технический, второй с менеджерским уклоном.

Атмосфера конференции выдалась дружеской. Между докладами получалось много общаться и выигрывать мерч)

Это был мой первый опыт проведения интервью. Сама идея стала зарождаться после HighLoad++, на котором познакомился с многими интересными людьми и узнал о Yatalks. Камеры, стойки, свет, микрофоны - ничего такого в наличие у меня не было. Зато было жгучее желание взять интервью) В ход пошли подручные средства - телефон и "вибрирующая" тринога, которая по итогу постоянно сбивала автофокус... О важности звука слышал и ранее. За день до старта успел выбрать и оформить удобные переносные микрофоны.

По итогу дня получилось взять целых 3 интервью. В этом посте хотел бы сфокусироваться на первом собеседнике - Александре Поломодове.

Интервью вдали от всех

С Александром я познакомился заочно. В процессе обсуждения его статьи - очередного разбора задачи для System Design интервью. Лично встретились на упомянутом HighLoad++. Но времени для общения тогда не было.

Зато нашлось сейчас. Я не знаю до конца как это работает. Я просто спрашивал собеседников об интервью. И они просто соглашались :) Хотя, наверное, были уставшие после общения, выступлений.

Думаю, что принцип:

Нормально делай, нормально будет

работает и в этой сфере. Я просто делал, что считал нужным - подготовил перечисленное оборудование. Этот необходимый минимум для съёмки и записи. Подготовил список вопросов. Сидел до ночи, составлял. Какие-то вопросы выделялись в общие для всех спикеров, с кем хотел пообщаться. Какие-то оставались персональными исходя из моего знания человека, его профессиональной ориентации.

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

Поставил триногу на стол, закрепил телефон, раздал микрофоны. Всё включил. Попереживал за то - пишется ли видео и звук. Хотя и видел, что всё горит нужным цветом, не покидало сомнение "а точно ли работает?..."

Сделали проверку связи и поехали.

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

Наверное, самый лучший язык - тот, который ты знаешь. Тот, который подходит для решения бизнес-задач. Он может варьироваться. Это может быть java, golang, C++, .... На некотором уровне инженера кажется что ему должен быть важен не сам язык, а те инженерные практики которые он умеет. То есть, он пишет не на языке, а с использованием языка.

Важны инженерные практики, которыми владеет специалист

Поэтому мы ждём, что высокоуровневые инженеры смогут писать на том языке, который нужен будет компании.

То есть, то самое, что важна предметная область, а язык - это уже что-то второе?

Ну, скорее, нужно быть хорошим инженером:

• Уметь писать код

• Знать алгоритмы, структуры данных

• Уметь проектировать сервисы

Болеть за тот продукт, который ты делаешь. Выполняя все эти требования мы считаем, что язык ты сможешь подтянуть. Например, ты пишешь на Scala, а какой-то кусочек нужно сделать более оптимальны. И ты можешь не ждать пока тебе в команду найдут какого-то избранного человека на этом языке, а сам сесть и разобраться.

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

И всегда помогут коллеги по цеху.

Да, так оно и есть.

Александр, спасибо большое. Вопрос по технологиям. Тинькофф считается технологичной компанией. Наверное, нету ни одного специалиста, который не знает о Тинькофф. За счёт каких технологий, практик разработки и формирования команд получилось так хорошо выстрелить в последнее время?

Мне кажется, что Тинькофф изначально знали за продукт для клиента. Удобный, понятный, приятный в использовании. В какой-то момент мы поняли, что для того чтобы делать такой продукт мы должны не просто брать коробки и делать свои продукты поверх них. А нужна собственная разработка. Нужно слезать, например, с Siebel на собственную CRM систему. В общем, нужно писать много своего кода.

В какой-то момент стало ясно что писать его без какой-то платформенной составляющей, поверх которой ты можешь сделать свои бизнес фичи, дорого и не очень эффективно. Продукты получаются разного уровня качества. С тех пор мы достаточно много сил вложили в развитие нашей внутренней платформы разработки. Этим занимался Игорь Маслов - руководитель технологических платформ. И много ребят у него этому очень много времени посвятили. За счёт такой внутренней платформы начали поднимать общий технологический уровень продуктов. За счёт того, что эти продукты со своих кастомных решений переезжают на обще технологические.

Плюс, мы много вкладывали в ML, AI. У нас сотни разработчиков, которые работают над этим. То есть, там тоже неплохой буст. Часть продуктов которые у нас особо хорошо получились теперь можно пощупать и снаружи:

• VoiceKit

• Sage - платформа для мониторинга

• Библиотека для предсказания временных рядов

• Тинькофф мессендежр

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

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

Да. Если вспомнить, что банк начинался в 2006 году. Дальше постепенно развивался. Как-раз бизнес вещи проще запускать на коробочный решениях. Потому что у тебя часто нету большой IT команды. У тебя нету больших IT бюджетов. Ты берёшь коробочные решения, соединяешь их как-то, делаешь продукт. А дальше у тебя появляется история, что стандартные вендорские коробки заточены под какие-то процессы часто не очень подходящие под цифровой банк без отделений. Ты начинаешь пилить собственные решения. В какой момент этих собственных решений становится больше, чем коробочных.

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

Здорово. Меня интересует тема ещё одной твоей деятельности. Помимо большого управления... сколько у тебя в отделах? 1000 человек, по-моему. Ты ещё находишь время для System Design. Я смотрел твои видео, где ты даёшь структуру. Вот вчера посмотрел другое видео с неких курсов. И был удивлён, потому что привык к твоим чётким пунктам, к рисованию схем, оценки кандидатов по разным параметрам.

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

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

Соответственно, процесс найма мы стали причёсывать как раз когда к нам пришёл Игорь Маслов. Он этим занялся. И появились полноценные отдельные интервью, состоящие из секций. Дефолтный набор секций в интервью для software development инженера:

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

2. Язык. Это java, scala, python, golang, неважно. Тот язык, который инженер считает своим основным.

3. И это System Design.

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

Сделать пул задачек побольше. Я себе забрал эту деятельность и стал курировать секцию. Ну и постепенно причёсывал внутри. Например, в прошлом году я провёл 199 интервью.

199. Ещё бы одно)

И было бы 200, да) Больше половины, наверное 2/3, был System Design интервью. Мне просто нравится проектирование. Это первое. Второе - я вижу в этом value. Потому что к нам, действительно, приходят более подкованный кандидаты. То есть, ты в среднем не ухудшаешь уровень инженеров компании. А может быть даже увеличиваешь. Если выставляешь определённые критерии для тех кто к тебе приходит.

Я видел определённые проблемы в том, что многие кандидаты может быть и умеют проектировать, но за счёт того что никогда не делали это структурно и в ограниченное время, они не могут себя проявить. Ты достаточно много времени на собеседование можешь обсуждать, объяснять что это за тип интервью, что нужно отвечать. Короче, свои ожидания. Я понял, что если публично сколько-то раз показать примеры, то те люди которые умеют проектировать, им будет проще пройти интервью. Показать, продемонстрировать свои умения. А тем кто не умеет, они может быть заинтересуются этой темой и пойдут ботать теорию.

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

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

Умел проектировать, да.

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

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

Мне нравится подход, который описан в книжке Вилла Ларсона "Staff Engineer”. Про то что у тебя высокого уровня инженеры - это, по факту, те люди, которые могут исполнять разные роли. Эти роли могут быть, например, архитектор, техлид. Это может быть роль такого некоторого пожарного, который приходит и помогает какие-то очень сложные задачи сделать, которые команда сама по тем или причинам не может сделать.

Ну и сейчас мы склоняемся к тому, что как-раз мы людей, которые хотят исполнять роль архитектора или тех лида, проводим по стандартным секциям - алгоритмы, язык, system design. И даём ещё четвёртую секцию. Мы про неё пока ещё не рассказывали публично. Это архитектура и процессы разработки. И по факту мы обсуждаем technical leadership.

Это секция похожа на менеджмент для тимлидов. Это история про то, как кандидат тянул какие-то крупные проекты в роли архитектора. Или как он инженерные практики и процессы в команде улучшал. И часто там не требуется быть менеджером. Может быть, project менеджер. А ты за техническую составляющую отвечаешь. Нам важно понимать, что кандидат умеет работать с архитектурными артефактами. Например, писать rfc. Проходить архитектурное ревью. Аргументировать свою точку зрения не в формате "я тут самый главный сторожил". А аргументировано.

Тезисно, по делу

Да. Мы пробегаемся по опыту кандидата. Дальше мы ещё обсуждаем какие-то модельные ситуации. И потом с кандидатом общаемся. Он задаёт вопросы интервьюеру. Узнаем, что он хочет узнать. И мы на это всё дело смотрим и дальше оцениваем насколько он матчится в наши ожидания от роли архитектора или тех лида внутри компании. Но это не отдельная какая-то ветка развития. То есть, инженеры туда дорастают, когда становятся очень крутыми

Здорово. Я помню собеседовался в Тинькофф 4 года назад и там ещё, по-моему, не было таких выделенных секций. У меня было 3 часа. Собеседовали три специалиста. Тогда ещё всё было вместе. Про язык полтора часа. Была задачка с битовыми операция алгоритмическая. Ну и архитектурная небольшая. Наверное, после этого Игорь пришёл.

Ну да. 4 года назад как раз это всё только начиналось. В начале 2020 года мы начали это всё причёсывать.

Сейчас когда с hr созваниваемся, уже рассказывает об этих секциях. Всё уже чётко, по полочкам.

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

Я, кстати, рассказывал ещё про траблшутинг для sre инженеров

Да, я смотрел это видео и почему вы убрали в компании секцию System Design от них - потому что им тяжело и то и то тянуть.

Недавно, кстати, было открытое интервью по траблшутингу. Я на devops conf проводил его.

Я смотрел System Design. А это что-то новенькое.

Относительно недавно в моём Telegram канале был анонс. Вот мы там с Салихом Фахрутдиновым решали задачку. Я показал как это выглядит у нас - траблшутинг для sre инженеров. Про то, что мы не вместе проектируем что-то новое. Скорее, у нас есть какая-то система. Я показал архитектуру этой системы, описал работоспособность. А потом мы стартанули инцидент. Я описывал симптомы, что не работает. И дальше Салих пытался понять что, как, как починить. Вроде, получилось интересно.

Да, спасибо Александр! Очень интересно рассказал. Хочется узнать как Тинькофф заботится о разработчиках, о сотрудниках. То есть, вот прошёл человек такой фильтр, прошёл испытательный срок. Работает. Как компания вообще бережёт? Или говорит "Всем работать после работы"?

Я приблизительно понял вопрос. Что компания даёт за работу на неё и прохождение такого отбора. На самом деле, эта стандартная история с зарплатой. Условия по ТК РФ. 3 дополнительных дня за, по идее, ненормированный рабочий день. Организация непрерывного цикла. В сервисах, которые должны всегда работать.

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

Я тогда ездил на "Водный стадион".

"Водный стадион" у нас останется. Меня с частью моих команд отправили на Белорусскую. Это в 5ти минутах от кольцевого выхода с Белорусской. Как-раз сегодня читал письмо, что с завтрашнего дня открывается фитнес. На четвёртом этаже. На третьем этаже есть кухня. Можешь спуститься позавтракать утром. В обед пообедать. Всё удобно. Как это модно называется - концепция город в городе.

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

Плюс, у нас есть такая интересная штука как Тинькофф рост процесс. Стандартный процесс роста сотрудников выглядит обычно так - сотрудник приходит и говорит "я хочу большую зарплату". Дальше руководитель оценивать насколько сотрудник ему ценен, надо ли удерживать. Когда был последний раз рост зарплаты. А если надо удерживать, то ему нужно придумать причину, почему Вася уже, условно говоря, не просто условный middle, а middle+ или сеньор. Хотя, это может быть высосано из пальца.

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

1. Он помог затянуть сложный продукт

2. Законтрибьютил много в профессию

3. Или в какие-то платформенные решения

Что такое офигенное сделал. Сотрудник может подать эту заявку указав набор крутых результатов, которые раскладываются по определённой матрицы sde, которая даже не про конкретные скилы, а, скорее, про:

• Скоп его обязанностей

• Impact

• Improvement - что он улучшал

• Про complexity - насколько сложные задачи

По такой матрице. И указать с кем он это делал, чтобы получить фидбэк. Дальше эта заявка проходит через жернова. Все пишут фидбек - ревьювят что он написал, попадает на лидов профессии. Я чуть раньше говорил что у нас профессия - это объединение специалистов в рамках одного стека. Например, JAVA разработчики. Лиды профессии - это обычно высокоуровневые инженеры, которые пишут на Java. Которые контрибьютят:

• В профессию

• В матрицу

• В интервью

• В общие библиотеки

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

• Что-то крутое

• В сложном домене

• Что приносит много пользы для компании

Ты можешь, конечно, выучить ещё один язык. Или ты можешь погружаться в теоретические дебри. Но за это плюшки не дают. Важен тот результат, который ты принёс. Мне кажется, что это достаточно такая нетривиальная история. Знаю не так много компаний, где применяется похожий подход.

Что ещё интересного с точки зрения плюшек для сотрудника. Есть участия в конференциях, обучении и так далее. Мы, на самом деле, уделяем этому много внимания. Есть такая история, похожая на анекдот. Когда люди говорят "вот он пойдёт учиться и уйдёт от нас". И дальше представьте что он не пойдёт учиться и останется с нами.

Мы вкладываем в развитие людей.

Да, не боитесь давать

Да. Мы, на самом деле, много берём людей с университетов. Со студенческой скамьи, через стажировки. У нас есть программа. И вот буквально в понедельник я ездил в МФТИ, который я лет 20 назад я на первом или на втором курсе был. Рассказывал как у нас внутри работается. На самом деле, я рассказывал про современные процессы разработки программного обеспечения. С примерами из Тинькофф. Это реально даёт хороший поток ребят, которые обычно обладают неплохим фундаментальным образованием.

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

Ты как точка входа. Как первая карьера. Если они видят хорошие отношения, соответственно, хочется работать в такой компани.

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

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

То есть, человек видит - я работаю, даю импакт. Делаю бизнес задачи или технологические. И вот чёткая матрица по оценки...

Да, есть рост по ветке индивидуального контрибьютора. В какой-то момент, когда ты дорастаешь, например, понимаешь что тебе хочется отвечать за команду - часто у тебя есть такая возможность. Потому что у нас есть определённая нехватка людей. Как раз на тимлидовых позициях. Когда ты ведущий разработчик достаточно сказать: "А я хочу с командой тоже работать".

Есть и курсы внутри и профессия. Ты можешь понятным образом расти дальше. Есть возможность сделать горизонтальный шифт. Например, у меня несколько разработчиков стали техническими продакт менеджерами в определенном домене. Стали отвечать за команду. Но не с позиции тимлида. А скорее с позиции - что команда должна делать. Например, это команда надёжности в мобильном банке. Там был технический продакт скорее из sre и аналитиков. Который прошёл несколько ролей. А потом ему нужна была помощь. Мы взяли тимлида команды. И он говорит: "А я хочу roadmap написать - какие фичи будем делать в этом техническом домене". И он свичнулся в эту позицию. Часть разработчиков могут вообще в бизнес уходить.

Выбор есть

Да, выбор есть. Главное понять, что сам хочешь. Вот так вот.

Продолжение следует...

----

Подсчитал, что для оформления первых 7 минут интервью потратил 1 час. Потом было побыстрее. В этом посте описал первые 30 минут. Поделитесь, пожалуйста, мнением - стоит ли дальше делать такое текстовое описание? Насколько зашёл сам материал, оформление?

Мой канал об IT, встречах сообществ, программистских наработках, интервью - Владимир в IT

Мой канал по подготовке к System Design Interview - System Design World

Удачи!