Интервью по System Design — это обязательный этап собеседований в большие технологические компании уровня FAANG, по результатам которого принимается финальное решение о найме.

Но на русском языке почти нет материалов для комплексной подготовки!

Поэтому Валерий Бабушкин, Vice President, Data Science в Blockchainꓸcom, и Евгений Нижибицкий, Lead Machine Learning Engineer в AliExpress, создали свой авторский курс, где вы научитесь выстраивать сложные и масштабируемые архитектуры программных систем.

За 4 недели вы научитесь:
- собирать требования и оценивать нагрузку
- применять высокоуровневые схемы и модульный дизайн
- масштабировать и повышать отзывчивость систем
- создавать подсистемы для хранения данных, поиска и аналитики

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

Записывайтесь на курс по ссылке до 19 июня! Ждём вас!

Техника обучения Фейнмана

Универсальный алгоритм, который помогает вкатиться в любую сколь угодно сложную тему:

1️⃣Запишите все, что вы знаете о теме, как будто вы объясняете ее кому-то.
2️⃣Отметьте все пробелы в рассуждениях, и вернитесь к изучению темы, пока не закроете их.
3️⃣Переписывайте свое объяснение, заменяя сложные идеи более простыми, пока оно не станет очевидным.

А вообще, если вы не читали «Вы, конечно, шутите, мистер Фейнман», закрывайте Телегу, покупайте книгу, и, я гарантирую, это будет лучшее вложение вашего времени.

Вебинар про карьерный рост продактов

Если есть профессия с еще более беспорядочным набором ожиданий и отличием роли от компании к компании, чем тимлид, так это продакт. Где-то от тебя требуется быть мини-СЕО (материальная компенсация при этом забывает про «СЕО», но не забывает про «мини»). Где-то – ты слепо перемалываешь поставленные кем-то задачи в разработческий бэклог. А где-то – исследуешь, как принести ценность пользователям и бизнесу. Короче, разные ожидания, разные навыки, и совсем разные карьерные пути.

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

Мне нравится, что все спикеры – СРО, а, значит, успели и за свою карьеру повидать всякое, и других продактов вырастить:
— Сергей Ершов, CPO СберОбразования.
— Максим Гришак, CPO Домклик от Сбера, лидер направления небанковских сервисов в недвижимости.
— Женя Агеев, CPO в стриме «Государственные услуги» в ВТБ
— Игорь Мелех, Head of Рroduct в Ozon, Автор телеграм-канала «MVP из палок».

📆Дата: 13 июня, 19:00
👉Регистрация

Как использовать Definition of Ready

Старый, но хороший пост с кучей комментариев про то, что такое Definition of Ready, как он может вредить командам и как его трансформировать в полезный инструмент.

Вообще, Definition of Ready – это набор критериев, которые показывают, насколько задача готова к тому, чтобы ее брали в работу. Например, она должна быть декомпозирована до определенного размера, иметь определенную отметку от QA, или содержать в себе дизайн со всеми возможными граничными состояниями.

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

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

Чтобы Definition of Ready не причинял проблем, следуйте двум принципам:

- Не включайте в список критериев требования по 100% готовности чего-то до старта работы.
- Трактуйте DoR как набор рекомендаций, а не обязательных правил.

Лайв-разбор инцидентов

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

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


📆Дата: 15 июня, 19:00
👉Регистрация

Причины плохого перфоманса

1️⃣Сотрудник плохо перформит, потому что вы поставили его на неподходящую ему роль.
2️⃣Сотрудник только вышел на новую роль, на него свалилось много всего неизвестного, и он не справляется из-за переизбытка информации.
3️⃣Причины кроются где-то в личных или семейных событиях.
4️⃣У вас есть неявные ожидания от роли сотрудника, а он привык работать по-другому.
5️⃣Люди меняются, и роли, которые им подходили раньше, могут переставать подходить со временем.

“Анти-требования” для модели данных

