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

В прошлую среду полтора часа проговорили с Антоном Касимовым об 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 тем зацепила сильнее всего — или может, у вас уже есть свой ответ на последний вопрос про продуктивность?

Привет! Напоминаю, что через час, в 19:00 мск будет эфир "Чему учиться айтишнику, когда повсюду AI". Буду в гостях у Антона Касимова, большого специалиста по observability в больших IT-системах, а также автора курсов по этой теме. Для участия переходите в бота: там будут ссылки на подключение и все напоминания. Увидимся 👋

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

9 собесов в HFT — один паттерн Первый пост этого лета — как и обещал, о моём опыте собеседований в HFT. Изучая заметки о своих собеседованиях, я понял, что проходил испытания в 9 разных HFT-компаний. Казалось бы, компании сильно разные и должны как-то по-разному собеседовать кандидатов. На деле — детали отличаются, но по сути почти везде проверяют один и тот же набор навыков. 1. В 100% случаев надо писать код на C++. Чаще всего — алгоритмическую задачу. Иногда задача связана с предметной областью: написать книгу заявок, сопоставление приказов, параллельную обработку событий в торговой системе. Иногда это просто классическая алгоритмическая задача без всякого финансового контекста. Но суть одна: можешь ли ты быстро понять условие, придумать решение, аккуратно реализовать его на C++ и не утонуть в краевых случаях. 2. Большинство компаний спрашивают про то, как работает компьютер. Про процессор, кеши, виртуальную память, когерентность кэшей, false sharing. Почему одна программа тормозит, хотя асимптотически всё хорошо. И это уже не уровень «ну, есть L1, L2, L3». Там довольно быстро становится видно, понимаешь ли ты, как исполняется твой код на железе. 3. Почти везде всплывают сети У меня опыта в сетях не так много, поэтому глубоко меня обычно не копали. Я честно говорил, что понимаю HTTP и базовые вещи, но не работал плотно на уровне TCP, kernel bypass и всего такого. Но сам вопрос возникал регулярно. И понятно почему: если компания зарабатывает на скорости, ей важно, чтобы разработчик понимал, где могут теряться микросекунды и как это исправить. 4. Глубина знания C++ Не «язык программирования вообще», а конкретно C++ со всеми его прекрасными способами выстрелить себе в ногу. Могут дать тест. Могут показать код и попросить объяснить, что он делает. Могут попросить написать решение так, чтобы там были шаблоны, виртуальные методы, концепты или аккуратная работа с move-семантикой. И здесь снова важно не просто знать слова copy elision, std::move, virtual dispatch или cache line. Важно понимать, какой код реально получится после компиляции и как он будет исполняться. Этот мой опыт наталкивает на интересный вывод. Если цель — устроиться в HFT, есть вполне ограниченный набор тем, которые достаточно освоить (правда достаточно глубоко и обязательно набрав реального опыта), чтобы чувствовать себя уверенно на техническом собеседовании. Просьба Мне стало интересно выйти за пределы личного опыта. Если вы сейчас целитесь в HFT или уже ходили на такие собесы, у меня к вам просьба — поставьте + в комментариях или напишите в личку @ishfb. Я хочу минут за 15-20 задать ряд вопросов про процесс подготовки и опыт общения с компаниями. Взамен расскажу, что сам заметил по 9 HFT, где собеседовался.

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

— В каком зале Третьяковки Репин Стрекоза? — Картина Ильи Репина «Стрекоза» находится в зале Репина в Третьяковской галерее — Спасибо, кэп! А номер у зала какой? — Я не нашла в номер зала. Посмотрите на сайте Третьяковской галереи или в отзывах на Яндекс Картах

Когда AI-ассистент поисковой компании предлагает посмотреть что-то сайте вместо того, чтобы сделать это самостоятельно, — это, на мой взгляд, epic fail 🤦🏻‍♂️ Вообще у меня сложилось такое ощущение: если ChatGPT — это мой бро, который общается на понятном мне языке, понимает, в какой я сейчас ситуации, и всеми силами старается помочь, то Алиса AI — это такая вышколенная девушка на ресепшн, корректная до скрежета в зубах, с ног до головы обложенная правилами корпоративной этики и имеющая только одну цель — не накосячить. Иногда она оказывается очень полезной, но в большинстве моих кейсов получается, как на скриншотах. А какой AI вам помогает больше всего?

