Хабр, привет! Меня зовут Владимир Михайлов, я занимаюсь бэкендом в Яндекс Такси — мы создаём внутренние продукты, которые используют в разных юнитах Яндекса. Также я работаю наставником на курсах «Разработчик C++» и «C++ для бэкенда» в Яндекс Практикуме. 

А ещё я помогаю компании с наймом и провожу предварительные секции с кандидатами — разработчиками C++. Я расскажу, какие задачи даю на этих секциях, на что обращаю внимание и как подготовиться к подобному собеседованию.

Почти за всем хорошим ML стоят хорошие данные. И так получилось, что таких данных часто нет и их приходится добывать, а даже добыв, из них нужно сделать что-то подходящее, и (если сильно огрубить) такой процесс называется разметкой.

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

Одна из наших важнейших метрик, помимо качества результата, это позаимствованный у бизнеса термин ttm (time to market), что в нашем случае — время от момента прихода клиента с идеей по момент продуманного запуска его задачи в разметку.

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

Расчехляйте вашу LLM, закатайте рукава, тут есть много работки!

Вы когда-нибудь задумывались, что такое interface? Ну, то есть, не ключевое слово синтаксиса, а что это такое в рантайме? Как выглядит его проинстанцированный объект? А, главное, каким свойством обладает при сравнении с nil? Нет? Тогда устраивайтесь поудобнее, я сейчас вам всё расскажу.

• Выбор формата. Если бы мы писали простенькую игру на JavaScript, нас бы устроил JSON или любой его самописный родственник. Но мы пишем серьёзную многопользовательскую игру, требовательную к трафику; мы не можем позволить себе отправлять ~16 байт на float вместо четырёх. Значит, нам нужен «сырой» двоичный формат. Однако, двоичные данные усложняют отладку; было бы здорово, если бы мы могли менять формат в любой момент, не переписывая целиком все наши функции чтения/записи.
• Проблемы безопасности. Первое правило сетевой игры: не доверяй данным, присланным клиентом! Функция чтения должна уметь оборваться в любой момент и вернуть false, если что-то пошло не так. При этом использовать исключения считается неважной идеей, поскольку они слишком медленные. Мамкин хакер пусть и не сломает ваш сервер, но вполне может ощутимо замедлить его беспрерывными эксепшнами. Но вручную писать код, состоящий из if'ов и return'ов, неприятно и неэстетично.
• Повторяющийся код. Функции чтения и записи похожи, да не совсем. Необходимость изменить структуру пакета приводит к необходимости поменять две функции, что рано или поздно приведёт к тому, что вы забудете поменять одну из них или поменяете их по-разному, что приведёт к трудно отлавливаемым багам. Как справедливо замечает Gaffer on Games, it is really bloody annoying to maintain separate read and write functions.

Предыстория