Краткая история алгоритмических интервью

Как тесты IBM, олимпиады, Microsoft и LeetCode создали главный экзамен для программистов

Время чтения: около 15 минут. Актуальность: сентябрь 2026 года.

Сегодня алгоритмическое интервью кажется естественной частью найма разработчиков. Кандидату дают массив, строку, дерево или граф, просят придумать решение, написать код и оценить его сложность.

Но этот формат возник не вместе с LeetCode и не был однажды изобретен Google. Он складывался десятилетиями из нескольких разных традиций:

• тестов на логическое мышление;
• программирования на бумаге и у доски;
• олимпиад и соревнований;
• автоматических проверяющих систем;
• стандартизированного найма в крупных технологических компаниях.

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

Что сегодня называют алгоритмическим интервью

Алгоритмическое, или DSA-интервью, это техническое собеседование, на котором кандидат в реальном времени:

1. уточняет условие задачи;
2. предлагает простое решение;
3. выбирает подходящую структуру данных;
4. улучшает алгоритм;
5. пишет работающий код;
6. проверяет граничные случаи;
7. оценивает время и память.

DSA означает Data Structures and Algorithms, то есть структуры данных и алгоритмы.

Такое интервью отличается и от олимпиады, и от обычного тестового задания. На олимпиаде участник несколько часов самостоятельно решает набор задач и отправляет программы в проверяющую систему. На live-интервью обычно есть 35–60 минут, рядом находится интервьюер, а ход рассуждения иногда важен не меньше финального кода.

1955 год: IBM ищет людей, которых можно научить программировать

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

В 1955 году сотрудники IBM Дж. Л. Хьюз и У. Дж. Макнамара разработали Aptitude Test for EDM Programmers. В 1959 году появилась переработанная версия под названием Programmer Aptitude Test (ACM).

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

Как выглядели вопросы IBM

В сохранившейся переработанной форме 1959 года предлагалось продолжить числовые ряды (архив IBM PAT, скан страницы).

Пример 1

19, 23, 27, 31, 35, 39, ?

Правило: каждый раз прибавляется 4. Ответ: 43.

Пример 2

53, 58, 54, 59, 55, 60, ?

Операции чередуются: (+5, -4). Ответ: 56.

Пример 3

11, 14, 18, 23, 29, 36, ?

Прибавляются 3, 4, 5, 6, 7 и затем 8. Ответ: 44.

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

Важно: это задания из переработанной формы 1959 года. Их нельзя без оговорки называть дословными вопросами первой редакции 1955 года.

К 1966 году тестирование программистов уже стало массовым. В опросе ACM различные тесты использовали 68% опрошенных организаций США и 73% канадских организаций (опрос ACM).

Главная идея той эпохи была простой: если готового программиста найти трудно, попробуем измерить способность человека им стать.

1968–1990 годы: алгоритмы становятся учебной дисциплиной

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

Дональд Кнут и «Искусство программирования»

Автора зовут Дональд Кнут, а его многотомная серия называется The Art of Computer Programming, или TAOCP. Первый том, Fundamental Algorithms, вышел в 1968 году; второй, Seminumerical Algorithms, в 1969-м; третий, Sorting and Searching, в 1973-м (University of Pennsylvania).

До Кнута сведения об алгоритмах были рассеяны по статьям и описаниям конкретных машин. Кнут собрал алгоритмы, структуры данных и математические методы анализа в единую систему. В биографии лауреата премии Тьюринга ACM прямо говорится, что первые тома помогли утвердить анализ алгоритмов как самостоятельную область и повлияли на построение учебных программ по computer science (ACM).

TAOCP не была книгой для подготовки к собеседованиям. Она создала интеллектуальный фундамент: алгоритм следовало не только написать, но и сравнить с альтернативами, оценить его эффективность и объяснить, почему он работает. Именно такой способ рассуждения позднее стал центральным для DSA-интервью.

Кормен, Лейзерсон, Ривест и Штайн

Вероятно, вторая огромная книга, которую часто вспоминают рядом с Кнутом, это Introduction to Algorithms, по-русски «Алгоритмы: построение и анализ». Ее обычно называют CLRS по первым буквам фамилий авторов: Thomas Cormen, Charles Leiserson, Ronald Rivest и Clifford Stein.

