Илья Шишков: код, собесы, IT

Как бороться со стрессом собеседования

Всем привет! Всех с началом рабочего года! Как ваше состояние: «никто так ни нуждается в отдыхе, как человек, вышедший из отпуска» или «мы бодры и веселы»?

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

Однако со временем я научился сохранять спокойствие на протяжении всего собеседования. В моём методе есть две части: стратегическая и тактическая.

Стратегическая часть

Она состоит в том, чтобы максимально снизить ценность любого отдельного собеседования. Сюда входят:
— проходить собеседования, когда у вас есть стабильная работа
— проходить собеседования, когда вы не находитесь в активном поиске работы (чуть отличается от предыдущего пункта)
— собеседоваться параллельно в 3+ компании
— пройти много-много собеседований

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

Тактическая часть

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

Для меня физические нагрузки работают безотказно.

Если во время собеседования я поймал себя на том, что меня трясёт, мне помогает пауза. Остановиться, закрыть глаза, сделать глубокий вдох и выдох. Это занимает 3-4 секунды, поэтому интервьюер может и не заметить. И после этого сразу сконцентрироваться на решаемой задаче. Я иногда начинаю сам себя оценивать в процессе решения задачи: «Не, это слишком слабая идея. Наверняка они хотят услышать что-то покруче», «Мда, что-то я медленно с этим вожусь. Это некруто, наверное, я проваливаюсь». Вот этот голос страшно мешает как следует себя проявить на интервью. Вдох/выдох помогают его заткнуть и снова сфокусироваться только на решаемой задаче.

А какие у вас методы? Делитесь в комментариях.

Праздник к нам приходит

Небольшой оффтоп. Вчера вернулись из Вотчины Деда Мороза в Великом Устюге. Ездили с семьёй на выходные.

Прекрасное место: настоящая зимняя погода, катание с горки на тюбинге, иммерсивные сказочные мероприятия, увлекательные мастер классы и, конечно, встреча с Дедом Морозом.

Прекрасная подготовка к наступающему Новому году. Особенно тронула встреча с Дедом Морозом - там не только хороводили детей, но и очень органично вовлекали взрослых. Я снова ощутил то детское ощущение волшебства, которым окутан Новый год 🎄

Как я готовлюсь к выступлениям на конференции

Здесь должна быть какая-то красивая привязка к Новому году, но я её не придумал 🤪

В этом году у меня было два доклада на System Level meetup. Со временем у меня сложился устойчивый процесс подготовки, который предсказуемо даёт хороший результат. О нём и расскажу.

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

Шаг 1. Что люди унесут с доклада

Я ещё раз для себя очень чётко формулирую: что люди унесут с моего выступления. Не «я расскажу про X», а «после доклада человек сможет Y». Это ключевая опора, относительно которой потом проверяется всё остальное.

Шаг 2. Структура выступления и супер-черновая презентация

Дальше я планирую структуру доклада. Накидываю примерное введение, основные блоки и переходы между ними. И сразу же делаю первую версию презентации. Она всегда максимально черновая: чёрный текст на белом фоне, без дизайна, без картинок. Если на каком-то слайде должен быть код, там просто написано: «Здесь будет код такой-то». Эту версию я стараюсь сделать очень быстро — примерно за час. Это не презентация для людей, это инструмент, чтобы как можно раньше перейти к прогону.

Шаг 3. Первый прогон (самый важный)

Когда первая версия презы готова, я делаю первый прогон. Закрываюсь в комнате и просто рассказываю доклад вслух. После этого появляется первое реальное понимание:
— сколько это длится (обычно мимо тайминга вообще),
— где логические дыры,
— где нет логики в переходах,
— где я сам чувствую, что несу ерунду.
Есть простое правило: если мне в процессе кажется, что получается ерунда, то аудитории точно не зайдёт.

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

Шаг 4. Погружение в детали и код

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

Поэтому код под доклад я почти всегда пишу отдельно. Отдельный проект, моки, заглушки — оставляю только то, что важно для идеи. И принципиальный момент: этот код обязан работать. На последнем System Level Meetup я показывал ускорения — и я реально прогонял код, снимал цифры, строил графики. Никакой «магии на слайдах».

На это легко уходит 8–10 часов. Иногда больше.

Шаг 5. Код на слайдах без боли

Здесь у многих начинающих спикеров возникает боль: код не влезает, его плохо видно с дальних рядов, хочется подсветку синтаксиса, но не хочется вручную размечать всё в PowerPoint. Я для себя выработал довольно простую связку. Я настраиваю clang-format под ширину примерно в 50 колонок, подбираю моноширинный шрифт и размер в PowerPoint так, чтобы эти 50 символов уверенно влезали по ширине слайда. Это проверено опытом — такой код читается даже с последнего ряда. Дальше я форматирую код, открываю его в VSCode и просто копирую в PowerPoint. VSCode переносит не только текст, но и подсветку. Это сильно экономит время.

