Что такое рекурсия

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

В ответе не останавливайтесь на фразе "функция вызывает саму себя". Добавьте две вещи: когда она остановится и почему каждый следующий вызов ближе к остановке.

function factorial(n) {
  if (n <= 1) {
    return 1;
  }

  return n * factorial(n - 1);
}

Здесь n <= 1 это базовый случай. Вызов factorial(n - 1) уменьшает задачу, поэтому функция рано или поздно дойдет до остановки.

Короткий сильный ответ можно построить так:

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

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

Во frontend-разработке рекурсия часто встречается не в математике, а в данных. Это меню с подменю, дерево комментариев, вложенные категории, DOM-подобные структуры и JSON от API.

Например, можно собрать список всех id из дерева:

function collectIds(node, result = []) {
  if (!node) {
    return result;
  }

  result.push(node.id);

  for (const child of node.children ?? []) {
    collectIds(child, result);
  }

  return result;
}

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

Рекурсия не делает решение автоматически лучше. Она выигрывает, когда код становится проще из-за формы данных. Если же вы обрабатываете обычный массив, рекурсивное решение может быть менее понятным и более рискованным.

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

Для React добавьте практический нюанс. Рекурсивный компонент для меню или комментариев нормален, но глубина, ключи и объем данных должны быть под контролем. Иначе пользователь увидит долгий первый рендер, зависание при раскрытии ветки или падение экрана на неожиданно глубоком ответе API.

Хвостовая рекурсия это форма, где рекурсивный вызов стоит последним действием функции. В некоторых языках это позволяет компилятору не хранить все предыдущие вызовы в стеке.

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

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

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