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

В 32 года я узнал, что неэффективен В 2019 году я пошёл на программу по личной эффективности под названием «Электронный мозг». Нам рассказывали, как перенести Getting Things Done в Evernote и построить систему, в которой не потеряется вообще ничего. Нужно было выгрузить из головы все дела, разложить их по заметкам и каталогам, регулярно обнулять inbox и закрывать незавершённые циклы. Звучало разумно. Проблема была только в том, что внедрить всё это предлагалось сразу. Я сел выгружать дела из головы — и довольно быстро понял, что их невозможно выгрузить за один вечер. Новые вспоминались быстрее, чем я успевал раскладывать предыдущие. Каталоги разрастались. Inbox не обнулялся. Незакрытых циклов становилось только больше. Ещё каждому участнику назначили личного коуча. Он должен был помогать выстроить систему. Мой в основном следил, чтобы я не оставлял незавершённых задач. Одна из таких задач почему-то регулярно оказывалась покупкой следующей программы 😁 Особенно хорошо я запомнил лекцию про завершение дня. Девушка-тренер подробно описала ежедневный вечерний ритуал: разобрать входящие, подвести итоги, подготовить следующий день, ответить на все сообщения и т.д. В сумме всё это занимало часа два. Я слушал и думал: а когда, собственно, жить и работать, если два часа каждый вечер нужно тратить только на то, чтобы правильно завершить день? При этом вокруг были люди, у которых всё якобы получалось. Коллеги поддерживали пустой inbox. Участники тренингов внедряли привычки, вели дневники, ставили цели и каждое утро начинали с правильных ритуалов. А у меня не получалось. И вот здесь был парадокс. К 32 годам я окончил вуз с красным дипломом, защитил кандидатскую, дважды участвовал в финале ACM ICPC и уже много лет работал разработчиком в Яндексе. До знакомства с личной эффективностью мне казалось, что я в целом нормально справляюсь с жизнью. А потом я узнал, что, оказывается, я жутко неэффективный 😱 Я не подумал: «Возможно, эта система требует от человека слишком многого». Я решил: «Значит, мне не хватает дисциплины и правильных инструментов». Так начался мой многолетний поиск системы, которая позволит делать всё важное, ничего не упускать и больше никогда не чувствовать, что я не справляюсь. Я попробовал календари, Todoist, SMART, GTD, привычки с наказаниями и кайдзен-планирование. Почти каждый подход сначала помогал. А потом начинал требовать свою цену. Но как человек, который до этого нормально справлялся без всякой системы, вообще дошёл до такого вывода? Для ответа придётся отмотать историю на несколько лет назад.

Итак, начинаем сезон личной эффективности. Я собрал всё-всё-всё, что делал и делаю в этой теме, и разделил на 12 историй. Все они объединены двумя вопросами: — зачем растить личную эффективность? — какая у этого цена? В предыдущем опросе самыми популярными оказались варианты «больше зарабатывать» и «освободить личное время». Мне нравятся эти варианты — они самые зрелые. Спасибо всем участникам опроса. Мой ответ на него чуть другой и давайте я приступлю к тому, чтобы его раскрыть 👇

Зачем вообще быть эффективным? В опросе по следующей теме с огромным отрывом победила личная эффективность. Я на этой неделе составлял контент-план и понял, что мне есть что рассказать. Не в формате «вот вам ещё один обзор GTD, Notion, календарей, таск-трекеров и привычек». Этого и без меня в интернете достаточно. Мне интереснее другое. Почему человек вообще начинает растить личную эффективность? На первый взгляд ответ очевиден: чтобы больше успевать. Но чем дольше я в этом варюсь, тем меньше мне нравится этот ответ. Потому что «больше успевать» легко превращается в бесконечный конвейер: закрыл одну задачу — получил три новых ("ну ты же быстро их сделаешь"). Освободил вечер — занял его ещё одним проектом. Научился планировать неделю — начал запихивать в неё больше, чем раньше. И в какой-то момент возникает неприятный вопрос: А я расту в эффективности, чтобы жить лучше — или чтобы эффективнее себя эксплуатировать? У меня путь в личной эффективности продолжается до сих пор. Были периоды, когда я пытался держать всё в голове. Были периоды, когда строил сложные системы. Были моменты, когда система мне помогала, а были моменты, когда она превращалась в ещё один источник давления 😣 Поэтому я хочу сделать серию постов не про «топ-10 методов продуктивности», а про свой путь: что сработало, что сломалось, какую цену пришлось заплатить и зачем всё это вообще нужно. Но перед тем как я начну серию, хочу свериться с вами 👇

