Собеседования глазами инженера

Начнем с предлагаемых автором принципов хорошего собеседования. Интервью должны:

👉Дифференцировать кандидатов, помогая отличать опытного сеньора от волка с AI под рукой.
👉Быть прозрачными, отражая фактические должностные обязанности, а не синтетические задачи.
👉Смотреть в перспективе, отдавая предпочтение соискателям, которые хорошо впишутся в команду на годы вперед.
👉Экономить время обеих сторон.
👉Строиться на уважении к соискателю.
👉Помогать оценить наличие инженерного вкуса.

Этим принципам отвечают не все из привычных форматов:

❌Лайвкодинг. Слабо показывает долгосрочную ценность сотрудника, не помогает дифференцировать кандидатов, слабо связан с повседневной работой. Да и по остальным принципам плоховато проходит – вкус не оценить, и многие кандидаты оценивают такой этап как неуважение к себе и своему времени.
❌Тестовые на дом. Проваливает пункты по экономии времени, дифференцированию и прозрачности. К такому собеседованию легко подготовиться с помощью AI.
ℹ️Проектирование. Вариант получше, но все еще не идеальный. Код человека вы не увидите.
✅Разбор примеров работы или опенсорсных проектов. Тут все хорошо, но только если такие примеры у кандидата есть.
✅Код-ревью плохого кода – кандидат и собеседующий вместе разбирают подготовленный заранее проект. Очень уважительный ко времени кандидата вариант, плюс хорошо обеспечивает прозрачность и помогает оценить вкус.

Альтернатива командной работе

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

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

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

Слышу много похожих рассказов от друзей, которые сейчас плотно работают с джунами. Расскажите, а как у вас?

Текущее состояние AI-assisted разработки

Держите большой обзорный материал по всем последним исследованиям и опросам, связанным с тем, насколько на самом деле продуктивнее становятся разработчики при работе с AI. Часть из этих исследований я уже публиковал, но тут довольно удобно все собрали в одном месте.

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

👉Адопшн AI очень большой и продолжает расти – разработчики всегда пытались сократить рутинную работу, и эти инструменты им помогают.
👉Трезвая оценка повышения продуктивности где-то в районе 20-30%, причем не во всех командах.
👉Все очень сильно варьируется от случая к случаю, например польза для новичков и для сеньоров будет очень разной.
👉С одной стороны, AI инструменты провоцируют over-confidence, а с другой – слепо доверять результатам их работы вообще нельзя.
👉Output != Outcome. Кода пишется больше, но скорость разработки может не измениться вообще, а то и упасть.

Как с этим вообще жить:

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

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

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

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

Так вот, поговорим о том, как построить эти здоровые границы:

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

Заменять джунов на AI – тупейшая идея

На волне популистских заявлений всех компаний, делающих что-то вокруг AI, последнее интервью СЕО AWS выглядит прямо хорошо:

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

Как работать с социопатами

Если вы когда-то встречали людей, для которых:

👉Должность – способ самоидентификации
👉Люди вокруг – ресурсы или препятствия
👉Рабочие отношения воспринимаются как игра в статус
👉Положение в иерархии определяет отношение к другим и способы общения

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

1️⃣Не играйте с ним в иерархию. Ведите себя нейтрально – не реагируйте ни на лесть, ни на хамство.
2️⃣Фиксируйте все договоренности письменно, чтобы уменьшить возможности манипуляций фактами.
3️⃣Не оправдывайтесь перед ним, иначе он воспримет это как уязвимость и использует ее.
4️⃣Не вступайте в моральные дебаты. Сводите все общение к конкретной рабочей задаче.
5️⃣Не становитесь его другом, даже если он пытается подкатить. Дружба с социопатом всегда условная, и будет использована им как инструмент.
6️⃣Ищите союзников, с которыми можно поделиться своими наблюдениями, и которые смогут поддержать вас.

Новые выпуски тимлидских подкастов

👉"Бреслав и Ложечкин" про то, как персональный бренд может иногда помочь прокачать карьеру, а иногда – быть уволенным
👉"Подлодка" про доверие к AI – откуда берутся галлюцинации и bias, и как с ними бороться
👉"Weekend Talks" с Виталием Шароватовым про его карьерный путь, помощь людям вокруг и важность тестирования
👉"КОДА КОДА" с Кириллом Мокевниным про A-players: кто это такие, надо ли их нанимать, и какую пользу бизнесу приносят
👉"Едим слона целиком" про способы управления командой и сохранения культуры в условиях очень быстрого роста