Шаг 6. Повторные прогоны и правки

После этого идут очередные прогоны. Обычно к пятому-шестому прогону я уже стабильно попадаю в тайминг, структура полностью устоялась, код на месте, все ключевые акценты расставлены. Слайды всё ещё выглядят как «чёрный текст на белом фоне», но контент уже практически финальный.

Шаг 7. Дизайн в самом конце

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

На этом подготовка обычно и заканчивается. Долго, не романтично, но зато без сюрпризов на сцене.

А у вас как с подготовкой к выступлениям? Или вы из тех, кто выходит и тащит чисто на харизме?

Итоги года для моего канала

👀 Наиболее просматриваемые посты:
— Переработки в Яндексе
— Жить лучше на те же деньги
— Почему я выбрал С++
— WTFM или итоги AI Dev Day в Яндексе
— Как я отлаживал ошибку «Type `struct List` should match type `struct List`»

👍 Посты с наибольшим количеством реакций (без учёта приведённых выше)
— Когда адекватно воспринял обратную связь
— Сара Коннор была права
— Я — днище, или каково мне работать в R&D
— Никогда не говорите этого на стендапе!
— Надо много работать

🔁 Посты, которые вы пересылали больше всего:
— Чем полезен этот канал
— А какую модель в ChatGPT используете вы?
— Балансировка трафика: между простотой и highload-безумием
— Почему Яндекс заморачивается с алгосекциями?
— Работа в Яндекс Лавке: кайф или тягость выживания

Всех с наступающим Новым годом! 🎄 Спасибо, что были со мной в этом году! Давайте отдохнём хорошо на праздниках и отлично проведём 2026-й! 🍾

Почему Яндекс заморачивается с алгосекциями?

"А зачем Яндекс как компания так заморачивается алгоритмическими секциями? Когда спрашивал уже прошедших его и вышедших на работу, то всегда слышал одно: "В бою" ни разу не использовал знания алгоритмов. Тогда что это дает? В чем практическая польза от требования знания алгоритмов?"

Наконец-то, я добрался до этого вопроса от подписчика - долго он висел в контент плане. Недавно Яндекс выложил статью с описанием нового процесса собеседования. Я думал, что они поменяли сами собеседования, но изменения касаются другой проблемы - того, что кандидаты могли проходить по 12 собеседований, 8 из которых примерно одинаковые. Суть отдельных секций осталась той же. А значит, этот пост актуальный 😃

Давайте разбираться. Так как во времена работы в Яндексе я провёл 250+ собеседований разработчиков, я очень хорошо умею объяснять, почему они такие. Итак, у нас стоит задача оценить, сможет ли человек справляться с работой разработчика. И есть ограничение - это надо сделать за 1 час. Ровно столько времени действующих разработчиков мы готовы выделять, чтобы это не мешало их основным задачам.

❓ Как распорядиться этим часом наиболее эффективно? Считается, что сильный специалист способен освоить любой язык программирования или технологию на приемлемом уровне за 2-3 месяца. Поэтому нет смысла расспрашивать его о глубинах вашей технологии - изучит, когда понадобится.

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

❓Теперь вопрос - как за 1 час проверить, что кандидат умеет решать задачи и превращать свои мысли в работающий код?

Давать задачи, близкие к работе? Тут есть 3 недостатка:
👉 объяснение такой задачи может занимать много времени - нужно учесть массу нюансов и деталей
👉 не факт, что её реально написать за 1 час
👉 сложно выработать чёткий критерий "Берём/не берём"

А вот leetcode-like задачи подходят куда лучше:
✅ любую можно объяснить за 2 минуты
✅ правильное решение обычно занимает до 30 строк кода
✅ за 1 час можно дать две таких задачи: попроще и посложнее
✅ легко выработать критерий успеха - кандидат написал работающий код для обеих задач (возможно, с подсказками и ошибками, которые смог исправить)

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

Мне как-то на собеседовании давали задачу, близкую к реальной работе в бекенде. Она очень хорошо раскрывает опыт и кругозор кандидата. При этом:
👉 та секция продлилась 2-2,5 часа
👉 меня проверяли на позицию senior backend, без опыта в бекенде её не пройдешь