Онлайн-бронь стола в кафе в 2026. Что может быть проще? Случайно увидел, что на Яндекс Картах теперь можно бронировать столики в кафе. -- Круто! -- подумал я. -- Рай для интроверта, не надо никуда звонить! 🔥 Выбрал дату, время, количество человек, нажал "Забронировать". Приходит СМС "Ресторан получил запрос, ожидайте подтверждения". Где-то здесь я всё ещё с большим недоверием отношусь к тому, что это всё сработает. Одно дело кнопочки в интерфейсе сделать - совсем другое дело добиться того, чтобы живые люди действовали по процессу, который эти кнопочки задают. К тому же кафе я бронировал не в какой-нибудь продвинутой Москве, а в своём родном Орле. А это добавляло вероятности, что что-то может пойти не так. Но взяв телефон спустя какое-то время и увидев там второе СМС со словами "Ресторан подтвердил вашу бронь", я успокоился и решил, что столик уже точно мой. Думаю, вы догадываетесь, что случилось, когда я в назначенное время пришёл в кафе... Сотрудники в недоумении спросили: "Какая бронь? У нас её нет". К счастью, у них оставался один свободный стол, куда меня и посадили. Мораль Пока одни делают агентов, которые программируют агентов, которые будут порождать субагентов, онлайн бронь столика в кафе - всё ещё не до конца решённая задача 😔

Курс подготовки к собеседованию в HFT — почему его не будет Посты последних нескольких недель так или иначе были связаны с HFT. Это заключительный пост из этой серии — дальше я сменю тему. Чуть больше года назад ко мне через GetMentor обратилась девушка с запросом «Хочу переехать в Лондон и сменить BigTech на HFT — помоги подготовиться». Мы прозанимались более полугода и прошли большой список тем: алгоритмы, С++ concepts, RAM architecture, Ethernet/IP/TCP/UDP и т.д., и т.п. Приведу отзыв, который она оставила о нашей совместной работе: Я давно работаю в big tech и рассматривала для себя возможность перейти в HFT — из-за более высоких зарплат и, возможно, более интересных технических задач. Насколько я понимаю, у собеседований в HFT нет чёткой структуры и стандартных coding-секций, как в big tech: они сильно различаются между компаниями, и в сети не так много информации о том, что именно нужно знать и как готовиться. При этом круг тем кажется довольно широким, а моя текущая работа далека от того, что релевантно для HFT (например, low latency). Самостоятельно составить план подготовки и придерживаться его было сложно, поэтому я решила попробовать поработать с ментором. Профиль Ильи я нашла на GetMentor — он явно указывал опыт в HFT, плюс я знала его по Яндексу, так что решила, что это хороший вариант — как минимум стоит попробовать. В формате 1:1 мне понравилась гибкость — можно было договариваться по времени так, как удобно. Сначала мы встречались два раза в неделю, потом перешли на один раз в неделю, но по два часа. По темам Илья учитывал мои запросы, но также предлагал свои — из опыта работы в HFT и прохождения собеседований. Он объяснял новые вещи или помогал освежить то, что я уже знала, поэтому я могла в основном фокусироваться на практике. Между занятиями были домашние задания, Илья напоминал про них и заранее проверял. Для меня было особенно ценно получать фидбэк на решения, обсуждать спорные моменты и неоднозначные темы, например memory barriers. В результате у меня сложилась более цельная картина: какие темы нужно знать и как они связаны между собой. Илья также давал точечные рекомендации на полезные лекции и conference talks по темам, которые мы проходили. В итоге я решила достаточное количество практических задач, чтобы появилась уверенность перед собеседованиями. Когда мы завершили работу, я подумал, что из этого можно сделать неплохой курс подготовки к HFT: список тем понятен и ограничен, часть материалов удалось уже наработать. Ценность прохождения курса тоже понятна — HFT славится высокими доходами. Но понимая, что создание качественного курса — это долго и сложно («Пояса по C++» мы командой делали 3 года, «Алгоритмический фундамент программиста» я с подрядчиками делал 1 год), я сначала постарался узнать, а есть ли запрос на такой продукт. Спасибо всем подписчикам, кто откликнулся на просьбу поговорить. Вы наряду с другими респондентами дали мне понять, что ... запроса нет 🚫 Из общения я сделал такие выводы: — люди, всерьёз рассматривающие для себя HFT, предпочитают готовиться самостоятельно — они используют ChatGPT/Claude для составления roadmap подготовки и глубокой проработки каждой темы, не испытывая потребности в наставнике для этой работы — ценность во внешней экспертизе они видят только от человека, который много лет провёл внутри HFT — экономика всего этого мероприятия у меня не сошлась Так что делать курс подготовки к HFT я не буду. И по себе, и по окружающим я вижу, что в сфере наставничества нейросети всё больше отбивают себе территорию. Если в сфере обучения оффлайн навыкам позиции людей ещё весьма сильны (игра на барабанах, танцы, вождение автомобиля), то у наставников онлайн-навыков появился очень сильный и гораздо более дешёвый конкурент. И конкурировать с ним можно только своими опытом, чуйкой и интуицией. Если у вас есть запрос, связанный с C/C++ codebase, code review, PostgreSQL internals или подготовкой к интервью или публичным выступлениям, приходите поговорить через страницу на GetMentor — там полный список того, с чем я могу помочь. Отзывы тех, кто работал со мной, есть в отдельном канале.

