Учебный процесс в IT

Июль в блоге SSP SOFT — месяц обзоров на книги по языкам семейства С. Сегодня рецензия на очень объемную книгу по С++. Качественных книг по Qt на русском языке немного, и тем заметнее новое издание Макса Шлее «Qt 6.9. Профессиональное программирование на C++». В книге тысяча страниц, десять частей, от сигналов и слотов до Qt Quick, мобильной разработки под iOS и отдельной новой части про работу с ИИ-ассистентами. Для студентов и начинающих разработчиков (джунов), выбирающих между C++ и C#, или уже пишущих на C++, эта книга — редкий по охвату вход сразу в Qt и в саму индустрию кросс-платформенной разработки.

Обучение в школе 21 в 2026 году — чему учат и можно ли чему-то научиться? Субъективная оценка прохождения бассейна и политики школы.

Родители могут месяцами выбирать курс и язык программирования для ребёнка. Аргументы разные: Python самый популярный, а JavaScript нужен везде. А потом ребёнок через несколько занятий хочет бросить обучение, потому что ему слишком скучно и сложно.

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

В статье разберём, почему детям нужно программирование, какой язык выбрать в зависимости от возраста ребёнка и где учиться.

Готовиться к собесу по списку «2000 вопросов с ответами» невозможно. Я пробовал: открываешь, листаешь минут сорок, отвечаешь на те, что и так знаешь, закрываешь с чувством выполненного долга. Через неделю в голове ноль. Список не помнит, где ты плаваешь, и не знает, когда ты забудешь то, что вчера повторил.

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

Мок‑экзамен, вопрос номер сорок с чем‑то. Сценарий: система должна классифицировать входящие обращения, и ни при каких условиях категория не может выходить за пределы фиксированного списка. Какой вариант обеспечивает это требование? Я уверенно тыкаю в ответ с формулировкой «добавить в системный промпт строгую инструкцию с перечнем допустимых категорий и явным запретом на другие значения».

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

Готовясь к CCA‑F (Claude Certified Architect — Foundations), я ожидал, что буду зубрить параметры API и лимиты контекста. Вместо этого экзамен методично бил меня по одному и тому же месту, пока я не сформулировал, во что именно я неправильно верил.

Хабр, привет! Меня зовут Андрей Пронин, я руководитель «бирюзовой» студии заказной разработки ProninTeam и наставник на курсе по управлению командой разработки в Яндекс Практикуме.

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

Хабр, привет! Меня зовут Сергей Бережной, я директор по взаимодействию с разработчиками в Яндексе и эксперт онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. Приёмная кампания в нашу онлайн-магистратуру уже идёт, программа рассчитана на опытных разработчиков и на тех, кто идёт с нуля. Поэтому, если хотите программировать на JavaScript, Python, Java или С++ — ждём вас. А в этой статье я хочу поговорить о том, почему работа с ИИ постепенно перестаёт сводиться к написанию промптов, зачем разработчику учиться мыслить процессами, а не отдельными запросами, и почему именно такой подход позволяет получать качественный результат.

Привет, хабровчане. Во второй половине июля наши преподаватели-практики проведут 52 открытых урока по актуальным темам из разных областей ИТ — от LLM, RAG и Claude Code до C++, Playwright, Kubernetes, TOGAF и сетей ЦОД. Это возможность посмотреть, как эксперты разбирают прикладные задачи, обсудить рабочие подходы, задать вопросы и заодно оценить формат обучения на практике.

Когда команда небольшая и все сидят в одном открытом пространстве, знания передаются почти сами собой — через разговор у кофемашины, ревью кода, общий чат. Пока команда маленькая, это терпимо, но как только появляется рост, удалёнка, параллельные проекты и новые сотрудники, хаос начинает стоить больших денег. Именно в этой точке большинство IT-компаний впервые задумываются о том, что «база знаний» — это не просто папка в Google Drive, а самостоятельная инфраструктурная задача.

Мы в Alpina Digital прошли этот путь и хотим рассказать, как это было.