Недавно я собеседовал кандидата в СБТ на middle-позицию. Дал ему задачу, которая и опыт в C/C++ раскрывает, и проверяет навык превращать мысли в работающий код. Кандидат никак не мог придумать решение, и я в итоге подсказками к нему привёл. Кандидат словами проговорил правильное решение, но когда настало время писать код, он так и не смог ничего написать. Буквально - ничего. То есть у него в голове так и не простроилась связь между идеей решения и кодом, который её реализует. При этом правильное решение занимает 10 строчек. Пришлось отказать.

А как вы поступили бы с кандидатом, показавшим такой результат секции?

P. S. Моё мнение может не совпадать с позицией Яндекса, где я не работаю уже больше 2 лет

Кто ещё помнит программу со скриншота?

Ребята, кто не знает, что на скрине — тот самый Far Manager. Меня жизнь внезапно с ним снова свела. Я думал, он остался в начале 2000-х, где-то между выпуклыми ЭЛТ-мониторами и моими первыми попытками писать код.

Я всю жизнь на Windows пользовался Total Commander. Удобно, привычно, всё под рукой. Но на работе он, как оказалось, под запретом. Зато можно Far. И вот я уже уставший от проводника Windows, вижу у коллеги знакомое синее окно — и ставлю себе.

И меня прям накрывает. Для меня Far Manager всегда был символом «магии компьютеров». В начале 2000-х я смотрел на людей, которые лихо перемещались по этим синим панелям, и казалось, что они управляют машиной силой мысли. Тогда Far был атрибутом тех, кто «знает секреты».

На олимпиадах по программированию мы тоже активно им пользовались. Писали код прямо в его редакторе. Почему не IDE? Да кто его помнит. Кажется, Far можно было поднять на любом компьютере, в любой аудитории, без плясок с настройками — и этого хватало. Три года все олимпиадные решения у меня были рождены именно там.

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

И вот я открываю его на рабочем ноутбуке — и такое: ого. Он всё ещё выглядит магически. Эта синяя расцветка, эти панели, этот вайб «олдскульного контроля над машиной».

Просто хотел поделиться ностальгией. А вы пользовались Far? Или для вас это уже музейный экспонат?

Жизнь любит проверять решения на прочность

Иногда мне кажется, что жизнь устроена как тестировщик уровня «бог». Принял решение — будь добр пройти стресс-тест. В 2023 году я уволился из Яндекса, чтобы попробовать поработать на себя, посмотреть, что получится, дать себе пространство. И буквально через неделю мне прилетает очень неплохой оффер. Такой, знаете… «Ну что, Илья, действительно готов выйти из найма?» 😏

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

Недавно я объявил, что закрываю свой курс «Алгоритмический фундамент программиста» — и снова прямо дежавю. Потому что за две недели к курсу присоединилось больше людей, чем за любой другой месяц во все пять лет его существования 😳

Ребята, ну где же вы были раньше? Когда я рассказывал про курс, приводил отзывы, объяснял пользу, размещал рекламу? Я бы, может быть, и не закрывал его. А сейчас отмена решения будет выглядеть как маркетинговая уловка.

Поэтому это для меня тоже проверка на прочность: удивительным образом продажи пошли именно после объявления о закрытии. Да, курс уходит. Но давайте я напомню важную вещь: сегодня на Степике последний день «Чёрной пятницы» — скидка 33% на курс. Завтра скидки уже не будет, и я попрошу Степик закрыть продажи курса. Если вы давно откладывали, но всё-таки хотите улучшить алгоскилы для интервью и рабочих задач, то вот он — последний день, чтобы запрыгнуть в вагон уходящего поезда.

👉 Ссылка, чтобы запрыгнуть 👈

В исходном посте я писал, что доступ у купивших пропадёт в марте. Этого не будет — доступ у купивших остаётся бессрочным ☺️

А с вами в жизни случались «проверки на прочность решений»?

AI-ассистенты уже здесь. Но кто за них отвечает?

Предыдущий пост был про моё выступление на System level meetup, но ещё я поучаствовал в дискуссии: «AI-ассистенты в разработке на C++: панацея или опасный костыль?» Когда модератор попросил поднять руки тех, кто пользуется ассистентами каждый день, это сделало больше половины зала. Кажется, мы прямо на глазах влетаем в эпоху, когда почти каждый разработчик живёт с AI-ассистентом в IDE так же естественно, как с автокомплитом.

Давайте рассмотрим главные мысли, которые прозвучали в дискуссии (😉 видео есть по этой ссылке)

AI галлюцинирует. Но не везде одинаково

По залу прокатилась волна историй о том, как ассистенты выдумывают несуществующие API, типы, функции — особенно в нишевых библиотеках.

Типичный сценарий:

— «Такой функции нет.»
— “Yes, you’re right!”
— Генерирует новый код.
— В нём опять тип, которого нет.
— «Такого типа тоже нет.»
— “Yes, you’re right!”
— Новый вариант.
— И опять ерунда.

И так по кругу, пока не сдадутся нервы.

Слушая всё это, я снова благодарил судьбу за Postgres: ChatGPT его выучил почти идеально. Мне просто повезло оказаться в экосистеме, которую модель знает в лицо. И вот это ощущение «я живу на лёгком уровне сложности» — оно очень ясно проступило именно на этой панели.

AI — это инструмент. И ответственность — на нас

AI-ассистент — такой же инструмент, как grep или bison. Можно написать неправильный регэксп — grep покажет мусор. Можно написать кривую грамматику — bison выдаст неудобоваримый парсер. Но никто же не додумывается говорить: «Это всё bison виноват». С AI то же самое.

Константин Владимиров сформулировал ещё жёстче:

«Если относиться к AI как к кодогенератору — всё нормально. Если относиться к нему как к персонажу, который написал код, вы пускаете в репозиторий безответственного участника команды.»

И вот тут меня пробрало. Потому что я за собой заметил одну вещь. Я — двумя руками за то, что разработчик на 100% отвечает за финальный код. Но когда на ревью прилетает замечание к тому, что сгенерил AI, руки так и тянутся написать: «Это не я, это qwen coder так написал». И каждый раз я себя останавливаю. Потому что это и есть та самая дорожка, на которой ты постепенно сдаёшь свои инженерные обязанности в аренду.

Долгосрочная перспектива: «вайбкодинг» станет коммодити, а гуру — редкостью

Была ещё одна интересная мысль, почти философская: когда надо быстро проверить гипотезу, собрать MVP, что-то покрутить — AI ускоряет работу настолько сильно, что продуктовая разработка постепенно превращается в коммодити. Сначала объяснил задачу на человеческом — ассистент навайбкодил — ты проверил — поехали дальше.

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

Как сказал один участник, каста станет меньше, но «легенды о них сохранятся». Звучит смешно, но где-то внутри есть доля правды.

И ещё одна мысль, которая мне сильно откликнулась

Константин Владимиров сказал фразу, которую я хочу повторить отдельно:

Язык программирования — это не инструмент. Это образ мышления.

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

По крайней мере пока.

Какие из этих мыслей оказались интересны вам?

Набажил в коде своего доклада

22 ноября выступал на System Level Meetup в Москве с техническим докладом про путь, который я прошёл в создании LRU-кеша для решения своей рабочей задачи.

Я много сил вложил в подготовку — по моим подсчётам получилось, что суммарно на подготовку 40 минутного выступления я затратил 26 часов. Я не тот человек, который может «набросать тезисы за вечер» и выйти на сцену. Удивляюсь спикерам, которые выступают десятками раз в год — я так не умею. Как минимум, если это выступление по программированию — по soft skills мне готовиться проще.

Считаю, что доклад удался. Как я это понял?

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

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

Причём баг не косметический, а связанный с параллельным доступом. Казалось бы, я в последнее время живу в этом коде — как можно было не заметить? Но, видимо, глаз замылился. На следующий день после выступления я перепроверил — там действительно ошибка 💥

И — внезапно — я считаю это успехом 💪

Потому что:
• значит, я донёс материал настолько ясно, что люди погрузились в детали;
• значит, я смог вовлечь аудиторию;
• значит, мой код станет лучше 😉

Это первый раз, когда слушатели помогают мне улучшить реальный production-код. И это чертовски приятно.

Я люблю такие моменты — когда ты выходишь на сцену не просто «поговорить», а реально обмениваешься с людьми знаниями и опытом. И в итоге сам уходишь более сильным, чем пришёл. В общем, доклад для меня стал важной точкой. И напоминанием: чем глубже готовишься, тем больше ценности получаешь обратно (к слову, я могу и вам помочь сделать доходчивое и уверенное публичное выступление)

Видео всех докладов доступно на 😉YouTube и 😄VKвидео. Кто был/смотрел System Level meetup? Как вам впечатления?

P.S. Баг был в коде поиска записи в LRU-кеше:

SharedPoolEntry* GetEntry(uint64 key) override {
  SharedPoolEntry* entry;
  UNDER_LOCK(LruLock(), LW_SHARED) {
    entry = (SharedPoolEntry*)hash_search(
        entries_, &key, HASH_FIND, nullptr);
  }
  if (entry) {
    TouchEntry(entry);
  }
  return entry;
}

Есть идеи, что в нём не так?