Как разработчикам «живется» в Тинькофф

Тинькофф занял 3-е место в новом рейтинге лучших работодателей России журнала Forbes Russia, поднявшись за год с 25 места. В группе 25641 сотрудник (с учетом Домашнего колл-центра Тинькофф), выручка за прошлый год составила 164,96 млрд рублей. Средний возраст сотрудников — 28 лет, выяснил Forbes.

Юлия Царева, руководитель фронтенд-разработки в Тинькофф Бизнес, в интервью Хабр Карьере рассказала о жизни разработчиков в Тинькофф. Как происходит найм, онбординг новичков и развитие сотрудников, как устроена работа в командах и сам процесс разработки. Юлия поделилась инсайтами о корпоративной жизни, условиях работы и способами борьбы с выгоранием. Честно, без купюр и банальных фраз в стиле “у нас бесплатные печеньки и кофе”. Публикуем самое интересное из ответов с “Хабра”.

Ответы актуальны на октябрь 2020 года, Тинькофф активно развивается и меняется, поэтому некоторые детали описания могут немного расходиться с опытом новичков.

Какой в вашей компании сложился рабочий график и какое отношение к переработкам?

Стандартный рабочий день с 10:00 до 19:00. Так работает большинство коллег. Начало рабочего дня можно сдвинуть — начинать и заканчивать пораньше или попозже. Например, кто-то выбрал работать с 9:00 или, наоборот, с 11:00.

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

Какие бытовые условия ждут нового сотрудника на рабочем месте?

Два больших монитора, компьютер на выбор PC или Mac. Раньше это были стационарные PC и Mac Mini, сейчас в основном ноутбуки — после самоизоляции стали больше ценить мобильность, возможность работать на том же устройстве из дома. Стол, стул, тумбочка — стандартные :)

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

По периметру панорамные окна — это что касается естественного освещения. Конечно, окон на всех не хватает, есть и искусственное освещение. В офисе есть бесплатный спортзал (тренажеры и групповые занятия), есть тренировки по футболу и некоторым другим видам спорта, Тинькофф Кафе, где можно пообедать бесплатно (и вкусно!), но во время пандемии оно закрыто.

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

Есть ли возможность удаленной работы?

С марта мы все на удалёнке. Можно выйти и в офис, если есть необходимость. Как будет дальше — пока сложно сказать, вероятно частично будет удалёнка, частично — работа в офисе.

До какой должности может дорасти разработчик и какой уровень жизни он сможет себе позволить на этом месте?

Это сложный вопрос: у нас нет какого-то официального предела, дальше которого нельзя расти. Разработчик может прокачивать хард скилы, чтобы стать старшим разработчиком, ведущим разработчиком, техлидом команды, архитектором — это техническая ветка. Кто-то предпочитает управленческую ветку — можно стать тимлидом, юнит-лидом, функциональным руководителем (например, руководителем бэкендеров в такой-то бизнес-линии, ведь у нас матричная структура), CTO бизнес-линии. Кто-то переходит в бизнес: становится продактом или бизнес-лидером направления.

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

Какой социальный пакет получают сотрудники?

Мы предоставляем ДМС со стоматологией, скидки на ДМС для родственников, страховка от несчастных случаев, корпоративные скидки на обучение иностранным языкам.

Есть свой спортзал с сауной. В «допандемийное» время была бесплатная столовая для сотрудников, надеемся, что скоро сможем и её посещать. Коллегам компания оплачивает 50% парковки. И ещё множество спецпредложений и скидок, но это уже не совсем соцпакет.

Какие бонусы, премии и компенсации предусмотрены в компании?

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

Есть и бонусы за разные дополнительные активности — рекомендации друзей, участие в конференциях, написание статей, Open Source и многое другое. Это приятно — ты вроде бы делаешь что-то, что интересно и тебе, и компании — развиваешь личный бренд, например. А потом получаешь новый айфон или что-то еще.

Какие есть перспективы для образования и личного развития у сотрудников?

Есть доступ к обучающим материалам — корпоративные аккаунты на egghead, Angular University и т. п. Есть библиотека — книги бумажные и электронные, пользуемся через бота-библиотекаря в слаке, там же можно заказать новую книгу, ее купят и добавят.

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

Также у нас есть свой тренинг-центр, который готовит различные учебные программы: курсы для тимлидов и других управленцев, тренинги по публичным выступлениям и переговорам, разбор управленческих кейсов (например, как давать обратную связь, как проводить один на один и т. п.). Иногда после работы проводятся и тренинги на отвлеченные темы — про work-life balance, экологию, здоровое питание и т. п.

Ну и, конечно, посещение профильных конференций, куда же без этого. Иногда даже зарубежные. Мне, например, удалось побывать на AngularConnect в Лондоне.

Что касается процессов, то мы практикуем постановку ИПР — индивидуальных планов развития. Обычно тимлид или куратор сотрудника помогает ему составить такой план. Цели выбираем «на вырост» и при этом применимые в работе, ну и по SMART.

Во сколько этапов проходит найм и что на них ожидает соискателя?

Чаще всего три этапа: телефонный мини-опросник и две встречи. Первая встреча — техническая, вторая — с командами. На технической встрече кандидат встречается с двумя интервьюерами. Они могут быть из разных команд и даже бизнес-линий, не обязательно именно с ними предстоит работать в будущем. Здесь идея в том, что мы нанимаем человека в первую очередь в компанию, а не на конкретный проект (в конце концов, проекты можно и менять, расти, стартовать новые).

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

Даете ли вы тестовое задание кандидатам? Как оно устроено?

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

Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?

