Как стресс влияет на прохождение интервью

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

Собеседуемые, которые решали задачу перед собеседующим, в среднем справились в два раза хуже чем те, кто делал это в одиночку!

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

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

Результаты опроса Stack Overflow за 2025

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

🧑‍💻Про разработчиков:

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

💻Про технологии:

👉Самый быстрорастущий язык, ожидаемо, Python, причем на невероятные 7%. Среди баз данных быстрее всего растет Redis.
👉В списке самых любимых языков новичок – Gleam. Обязательно про него выпуск Подлодки скоро запишем!

🤖Про AI:

👉В прошлом году к AI относились на 10% позитивнее, чем в этом. Что контринтуитивно – профессиональные разработчики ценят AI больше, чем начинающие.
👉84% опрошенных используют AI в своей работе.
👉Чаще всего AI используют для поиска и генерации контента, а реже всего – для деплоя, мониторинга, планирования проекта.
👉AI агенты все еще не стали мейнстримом, только треть опрошенных их как-то использует. Из них 70% считают, что их продуктивность выросла.

Как бороться с лишними созвонами

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

И еще одно правило борьбы с плохо организованными встречами по принятию решений.

Вам надо ответить всего на три вопроса:

1️⃣Какая информация нужна, чтобы принять решение?
2️⃣Есть ли у нас эта информация?
3️⃣Какое решение принимаем?

При этом для ответа на первые два вопроса никаких встреч собирать не нужно.

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

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

👉Дифференцировать кандидатов, помогая отличать опытного сеньора от волка с 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, конечно, виднее, как повышать эффективность своей организации. Но всем остальным я напоминаю, что на способность менеджера управлять каким-то куском компании влияет не только количество людей в подчинении, но и когнитивная сложность системы, за которую он отвечает. Условно говоря, управлять командой из трех человек норм, когда эти три человека обслуживают технологически сложную систему, экспертом в которой является и сам менеджер.