Пока все вайбкодят, я хожу по художественным музеям В предыдущем посте я рассказал про собеседование в Яндекс. Дальше ещё хочу поделиться опытом нескольких собеседований, но сначала сделаю небольшое лирическое отступление. Вокруг меня сейчас очень много разговоров о том, как искусственный интеллект поменял разработку. Из каждого утюга доносится слово «вайбкодинг». У меня пока мало в этом опыта, но AI сделал для меня интересной живопись! Когда были в Нью-Йорке и ходили в MoMA. А сегодня выбрались с семьёй в Третьяковскую галерею. Фотографии выше как раз об этом. Раньше художественные музеи были для меня довольно мучительным опытом. После7-10 просмотренных картин мозг устаёт, и всё начинает сливаться в одну бесконечную площадь холстов. Подходишь к очередной картине и думаешь: «Окей, а почему она висит в музее? Что в ней такого значительного? Чем она отличается от миллионов других написанных картин?» Но музей обычно не отвечает на этот вопрос. На табличке написано название, автор, годы создания и материал: «холст, масло». Как будто слово «масло» должно объяснить мне, почему передо мной великая работа, а не просто очередная старая картина. И вот тут LLM внезапно оказались очень полезны. В MoMA и в Третьяковке я сначала просил ChatGPT построить мне маршрут по залам: «покажи 10–15 главных работ музея, чтобы я не распылял внимание и не пытался охватить всё сразу». Получался понятный маршрут: иди в этот зал, смотри Ван Гога; потом туда, смотри Пикассо; в Третьяковке — Васнецова, Репина, Серова и так далее. А дальше я подходил к картине и прямо голосом надиктовывал: «Я стою перед “Богатырями”. Объясни, как её смотреть и на что обратить внимание». И получал короткий, но ёмкий рассказ: что здесь важно в композиции, почему фигуры стоят именно так, почему это не картина про войну, хотя на первый взгляд ждёшь эпический замес. Кстати, «эпический замес» — это важная часть опыта. Я не уверен, что музейный гид использовал бы такие слова. А ChatGPT может объяснять не высоким музейным языком, а нормальным человеческим. Иногда почти разговорным. И от этого картина становится только доступнее. Особенно интересно так смотреть Пикассо или Малевича. Например, на фотографии выше есть работа Малевича «Белое на белом». Если просто подойти к ней в музее, первая реакция довольно предсказуемая: «Ну и что это? Белый квадрат на белом фоне?» Без объяснения я бы прошёл мимо и ничего не понял. А с пояснением становится видно, что за этим стоит целая система взглядов: супрематизм, попытка убрать из живописи предметный мир, оставить форму, цвет, пространство и само ощущение движения. Можно с этим соглашаться или не соглашаться, но хотя бы становится понятно, почему эта работа вообще попала в музей. В итоге полтора часа в музее превращаются не в усталое блуждание между картинами, а в сфокусированное погружение. Я выхожу не с ощущением «сходил разок — и хватит», а с новыми знаниями и реальным интересом. Пока все обсуждают, как AI помогает писать код, я внезапно обнаружил, что он помогает ещё и смотреть картины. Для меня это один из самых неожиданных способов применения LLM. Всё, лирическое отступление закончил. Дальше — про собесы в HFT.