Про экзотические метрики

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

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

Я всегда к этому вопросу захожу немного с другой стороны. Мне кажется, что самое важное – это сформулировать простым языком смысл того, в чем заключается успех, и сделать так, чтобы вся команда это понимала. А затем, отталкиваясь от смысла, подобрать несколько простых релевантных метрик. Пока все понимают смысл того, что мы делаем, читить метрики бессмысленно. А то, что они не идеально отражают смысл – ну и пусть, все равно в итоге MRR всех рассудит!

Джунов все-таки стали нанимать меньше

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

Держите свежее исследование рынка вакансий США, из которого видно следующее:

👉Начиная с 2022 года, найм сотрудников возраста 22-25 лет на вакансии, наиболее автоматизируемые с помощью AI, уменьшился на 13%.
👉В эту категорию работ попадают программисты, саппорт, бухгалтера.
👉При этом с занятостью опытных сотрудников в той же категории, равно как и джунов других специальностей, все вполне нормально.

Про умение признавать ошибки

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

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

Вот что стоит сделать, если вы накосячили:

👉Будьте конкретными, когда говорите про свою ошибку. Вместо "можно было поступить лучше" говорите что-то вроде "Я перебил тебя на встрече, из-за чего тебе не дали высказать свою точку зрения".
👉Не оправдывайтесь. Не нужно объяснять, что именно вызвало ваш поступок – об этом вы сможете поговорить со своим терапевтом. Сосредоточьтесь на том, как ваша ошибка повлияла на других.
👉Чтобы слова не остались пустыми, вам надо изменить свое поведение и не повторять аналогичных косяков.
👉Готовьтесь к тому, что одного признания вины будет недостаточно, и на восстановление доверия уйдет время.

Ментальные модели работы организации

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

👉Parkinson's Law of Triviality. Группам свойственно тратить слишком много времени на самые тривиальные вопросы. Это происходит потому, что обсуждать простые и понятные темы – безопасно.
👉Hick's Law. Чем больше вариантов решения есть, тем дольше оно будет приниматься.
👉Chesterston's Fence. Не отказывайтесь от каких-то правил, пока не поймете, зачем их вводили.

Правила хорошей коммуникации

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

👉Чем больше аудитория, тем больше в ней групп, заинтересованных в разном количестве деталей. Поэтому делайте вашу коммуникацию "слоеной" – начинайте с ключевой мысли, затем разбивайте ее на основные тезисы, а затем уже уходите вглубь каждого тезиса. Так люди смогут быстро понять, на какой уровень хотят погрузиться, и не отвалятся, совсем ничего не поняв.
👉Учитывайте не только тех, кому вы что-то рассказываете, но и аудиторию второго порядка – тех, до кого информация дойдем в пересказе. Поэтому информацию полезно давать в сжатом виде, который легко пересказать.
👉Учитывайте самый циничный способ интерпретировать свои слова. Такой человек обязательно найдется, он же перескажет ваши слова в таком виде другим людям, и эта версия разойдется по всей компании. Поэтому всегда перечитывайте свои мысли, оценивайте, можно ли их истолковать превратно, и докручивайте, чтобы уменьшить шансы на это.
👉Чтобы вашу ключевую мысль точно услышали, повторяйте ее несколько раз.
👉Используйте сразу несколько каналов, чтобы передать важную информацию – разные люди предпочитают разные источники. Плюс даже в маркетинге есть правило нескольких касаний.
👉Поддерживайте свои каналы донесения информации даже тогда, когда они вам не нужны – иначе потом, когда они понадобятся, будет поздно.
👉Доносите информацию как можно раньше, и как можно чаще. В большинстве случаев не нужно ждать 100% уверенности и вылизанности сообщения – шанс ошибиться не перевешивает появление слухов. Люди гораздо лучше справляются с неидеальной или неполной информацией, чем с информационным вакуумом.
👉Дебажьте проблемы в коммуникациях. Если вы что-то рассказали, а люди это не услышали, либо интерпретировали не так – в этом только ваша вина. Единственное, что вы можете сделать – попробовать понять, почему это произошло, и быть лучше в следующий раз.

