Был ли отдельный отдел для нагрузочного тестирования или занимались вы
Что проверяют
Как была устроена работа с производительностью в вашей прошлой команде и какую роль в ней играли лично вы. Интервьюер отделяет тех, кто писал и анализировал нагрузочные тесты, от тех, кто видел только отчёты. Следом спрашивают про инструменты и метрики.
Как отвечать
Начните с честного описания структуры: была отдельная команда производительности, этим занимались SRE, нагрузку делали сами QA или её не проводили вовсе. Потом опишите свою роль. Если занимались сами, пройдитесь по циклу:
- цель и профиль нагрузки: какие сценарии, какой ожидаемый RPS, откуда взяли цифры (логи прода, прогноз бизнеса);
- виды тестов: нагрузочный на целевой уровень, стресс до отказа, длительный (soak) на утечки памяти, пиковый (spike);
- инструменты: JMeter, Gatling, k6, Locust, в российских компаниях часто Яндекс.Танк. JMeter для нагрузки запускают без GUI:
jmeter -n -t plan.jmx -l result.jtl; - метрики: время ответа по перцентилям p95 и p99, пропускная способность, доля ошибок, плюс ресурсы серверов в Grafana по данным Prometheus;
- окружение: насколько стенд был похож на прод и как готовили тестовые данные;
- результат: какое узкое место нашли (пул соединений, медленный запрос, отсутствие кэша) и что изменилось после исправления.
Если нагрузкой занимались другие, так и скажите: «была отдельная команда, я согласовывал с ними сценарии и проверял функциональность после оптимизаций». Добавьте, что изучали сами, например писали сценарий на k6 для учебного API. Это честно и показывает интерес.
Где спотыкаются
Приписывают себе всю нагрузку, а на вопросе про перцентили или про разницу между виртуальными пользователями и RPS теряются.
Смотрят на среднее время ответа. Среднее прячет хвост: при среднем 200 мс каждый сотый запрос может идти три секунды.
Запускают сотню потоков JMeter с ноутбука в GUI-режиме и выдают это за нагрузочное тестирование. Генератор сам становится узким местом, и цифры ничего не говорят о сервере.