Абсурдность системы найма и роста джунов

Я писал код почти всю сознательную жизнь. Началось все с толстенного зеленого тома "Библия Delphi", калькуляторов и симуляторов бомжей, потом пришла J2ME с деобфускацией и модами для мобильных игр, а в старших классах продолжилось С++ с простыми вирусами и кейлоггерами. Где-то тогда же я погрузился в прекрасный мир готовых PHP движков, и стал собирать на заказ бесконечные интернет-магазины, портфолио и визитки. Универ меня немного подвел – вместо ожидаемого технического хардкора я получил изучение бесконечных гостов и аппаратных методов защиты информации.

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

Спустя два года работы в студии, в принципе, мало что поменялось – я собрал еще больше странного разношерстного опыта, но программистом все еще был объективно слабеньким. При поиске второй работы я нацелился уже на то, чтобы попасть в крупную продуктовую компанию. И тут, кажется, мне снова повезло. В 2013 году сам процесс собеседований был довольно лайтовый – с несколькими проектами в проде за плечами и довольно базовыми знаниями своего языка я попал в Rambler&Co на роль мидла, хотя на него тянул ну с очень большой натяжкой.

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

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

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

👉"Три тимлида заходят в бар" про work/life balance – действительно ли руководитель может своим примером влиять на команду, и как этого избегать.
👉"Бреслав и Ложечкин" про вред от бездумной data-driven культуры.
👉"КОДА КОДА" про андрагогику – науку про обучение взрослых, куда позвали Орлова и Панкратова из Стратоплана
👉Подлодка про то, как AI помогает небольшим командам и стартапам ускорять разработку в десятки раз

Кстати, если вы вдруг знаете еще какие-то подкасты и блоги на YouTube, которые не попадают ко мне в подборки – поделитесь!

Паттерны использования AI в команде

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

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

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

Избегайте нытиков

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

Присоединиться к такому кружку циников на первый взгляд довольно притягательно – быть критиком просто и безопасно. Но этого стоит избегать:

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

Сколько инженеров работают на двух работах сразу

В Стэнфорде есть группа ученых, которые занимаются изучением продуктивности разработчиков. Самое крутое – это то, что у них есть доступ к приватным репозиториям 1000 разных компаний, с коммитами от 100к+ разработчиков. На его основе они находят много интересных инсайтов (например, можно вот этот доклад послушать или почитать эту бумагу). Но сегодня я принес два интересных факта:

👉9,5% всех инженеров – "призраки". Они делают где-то 10% коммитов в сравнении с медианным разработчиком.
👉4% инженеров работают на 2+ работах сразу. При этом продуктивность их работы почти в два раза ниже медианы.

Я очень хочу вытащить ведущего рисерчера в подкаст и обсудить асе детали – предварительное согласие есть, где-то осенью будем пробовать!

Месяц экспериментов с AI в компании на 700 человек

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

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

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

На результаты, конечно, стоит смотреть немного скептически, так как про них рассказывает топ-менеджер, а не люди на местах, но все равно интересно:

👉Доля AI-assisted PRs выросла с 50% до 90%
👉Команды показали 71 работающую демку того, как они используют AI в своей работе
👉Оценка на распил монолита уменьшилась с 408 до 21 человеко-недели (что ж они там такого автоматизировали-то)

Не надо искать идеальных

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

В статье как раз про системный подход, который позволяет подходить к поиску кандидатов рациональнее:

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

Шаблон для подбора в команду

Я в JetBrains недавно решал похожую проблему с наймом продакт-менеджеров – многие команды не могли четко сформулировать рекрутерам, кто конкретно им нужен, и это тащило за собой ворох негативных последствий. Мы договорились, что перед открытием новой позиции нанимающий менеджер должен заполнить небольшой hiring brief.

Сначала идут вопросы про роль:

👉За какие продукты или фичи кандидат будет отвечать
👉Основные цели, которые перед ним будут стоять
👉Примеры конкретных задач
👉Уровень сеньорности по нашей линейке грейдов
👉Кого ему придется менеджерить

Профиль идеального кандидата:

👉Тип опыта (B2C/B2B, corporate/startup, new product/scaling/mature)
👉Доменный опыт (например, геймдев)
👉Конкретные требования к техническому бэкграунду (он у нас нужен почти любому продакту, но уровень может различаться)
👉Конкретные компетенции с разбитием на must-have и nice-to-have
👉Важные для позиции личные качества (например, готовность к росту в пипл-менеджмент)

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

Два вида сложных решений

1️⃣70/30, когда один из вариантов точно лучше другого
2️⃣49/51, когда решения примерно одинаковы

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

Фундаментальные истины про разработку

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

Ни одна из этих истин не меняется из-за того, что код теперь пишут не кожаные мешки, а AI.

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

Почему сеньоры теперь особенно ценны

В 1985 году ученый Петер Наул написал эссе "Programming as Theory Building". Его основная идея была в том, что в основе любой программы лежит не код, а теория – общая ментальная модель того, как работает система, почему она работает именно так, и как должна развиваться дальше. При этом сам код не вмещает в себя всю ментальную модель, так как значимая часть ее остается в головах архитекторов системы.

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

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

В результате кодовые базы поначалу вроде работают, но по мере роста становятся все менее согласованными. И именно поэтому индустрию спасают опытные сеньоры:

👉Они понимают ту самую ментальную модель, умеют поддерживать и упрощать ее
👉Они следят за эволюцией архитектуры
👉Они могут научиться осознанно использовать AI (хоть и не все, как показал понедельничный рисерч)
👉Они передают знания и умения новичкам

Про важные личные качества руководителя

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

Я не буду пересказывать все качества, про которые она рассказывает, остановлюсь на одном – последовательности.

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

Держите небольшое пятничное напоминание про то, как важно менеджеру хотя бы иногда слышать "спасибо"!

Как OpenAI работает изнутри

За последний год OpenAI вырос в три раза, с 1000 до 3000 человек. При этом количество направлений, которыми они занимаются, выросло еще сильнее – это и собственные дата-центры, и новые семейства моделей, и куча консьюмерских продуктов, и консалтинг, и куча чего еще. Инвесторских денег – море, продукты растут безумными темпами, поэтому почитать про то, как вообще устроена их рабочая культура особенно интересно!

Держите интересные хайлайты:

👉Компания работает в bottom-up режиме. У разных людей появляются идеи, они их проверяют, и, если что-то оказывается действительно классным, оно отправляется к пользователям. Понятным образом это ведет к тому, что одновременно в разных местах компании могут разрабатывать 3-4 конкурирующие друг с другом идеи.
👉Побеждают обычно те идеи, авторам которых удается заинтересовать рисерчеров. Если идея кажется им скучной или уже кем-то решенной, ничего не полетит.
👉Очень сильно ценятся продакты и research managers, как раз за то, что могут свести друг с другом много независимых команд и инициатив, и сделать что-то большего масштаба.
👉По сравнению с влиянием цены на GPU, все остальные факторы стоимости фичи практически равны нулю, поэтому в capacity management умеют все.
👉Структура команд очень гибкая, важному проекту можно за пару дней получить в помощь нужных людей из других команд.
👉Все лидеры компании очень вовлечены в R&D и делают что-то руками.
👉Технические решения принимаются не архитекторами или комитетами, а командой, которая пишет конкретный код. Поэтому в кодовой базе очень мгого дублирующих друг друга подсистем.
👉Инженерная команда росла очень быстро, все пилили фичи, поэтому с инфрой и тулингом все очень плохо – сборки долгие, все часто отваливается.

Про сомнения в себе

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

Вот типичные паттерны проявления у нас этого синдрома:

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

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

Что на самом деле умеют AI агенты

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

Как начинать работу в новой компании

1️⃣Защитите то, что уже работает

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

2️⃣Найдите низковисящие быстрые победы

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

3️⃣Выберите big bet, за который возьметесь

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

4️⃣Займитесь доработкой стратегии

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

А вот чего стоит избегать в первые 90 дней:

❌Не обещать слишком много ранних результатов
❌Двигаться слишком быстро без выравнивания с соседями
❌Чинить то, что не сломано

LLM не подходят для психотерапии

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

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