Первое издание вышло в 1990 году и имело более тысячи страниц. Тогда авторов было трое, поэтому книгу называли CLR или «большой белой книгой». Клиффорд Штайн присоединился ко второму изданию 2001 года, после чего закрепилось сокращение CLRS. Учебник вырос из курса MIT 6.046 и стал стандартным университетским текстом; к 2011 году было продано 500 тысяч экземпляров (MIT News).

Если Кнут строил фундаментальную энциклопедию алгоритмов, то CLRS предложила удобную структуру систематического обучения: асимптотика, сортировки, деревья, хеш-таблицы, динамическое программирование, жадные алгоритмы и графы. Позже почти тот же набор тем превратился в учебную программу подготовки к алгоритмическим интервью. Это не означает, что интервью были скопированы из CLRS, но книга помогла стандартизировать знания, которые компании ожидали от выпускников computer science.

1970–1989 годы: появляется олимпиадное программирование

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

Главные даты

Олимпиады закрепили формат, хорошо знакомый современному разработчику:

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

Но это еще не означает, что алгоритмические интервью непосредственно произошли из ICPC или IOI. Корпоративные тесты существовали раньше олимпиад, а live coding развивался и внутри самих компаний.

Примеры первых олимпиадных задач

Всесоюзная олимпиада 1988 года: разбиения числа

Для положительного числа (n) требовалось посчитать количество способов представить его как сумму положительных слагаемых без учета порядка. Например, для (n=4) существует пять вариантов:

4
3 + 1
2 + 2
2 + 1 + 1
1 + 1 + 1 + 1

Значит, (p(4)=5) (факсимильный скан задачи, история олимпиады).

Современное решение использовало бы динамическое программирование:

dp[0] = 1

для каждого допустимого слагаемого:
    обновить количества способов получить все следующие суммы

В интервью эту задачу, скорее всего, превратили бы в знакомый вариант Coin Change: посчитать количество способов набрать заданную сумму монетами различных номиналов.

IOI 1989 года: перестановка коробок

В ряд стоят коробки с символами A, B и двумя пустыми позициями. За один ход разрешено перенести соседнюю пару символов в две пустые коробки, сохранив их порядок. Нужно добиться состояния, в котором все A находятся левее всех B, а затем найти минимальное количество ходов (архив IOI 1989).

Пример переходов:

__ABBA → AB__BA → ABBA__ → A__ABB

После удаления пустых клеток получается AABB.

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

На современном интервью оставили бы только функцию:

minMoves(startState)

Кандидата попросили бы объяснить представление состояния, генерацию соседей, хранение посещенных конфигураций и восстановление пути.

ICPC 1995 года: велосипедный маршрут

В задаче Jill’s Bike город представлен сеткой улиц. Для каждой точки известна высота, часть дорог односторонняя, а велосипедист не может подниматься больше чем на 10 метров за один участок. Нужно найти маршрут с минимальным количеством ребер (официальный комплект ICPC 1995).

За длинной историей скрывается обычная задача:

1. построить ориентированный граф;
2. оставить только допустимые переходы;
3. запустить BFS;
4. сохранить родителей вершин;
5. восстановить кратчайший маршрут.

Интервьюер, скорее всего, убрал бы сложный формат ввода и попросил реализовать shortestRoute(start, end) для готовой матрицы высот.

1990-е: Microsoft популяризирует задачи у доски

В 1990-е Microsoft стала известна интервью с логическими головоломками и необычными вопросами. NPR позднее назвала Microsoft компанией, популяризировавшей этот стиль (NPR).

Какие головоломки задавали в Microsoft

В 2002 году разработчик Крис Селлс опубликовал подборку, которую назвал реальными вопросами с интервью, проводившихся сотрудниками в главном кампусе Microsoft. Это не официальный банк компании и не доказательство того, что каждый вопрос использовался именно в 1990-е. Но подборка хорошо показывает стиль puzzle-интервью, который Microsoft к тому времени успела сделать знаменитым (Chris Sells).

