Как организована разработка и архитектура, как собирают команды и какие особенности найма есть в международных компаниях — разберем вместе с Артемом Манченковым, Software Engineer в Microsoft, ex-Software Engineering Manager Delivery Club.
UnionVK
Материал подготовлен на основе онлайн-встречи UnionVK, сообщества текущих и бывших сотрудников группы компаний VK. Присоединяйся к комьюнити, если тоже являешься выпускником группы VK :)
А полную запись встречи можно посмотреть по ссылке на нашем YouTube канале.
Что такое инженерная культура?
Это набор практик и стандартов, которым следует команда или компания. Они определяют способ коммуникации, обмена опытом, разработки, поддержание качества продукта и многое другое.
Microsoft vs VK: первое впечатление
- сложный процесс интервью, по сравнению с VK
- акцент на обучении сотрудника
- восприятие стратегии компании
- безопасность превыше всего
- “инновационная черепаха”
- а когда начинать кодить?
Хайринг или как пережить все этапы
Путь в Microsoft
Основные этапы интервью
Каждый этап длится примерно час.
- Algorithms. Решение задачек по типу LeetCode на знание алгоритмов и структур данных, можно писать на любом языке.
- Design patterns / ООП. Вопросы и задачи на ООП и паттерны, также без привязки к языку, а возможно и без кодинга. После этого этапа скорее всего тебя будет ждать небольшой перерыв.
- System design. Классическая задача на построение полноценной системы для проверки знаний в области технологий, сетей, масштабирования, надёжности и нагрузки.
- Behavioral Interview. Вопросы по soft-skills: адаптация, команда, планирование, исполнение и прочее. Методика STAR приходит на помощь. Эту часть будет проводить не айтишник, а кто-то из бизнеса.
✅ Если ты ошибся, это не значит, что интервью провалено. Тебя могут взять на вакансию уровнем ниже.
Software Engineer в Microsoft: что общего с нашими "разработчиками"?
Модель поведения в Microsoft
Компания предоставляет советы по тому, как должен вести себя инженер.
- Individual contributions. Ценится независимый вклад. Инженер должен разбираться в проблемах, уметь довести задачу до конца, отвечать за результат.
- Use work of others. От сотрудника ожидают, что он будет использовать готовые решения, привлекать помощь людей, находить способы оптимизации.
- Help others. Необходимо быть готовым прийти на помощь, задавать вопросы, высказывать мнение. То же самое можно ждать и от коллег.
Growth mindset
- я без понятия, как это делать, на данный момент
- я не боюсь, что это не сработает
- эту проблему так легко не исправить, но мы найдём способ
- фокус на результат
- делаю решение на века для проверки гипотезы
Этого компания ожидает не только от инженеров, но и от сотрудников вообще.
Technical diversity
В Delivery Club я писал код на PHP/Golang, собеседование в Microsoft проходил на Python, сейчас пишу код на C# и не только.
Microsoft использует разные технологии. Если инженер понимает, что реализовать задачу будет проще с помощью другого, хоть и менее привычного инструмента, команда не станет протестовать. К тому же, техническое разнообразие расширяет кругозор сотрудников.
❗ Technical diversity ≠ Full-stack developer
Организация vs VK-шный бизнес-юнит
Microsoft делится на несколько структур. Я расскажу о такой структуре, как организация, которая аналогична бизнес-юниту VK.
Отличия между организациями могут быть во всём: свои мероприятия, наборы стандартов, карьерные сетки и набор компетенций.
А вот что есть общего:
- performance review
- развитие карьеры и навыков
- прозрачный open source
- внутренний StackOverFlow
- отличный work-life balance
Существует много возможностей для обмена опытом для инженеров:
- tech talks
- office hours
- architecture reviews
- product demo
- learning day / week
В Microsoft развита культура наставничества. Сотрудники пользуются правилом: “Помогли тебе — помоги другому”.
- early in career
- правило level+2
- карьерные гайды
Команда: инженерные процессы и практики
Работай, как тебе удобно, главное — решать задачи. В Microsoft команды ни к чему не привязаны, режим работы будет зависеть от самих участников.
Процесс онбординга
- есть buddy, который тебе поможет
- общий онбординг
- локальный онбординг
- тренинги и стандарты работы
- bootcamp по технологиям и языкам Компания отправляет тебя на две недели на обучение, и не ждёт в это время, что ты будешь что-то делать для команды
Полный “agile”
Спринты, планирование, оценка — всё это используется по желанию, осознанно и только тогда, когда необходимо. Предоставляется свобода в выборе подходов.
Например, наша команда отказалась на какое-то время от дейликов, потому что каждый инженер занимался абсолютно разными вещами.
Из-за такой политики могут возникать проблемы: не всегда задачи будут детально описаны и структурированы.
Жизнь без тимлида
В Microsoft менеджеры являются замещающим звеном для роли тимлида. Они могут не участвовать в выборе технологий. Зона ответственности менеджера больше, он также занимается вопросами бюджета и people менеджментом, помогает найти связь с другими специалистами.
Документная культура
В нашей компании много документации. Сначала инженеры готовят документы на архитектуру, функционал, и только потом начинается поиск решения.
Если возникает необходимость, мы пишем инструкции.
Для бизнес-задач используется one pager.
При этом компания очень адаптивна. Можно предложить новый подход к ведению документации.
Код ревью
Здесь inner-source процветает. У нас нет чек-листов и стандартов для ревью, всё зависит от конкретной команды. Короче говоря, расслабленный формат, если что, каждый готов поделиться рекомендацией.
Обычно назначаются ответственные команды за отдельный проект. Они и отвечают за ревью.
А где у нас QA?
В нашей организации их просто нет, вообще.
- Пишем ли мы тесты? — Да.
- Проверяем на preproduction? — Конечно.
- Строим правильный мониторинг? — Естественно.
- Есть ли у нас баги? — Есть.
Мы проверяем всё сами, и в этом есть смысл. QA рассматривается как дополнительный шаг после выполненной работы.
Архитектура и разработка
- базируемся на “наших” технологиях Стараемся упаковать их в ресурсы, доступные в Microsoft Azure
- максимальное переиспользование
- изучаем разные способы
- следуем правилам PoC / MVP
- есть свой фреймворк, как и у всех нормальных компаний
Подготовка к production
Здесь возникают сложности. Так как никакой сервис не может просто взять и релизнуться сам. Компания большая, и риски, соответственно, тоже. Перед релизом проект проходит следующие этапы проверки:
- architecture review
- threat model
- security review
- compliance review
- private review
- public review
- global availability
Этот процесс может затянуться на несколько месяцев.
Релизы и мониторинг
- единый стандарт деплоев и единый центр мониторинга, если это позволяет сервис
- полная автоматизация
- никакой эксплуатации и админов
- команда несёт ответственность
Когда что-то пошло не так…
Мониторинг в основном автоматизирован. В случае ошибки приходят уведомления, вызывается команда, отвечающая за проект.
- центр менеджмента инцидентов
- синхронизация с командами
- уровни тревоги
- primary и backup on-call инженеры
- Troubleshooting Guide спешат на помощь Мы пишем их сами, это очень полезно
✅ Такая инженерная культура даёт потрясающий инструмент — команду, которая может сама решить любую проблему и научить других.
Что можно перенять
- Technical Diversity
- регулярные хакатоны / FHL
- больше свободы командам: методы работы, релизы, решения
- культура наставничества
- прозрачные карьерные гайды
Инженерная культура компании может значительно варьироваться в зависимости от конкретной команды и организации. Она играет важную роль в успехе компании и эффективности работы команды. Поэтому важно уделять достаточное внимание её развитию, поддерживать атмосферу доверия и сотрудничества, а также поощрять постоянное обучение и саморазвитие сотрудников.