Вопросы на собеседовании Rust-разработчика

Пример сильного ответа

Ownership — это модель управления памятью, где у каждого значения ровно один владелец, и при выходе владельца из области видимости память освобождается автоматически, без сборщика мусора. Borrow checker на этапе компиляции проверяет, что ссылка не живёт дольше данных и что нет одновременного мутабельного и немутабельного доступа. Практически это убирает целый класс проблем: use-after-free, двойное освобождение, гонки данных. В моём опыте сервис держит около двадцати тысяч запросов в секунду, и за полгода работы не было ни одного падения из-за гонок, хотя раньше такие инциденты случались по нескольку раз в квартал.

• Показано понимание модели памяти, а не заученная формулировка
• Названы конкретные классы проблем, которые это решает
• Есть измеримый результат из личной практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

String — владеющая строка в куче: её можно менять, растить, передавать по владению. &str — это заимствованный срез, указатель на байты UTF-8 плюс длина; он может смотреть и в литерал, и внутрь String. Поэтому в сигнатурах функций я предпочитаю &str: такой параметр принимает и литерал, и &String, и не заставляет вызывающего аллоцировать. Owned String нужен, когда значение живёт дольше вызова, меняется или возвращается из функции. На одном парсере замена String на &str в параметрах дала примерно на треть меньше аллокаций, и обработка батча ускорилась примерно на пятнадцать процентов.

• Различие объяснено через владение и аллокации, а не заучивание
• Показано практическое правило выбора для API
• Приведён измеримый эффект оптимизации

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

По умолчанию присваивание в Rust — это перемещение: владение переходит к новой переменной, а старая становится недоступной, и компилятор это проверяет. Так не бывает двойного освобождения и случайного использования уже отданных данных. Для простых типов — чисел, bool, char, кортежей из них — работает Copy: значение побайтово копируется, и обе переменные остаются валидными. Clone — это явное копирование, часто с аллокацией, и его цена видна в коде. В одном сервисе неявные clone в горячем цикле занимали до сорока процентов профиля, после перехода на перемещение и ссылки задержка заметно снизилась.

• Чётко разделены move, Copy и Clone
• Показано, почему Clone — явный сигнал о стоимости
• Есть цифра из профилирования своего кода

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Lifetimes — это аннотации, которые говорят компилятору, как времена жизни ссылок связаны между собой, чтобы он мог доказать, что ссылка не переживёт данные. В большинстве случаев работает elision, и писать ничего не нужно. Явные аннотации нужны, когда функция возвращает ссылку, а на входе несколько ссылок: компилятор не может самостоятельно решить, к какой привязан результат. Ещё они появляются в структурах, которые хранят ссылки, и в реализациях трейтов. Структура, хранящая ссылку на буфер вместо копии, сэкономила около трети памяти на соединение при десятках тысяч одновременных соединений.

• Сначала смысл, потом случаи явного указания
• Названы правила elision своими словами
• Есть пример выигрыша по памяти из практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Сформулировано главное правило и его цель
• Показан рабочий приём обхода ограничения
• Есть пример пользы проверок компилятора

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Объясняю так: Box — владение в куче, нужен для рекурсивных типов и динамического полиморфизма, когда размер известен только в рантайме. Rc даёт общий доступ внутри одного потока, счётчик неатомарный и потому дешевле. Arc — то же самое, но счётчик атомарный, для данных, общих между потоками. RefCell добавляет внутреннюю изменяемость: правила заимствования проверяются в рантайме, и нарушение даёт панику вместо ошибки компиляции. На практике комбинирую: Rc с RefCell для графа в одном потоке, Arc с мьютексом — когда данные общие. В проекте с деревом конфигурации на пять тысяч узлов замена Arc на Rc убрала лишние атомарные операции, обход стал быстрее примерно на пятнадцать процентов.

• Названы все четыре типа и их ключевое отличие
• Есть критерий выбора и пример комбинации
• Подкреплено личным результатом с числом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Async в Rust — это состояние, а не поток: async-функция возвращает Future, которая ничего не делает, пока её не опросят. Await — точка, где задача отдаёт управление исполнителю. Самостоятельно по себе Future не работает, нужен рантайм: tokio даёт многопоточный планировщик, реактор ввода-вывода и таймеры. Компилятор превращает async-функцию в конечный автомат, поэтому тысячи задач уживаются в одном потоке с маленьким стеком. В одном сервисе восемь тысяч одновременных соединений обслуживал один tokio-рантайм с несколькими рабочими потоками, и память на задачу оставалась в пределах пары килобайт.