Так чтобы сразу выкинуть — не знаю… Может быть токсичность. Если уже на собеседовании человек грубит или ведет себя не адекватно, то нам точно не по пути. Высокомерное, презрительное отношение к бывшим коллегам тоже не одобряю. Ну такое — все дураки, один я молодец.

Как происходит онбординг нового сотрудника?

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

На уровне бизнес-линий есть свои дополнительные материалы. Например, у нас в Тинькофф Бизнес есть чеклист, в котором описаны основные действия для тимлида / ментора и для самого нового сотрудника. Тимлид должен добавить новичка в определенные чаты, что-то рассказать, с кем-то познакомить. Для новичка описано, какие доступы проверить, какое ПО поставить, есть «гид» по полезным каналам в слаке и т. п. Когда все действия из чеклиста выполнены, новый коллега готов к работе.

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

Каковы размеры и структуры команд?

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

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

Команды разные по размеру, в среднем 4-6 человек (до 10). Слишком большие команды стараемся не делать.

Кто чаще возглавляет команды — продуктовый специалист или технический?

Команду возглавляет тимлид — это технический специалист, разработчик или тестировщик. Тимлид отвечает за техническую составляющую проекта и за людей (мотивацию, развитие). Продуктовые специалисты отвечают за бизнес-составляющую продукта. Конечно, при оценке людей их мнение тоже важно и учитывается. Вообще, мы практикуем опросы 360. Но именно руководит командой всё же тимлид.

Как часто люди меняют команды?

У нас нет жестких установок на этот счёт, мы не говорим «не чаще, чем в N месяцев» или «нельзя работать в команде дольше, чем N лет». Человек может сам инициировать смену команды — например, если устал, засиделся, хочет попробовать что-то новое, новую роль, новую область. Это решается с непосредственным руководителем. Мы всегда в таких случаях идем навстречу.

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

Что важнее, софт-скиллы или хард-скиллы?

Нужен баланс, сомневаюсь, что кто-то может ответить по-другому :) Я видела технически прокачанных ребят, которые не могли сработаться с коллегами и заказчиками. Иногда таким людям можно найти применение — особые сложные задачи + лид или коллега, который берет на себя остальное общение. Ну и давать фидбек, конечно, чтобы человек понимал, чего от него ждут.

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

Как много собраний у вас проводится? Есть ли особые подходы к ним?

Здесь очень многое зависит от команды. Но если наметить широкими мазками, то как-то так:

Также бывают более узкоспециализированные обучающие встречи — про CI для фронтов, о производительности веба, о настройке метрик и алертов. Конечно, ребята ходят туда по желанию. Все значимые встречи записываются, можно посмотреть видео позже.

Отдельно я бы выделила митапы и воркшопы. Например, мы проводим митап SME Tech, это внутренний технический митап для всего IT Тинькофф Бизнес. Они кросс-функциональные — там и бэкендеры, и фронты, и мобилка, и тестирование. Зовем коллег из других бизнес-линий, чтобы лучше узнать о банковских системах, ну и делимся своими наработками. Также сейчас готовим внутренний воркшоп по ML — на одном из митапов был доклад о применении ML на фронте. Выяснилось, что тема интересна, решили сделать более практический разбор.

Как вы боретесь с выгоранием сотрудников?

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

Наш тренинг-центр проводит лекции / воркшопы о выгорании и work-life balance, туда может записаться любой желающий. Есть даже лайф-коучи! Опять же, тренинг-центр проводит обучение лидов и прочих руководителей, где выгоранию сотрудников уделяется особое внимание: как заметить, как предотвратить.

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

Какие языки, фреймворки и библиотеки используются на проекте?

Мы пишем на TypeScript (с 2015 года, я бы сказала, что мы перешли на TypeScript еще когда это не было так популярно как сейчас, и ни разу не пожалели).

Фреймворк — Angular. Стараемся поддерживать в своих проектах последние версии, сейчас это 9 и 10. Также у нас в Тинькофф есть проекты на React, но не в Тинькофф Бизнес. Соотношение фреймворков у нас примерно 50 на 50. У такого двоевластия фреймворков есть свои плюсы, но это уже выходит за рамки данного вопроса.

В качестве стейт-менеджера используем NGRX, также ресерчим Akita.

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

Для тестов используем Jest, Cypress.

Какая у вас принята политика код-ревью?

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

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

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

А еще у нас есть сайт с разными метриками по разработке, мы называем его «геймификация», потому что там есть и разные рейтинги. Так вот, там есть ТОП ревьюеров — общий + можно посмотреть, кто топ-ревьюер в команде, кто кого чаще ревьюит, выявить какие-то антипаттерны.

Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

Как известно, легаси-код — код, написанный другими разработчиками ;) В этом смысле он есть… про процент затрудняюсь ответить. Есть проекты, которые находятся на стадии поддержки без активной разработки, а есть — где всё с нуля написано недавно.

Мне кажется, что здесь важен не процент, а то, как устроена работа с техническим долгом и вообще техническими фичами. У нас есть договоренность с бизнесом, что команда может 20% времени тратить на технические задачи. Дальше сама команда (вместе со своим техлидом) решает, что надо делать — что-то отрефакторить, поресерчить что-то новое или затащить известную техническую фичу.

Возможно, будет уместно еще про технические фичи рассказать. У нас в Тинькофф Бизнес несколько десятков приложений. Когда есть техническая фича, которую надо раскатывать на активные приложения, мы заводим эпик в Jira и заводим её на специальном дашборде с внедрением технических фич. Там каждая команда может видеть, что у них еще не сделано, и выбрать самое актуальное для них (перейти на Angular 10, внедрить бюджеты сборки и т. п.)