Программирование *

Привет! Хочу поделиться историей о том, как я пытался трудоустроиться в Яндекс в начале 2026 года. Только факты, без эмоций. От каких‑либо выводов также воздержусь.

Немного контекста. Меня зовут Дмитрий, 44 года, C++/Go разработчик, стаж почти 20 лет, в том числе в крупных международных компаниях. Разрабатывал софт для mobile, desktop, backend, инфраструктурные сервисы. Осенью 2023, имея полупассивный доход, я решил взять перерыв в карьере, с целью сосредоточиться на личных приоритетах и «перезагрузиться». В течение этого времени продолжал поддерживать свои навыки разработчика, держал руку на пульсе индустрии. В итоге, личное разгрёб, перезагрузился, полностью готов к продолжению карьеры в ИТ, ищу работу. Обо всём этом прямо написал в резюме, чтоб предвосхитить вопросы. Да, насчёт резюме, тут ссылку на него давать не буду, пост не для этого; cкажу лишь, что резюме я уделил довольно много внимания, и оно… ну, нормальное.

Итак, в декабре 2025 со мной связался HR из Яндекса с предложением пообщаться насчёт вакансий в инфраструктурные команды. В прошлом я уже несколько раз собеседовался в Яндекс, но обычно отваливался на второй технической секции. Но последнее время активно готовился к собеседованиям и практиковался на LeetCode, и решил попробовать ещё раз. С HR пообщались хорошо. Он сказал что процесс найма в Яндекс в backend сейчас полностью унифицирован, такие‑то секции. Ок, назначили первую секцию — лайвкодинг, скорее всего многопоточка.

Первая секция. Действительно многопоточка. Задачка не то чтоб простая, но и не супер сложная, во время уложился, решил. HR пишет что всё отлично, интервьюер оценил меня высоко — и в техническом плане, и по общению. Назначаем вторую секцию, алгоритмическую, на после праздников. Все праздники готовился, решал LeetCode.

Знакомая ситуация: просишь Claude Code добавить авторизацию — он переписывает половину проекта. Просишь поправить одну функцию — получаешь удалённые тесты и новую зависимость, о которой не просил. За час строишь рабочий прототип, а потом три часа разгребаешь то, что Claude наворотил при «улучшении».

Я Python-бэкенд разработчик, веду свою компанию CREATMAN и кожу в основном один. У меня нет роскоши держать QA-инженера, который будет ловить регрессии после каждого промпта. Мне нужно, чтобы AI-агент помогал быстрее шипить, а не создавал новые проблемы.

После нескольких недель исследования — чтения доков, обсуждений на Reddit, разбора чужих сетапов — я собрал конфигурацию, которая реально работает. Собрал всё в открытый репозиторий с готовыми файлами: claude-code-antiregression-setup. В этой статье — что именно и почему.

В прошлую пятницу я объяснял джуну, почему его код на отсортированном массиве работает в шесть раз быстрее, чем на неотсортированном. Тот же массив, тот же алгоритм, и те же данные. Просто в другом порядке. Джун смотрел на меня как на сумасшедшего и, честно говоря, я его понимаю.

Потому что ответ звучит безумно: процессор внутри вашего ноутбука постоянно пытается предсказать будущее. Буквально. Он гадает, какая ветка if выполнится ещё до того, как условие будет вычислено. И на отсортированных данных ему угадывать проще.

Ну, давайте разбираться.

Показываю, как запустить локальную LLM и подключить её к IDE за 15 минут, а также четыре бесплатных облачных альтернативы.

Локальный вариант: LM Studio + Qwen3-Coder + Kilo Code. Работает офлайн, без подписки и лимитов на запросы.

Облачные варианты: Kilo Code со своими бесплатными моделями, Qwen Code с 1 000 запросов в день, OpenCode с ротируемыми open source free моделями и OpenAI Codex — пока бесплатный для Free-аккаунтов.

Иногда возникает странное ощущение: железо стало безумно быстрым, процессоры научились выполнять миллиарды операций в секунду, памяти стало больше, чем раньше было дискового пространства. Но почему-то программы всё равно тормозят. Открываешь простой веб-интерфейс — и ноутбук начинает шуметь вентиляторами. Запускаешь приложение для заметок — и оно ест полгигабайта RAM. Я долго думал, откуда это ощущение. Потом начал копаться: читать дизассемблер, смотреть профилировщики, запускать микробенчмарки. И постепенно стало понятно, что дело не в железе. Дело в том, как мы пишем код.

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

Каждый раз, когда вы вставляете рабочий код в чат с ИИ, в голове мелькает вопрос: «Не попадут ли мои данные не в те руки?» Единственный способ сохранить свои нервы — развернуть модель на собственном железе. А на фоне новости о переходе создателя OpenClaw в OpenAI сделать это хочется еще быстрее.

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

Недавно на созвоне финансовый аналитик показывал мне свою Excel-модель. Двенадцать листов, формулы ссылаются друг на друга через три уровня вложенности, именованные диапазоны вместо переменных, и INDIRECT, который динамически собирает адреса ячеек из строк. Я смотрел на это и думал: чувак, ты же написал компилятор. Ты просто не знаешь об этом.

750 миллионов человек используют Excel. Для сравнения — на Python пишут примерно 15 миллионов, на JavaScript — около 17. Excel обгоняет их всех вместе взятых раз в двадцать. И вот что забавно: подавляющее большинство этих людей искренне считают, что они «просто работают с таблицами». Заполняют ячейки. Делают отчёты.

Нет, они программируют.

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

«Пакман, я сделал тебя. Ты такой голодный, я знаю. Не надо больше есть. Хороший мальчик» — актёр Денис Акияма (Тору Иватани).