Скромный и немного скучноватый рассказчик «Великого Гэтсби» Ник Кэррауэй был трейдером на рынке облигаций (его сыграл Тоби Магуайр). Облигации долгое время считались самым скучным видом активов. Они никогда не фигурировали в массовом воображении так же, как акции или корпоративные слияния и поглощения (M&A). Даже Ян Флеминг выбрал имя «Бонд» для своего шпиона, потому что считал, что это «самое неприметное имя, которое я когда-либо слышал». Но, скорее всего, именно они вызовут следующий финансовый кризис.

Всё началось с прокрастинации. Готовился к собеседованиям: SQL, git, брокеры сообщений, Django, алгоритмы. Открывал статьи, читал полтора абзаца и через десять минут обнаруживал себя где угодно, только не за материалом. К третьему заходу стало ясно: в формате «читать и запоминать» это в меня не лезет.

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

Спойлер: план провалился, учиться всё равно пришлось. Но по дороге вышло кое-что интереснее самого тренажёра, про это и статья.

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

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

Привет! Я Ольга Матушевич, преподаватель курса «Нейросети для бизнеса», а в прошлом ментор Мастерской Яндекс Практикума. В e-commerce и маркетинге есть множество наработанных методик. Но как применить их там, где цель — не прибыль, а спасение жизней? 

Хочу поделиться кейсом Мастерской: мы работали с DonorSearch — крупнейшим сообществом доноров крови в Рунете. Заказчик поставил задачу: сегментировать донорскую базу так, чтобы можно было вести адресную коммуникацию с разными группами доноров. Понять, кого считать активным донором, кто выпал из донорства, а кто только начинает свой путь — и что делать с каждой из этих групп. 

Мы выбрали необычное решение — применить RFM-анализ, классический инструмент из маркетинга. В статье я расскажу:

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

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

Хабр, привет! Меня зовут Илья Благородов, я занимаюсь разработкой уже более 30 лет, а ещё я — один из экспертов онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. Сегодня хочу поговорить о том, как правильно выбирать инструменты для разработки, почему разбираться в разных инструментах — не равно уметь их правильно применять и что с этим делать.

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

Это довольно частая история: многие дети доходят до конца обучения, особенно в онлайн-формате. Почему так происходит и что с этим делать — разбираемся в статье.

«Освоить профессию с нуля» — популярный запрос, но не всегда корректный. А что, если абсолютного нуля не бывает? Ведь у каждого из нас есть свой опыт, знания и преимущества в чём-то своём.

Хабр, привет! Меня зовут Альберт Болотнов, я главный системный аналитик продукта в бигтех-компании. Я отучился на инженера в МГТУ им. Баумана, но через два года работы сменил сферу на IT, а ещё спустя год — добрал необходимые знания в курсе «Системный аналитик» в Яндекс Практикуме. В этом тексте расскажу про свой путь и дам несколько советов тем, кто ищет себя или делает первые шаги в профессии.

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

Для кандидата это один этап. Для компании — процесс, который может меняться от встречи к встрече.

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

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

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

Все обсуждают модели: GPT, Claude, Codex, Gemini, Opus. Но в реальной работе побеждает не только самая сильная модель, а правильно собранная система вокруг неё. Эта система называется agent harness — харнесс. В статье разберём, что это такое, из каких компонентов он состоит и как я собираю свой рабочий AI-сетап: Orca, GitHub, VPS, Pi Agent и кастомный pipeline для разработки.

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

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

Почувствовали разницу в уровне валидности? Вот и я почувствовала.

...

Ладно, если рисовать вы не хотите, пойдём сразу к результатам.

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

Ответьте себе на вопрос: где проходит ваша граница доверия с вашим агентом? Что вы готовы ему простить? А что для вас жесткий ред-флаг?

Готовы ли вы делегировать агенту задачу, в которой вы не разбираетесь, и взять за это ответственность, если что-то пойдет не так? А если наоборот, все будет очень хорошо — искренне признать, что по факту это не совсем ваш труд?

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

У меня есть несколько смешных кейсов, которые я вам сейчас расскажу, но смеяться вы скорее всего не будете.