Собеседование в Яндекс: где мне помог ChatGPT? Раз уж в предыдущем посте мы затронули тему подготовки к собеседованиям, давайте поделюсь своим недавним опытом. В декабре я рассказывал про новый процесс собеседования разработчиков в Яндекс. В начале года мне предоставилась возможность опробовать его на себе. Расскажу, как это было. TL; DR Стало гораздо лучше, быстрее и понятнее. Самое главное — у меня было три секции! Три! Не 5, не 10, не 17 — только 3, каждая по часу. Вот что на них происходило. 1. Скрининг Дали готовый код. Там была заготовка логики и тесты. Надо было понять код, проверить, нет ли багов в тестах. Дальше надо было реализовать логику так, чтобы тесты в итоге прошли. Это всё как обычно в онлайн-редакторе без запуска кода и компиляции. Причём в коде была многопоточка — на мой взгляд, не самая простая. Я удивился, что процесс начался именно с такой секции, но в целом выглядит логично — так как я в компании уже работал, эта секция даёт быстро понять, не растерял ли навыки на тот грейд, который у меня был. 2. Алгосекция Здесь были старые добрые leetcode-like задачи. Решил обе, но пришлось попотеть. Перед секцией я 3-4 дня решал leetcode по часу плюс положился на прежний опыт. Этого хватило, чтобы справиться с обеими задачами в срок, но это не было прям лёгкой прогулкой. Так что настоятельно рекомендую перед такими секциями выделить побольше дней на прорешивание leetcode, просто чтобы вернуть себя в форму, если вы давно этого не делали. Минутка AI-рефлексии Когда я шёл в этот процесс, мне было ещё интересно узнать, насколько сейчас проще собеседоваться на разработчика, имея под рукой ChatGPT/Claude/etc. Мне показалось, что вообще не проще, потому что я не понимал, а куда в процессе секции эти GPT-воткнуть? Я всё время был в диалоге с ревьюером, постоянно вслух рассуждал и комментировал, какой код и почему я пишу. В этом потоке совершенно не понятно, как можно уйти в ChatGPT, сформулировать ему задачу, а потом ещё каким-то образом делать вид, что это ты сам из головы придумал. У меня только на скрининге был момент, когда мне надо освежить в голове один API стандартной библиотеки C++, и я понял, что мне это проще сделать в ChatGPT, чем копаться в cppreference. Я сказал об этом интервьюеру, он кивнул, и мы пошли дальше. 3. Оценка опыта Впервые проходил такую секцию. Нужно было заранее подготовить рассказ о проекте, в котором я сыграл ключевую роль и в котором уже есть понятные результаты. И вот это как раз та секция, где ChatGPT жжёт 🔥 Но не чтобы облапошить интервьюера, а чтобы как следует упаковать свой опыт и выгодно его преподнести (недаром я недавно говорил о важности упаковки). Сначала я думал: «Ну я просто пишу код... Какие у меня есть проекты с ключевой ролью и понятными результатами?» Потом придумал 4 кандидата на роль таких проектов. Про каждый из таких проектов я надиктовал в ChatGPT всё, что есть в голове, и поставил ему задачу выбрать тот, который лучше всего характеризует меня как сильного специалиста. После пары итераций был отобран топ-1 кандидат для рассказа на секции. Дальше там же я сделал хорошие формулировки результатов и своего вклада, и у меня получилась хорошая презентация проекта. С ней я и пришёл на собеседование. Интервьюер много спрашивал меня и вширь, и вглубь — было интересно, и исход секции был положительным. Здесь хочу отметить важное — ChatGPT помог мне не нафантазировать то, чего не было, а именно посмотреть на мою работу с большей высоты, «увидеть за деревьями лес» и презентовать проект целиком. В общем, мой вам совет — пользуйтесь. Итоги В итоге я на своём опыте прошёл новый процесс собеседований разработчиков в Яндексе, и считаю, что компании правда удалось сделать его более быстрым и понятным для кандидатов. К тому же мне удалось найти win-win подход к применению AI в подготовке к собеседованиям — ChatGPT сильно помог выгодно презентовать свой опыт. Расскажите в комментариях, как вы применяете AI для подготовки и прохождения собеседований?