Отрываем коммуникации от оргчарта

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

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

Лучшая архитектура – самая простая

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

Более рациональный альтернативный подход – возвести принцип YAGNI в абсолют, и стараться найти самое-самое простое решение из возможных, исходя из текущей ситуации. Не думать про потенциальное масштабирование, нагрузку, nice-to-have фичи, и элегантность архитектуры. А расширять эту архитектуру начинать только тогда, когда без этого никак не обойтись, чтобы поддержать реальные требования.

Google сократил треть руководителей маленьких команд

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

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

Как разговаривать про повышение зарплаты

1️⃣Занизьте свои изначальные ожидания, и не расчитывайте на то, что зарплату точно поднимут до того уровня, который вы хотите. Вместо этого сфокусируйтесь на том, что в зоне вашего контроля.
2️⃣Разберитесь в том, как работает пересмотр зарплат в вашей компании, и какие факторы на него влияют. Получить повышение проще, когда вы приходите за ним в нужный момент цикла бюджетирования. Еще лучше, если вы сможете получить критерии, на которые обычно смотрят при пересмотре.
3️⃣Подготовьтесь к разговору и покажите: план/факт по вашим целям и ожиданиям; что заметного вы сделали за рамками этих ожиданий; как ваша работа соответствует ценностям компании.

По итогу, на вероятность пересмотра больше всего влияет:

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

Про хорошие публичные выступления

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

1️⃣Информировать аудиторию о том, что вы сделали, и почему это важно. Причем делать это, не вдаваясь слишком глубоко в детали, не интересные аудитории.

Стандартные паттерны:

👉Что-то раньше считалось невозможным, а вы показали, как это сделать
👉Что-то раньше было сложным или неэффективным, а вы показали путь получше
👉Что-то подвержено ошибкам, а вы показываете, как уменьшить их риск
👉Что-то очень сложное, или аудитория это плохо понимает, а вы можете это объяснить простым способом
👉Что-то кажется всем верным, а это на самом деле не так

2️⃣Образовывать аудиторию. То, о чем вы рассказываете, должно быть полезным, причем не только в вашем узком домене. Ключевые идеи должны быть сформулированы так, чтобы слушатели могли перенести их в свой контекст.

3️⃣Развлекать аудиторию. Это не значит, что нужно вставлять мемы на каждый слайд, или превращать доклад в стендап – вам надо нащупать комфортный вам способ зацепить аудиторию. Это может быть структура доклада, какие-то отсылки, искренность, открытость.

Я, кстати, когда-то давно писал статью со своими мыслями про подготовку хороших выступлений, куда добавил побольше прикладных советов и практик. Old but gold!

Про градиент власти

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

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

Вот некоторые из практик, которые помогают уменьшать такой разрыв:

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

Принципы СТО Amazon

👉Думайте о решении реальных проблем, а не о хайпе. Не нужно внедрять технологии только из-за FOMO.
👉Сбои и падения – часть плана, не нужно строить идеальные системы. На больших масштабах каждая дополнительная девятка в SLA стоит миллионы. Стремиться сделать отказоустойчивыми все элементы системы – дорого и бессмысленно. Вместо этого можно думать про три категории сервисов – Tier 1 (ни в коем случае не должно падать), Tier 2 (может немного деградировать), Tier 3 (может упасть, и никому не будет дела).
👉Разделяйте решения на обратимые и необратимые, они же – one-way/two-way doors. Обратимые решения принимайте как можно быстрее на неполных данных. Необратимые – замедлитесь и подумайте глубоко.
👉Security > Operations > Cost. Security – нельзя допускать никаких компромиссов в вопросах безопасности. Operations – софт дольше живет в продакшне, чем в разработке, так что удобство его поддержки должно быть заложено на самом старте. Cost – системы должны дизайниться с расчетом не только на масштабирование, но и наоборот, на возможность сжиматься в меньшие масштабы.
👉Кто сервис написал, тот за него дальше и отвечает – поддерживает, дежурит, чинит аварии по ночам. Благодаря этому у инженеров сохраняется плотный цикл обратной связи, и они видят последствия своих решений.