И вот я подумал: а почему бы не попробовать самому создать Пакмена? Не такого кровожадного, конечно, а просто для души. Тем более что с «Тетрисом» получилось удачно, захотелось закрепить успех.

В подразделении, где я работаю, есть традиция - новичку при онбординге вручается ссылка на Wiki с легендарными багами, приведшими к заметным последствиям. Недавно мне пришла в голову идея сделать такую же страницу, но уже со ссылками на Хабр, потому что на русском о багах пишут с бОльшим огоньком. Но, увы, оказалось, что каскадному падению серверов AT&T 15 января 1990 года внимание как-то не уделено. А ведь история получилась, прямо-таки эпическая.

Итак, 15 января 1990 года из-за одной строчки кода телефонная сеть AT&T получила 9 часов даунтайма, 70 миллионов несовершенных звонков, а общий убыток насчитали в $60 миллионов еще не инфляционных долларов. И нет, там не было неудачного релиза, развернутого сразу и везде. Все было гораздо интереснее.

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

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

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

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

Привет, Хабр! Это Антон Дятлов, инженер по защите информации в Selectel. Не так давно компания «Эшелон» выпустила Сканер-ВС 7, в котором изменилась логика работы с API. Старый скрипт перестал корректно работать, да и улучшения напрашивались сами собой. 

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

"Поскольку вы программист на C++, вероятность того, что вы слегка одержимы производительностью, выше среднего. А если нет, то вы, вероятно, по крайней мере с пониманием относитесь к такой точке зрения. (Если производительность вас совсем не интересует, аудитория Python разработчиков дальше по коридору)"
— Из пункта 42 книги С. Майерса “Effective Modern C++”, 2015.

Эта заметка описывает мой личный взгляд на то, как писать эффективный и надежный код для CPU. Статья ориентируется на С++, но значительная часть обсуждения CPU, кэшей, паттернов доступа к памяти и профилирования применима к Rust, Go и другим компилируемым языкам. Статья задумана как краткое введение и больше всего подходит студентам, имеющим опыт программирования на занятиях, но не в реальных проектах. Для профессионалов статья может быть полезной в качестве референса, чтобы не пугать новичков чем-то в духе Что каждый программист должен знать о памяти.

В статье опишу "набор новичка": godbolt.org, профилирование, бенчмарки, особенности CPU и его взаимодействия с памятью, когда есть смысл от асимптотических оптимизаций и почему важно при этом пользоваться санитайзерами, отслеживать coverage и вообще более трепетно относится к надёжности.

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

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

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

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

Естественно, это происходит ненамеренно. Никто не строит коварных планов в духе «А давай сделаем так, чтобы повышение получали только те, кто всё усложняет.» Но такое нередко происходит, когда в компании неверно оценивают проделанную сотрудниками работу.

С некоторых пор я пытаюсь уловить настроения, стоящие за этим активным продвижением идеи об «ИИ, который пишет весь код».

Не «ИИ помогает вам автодополнить функцию». Не «ИИ объясняет стек вызовов». Я имею в виду полноценную риторику:

«Нам больше не понадобятся инженеры-программисты».

И я никак не мог сформулировать, что именно меня в этом напрягает — пока в голове не щелкнуло.

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

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

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

Но внезапно я открыл для себя тот факт, что не во всех ошибках моя вина. То есть да, это моя голова думает код, это мои руки печатают этот код, но ошибка идёт не от меня. Ошибка заложена ещё раньше, вообще задолго до меня, а иногда даже задолго до моего рождения.

Сейчас я вам это покажу. Будет интересно, но впереди много боли. Я предупредил.

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

Первое, что нужно понять: процессор не является абстрактным вычислителем, а вполне себе реальный кусок кремния размером примерно с ноготь большого пальца, на котором размещены миллиарды транзисторов и когда мы говорим «данные передаются из памяти в регистр», то мы буквально имеем в виду, что электрический сигнал проходит по металлическому проводнику длиной в несколько миллиметров или сантиметров. И это тоже расстояние, пусть и ничтожное по человеческим меркам, но при тактовой частоте 3–4 ГГц оно уже имеет значение, просто потому что за один такт сигнал в идеальных условиях будет проходить всего 10 сантиметров, а в металлическом проводнике на кристалле и того меньше.

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

Привет, Хабр! Меня зовут Александр Зевайкин, и мы с командой делаем YDB (СУБД Яндекса). В конце прошлого года Яндекс представил специализированного ИИ‑помощника — Нейроюриста, для которого обучил языковую модель на основе Alice AI LLM. Сервис работает на базе RAG, под капотом у которого находится YDB c миллионами различных юридических документов.

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

Привет, Хабр. Меня зовут Владимир, я бэкенд-разработчик. Это моя первая статья здесь — о том, как пет-проект для нишевого варианта шахмат прошёл путь от «а что, если...» до первого места в рейтинге на chess.com. Без нейронок. На чистом alpha-beta поиске, написанном на Rust.

Статья будет полезна тем, кто интересуется шахматным программированием, оптимизацией CPU-bound задач или связкой Python + Rust через PyO3.

Полгода назад была статья как Яндекс обновляет процесс найма разработчиков - а недавно, в феврале 2026 я вновь опробовал этот "процесс" - и вот поделюсь, насколько он реально "обновился" (т.к. я проходил его и раньше). Одновременно шёл аналогичный процесс с ВК - постараюсь описать сходства и различия по всем этапам, в которых участвовал - может быть полезно и тем кто проходит подобные собеседования - и тем кто формирует процессы найма.

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