Я уже писал, что, по моим ощущениям, мы живём в золотое время ИИ. Сейчас он не просто подсказывает, а способен полноценно помогать.  Но помогать можно, делая за человека все, а можно — указывая путь и оставляя пространство для собственных решений, ошибок и роста. Именно по такому пути реализовали новую фичу «Кодерун AI» в онлайн-тренажёре для разработчиков CodeRun. В нём можно решать задачи, прокачивать скиллы, соревноваться с другими разработчиками и готовиться к техсобесам. Новая фича связана с интеграцией AI-помощника, который, когда ты застреваешь на задаче, дает не готовое решение, а небольшую подсказку. Бонусом Кодерун AI объясняет примеры из условия и генерирует тест-кейсы для проверки решения. Таким образом AI-помощник не додумывает за тебя, а делает ровно то, что делал бы хороший наставник, помогая пройти путь самому. Чтобы попробовать, заходите в задачи на CodeRun, открывайте вкладку «Кодерун AI» и пользуйтесь. Пока фича в бете и нужна авторизация, а лимит 20 бесплатных запросов.

Claude - уже вчерашний день В моём информационном пузыре очень много людей говорят про Claude: "Я за 2 вечера сделал то, на что уходил месяц", "Мне больше не нужны программисты, я за выходные сам сделал себе все нужные сервисы" и т.д. Claude и правда хорош. Но когда мы были в Нью-Йорке, меня удивило, что там рекламируют другие сервисы, указывая на недостатки Claude (см. первое фото ниже). Там вообще рекламируют очень много разных AI-сервисов, о которых я ничего не слышал. Но ещё больше меня удивило, что их рекламируют в метро! 🤯 Там, где в Москве рекламируют вклады, кредиты и недвижку, в Нью-Йорке размещают рекламу exa.ai. Для меня выглядит крайне необычно. Как если бы на метро Курская повесили плакат с рекламой Giga IDE...

Как командная офлайн-игра может познакомить с инженерной культурой Москвы Думаю, никто не будет спорить, что офлайн-ивентов для айти-спецов сейчас предостаточно, можно ходить на подобное чуть ли не каждую неделю. Обычно, речь идет про встречи, где на первый план выходят доклады и нетворкинг: классические форматы, которые понятны всем. Но мне особенно запоминаются ивенты, которые стремятся придумать что-то необычное или как минимум перепридумать что-то знакомое. Один из таких пройдет 23 мая — Яндекс приглашает на командную офлайн-игру «Рекурсия по городу». И это как раз тот случай, когда формат перекрутили, потому что упор не на практику хакинга, а на изучение инженерной истории Москвы. По легенде, часть системы ушла в бесконечную рекурсию: тесты падают, пул-реквесты конфликтуют, финальный merge так и не случился. Командам предстоит починить её, перемещаясь по городу, находя «флаги» и разбирая архитектуру проекта. Если всё сделать правильно — релиз состоится. Все 30+ локаций связаны с историей российского IT: от МГУ и Центра фундаментальных исследований РАН до Шуховской башни и офиса Яндекса в «Красной Розе». В ряде заданий участникам будут помогать сотрудники компании. Задачек много, время ограничено, так что строить оптимальный маршрут придётся самим. При этом можно выбрать и другой путь: решать задачи в своём темпе, проживая итерацию целиком, и шаг за шагом знакомиться с инженерной культурой. Для участия нужно собрать команду из 2-5 разработчиков с любым стеком, но, если своей нет, на старте помогут найти сокомандников и сформировать состав. Начало 23 мая в 17:00 в БЦ «Красная Роза» на Льва Толстого 16 (офис Яндекса). После квеста участников ждет финальный merge, награждение и вечеринка. Подать заявку на участие можно здесь.