• Разделены язык async и конкретный рантайм
• Объяснена ленивость Future и роль await
• Есть пример нагрузки с числом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Дан ясный критерий выбора
• Показан гибридный подход, а не догма
• Результат подтверждён измеримым числом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Вариантов несколько: каналы, разделяемое состояние под мьютексом или RwLock, атомарные типы и scoped-потоки. Каналы — мой выбор по умолчанию: передаю владение и вовсе не делю память, поэтому гонок не возникает. Где данные читаются часто, а пишутся редко, ставлю RwLock, чтобы читатели не мешали друг другу. Для счётчиков и флагов хватает атомиков. Главное — держать блокировку коротко и не делать внутри неё ввода-вывода. В одном конвейере переход с общего мьютекса на канал и RwLock для конфигурации убрал ожидание на блокировке, пропускная способность выросла примерно на сорок процентов.

• Перечислены основные механизмы и их назначение
• Есть правило про короткие блокировки
• Приведён личный результат в процентах

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Send означает, что значение можно передать в другой поток, Sync — что на него можно ссылаться из нескольких потоков одновременно. Это автотрейты: компилятор выводит их самостоятельно, и если тип содержит Rc или сырой указатель, Send не появится — код просто не соберётся. Так потокобезопасность становится проверкой на этапе компиляции, а не договорённостью в команде. Отсюда же ограничения асинхронного кода: guard мьютекса нельзя держать через await. В команде из шести человек это правило ловило ошибки ещё до ревью, и число инцидентов с гонками на релизе свелось практически к нулю.

• Дано точное определение обоих маркеров
• Показано, что гарантию даёт компилятор
• Связано с практикой и результатом команды

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Показано разделение практик для библиотек и приложений
• Контекст ошибок и структурные логи названы как приёмы
• Есть измеримый результат: часы против десятков минут

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

unsafe — это разрешение компилятору не проверять часть гарантий: работа с сырыми указателями, вызов внешних функций, ручная реализация Send и Sync, доступ к небезопасным внутренностям стандартной библиотеки. Оправдано там, где без него не обойтись или где замеры показывают реальный выигрыш: обёртки над библиотеками на C, низкоуровневые структуры данных, горячие участки. Мой подход — изолировать такой код в небольшой модуль за безопасным интерфейсом, писать комментарий с инвариантами и проверять тестами и санитайзерами. В одном проекте это дало ускорение парсинга примерно на двадцать процентов при сохранении безопасного API.

• Дано точное определение с примерами применения
• Подчёркнута изоляция unsafe за безопасным интерфейсом
• Упомянуты комментарии с инвариантами, тесты и санитайзеры

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Ответ начинается с измерения, а не с догадок
• Названы типичные причины просадок производительности
• Есть конкретный результат по задержке

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Показано понимание Cargo как трёх инструментов в одном
• Названы рабочие пространства, фичи и приватный реестр
• Есть масштаб: около пятнадцати крейтов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Для сериализации обычно беру serde с форматом под задачу: JSON для внешних API, компактные форматы там, где важен размер или скорость. Модели описываю строгими типами, а не строками и словарями: перечисления для статусов, обёртки для идентификаторов, отдельные типы для запросов и ответов. Для внешних API настраиваю таймауты, повторы с задержкой и ограничение параллелизма, а ошибки разбираю по коду ответа. Версионирование схемы продумываю заранее и добавляю контрактные тесты на реальных примерах ответов. Это уменьшило число сбоев интеграции примерно на четверть.

• Названы serde и осознанный выбор формата под задачу
• Показана типизация моделей вместо строк и словарей
• Есть таймауты, повторы и контрактные тесты

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В одном проекте был граф зависимостей, и borrow checker не давал держать изменяемые ссылки на несколько узлов одновременно. Сначала был вариант с Rc<RefCell<...>>, но он усложнял код и замедлял работу. Тогда архитектура изменилась: узлы стали храниться в векторе, а связи — через индексы. Это убрало конфликты заимствования и ускорило обход на 20 процентов. Код стал проще, а ошибок с временем жизни больше не возникало. Теперь при похожих задачах я сразу думаю про владение и разделение данных, а не про обходные пути.

• Показывает понимание borrow checker на практике
• Конкретный результат: ускорение обхода на 20%
• Демонстрирует системное мышление, а не обходные пути

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.