• Почему крышка канализационного люка круглая? У вопроса нет одного обязательного ответа. Круглая крышка не провалится в отверстие, ее не нужно ориентировать при установке и ее можно катить. Интервьюеру был важен не заученный факт, а ход рассуждений кандидата.
• Сколько автомобилей находится в США? Это задача Ферми: точное число заранее не известно. Кандидат должен разбить оценку на понятные величины, например население, средний размер домохозяйства и количество автомобилей на семью, а затем проверить правдоподобность результата.
• Три выключателя и три лампочки. Выключатели находятся снаружи закрытой комнаты, а войти в нее можно только один раз. Решение использует не только свет, но и нагрев лампы: одну включают надолго и выключают, вторую оставляют включенной, третью не трогают.
• Восемь бильярдных шаров. Один шар немного тяжелее остальных. Его можно найти за два взвешивания: сначала сравнить группы по три шара, а затем сравнить два шара из подозрительной тройки или два из оставшейся пары.
• Слиток для оплаты семи дней работы. Слиток разделен на семь секций, работнику необходимо платить ежедневно, но разрешено сделать только два разреза. Нужно получить части размером 1, 2 и 4 секции, а затем каждый день выдавать или обменивать их, используя двоичное представление суммы.
• Банки с испорченными таблетками. В одной из четырех банок каждая таблетка на единицу тяжелее. Нужно определить банку одним взвешиванием: взять одну таблетку из первой банки, две из второй, три из третьей и четыре из четвертой; величина превышения ожидаемой массы укажет номер банки.

Такие вопросы обычно не требовали написания программы. Они проверяли, как кандидат уточняет условия, строит модель, замечает скрытые свойства и объясняет решение вслух. В этом смысле puzzle-интервью стало одним из предшественников современного требования «показывать ход мыслей», хотя сами головоломки позднее стали критиковать за слабую связь с реальной работой.

Но головоломки были только частью процесса. Кейси Муратори сохранил описание своего интервью на стажировку в Microsoft в 1993 или 1994 году. Четыре интервьюера дали ему четыре программных задания (Computer, Enhance!):

1. скопировать прямоугольную область пикселей с учетом шага строк;
2. реализовать копирование строки в C;
3. ускорить проверку цвета packed-pixel;
4. придумать целочисленный алгоритм рисования окружности.

Последнюю задачу он решал на доске.

Это еще не современный набор «массив, хеш-таблица, BFS, dynamic programming». Вопросы были тесно связаны с C, памятью, графикой и производительностью. Однако главный принцип уже появился: кандидат должен написать код в реальном времени и показать, как он думает.

К 2000 году практика стала достаточно распространенной, чтобы появилась книга Programming Interviews Exposed. Она разбирала linked lists, strings, trees, graphs, recursion, Big O и написание функций на доске или бумаге (рецензия 2000 года).

Как олимпиады все-таки повлияли на интервью

Правильнее говорить не о прямом происхождении, а о постепенном пересечении двух традиций.

Общий предмет

И олимпиады, и интервью проверяют:

• декомпозицию задачи;
• выбор структуры данных;
• корректность алгоритма;
• оценку сложности;
• работу с граничными случаями.

Общая инфраструктура

В 1995 году в Университете Вальядолида появилась первая версия UVa Online Judge. Ее создали для отбора и подготовки команды к ICPC. В 1997 году judge стал публичным и позволил программистам со всего мира отправлять решения круглосуточно (The UVa Online Judge Experience).

Затем появились:

• Timus Online Judge, работающий с 2000 года (Timus);
• Topcoder, запустивший регулярные онлайн-раунды в 2001 году (архив Topcoder);
• Google Code Jam, начавшийся в 2003 году (Google Developers Blog);
• Codeforces, запущенный Михаилом Мирзаяновым в 2010 году (Codeforces).

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

условие → код → компиляция → скрытые тесты → результат

Соревнование как рекрутинг

Google Code Jam был не только спортивным мероприятием. В 2003 году конкурс описывали как возможность оценить участников в качестве потенциальных сотрудников, а на сайте использовалась формулировка «job interview with a significant cash incentive» (ZDNet).

Получилась двусторонняя связь:

• компании заимствовали у соревнований задачи и автоматическую проверку;
• платформы начали адаптировать олимпиадный формат специально под подготовку к найму.

2008–2012 годы: подготовка превращается в индустрию

В 2008 году вышло первое издание Cracking the Coding Interview. Книга не изобрела алгоритмическое интервью, но превратила разрозненные практики в понятную программу подготовки: структуры данных, алгоритмы, сложность и тренировка решения без полноценной IDE (список изданий).

В 2011 году уже работал LeetCode. Архив сайта показывает разделы Interview Questions и Online Judge, а страница About называла сервис платформой для подготовки к техническим интервью (Internet Archive).

LeetCode не создал формат. Он сделал три другие вещи:

1. собрал задачи в одном месте;
2. дал мгновенную автоматическую проверку;
3. превратил подготовку в постоянную измеримую практику.

HackerRank: задачи становятся инструментом массового отбора

История HackerRank началась раньше самого бренда. В 2009 году Вивек Рависанкар и Хари Карананиди начали создавать InterviewStreet, сервис для проверки навыков программистов. В сентябре 2012 года появилась платформа под названием HackerRank. Она объединила публичные соревнования и задачи для разработчиков с корпоративным продуктом, с помощью которого компании могли проводить автоматизированные coding assessments (HackerRank).

Если LeetCode прежде всего стал ассоциироваться с самостоятельной подготовкой к интервью, то HackerRank занял сразу две стороны рынка:

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

Так олимпиадная механика условие → код → тесты → балл окончательно превратилась в масштабируемый инструмент найма.

Codewars: программирование как система kata

Ещё одна известная платформа появилась в ноябре 2012 года. Нейтан Доктор и Джейк Хоффнер создали Codewars, где упражнения по программированию получили название kata, по аналогии с повторяемыми формами тренировки в боевых искусствах (Codewars).

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

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

Так возник современный жанр задачи, находящийся между олимпиадой и интервью:

• условие короче олимпиадного;
• ввод и вывод часто заменены сигнатурой функции;
• решение рассчитано примерно на один интервью-раунд;
• после базового решения можно задавать follow-up вопросы.

Типичные примеры:

• Two Sum: хеш-таблица вместо перебора пар;
• Valid Parentheses: стек;
• Number of Islands: DFS или BFS;
• LRU Cache: хеш-таблица и двусвязный список.

К началу 2010-х сформировались три соседних, но не одинаковых типа платформ:

2016–2020 годы: алгоритмы объясняют картинками и видео

В мае 2016 года Manning выпустило первое издание Grokking Algorithms Адитьи Бхаргавы. Русский перевод под названием «Грокаем алгоритмы» появился в 2017 году. В отличие от энциклопедического Кнута и университетской CLRS, книга была рассчитана на первое знакомство с темой: короткие объяснения, рисунки, наглядная интуиция и примеры на Python (Manning, издательство «Питер» на Хабре).

В 2020 году появился еще один влиятельный формат подготовки: видеоразборы NeetCode. 30 мая 2020 года вышел самый ранний доступный ролик канала, разбор задачи LeetCode 1299 Replace Elements with Greatest Element on Right Side (первое видео NeetCode). Сам создатель Навдип Сингх пишет, что создал NeetCode в 2020 году, когда был без работы и готовился к найму (NeetCode).

Значение NeetCode было не в создании новых алгоритмов. Он сделал массовым определенный формат обучения: сначала визуальное объяснение идеи, затем реализация, анализ сложности и привязка задачи к повторяющемуся паттерну. В результате подготовка к интервью стала похожа не на чтение справочника, а на прохождение структурированного видеокурса по типовым моделям задач.

Когда алгоритмические интервью появились в России

Точную первую российскую компанию установить невозможно. Ранние процессы найма почти не документировались публично.

Тем не менее открытые свидетельства показывают, что узнаваемые алгоритмические и whiteboard-задачи применялись в России не позднее 2008 года:

• в публикации 2008 года интервьюер предлагал реализовать max-stack с операциями (O(1)), очередь через два стека и спиральный обход матрицы (Хабр);
• ABBYY в 2010 году официально описала интервью с задачами на алгоритмы и сообразительность (ABBYY);
• кандидат Яндекса в 2011 году описал задачи на массивы, сортировки и анализ сложности (Хабр);
• в 2013 году Яндекс публично рассказывал об алгоритмическом этапе и переходе от квадратичного решения к линейному (Яндекс).

У России была подготовленная почва: Всесоюзная олимпиада с 1988 года, сильные университетские команды, кружки, Timus и позднее Codeforces. Поэтому олимпиадная культура могла влиять на найм особенно сильно.

Корректная формулировка:

В России алгоритмические интервью публично документированы не позднее 2008 года. Среди первых крупных работодателей с открытым описанием процесса были ABBYY и Яндекс, но назвать абсолютного первопроходца нельзя.

Как устроено алгоритмическое интервью в Big Tech сегодня

Современный процесс обычно состоит не из одной встречи с будущим начальником, а из последовательности независимых оценок:

Отклик или приглашение рекрутера
        ↓