Ты сделал хорошо. Почему это никому не важно? Я сейчас в отпуске, и мы с семьёй поехали в США, пока ещё действует наша туристическая виза. Несколько дней гуляли по Нью-Йорку: прошлись по Пятой авеню, сплавали к Статуе Свободы, посмотрели на Бруклинский и Манхэттенский мосты, сходили в Американский музей естественной истории. И в какой-то момент я поймал себя на мысли: а почему именно эти места кажутся обязательными к посещению? 🤔 Да, Статуя Свободы — впечатляющее сооружение. Мосты Нью-Йорка — мощная инженерная работа. Музей естественной истории — огромный и очень качественно сделанный музей. Но людей туда приводит не только качество само по себе. Людей приводят истории. Статуя Свободы сотни раз появлялась в кино, на открытках, в заставках и новостях. Бруклинский и Манхэттенский мосты столько раз взрывали, разрушали и эффектно показывали в фильмах, что они стали узнаваемыми символами города. А музей естественной истории для огромного количества людей — это не просто музей, а место, где происходила «Ночь в музее». Мы, например, пошли туда во многом потому, что перед поездкой показали дочке все три части фильма. И повели её смотреть «Дам-дам». Без этой истории музей был бы для неё просто ещё одним большим зданием с экспонатами. А так это место, где оживает знакомый мир. При этом важно: музей сам по себе действительно хороший. Это не пустышка, которую красиво продали. Там огромная коллекция, сильная экспозиция, классно выстроенный опыт для детей и взрослых. Но именно упаковка дала нам причину выбрать его среди десятков других мест в Нью-Йорке. И вот тут я подумал про нас, программистов. Мы часто пренебрегаем упаковкой того, что делаем. Нам кажется, что если система технически сложная, код аккуратный, архитектура продуманная, а решение реально полезное, то этого достаточно. Люди сами должны оценить. Но обычно не должны. У людей вокруг слишком много сигналов. Слишком много задач, проектов, кандидатов, докладов, статей, репозиториев и внутренних инициатив. Чтобы на вашу работу обратили внимание, у неё должна быть понятная упаковка. Что это вообще такое? Это не обязательно маркетинг в плохом смысле. Упаковка — это ответ на вопросы:

— что именно я сделал? — почему это было сложно? — какую проблему это решает? — кому от этого стало лучше? — почему на это стоит обратить внимание?

Хорошо сделанный продукт без упаковки так же плох, как хорошо упакованная пустышка. В первом случае ценность есть, но о ней никто не узнаёт. Во втором — внимания много, но внутри ничего нет. Нормальный вариант — когда есть и содержательная работа, и внятное объяснение, почему она важна. Причём упаковка — это отдельная работа. Её нельзя нормально сделать за один вечер (даже с ChatGPT/Claude/etc 😜). Нужно думать, выбирать акценты, убирать лишнее, искать понятные примеры, переводить техническую сложность на язык ценности. И, кажется, это один из навыков, который современным инженерам всё сложнее игнорировать. Потому что мало сделать хорошую работу. Нужно ещё дать людям причину этой работой заинтересоваться. А вы как относитесь к упаковке своей работы: считаете это важной частью инженерного роста или всё-таки чем-то внешним и не очень нужным?

Don't even try to PG_TRY Ранее я уже рассказывал об особенностях дизайна исключений в PostgreSQL (первый пост, второй пост). Вы недавно проголосовали за то, чтобы внутрянки PostgreSQL было больше, так что я сделал видео про реализацию исключений на языке С в PostgreSQL. Залез в код, раскрыл для вас все макросы, показал то что скрыто 😆 Что я рассказал в видео: — для чего именно сделали исключения в PostgreSQL — как на языке С реализовали исключения в PostgreSQL, до самых глубоких деталей — что будет, если нарушать гайдлайны использования PG_TRY — что будет, если не поймать выброшенное исключение — почему в коде PostgreSQL опасно использовать C++ Таймкоды видео: — 00:00 — начало — 01:01 — концепция исключений в языках программирования — 02:56 — пример использования PG_TRY в коде PostgreSQL — 05:26 — с какой целью в PostgreSQL применяется PG_TRY — 07:16 — что ускользает из внимания в документации — 09:48 — как внутри устроен PG_TRY? — 14:30 — магия функции siglongjmp — 17:12 — почему после PG_CATCH нельзя просто продолжить? — 24:02 — где обрабатывается исключение, если нет ни одного PG_CATCH — 28:35 — чего нельзя делать внутри PG_TRY/PG_CATCH и причём тут C++ — 33:49 — итоги Можно смотреть: — тут в Телеграм — 😉 на моём YouTube-канале — 😄 на странице в ВК (скоро)

