А вот еще один классный материал про найм. Лайвкодинг бесит. Алгоритмические задачи по большей части проверяют не скиллы человека, а то, насколько упорно он готовился к этому интервью. Что, если вместо написания кода, просить его читать?
📌Читать код – базовая задача, занимающая 95% времени программиста.
📌Читать гораздо быстрее чем писать, время проверки сокращается.
📌Кандидаты меньше стрессуют на таком задании, интервью менее искажается.

Вот какой процесс предлагает автор:
1️⃣Подготовить несколько задач вида «что выдаст этот код», от простого уровня к сложному.
2️⃣Опробовать эти сниппеты на тех, с кем вы уже работаете.
3️⃣Объяснить кандидату, что вы не проверяете его знания синтаксиса, не ставите дедлайнов, не ожидаете правильных результатов. Попросите его рассуждать так, будто он дебажит незнакомый код.
4️⃣Когда кандидат дает свой ответ, запустите этот код, и если результат отличается, попросите прокомментировать.

Три частых трудности начинающих тимлидов:
1️⃣Подозреваю, что есть инструменты, чтобы делать мою работу лучше, но я о них не знаю и не очень понимаю, где их достать;
2️⃣ Нелегко применять софты: быть открытым, уверенным, проявлять эмпатию.
3️⃣Тяжело даются one-on-one, фидбек и общение, особенно когда надо поговорить не про работу, а про что-то еще.

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

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

Держите гайд по тому, как стать техническим инфлюенсером. Несколько запомнившихся мыслей:
📌Большинство профессионально успешных людей не заметны в онлайне, не стоит верить своему пузырю.
📌Самая полезная метрика – количество людей, которые обращаются к тебе за советом.
📌Выбирайте самые топовые свои материалы и прорабатывайте для них сертезный план дистрибуции. Каналов получения новых читателей очень много.
📌Вы всегда можете присосаться к чужому каналу дистрибуции – например, написав гостевой блогпост (я тоже, если что, с радостью выложу ваши статьи)

Девять причин, по которым ежегодные performance review – зло:
1️⃣Они усиливают существующее несправедливое отношение к людям
2️⃣Они поощряют оставаться в общепринятых рамках ожиданий и не проявлять нестандартной инициативы
3️⃣Они подталкивают к тому, чтобы давать фидбэк только раз в год вместо того, чтобы делать это постоянно
4️⃣Они мешают росту сотрудников, особенно долгосрочному
5️⃣Они уменьшают чувство безопасности и провоцируют тревожность
6️⃣Они являются напоминанием, что менеджер контролирует все самое важное в жизни сотрудника
7️⃣Они очень сильно вырывают из работы
8️⃣Они не придают ценности командной работе, оценивая результаты человека в отрыве от нее
9️⃣Они не учитывают существование системных проблем в компаниях, и приравнивают следствия их существования к личным результатам людей

Если вы вынуждены применять performance review, то вот, что можно делать:
📌В явном виде отделяйте его от постоянного фидбэка
📌Уменьшайте влияние его результатов на штрафы или награды
📌Постоянно помните, что процесс поломанный
📌Старайтесь сделать их менее токсичными и не давайте себе и остальным сильно вовлекаться в процесс
📌При любой удобной ситуации убеждайте отказаться от них

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

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

Для тех, кто подумывает о том, чтобы искать работу Engineering Manager’ом где-то за рубежом, я собрал небольшую подборку ссылок. Пользуйтесь!
📰Серия статей “Cracking the Engineering Manager Interview”: часть 1, часть 2, часть 3, часть 4, часть 5
📰Статья от Calm про устройство их процесса найма
🎥Рассказ бывшего Engineering Director из Google про найм инжиниринг менеджеров
🎥Mock-интервью про то, как ставить цели инженерным командам
🎥Mock-интервью про то, как отвечать на вопрос “What’s your leadership philosophy”
🎥Mock-интервью про приоритизацию в команде

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

Часто бывает так, что в компании нанимают нового человека, но не могут нормально сформулировать ожидания от него. В статье предлагается интересный способ по их систематизации. Он основывается на разделении всех проблем, которые должен решать человек, на четыре кучки:
1️⃣ Использование известных проверенных решений (copy and paste)
2️⃣ Комбинация нескольких известных решений (mix and match)
3️⃣ Адаптация и кастомизация решений под контекст (adapt and customize)
4️⃣ Создание новых решений (invent)

Эти требования различаются для типов задач и контекстов их возникновения. Например, завести процесс онбординга новых разработчиков – довольно тривиальная задача в большинстве компаний, и попадает в область 1️⃣ или 2️⃣. Но вот в моем случае, о котором я раньше кратко рассказывал, она попала в область 4️⃣, и потребовала от меня совсем других компетенций и времени на реализацию.

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

Как бонус – автор для иллюстрации своих идей использует технику Wardley Mapping. Выглядит очень классно, я хочу попробовать вкатиться!

