Когда алгоритм не нужно оптимизировать
Что проверяют
Умеете ли вы считать стоимость оптимизации, а не только сложность алгоритма. Интервьюеру важно услышать, что решение принимается по измерениям и требованиям, и почти всегда следом звучит вопрос: как вы поймёте, что оптимизировать всё-таки пора.
Как отвечать
Оптимизация не нужна, когда выигрыш никто не заметит, а цена в виде сложности кода вполне реальная. Типовые случаи:
- маленький и ограниченный вход: сортировка списка из пятидесяти элементов, перебор настроек пользователя. Важно, чтобы ограничение было гарантировано, а не держалось на «пока данных мало»;
- код не на горячем пути: задача раз в сутки, миграция, служебный эндпоинт. Экономить на них миллисекунды бессмысленно;
- время съедает другое: если запрос в базу идёт 40 мс, а цикл в памяти занимает микросекунды, ускорять цикл нет смысла;
- требования уже выполнены: сервис с запасом укладывается в SLA по латентности;
- быстрая версия хуже читается и тестируется, а выигрыш измеряется процентами на нагрузке, которой в проде нет.
Главная мысль: решение принимается по профилю, а не по ощущениям. В Java для поиска горячих мест в живом приложении есть JFR (Java Flight Recorder) и async-profiler, а для точечного сравнения вариантов JMH. Самописный бенчмарк на System.nanoTime() обманывает: JIT ещё не прогрет, а неиспользуемый результат компилятор может просто выбросить.
При этом асимптотику держат в голове всегда. Квадратичный алгоритм на тысяче элементов незаметен, а на миллионе превращается в инцидент, поэтому уместно спросить, как будут расти данные.
Где спотыкаются
Отвечают «оптимизация не нужна никогда, железо дешёвое». Это та же крайность, что и оптимизировать всё подряд: нужен критерий, а не лозунг.
Цитируют Кнута про преждевременную оптимизацию, но без контекста. У него речь о мелких улучшениях в некритичных местах, а не о выборе O(n²) вместо O(n log n) на растущих данных.
Делают выводы без замеров или по бенчмарку из main() с одним прогоном. Такие цифры отражают прогрев JVM, а не качество алгоритма.