Recruiter screen
        ↓
Иногда online assessment
        ↓
Technical screen с live coding
        ↓
Full loop из 4–6 интервью
        ↓
Независимые письменные оценки
        ↓
Общее решение и team matching
        ↓
Offer

В full loop могут входить:

• 1–3 coding/DSA-раунда;
• system design, особенно для senior-кандидатов;
• behavioral-интервью;
• обсуждение прошлых проектов;
• вопросы по конкретному инженерному направлению.

Почему интервьюеры могут быть из других команд

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

У разных компаний свои механизмы:

• Google публично описывает структурированные вопросы, рубрики, обучение интервьюеров и рассмотрение пакета кандидата hiring committee (Google re:Work).
• Amazon включает в процесс независимого Bar Raiser. Он не относится к нанимающей команде, следит за общей планкой и участвует в финальном решении вместе с hiring manager (About Amazon).
• Microsoft сообщает, что кандидат встречается с несколькими потенциальными коллегами и кросс-функциональными сотрудниками. Конкретная схема сильнее зависит от команды и роли (Microsoft Careers).
• Netflix для backend-ролей описывает процесс с инженерами, hiring manager, recruiter, engineering director и партнерами из других направлений. Компания делает акцент на задачах, приближенных к реальной работе, а не на puzzle-style упражнениях (Netflix TechBlog).

Количество раундов зависит от компании, уровня, роли, страны и текущего процесса найма. Поэтому схема из интернета никогда не должна восприниматься как гарантированный сценарий.

Кто придумывает задачи

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

Обычно жизненный цикл вопроса выглядит примерно так:

Выбор проверяемой компетенции
        ↓
Создание или адаптация задачи
        ↓
Эталонные решения, тесты и edge cases
        ↓
Рубрика оценки и follow-up вопросы
        ↓
Проверка и калибровка сложности
        ↓
Добавление во внутренний банк
        ↓
Использование и анализ результатов
        ↓
Изменение или вывод задачи из обращения

Google официально пишет о проверенных role-relevant вопросах, единых шкалах, подробных заметках, рубриках и калибровке интервьюеров (Google re:Work).

Профессиональные платформы помогают компаниям создавать банки вопросов, проверять скрытые тесты и находить утечки. Например, HackerRank маркирует скомпрометированные задания и позволяет заменять их, а CodeSignal использует варианты задач, чтобы снизить эффект заучивания (HackerRank, CodeSignal).

При этом Big Tech не публикует свои полные внутренние каталоги. Поэтому нельзя уверенно утверждать, что в каждой компании:

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

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

Пять популярных мифов

«Алгоритмические интервью придумал Google»

Нет. IBM тестировала будущих программистов с 1955 года, а coding-интервью в Microsoft документированы в первой половине 1990-х.

«Все началось с олимпиад»

Не совсем. Олимпиады и корпоративный отбор развивались параллельно. Позже компании заимствовали алгоритмические темы и online-judge-механику.

«LeetCode создал этот формат»

Нет. К моменту появления LeetCode уже существовали whiteboard interviews, книги по подготовке и платформы автоматической проверки. LeetCode сделал подготовку массовой и систематической.

«На интервью оценивают только правильный код»

Оцениваются также уточнение задачи, объяснение решения, выбор структуры данных, сложность, тестирование и реакция на подсказки.

«Все компании проводят одинаковые интервью»

Нет. Даже внутри одной компании процесс зависит от уровня, роли, локации и команды. Для senior-разработчика system design и прошлые проекты обычно важнее, чем для выпускника.

История в одной временной шкале

Главный вывод

Алгоритмическое интервью не имеет одного изобретателя.

Сначала компании проверяли общие способности к логическому мышлению. Затем программистов начали просить писать код на бумаге и у доски. Параллельно олимпиады развивали культуру формальных задач, сложности и объективного судейства. Online judges сделали эту практику массовой, а LeetCode адаптировал ее специально под найм.

Поэтому современное алгоритмическое интервью можно представить как пересечение четырех традиций:

Тесты способностей
        +
Live coding
        +
Олимпиадные алгоритмы
        +
Автоматическая проверка
        =
Современное DSA-интервью

Этим задачам уже не пять и не десять лет. Их история в найме начинается в 1950-х, кодирование у доски хорошо документировано с 1990-х, а современный стандартизированный формат существует более двух десятилетий.

🐆