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

Начнём с самого срочного. YADRO набирает студентов на курс «Системное программирование с использованием языка C». Заявки принимают до 28 сентября, то есть до завтра, так что если давно хотел разобраться, как код работает поближе к железу, откладывать некуда. Дальше будет отбор с 29 сентября по 12 октября, а занятия стартуют 19 октября и идут раз в неделю до мая. Формат онлайн, большая часть времени уходит на практику с разбором домашек от инженеров компании, а самых сильных участников приглашают на стажировку в YADRO. Подать заявку могут студенты со второго курса. После окончания регистрации на канале будет оперативно выложен разбор тестового задания.

Если хочется войти в разработку с нуля и без всякого профильного бэкграунда, стоит посмотреть на Школу 21 от Сбера. Поступление идёт через «бассейн», двухнедельный очный интенсив в кампусе, на котором как раз погружают в основы и командную работу. Ближайшие бассейны пройдут в Магасе с 12 октября (заявки до 7 октября, иногородним там ещё и дают бесплатное жильё), в Ярославле тоже с 12 октября и в Казани с 26 октября. Участвовать может любой человек старше 18 лет, опыт программирования не нужен.

Напоследок вариант для тех, кто не хочет привязываться к расписанию. У VK Education открыт набор на асинхронные курсы, среди которых есть «Системное программирование», «Алгоритмы и структуры данных» и «Базовый Python». Лекции уже записаны, смотреть их можно в своём темпе, а подать заявку получится до 31 декабря. Неплохой способ подтянуть базу параллельно с учёбой или работой.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

System Design: backend

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

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

Для этого используют приём, который называется Transactional Outbox. В той же базе, где лежат платежи, заводится отдельная таблица для исходящих событий, и строка в неё пишется в той же транзакции, что и сам платёж. База умеет гарантировать атомарность внутри себя, поэтому после коммита у нас либо есть и платёж, и событие о нём, либо нет ни того, ни другого. В Kafka эти строки перекладывает отдельный процесс, его обычно называют реле. Он берёт из таблицы то, что ещё не отправлено, публикует в брокер и только после подтверждения помечает строку как отправленную. Если реле упадёт между публикацией и пометкой, после перезапуска оно отправит те же строки повторно, и здесь становится понятно, зачем вопрос про дубли задавали в самом начале. Когда экземпляров реле несколько, строки удобно разбирать через SELECT FOR UPDATE SKIP LOCKED, чтобы два процесса не схватили одну запись, а ключом сообщения лучше делать id заказа, тогда все события одного заказа попадут в одну партицию и склад получит их в правильном порядке.

Раз повторы стали нормальной частью системы, получатель обязан с ними справляться. Склад хранит идентификаторы уже обработанных событий и просто пропускает те, что видел раньше. Если про это забыть, Outbox решит проблему у отправителя и тут же создаст новую у склада, где один и тот же заказ начнут собирать дважды. Обычно после этого интервьюер переходит к эксплуатации. Опрашивать таблицу раз в секунду можно, но это нагружает базу и добавляет задержку, поэтому в больших системах изменения часто читают прямо из журнала транзакций с помощью CDC вроде Debezium. Отправленные строки со временем нужно чистить, иначе таблица событий разрастётся быстрее самих платежей. Для мониторинга хватает одной метрики, возраста самой старой неотправленной строки. Если он начал расти, значит реле встало или брокер лежит, и лучше узнать об этом от алерта, чем от склада.

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

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

Кто подался на курс YADRO по системному программированию на Си, отборочный тест нужно пройти до сегодняшнего вечера, дедлайн 1 октября в 23:59 по Москве. Времени мало, поэтому мы разобрали отборочный тест целиком: 19 вопросов по Си и 4 вопроса на мотивацию, по каждому есть правильный ответ, объяснение и ловушка, на которой чаще всего спотыкаются.

На тест дают около 25 минут, и проверяет он в первую очередь знание тёмных углов языка. Почти у каждого вопроса есть очевидный ответ, который оказывается неверным. Попробуй навскидку: что лежит в указателе после вызова free, если многие уверены, что там NULL? Сколько вернёт strlen("Hello\n"), 5, 6 или 7? Скомпилируется ли switch, у которого в case стоит обычная переменная? Нужно ли освобождать массив, объявленный на стеке, если один из вариантов ответа уверяет, что в C23 завезли сборщик мусора? Если хоть где-то засомневался, разбор тебе пригодится.

Вопросы в файле сгруппированы по четырём темам: поток управления, биты и числа, сборка и препроцессор, указатели и память. Внутри разобраны static в функции, XOR и дополнительный код, трюк с n & (n - 1), макросы без скобок, strtok и указатели на функции. В конце есть ключ на одной странице и таблица «десять ловушек Си», которую полезно держать под рукой и после отбора, перед любым собесом на позицию с Си.

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

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

System Design: frontend

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

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

Дальше разговор строится вокруг буфера. События складываются в память вкладки и уходят на сервер одной пачкой, когда их накопилось несколько десятков или прошло несколько секунд. Общие данные вроде id сессии и модели устройства кладутся в пачку один раз, поэтому каждое событие весит совсем немного, а у буфера есть предел, чтобы при недоступном сервере вкладка не съела всю память. Самое интересное начинается, когда пользователь уходит со страницы, потому что последняя пачка содержит как раз то, что аналитикам нужнее всего, момент, в который человек бросил просмотр. Обычный fetch браузер при закрытии вкладки может оборвать, поэтому для последней отправки используют navigator.sendBeacon, который отдаёт запрос браузеру, и тот доставит его уже после закрытия страницы. Сбрасывать буфер правильнее в момент, когда вкладка становится скрытой, по событию visibilitychange, потому что на телефонах страницу чаще сворачивают, чем закрывают, и событие unload там может вообще не прийти.

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

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

Подписаться: @codeof_art
Вступить в чатик: @code_of_art