Самый очевидный способ подойти к проработке модели данных – смотреть на ее сущности как на объекты реального мира, добавляя им атрибуты, которые имеют очевидный смысл. Например, “товар” в корзине интернет-магазина, состоит из названия, его описания, цены, количества приобретенных единиц и других похожих свойств. Недостаток такого подхода в том, что модели такого рода могут очень сильно разрастаться, их состояние зависит от кучи различных условий, и для корректного их обновления придется писать сложную логику.

Распилить модель правильным образом могут помочь “анти-требования”. Идея такая – вы формулируете фейковое бизнес-требование, влияюбщее на отношения атрибутов, и оцениваете его адекватность. Например, “Когда описание товара длиннее 5000 символов, его цена должна измениться на 20%”. Если требование звучит неадекватно – нет никакой необходимости держать эти атрибуты в рамках одной сущности. Если звучит адекватно – связь есть, нужно выделять в отдельную сущность.

Как убеждать людей, когда у вас нет административных рычагов

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

Challenges -> Concerns -> Problems -> Barriers

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

Ищут Тимлида в Облако Selectel.

Тимлид в Selectel это

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

Откликнуться можно тут
По вопросам можно писать сюда

Подробный обзор системы грейдов в Shopify

Shopify зарефакторили свою систему грейдов. Основные идеи следующие:

- Всего у инженеров восемь грейдов, от стажера до fellow.
- Каждый грейд разделен на пять сегментов по “mastery”. Mastery – это технические навыки и доменные знания, получаемые сотрудником по мере приобретения опыта.
- Mastery отдельно оценивается по пяти характеристикам: технические знания, решение задач, принятие решений, лидерство.
- Переход между уровнями не завязан на mastery. Это просто еще одна проекция, в рамках которой можно расти в зарплате, не беря на себя новую ответственность.

Вебинар от Otus про использование метрик для управления командой

Ребята из Otus проводят вебинар про то, как выстроить систему метрик для оценки эффективности работы разного типа команд. Обещают разобрать следующие темы:

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

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

📆Дата: 28 июня в 19:00 по Москве
👉Регистрация

Нативная интеграция информация о продукте www.otus.ru

Вторая часть обзора системы грейдов в Shopify

На прошлой неделе пост про новую систему грейдов в Shopify собрал под 300 комментариев. Давайте продолжим обсуждать!

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

Вторая часть обзора системы грейдов в Spotify

На прошлой неделе пост про новую систему грейдов в Shopify собрал под 300 комментариев. Давайте продолжим обсуждать!

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

Доклад на TeamLead Conf про импортозамещение

На этой неделе в Петербурге проходит конференция TeamLead Conf. Ребята из ГК «Астра», ветераны отечественного ПО, продукты которых внедрены на куче предприятий в разных отраслях, попросили нас рассказать об их докладе про то, как их процессы и системы внутренних сервисов помогают создавать продукты для импортозамещения и быстро адаптироваться к меняющемуся рынку. Если вы занимаетесь чем-то близким к импортозамещению, вам должно быть интересно.

Чтобы не заблудиться – 29 июня 16:30, «Зал Синий».

Три ошибки менеджеров-новичков

1️⃣Вы тратите большую часть своих усилий на менеджмент ваших сотрудников: их развитие, обратную связь, помощь в решении проблем и wellbeing. Но из-за этого вы забываете заниматься менеджментом других людей – руководителя, стейкхолдеров, ваших peers.
2️⃣Helicopter management – вы слишком трепетно относитесь к людям в своей команде, не даете им совершать ошибки, тратите слишком много собственного ресурса на поддержку их работоспособности, оберегаете от негативного фидбэка.
3️⃣Вы не мыслите системно. Если вам что-то не нравится в действии других людей, вы считаете их некомпетентными вместо того, чтобы попытаться понять, как окружающая среда могла привести их к принятым ими решениям.

Как можно жить без оценок задач

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

А вот, если что, выпуск Подлодки на эту же тему!