Когда производительность упирается в железо, а когда в архитектуру? Как проектировать надежные и быстрые системы на C++? Какие подходы используют разработчики компиляторов, рантаймов и системного ПО? Ответы на эти и другие вопросы найдем на C++ Russia — конференции для C++ разработчиков, инженеров, разработчиков компиляторов, тимлидов и исследователей. 📅 7 мая 2026 — онлайн-день 📅 16–17 мая 2026 — Москва + онлайн Три дня докладов, воркшопов и общения C++ сообщества. Будем говорить про язык и инженерные задачи: архитектуру, производительность, управление памятью, многопоточность и разработку низкоуровневого ПО. Новое в этом году — системное программирование: компиляторы, рантаймы, операционные системы, управление ресурсами и дизайн языков программирования. В карточках собрали несколько топовых докладов из программы. Используйте промокод, чтобы купить персональный билет со скидкой — IMHIRED Купить билет Реклама. ООО «Джуг Ру Груп». ИНН 7801341446

Ненавижу покупать авиабилеты ✈️ Для меня покупка авиабилетов — как хождение по минному полю. Никогда не знаешь, где тебя ждёт засада: где по-тихому впихнут страховку, где уберут ручную кладь из тарифа, где попытаются взять деньги за выбор места. Нужно внимательно сверять размеры чемодана с правилами ручной клади, проверять вес багажа, паспортные данные, даты, время вылета, аэропорты. Один раз отвлёкся — и либо переплатил, либо сам себе создал проблему. У меня каждый раз на это уходит куча сил и времени. И каждый раз у меня остаётся неприятное ощущение, что система как будто проектировалась не для того, чтобы я быстро и спокойно купил билет, а для того, чтобы я где-нибудь ошибся. Я хорошо помню, как лет 20 назад покупка билетов в Интернете была символом прогресса 🚀 Тогда вокруг меня многие ещё ездили за железнодорожными билетами на вокзал: стояли в очередях, толкались, ругались. А самые продвинутые люди с лёгкой гордостью говорили: «А я купил билет в интернете 😎». Это ощущалось как победа технологии над хаосом. Быстрее. Проще. Удобнее. А потом что-то сломалось. Все эти неочевидные формы, галочки, допродажи, ловушки в интерфейсе — это же не случайность. Наверняка за ними стоят A/B-тесты, метрики, продуктовые гипотезы. В таком варианте авиакомпания зарабатывает больше. То, что пассажиру при этом хуже, — уже побочный эффект. Когда я только заходил в IT, мне нравилась мысль, что мы создаём технологии, которые делают жизнь людей проще. А правда оказалась в том, что современные Интернет-технологии часто делают жизнь сложнее — просто потому, что так выгоднее 😔 И мне кажется, с ИИ мы сейчас проживаем очень похожий момент. Сегодня искусственный интеллект во многом стоит на стороне пользователя. Он помогает быстрее разобраться, принять более осознанное решение, снять часть рутины. Да, он ошибается. Да, у него полно ограничений. Но по моему ощущению, он пока что помогает человеку, а не манипулирует им. Примерно так же когда-то ощущался Интернет! И у меня есть страх, что сейчас — золотое время ИИ. Что через сколько-то лет появится достаточно способов использовать ИИ уже не на благо пользователя, а на благо чьей-то выручки. Не чтобы помочь тебе лучше выбрать, а чтобы тоньше подтолкнуть тебя к нужному решению. Не чтобы снять нагрузку, а чтобы монетизировать твоё внимание, тревогу и слабые места ещё эффективнее, чем это делает Интернет. Может быть, платная подписочная модель частично от этого защищает. А может, и нет. Кто знает, что будет через 10 лет. Так что, возможно, нынешний момент — это то время, которым стоит наслаждаться. Пока технология ещё чаще помогает, чем манипулирует. P.S. С 27 апреля по 14 мая еду в США воспользоваться туристической визой, пока она ещё действует 🇺🇸. В программе Нью-Йорк, Ниагарский водопад, Лас-Вегас, Гранд-Каньон и Лос-Анджелес. Пишу сюда, потому что в прошлую поездку удалось познакомиться и интересно пообщаться с подписчиком канала. Вдруг и в этот раз это сообщение приведёт к интересной встрече. А как вам кажется: сейчас золотое время ИИ?

