Могут ли на интервью по ML задавать задачи по структурам данных, например, деревья и связанные списки

Что проверяют

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

Как отвечать

Да, могут, и на позиции ML-инженера алгоритмическая секция скорее норма. Реже её дают аналитикам и исследователям, у них вместо неё SQL, статистика или разбор статей. Спросить заранее нормально: будет ли отдельный этап live coding, на каком языке и есть ли задачи с ML-уклоном.

Что встречается чаще всего:

• массивы и хэш-таблицы: подсчёт частот, два указателя, скользящее окно;
• кучи: top-k элементов через heapq, слияние отсортированных потоков;
• деревья: обходы в ширину и глубину, проверка BST, наименьший общий предок;
• связные списки: разворот, поиск цикла двумя указателями, слияние;
• графы: BFS, топологическая сортировка, иногда простая динамика.

Отдельно бывают задачи с ML-оттенком, где готовые библиотеки запрещены: написать k-means или kNN на чистом Python, посчитать ROC AUC по списку предсказаний, реализовать численно устойчивый softmax, сделать reservoir sampling по потоку неизвестной длины.

Готовиться стоит на Python, его ждут почти всегда: знать collections.deque, Counter, defaultdict, heapq, bisect, уметь оценивать сложность по времени и памяти. Связь с ML полезно показать одной фразой: решающее дерево это то же дерево, а поиск ближайших соседей упирается в структуры вроде KD-tree и графовых индексов HNSW.

Где спотыкаются

Считают, что на ML-позиции спросят только про модели, и приходят без единой решённой задачи на структуры данных.

Тянутся к numpy и pandas там, где проверяют сам алгоритм. Интервьюер просит обойтись без них, и решение рассыпается.

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