Держите неплохой список софт-скиллов, вокруг которых можно выстроить обсуждение роста инженеров. Мне понравилось в нем то, что вместо довольно абстрактного «коммуникация» выделяются более предметно-ориентированные навыки: «задавание хороших вопросов», «обсуждение сложных тем с разными сегментами слушателей», «общение со стейкхолдерами».

Пока все со страхом смотрят на проведение disaster recovery учений с отключением отдельных сервисов, Dropbox играет по-крупному, и отрубает целый дата-центр! В лонгриде ребята рассказывают про свою команду Disaster Recovery и ее путь от первых робких экспериментов с управляемыми падениями через 50-минутный downtime к выключению дата-центра без хоть сколько-то заметного влияния на доступность.

Кстати, если вам хочется больше технических материалов, подписывайтесь на рассылку Architecture Weekly Владимира Иванова, он делает отличную подборку статей!

Один из важных, но недооцененных навыков тимлида – умение управлять ожиданиями стейкхолдеров. От того, насколько хорошо вы умеете их вовлекать в проект, зависят и его шансы на успешное окончание, и ваши собственные перспективы роста в компании. Держите статью с несколькими техниками того, как работать со стейкхолдерами:
🤝Сделайте их своими партнерами – поймите, в чем конкретно интерес каждого стейкхолдера, и учтите его в своем плане.
🎯В явном виде обозначайте свои цели в виде outcomes, и придерживайтесь объективного подхода при приоритизации чьих-то хотелок.
📚Оперируйте фактами, а не саоим мнением – иначе любой более сеньорный стейкхолдер вас легко переспорит.

Тема стейкхолдер-менеджмента – прямо очень большая, и я как-нибудь сделаю подробный пост на эту тему. Если интересно – ставьте 👍, посмотрю на уровень интереса.

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

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

Что делать менеджеру менеджеров, которого волнует, чтобы проекты на уровне конкретных команд делались в срок, но который не хочет скатываться в микроменеджмент? В этой заметке предлагаются наборы инструментов для того, чтобы разобраться в ситуации, добавить в систему недостающие элементы и устранить возможные препятствия. Для привлечения внимания несколько конкретных техник:
📌Установить систему кроссфункциональных приоритетов, чтобы проект одной команды не останавливался из-за собственных планов другой
📌Провести Skip levels встречи с членами команд, чтобы понять их картину мира
📌Проверить наличие у команд сразу нескольких стейкхолдеров с разными запросами или других источников приоритетов, которые могут отвлекать их от основной задачи

#инструменты #люди

Требуется разработка, нанимать специалистов долго и дорого, а дедлайны горят?
Сервис brainskills.tech помогает разрабатывать IT-продукты без сдвига сроков и без сбоев в работе🔥

Brainskills.tech — аутстаффинг и аутсорсинг специалистов в области Data Science, AI и разработки:
🔺Разработка продуктов на базе open source стека
🔺Решение бизнес-задач с помощью искусственного интеллекта
🔺Решение задач автоматизированного сбора, хранения и анализа данных
🔺Разработка CV/NLP/RecSys инструментов с использованием глубоких нейронных сетей
🔺Поддержка, эксплуатация и мониторинг

✔️40 опытных разработчиков и дата саентистов
✔️Безрисковые 2 недели — вернем деньги на старте, если не устроил результат
✔️0 рублей — стоимость плана MVP по вашему проекту

Чтобы получить бесплатную консультацию, оставьте заявку на нашем сайте или напишите в telegram. Обсудим задачу и поможем сформулировать требования к проекту!

https://brainskills.tech/

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

#управление_компанией

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

Но если вы не Meta, и верите в то, что внутреннюю документацию в вашей компании надо улучшать, в статье рассказывается, как к этому подойти, определить цели, продать бизнесу, выбрать инструменты и внедрить в рабочие процессы. Все это – с фокусом на улучшение developer experience.

#техлидство

Разбор трех принципов работы с людьми из хорошей книги «The One Minute Manager»:
🎯Ставьте короткие и понятные цели
🙏Хвалите за хороший перфоманс
💬В случае плохого перфоманса давайте незамедлительный точный фидбэк

Каждый из принципов раскладывается на простые алгоритмы и разбирается на примерах. Если понравится – добавляйте и саму книгу в избранное, она стоит того!

#люди

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

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

В итоге команда выработала свой подход с двумя типами итераций: build iteration со скользящей продолжительностью для работы над конкретной пользовательской проблемой и refine iteration фиксированной продолжительности для багфиксов и закрытия техдолга.

#процессы

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

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

В Яндекс Практикуме есть курс “Управление командой для начинающих руководителей”. Это базовый набор инструментов, который позволит лучше разобраться в новой роли, увидеть свои недостатки как руководителя и выстроить работу команды.

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

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

Старт потока 19 мая

Зарегистрироваться на бесплатную вводную часть