В онлайн-тренажере для разработчиков CodeRun стартовал CodeRun Summer Challenge. В этот раз фокус челленджа как раз на Performance engineering — скорости + эффективности. Всего 15 задач, 11 языковых лидербордов и упор на производительность. Как всё устроено Три волны по 5 задач — от лёгких к сложным. Задачи выходят постепенно, стартовать можно в любой день до 17 июля. Баллы начисляются за скорость и эффективность решения. Это ровно то, что проверяют на сильных секциях: умеешь ли ты так, или пишешь «лишь бы прошло тесты». Призы 🥇 топ-1 по каждому из 11 языков → мерч-пак CodeRun 🏆 топ-3 общего зачёта → коллекционный лего-набор 🚀 топ-200 → скип контеста + пробное интервью в Яндекс Даже если не возьмёте приз, получите 15 качественных задач и поймёте, где проседаете по эффективности. На собесах такая ясность окупается лучше любого приза. Участвуем тут. Как вы относитесь к такой практике? Делитесь в комментариях 🔥

Когда «готово на 99%» — это ноль Недавно я проходил первый этап собеседования в одну голландскую HFT-компанию. Мне заранее озвучили формат: онлайн-тест на HackerRank, 2 часа, C++. Я ожидал, что это будет именно тест на знание языка. Перед началом даже немного волновался, потому что чувствую, что отстал от C++23/26. Думал, сейчас начнутся вопросы про новые тонкости стандарта, и будет больно. Вместо была одна большая алгоритмическая задача. Перед стартом я поставил галочку, что обещаю не использовать AI-инструменты. Такой вот формальный барьер от вайбкодинга. Думаю, HackerRank ещё и таймлайн написания кода умеет показывать, так что отличить живое решение от копипасты из AI, наверное, можно. Условие оказалось длинным и мудрёным. Мне потребовалось около 20 минут, чтобы понять, что вообще дано, что надо сделать и где в этой задаче задача. Потом примерно за 10 минут я придумал решение. Сейчас, уже после разбора, я знаю, что оно было правильным. Никакого rocket science там не было. Большой leetcode medium/hard: считать данные, разложить их по структурам, переложить в другие структуры, проверить несколько условий, а потом отвечать на запросы. Через полчаса после старта у меня было решение и оставалось полтора часа на реализацию. Казалось, что времени достаточно. Но кода надо было написать много. Я писал его руками, по старинке, постепенно сверху вниз. И в какой-то момент заметил, что до конца осталось 40 минут, а код ещё не дописан. При этом ощущение было нормальное: я продвигаюсь, всё под контролем. Тестировать я начал за 15 минут до конца. И вот тут стало понятно, что 15 минут — это катастрофически мало. Сначала я исправлял ошибки компиляции. Потом оказалось, что программа не проходит даже примеры из условия 😱 Потом я понял, что она вообще ничего не выводит. За минуту до конца мне уже ничего не оставалось, кроме как отправить тот код, который есть. Код не прошёл ни одного теста 😔 После теста я спокойно разобрался, в чём была проблема. Надо было не только считывать входные данные, но и проверять их на валидность. Я чуть неправильно валидировал ввод, и из-за этой ошибки любые входные данные признавались некорректными 😕 После исправления этого места код прошёл все тесты, которые у меня были. То есть алгоритм был придуман. Решение было реализовано. Основная логика работала правильно. Мне не хватило буквально 15-20 минут на отладку парсинга. И вот это неприятное место 🤦🏻‍♂️ Нас часто учат не быть перфекционистами. Не полировать бесконечно код. Не ждать идеального состояния. Доставлять ценность итерациями. Но есть ситуации, где всё, что не 100%, — это ноль. Если программа из-за одного бага в парсинге не проходит ни одного теста, никого не волнует, что внутри у неё правильный алгоритм. Никто не будет разбираться, что там почти всё сделано. Система видит: тесты не пройдены. До свидания. Эмоционально это странный опыт. С одной стороны, очень обидно. Такое ощущение, что Акела промахнулся. Я привык проходить скрининги и воспринимал это как подтверждение, что я всё ещё в форме. С другой стороны, это не похоже на полный провал. Я не сидел два часа перед задачей, не понимая, что делать. Я понял условие, придумал решение, написал код и после теста быстро нашёл последний баг. То есть конкретная попытка провалилась. Но из этого не следует, что провалился навык. Пожалуй, главный вывод для меня такой: на timed coding task важно не просто придумать решение. Важно достаточно рано получить хоть что-то работающее и оставить себе нормальное время на отладку. Потому что между «почти решил» и «решил» иногда лежит не 1% — иногда там лежит весь результат. Вам доводилось сталкиваться с подобным?