Непозволительно высокая цена плохого API В PostgreSQL есть конфиг с параметрами запуска СУБД — postgresql.conf. В нём параметры заданы в формате key = value. Например,

port = 5432
max_connections = 100
authentication_timeout = 1min

А ещё в PostgreSQL можно создавать расширения — по сути плагины. Если расширение хочет доставать из postgresql.conf какие-то свои параметры, оно должно определить их с помощью функции DefineCustomStringVariable. Вот пример из расширения basic_archive:

void _PG_init(void) {
  DefineCustomStringVariable(
    "basic_archive.archive_directory",
    "Archive file destination directory.",
    NULL,
    &archive_directory,
    "",
    PGC_SIGHUP,
    0,
    check_archive_directory, NULL, NULL);

  MarkGUCPrefixReserved("basic_archive");
}

Здесь задаётся название параметра, указатель на переменную, в которую надо записать его значение, хук проверки корректности значения и т.д. Главное, на что я хочу обратить ваше внимание, — этот вызов выглядит максимально декларативно. Начиная с названия — DefineCustomStringVariable — и заканчивая тем, что мы передаём туда пачку параметров, которые влияют на разные стадии времени жизни сервера СУБД. Видя такой вызов, я ожидаю, что он добавит это всё в какой-то список параметров конфига. А применяться это будет когда-то потом, когда мы будем парсить конфиг. Более того, если заглянуть в её реализацию, она, на первый взгляд, так и выглядит. Зачем ты всё это рассказываешь? postgresql.conf читается при старте сервера СУБД. Если в нём есть ошибки (например, указан путь к несуществующему файлу), надо аварийно прервать запуск сервера и сообщить об ошибке в лог. Кроме того postgresql.conf можно явно перечитать, когда сервер уже запущен. В этом случае об ошибках надо просто сообщить в лог, сохранив прежние значения параметров и продолжив работу. У меня была задача реализовать такое поведение для параметра в моём расширении. Я был уверен, что DefineCustomStringVariable делает такое из коробки, потому что расширения для PostgreSQL создаются уже десятки лет... Как же я был не прав... Я не буду перегружать вас, рассказывая весь свой путь, перейду сразу к финалу: 👉 у меня ушло примерно 2 часа — 2 часа, чтобы добавить поддержку нового параметра в конфиге, Карл! 👉 оказалось, что DefineCustomStringVariable сразу выполняет парсинг параметра из конфига, запуск всех хуков и инициализацию переменной, а не просто добавляет параметр в список. И важно, чтобы парсинг работал в режиме «сообщи об ошибке и продолжи со старым значением» 👉 чтобы парсинг падал при старте СУБД, нужно отдельно вручную вызывать его в режиме «fail fast» Итого я считаю, что DefineCustomStringVariable — пример плохого API, который, во-первых, не позволяет решить простую типовую задачу быстро и легко, а во-вторых, требует детального понимания своей реализации, чтобы пользоваться им правильно. Ок, а правильно-то как? Мне в голову приходят две идеи. 1. Переименовать в DefineAndTryParseCustomStringVariable. Да, название перегружено, но оно хотя бы явно даёт понять, что парсить будем сразу. Это тут же поднимает вопрос, что происходит, если распарсить не удалось, и позволяет быстрее прийти к пониманию, что для «fail fast» надо писать отдельный код 2. Добавить отдельную функцию для use case «добавить параметр расширения» — AddExtenstionGuc(...). Внутри она бы делала DefineCustomStringVariable, а потом вызывала бы парсинг в режиме «fail fast». Неидеально, но решает пользовательскую задачу «добавь параметр конфига правильно». ❗️Итого, неудачный API design работы с параметрами конфига в расширениях стоил мне 2 часов рабочего времени, которые я мог бы уделить менее тривиальным задачам. Пока все программисты не превратились в тимлидов, у которых кода касаются только AI-агенты, за удобством и интуитивностью API всё ещё актуально следить.