Странные вопросы на HFT интервью Продолжу тему собеседований в HFT, которую начал на прошлой неделе. Я говорил, что большинство компаний, по моему опыту, на технических секциях проверяют примерно один и тот же набор тем. Я пообщался с подписчиками, кто откликнулся на прошлый пост, — наши разговоры это подтвердили (хотя и были удивительные истории про глубокие вопросы в духе «расскажи в подробностях путь байта между двумя машинами через WebSocket» 😱). Сегодня хочу затронуть тему финалов (aka team fit interview). Они тоже проходят примерно по одной схеме — причём не только в HFT. Цель финала ясная — попытаться понять, что кандидат из себя представляет как человек и насколько он впишется в команду. Но иногда это делают довольно странными вопросами. Например, Оцените свой уровень владения C++ по шкале от 1 до 10 Мне задавали этот вопрос примерно в четырёх местах. И я искренне не понимаю, какой сигнал через него хотят считать. Я обычно пускаюсь в короткое рассуждение, что слегка отстал от C++23/26 и что там всегда есть, что ещё изучить, поэтому ставлю себе 7-8. Может, если я отвечу «10», они решат, что я слишком самоуверен и сразу дадут мне оффер, потому что в индустрии нужны те, кто действует, а не сомневается? 🤪 Или если я после пройденного зубодробительного C++-интервью скажу: «Ну так, на двоечку», то они увидят в этом не заниженную самооценку, а нестандартный образ мышления и тоже сразу дадут мне оффер? 😁 Если вас тоже о таком спрашивали, расскажите в комментариях, что отвечали. Какими задачами вы хотите заниматься? Этот вопрос, конечно, не настолько странный. Он раскрывает, что для человека важно в работе. Тем не менее... Если кандидат последние 15 лет делал в разных компаниях распределённые хранилища данных, то, скорее всего, он уже такой гуру в этом, что на очередной работе хочет сказать новое слово в этой теме. Но я всегда впадаю в ступор, когда слышу этот вопрос. Потому что какая разница, что я хочу делать, — все равно надо будет перекладывать JSON'ы делать что надо. Я много чем занимался и всегда делал те задачи, которые наиболее важны проекту в данный момент. Ну то есть я могу хотеть писать навороченные штуки на C++, про которые потом можно рассказать на конференции 😎, но у моего сервиса есть баги в проде, поэтому я пишу скучные тесты на Python, чтобы их найти и исправить. На вопрос про задачи я обычно отвечаю, что мне не так важно, что делать, гораздо важнее — с кем. Потому что классные и тяжёлые этапы моей карьеры всегда определялись окружающими людьми, а не скучностью или увлекательностью задач. Если вокруг токсичненько, то самая крутая задача не будет радовать. Если я нахожусь в конструктивной и уважительной обстановке, то не-sexy задачи, которые приносят понятную пользу, мне делать в кайф. Вы наверняка тоже сталкивались с таким вопросом. Расскажите в комментариях, что отвечаете. К сожалению, если ваши ответы на эти или подобные вопросы компанию не устроили, вы вряд ли узнаете, чем именно вы не подошли и над чем надо поработать, чтобы в следующий раз был другой итог. Большинство либо пропадают, либо кратко отказывают. Единицы работают с кандидатами в долгую и вкладываются в прозрачный фидбек (пару лет назад меня даже нанимали на такой проект). Ну и ещё есть классическое «Мы приостановили найм по этой позиции» и «Мы сделали выбор в пользу кандидата с более подходящим опытом». Я всегда возмущался, когда видел, что компания избегает давать фидбек после отказа. Но сейчас стал относиться к этому проще. В конце концов, такой стандарт индустрии даёт возможность и мне отказываться без разъяснений.

В прошлый четверг полтора часа проговорили с Антоном Касимовым об AI в образовании. Так вышло, что я забрал почти весь эфир 😆 Полтора часа — это прям долго, поэтому я сделал выжимку 7 самых сильных мыслей, прозвучавших за эфир: 00:00 — почему «код на любом языке программирования — это новый ассемблер» 01:31 — бухгалтеры пережили Excel, переживёт ли кодинг AI 02:43 — онлайн-курсы в 2026: зачем они нужны, если весь материал есть в ChatGPT/Claude 10:29 — как я сам пишу посты в канал с помощью AI (и почему это не «AI написал за меня») 14:38 — почему AI не натренирует тебя на переговорах о зарплате 21:07 — в чём теперь ценность ментора, если знания и без него можно достать 26:44 — производительность труда выросла в 50 раз за 100 лет. А свободного времени у нас стало больше? Сам эфир получился живой, спасибо Антону, что в кадре было не только моё бубнение. Какая из этих 7 тем зацепила сильнее всего — или может, у вас уже есть свой ответ на последний вопрос про продуктивность? Upd. Полная запись доступна на YouTube 😉

Что изучать программисту, когда повсюду Claude? Тему с HFT продолжу в следующих постах, а сейчас анонс эфира, куда меня пригласили гостем: 📢 11 июня в 19:00 МСК — совместный эфир Антона Касимова и Ильи Шишкова Как учиться в IT, когда AI всегда под рукой? Поговорим о том, как меняется обучение и развитие специалистов в эпоху Claude, ChatGPT и других AI-инструментов. 👤 Спикеры: — Антон Касимов, CEO Gals Software, автор и преподаватель курсов по системам мониторинга Автор канала Мониторим ИТ — Илья Шишков, R&D разработчик в СберТехе, ex-Яндекс, создатель обучающих программ по переговорам в IT, алгоритмам и C++, через которые прошли тысячи людей Автор канала Илья Шишков: код, собесы, IT Обсудим: 🔹 Чему стоит учиться айтишникам в 2026 году 🔹 Нужны ли сегодня курсы и менторы 🔹 Как эффективно использовать AI для обучения 🔹 Стоит ли платить за обучение или можно справиться самостоятельно 🔹 Как развивать карьеру и оставаться востребованным специалистом Формат — открытая дискуссия, обмен опытом и ответы на ваши вопросы. 📅 11 июня, 19:00 МСК 📝 Регистрация на эфир Оставляйте вопросы в комментариях — самые интересные разберём в эфире 🚀