Как проходят собеседования в HFT? Пока я занят инфраструктурной работой, связанной с этим каналом, напомню, что у меня есть подборки постов с историями прохождения собеседований в разные компании. Сегодня хочу поделиться такой подборкой про мой опыт собеседования в одну из HFT-компаний: 1. Когда пригодилось умение корректно писать двоичный поиск 2. Проектируем API классов на С++ прямо на собеседовании 3. Самое сложное собеседование по C++ в моей жизни 4. Как я нагуглил решение задачи прямо во время собеседования Прочитайте посты, чтобы узнать, какие именно навыки пригождаются для успешного прохождения собеседований в HFT, а также какой уровень владения C++ и алгоритмами достаточен для этого. Enjoy!

Сегодня целый день читаю в телеграм-каналах о полной блокировке и недоступности Телеграма с 1 апреля...

Три главных инсайта с AI DevDay Я сходил на второй AI Dev Day в Яндексе. Его главное отличия от первого мероприятия: позвали спикеров из других компаний и сфокусировались не на инструментах, а на анализе эффективности использования AI в разработке. И у меня после него осталось три чётких инсайта. 1. Концепция AI-first разработки Это подход, в котором разработчик по умолчанию не пишет код сам. Он ставит задачу агентам, даёт им время её выполнить, и дальше подключается только там, где это действительно нужно: посмотреть результат, поправить, переписать, если получилось плохо. То есть могут быть задачи, где разработчик вообще не пишет код. Он только формулирует задачу и принимает результат. Это то, куда сейчас движется индустрия. В последнее время я и сам стал на подобном себя ловить. Есть задачи, где нет исследования: нужно поправить несколько файлов, написать тесты, всё это прогнать и довести до рабочего состояния. Раньше это был режим «сел и сделал». А сейчас у меня первая мысль — «может, проще поставить задачу и проверить, что получилось». Это уже другой тип работы. Ты становишься не тем, кто пишет код, а тем, кто управляет тем, как он пишется, и главное — несёт ответственность за то, что получилось. 2. Внедрение AI происходит крайне неравномерно. В моём информационном пузыре сейчас все обсуждают ClawdBot, OpenClaw и подобные штуки. Создаётся ощущение, что «все уже там». На митапе я специально спрашивал всех подряд: кто реально пользовался и получил пользу. Я не нашёл ни одного. В то же время на одном докладе рядом со мной сидел человек, который с помощью Claude desktop возился с какими-то документами. И это хорошо показывает текущую картину. С одной стороны — хайп и ощущение, что всё уже произошло. С другой — только точечное использование. Так что внедрение AI-инструментов очень неравномерное и сильно искажается инфошумом. 3. Как выглядит разработчик будущего Разработчик будущего благодарит за поездку и просит поставить оценку в Яндекс.Go 🤪. Если смотреть на горизонт лет пяти, то это не «все станут не нужны» и не «все будут писать промпты». Разработчик по умолчанию становится кем-то вроде engineering manager — человеком, который: — понимает разработку глубоко — ставит задачи — контролирует исполнение — больше думает про архитектуру — понимает продуктовый и бизнесовый смысл Он редко пишет код руками. Он управляет системой из агентов, которые пишут код, тестируют, пробуют, ошибаются и приносят результат на ревью. В этой модели резко возрастают другие навыки: — умение формулировать задачу — умение переключаться между контекстами — способность вести несколько задач параллельно — способность держать целостную картину То есть ты начинаешь менеджить не людей, а процессы и агентов. Видео докладов есть на 😉 YouTube и 😄 ВКвидео. Расскажите в комментариях, начинаете ли вы уже мыслить в AI-first режиме, когда берётесь за очередную задачу? P. S. Я стараюсь выпускать 1 пост в неделю. Вероятно, в ближайший месяц посты будут выходить пореже, потому что надо уделить время подключению к каналу дополнительных площадок. Спасибо, что остаётесь здесь, но соломку надо подстелить.