Вопросы с собесебования на senior php developer (11 вопросов из ютуба)

Послушал сегодня довольно качественное интервью:

Вопрос 1. Опыт оптимизации архитектуры

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

Какие ключевые решения вы принимали и почему?

Как вы обеспечили масштабируемость и поддерживаемость этой архитектуры?

Пример:

• Проект: Высоконагруженная платформа электронной коммерции B2B с ежедневной обработкой ~500k заказов, интеграцией с 50+ поставщиками и сложной логикой ценообразования.

• Исходное состояние: Монолит на Laravel 5.x, одна база данных MySQL, синхронные интеграции с API поставщиков, время ответа критичных эндпоинтов до 3-5 секунд при пиковой нагрузке.

Ключевые проблемы, которые нужно было решить:

1. Масштабирование: Пиковые нагрузки (Черная пятница) приводили к полной остановке системы.

2. Поддерживаемость: Новые разработчики тратили 2-3 месяца на онбординг из-за высокой связности кода.

3. Надежность интеграций: Падение API одного поставщика блокировало обработку заказов от других.

4. Гибкость: Внедрение нового типа поставщика занимало 2-3 месяца из-за необходимости изменять ядро системы.

Методики оптимизации:

• Переход к модульной монолитной архитектуре с четкими границами контекстов (Bounded Contexts)
• Внедрение CQRS и Event Sourcing для критичных подсистем
• Асинхронная обработка через message broker и worker-ы
• Стратегическое кэширование многоуровневой архитектуры
• Шардинг базы данных и read-replicas

Вопрос 2. Паттерн «Стратегия»

Как вы реализуете паттерн проектирования ‘Стратегия’ в PHP?

В каких ситуациях его применение будет наиболее целесообразным?

Приведите пример кода.

Паттерн «Стратегия» (Strategy) — это поведенческий паттерн проектирования, который определяет семейство схожих алгоритмов, инкапсулирует каждый из них и делает их взаимозаменяемыми. Он позволяет изменять алгоритмы независимо от клиентов, которые ими пользуются.

Когда целесообразно применять паттерн «Стратегия»:

1. Когда есть несколько вариантов одного алгоритма и нужно выбирать между ними в runtime.
2. Когда в коде много условных операторов для выбора различных вариантов поведения.
3. Когда необходимо изолировать логику алгоритма от клиентского кода для соблюдения принципа единственной ответственности.
4. Для соблюдения принципа открытости/закрытости — добавление новых алгоритмов без изменения существующего кода.
5. В коммерческих проектах часто применяется для:
   • Платежных систем (разные процессинги)
   • Систем доставки (разные службы)
   • Систем скидок и промо-акций
   • Форматов экспорта/импорта данных
   • Алгоритмов ценообразования
   • Стратегий кэширования
   • Методов аутентификации

Вопрос 3. Оптимизация запросов

Как вы оптимизируете запросы к базе данных в PHP для улучшения производительности в приложении с большем объемом данных?

Расскажите о вашем опыте оптимизации SQL-запросов и работы с индексами.

Для оптимизации запросов к БД в PHP-приложениях я применяю комплексный подход:

1. анализ и оптимизация SQL-запросов через EXPLAIN,

2. правильное проектирование и использование индексов,

3. кэширование результатов,

4. нормализация/денормализация данных,

5. использование репликации и шардинга.

   Ключевой опыт — на проекте аналитической платформы, где оптимизация индексов и переработка запросов сократила время выполнения отчетов с 12 секунд до 400 мс.

Вопрос 4. Тяжелый запрос

Представьте что у вас есть очень тяжёлый sql запрос, который выполняется 1 минуту и никак его оптимизировать нельзя.

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

Вы, конечно же, закэшируете данные запроса (например на 5 минут) и в дальнейшем пользователи будут работать с этим кэшем.

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

Как бы вы решили такую проблему?

Краткий ответ:

Проблема известна как «Thundering Herd» (стадный эффект). Решаю комбинацией подходов:

• 1. предварительное обновление кэша до его истечения,
• 2. использование мьютексов (блокировок) для гарантии выполнения только одного тяжелого запроса,
• 3. возврат устаревших данных с фоновым обновлением,
• 4. добавление случайного разброса времени жизни кэша,
• 5. использование асинхронной очереди запросов.

В PHP-приложениях чаще всего применяю связку «предобновление кэша + Redis-блокировки».

Вопрос 5. Разница между PK & Unique

Объяснить разницу между primary key и unique key в MySQL

Primary Key (первичный ключ) — уникальный идентификатор записи, который не может быть NULL, создает кластерный индекс, может быть только один на таблицу. Unique Key (уникальный ключ) — обеспечивает уникальность значений, может быть NULL, может быть несколько на таблицу, создает неуникальный индекс. Оба гарантируют уникальность, но Primary Key имеет дополнительные ограничения и семантическую значимость.

Вопрос 6. Партифионирование

Что такое партицирование? Задача на партицинирование:

Что будет если разбить партицию по одному параметру (к примеру, по id),

а запрашивать данные по другому параметру (к примеру, по user_sex).

Будет ускорение выборки, замедление выборки или не будет отличий вообще.

От чего это может зависеть?

Краткий ответ:

Партиционирование — физическое разделение таблицы БД на части по определённому столбцу для ускорения запросов и удобства управления.

Если разбить по id, а запрашивать по user_sex: скорее всего будет замедление,

потому что БД придётся сканировать все партиции (нельзя применить partition pruning).

Результат зависит от:

1. Наличия индекса на user_sex
2. Типа партиционирования (hash, range, list)
3. Распределения данных
4. Возможностей оптимизатора СУБД
5. Количества партиций

Вывод: Партиционирование эффективно только при запросах по столбцу партиционирования. В противном случае — добавляет накладные расходы.

Вопрос 7. Задача на поиск

Есть постоянно обновляемая таблица из нескольких миллионов записей о пользователях и их очков.

Необходимо на клиентской стороне показывать ТОП-100 пользователей.

Как бы вы это реализовали?

Использовать Redis Sorted Set для хранения актуального рейтинга, обновляя его асинхронно при каждом изменении очков в основной БД (MySQL/PostgreSQL).

Получение топа: ZREVRANGE top_scores 0 99.

Для отказоустойчивости : дублирование данных в БД, кэширование на короткий TTL или materialized view.

Вопрос 8. Чем в GIT отличается merge or rebase.

Читая официальное руководство Git, говорится, что:

• “rebase повторно применяет коммиты поверх другой базовой ветви”, тогда как
• “merge объединяет две или более истории разработки вместе”.

Другими словами, ключевое различие между merge и rebase заключается в том, что в то время как merge сохраняет историю в том виде, в каком она произошла, rebase переписывает ее.

Вопрос 9. Что такое php-fpm и FastCGI?

• FastCGI — протокол для общения веб-сервера (Nginx/Apache) с внешними программами (PHP), где процессы долгоживущие, а не создаются на каждый запрос.
• PHP-FPM — менеджер процессов PHP, реализующий FastCGI, с расширенными возможностями: управление пулом процессов, graceful перезапуск, мониторинг.
• Связь: Веб-сервер (Nginx) → FastCGI → PHP-FPM → PHP-воркеры.

Вопрос 10. Инструменты отладки

Какие инструменты и методики вы используете для отлирования PHP-приложений? Расскажите о случае, когда удалось значительно улучшить производительность с помощью профилировки.

Инструменты: Xdebug (для детального анализа), Blackfire.io (production-профилирование), Tideways/XHProf, New Relic APM (мониторинг в реальном времени), а также встроенные средства (memory_get_usage(), microtime).

Методики: Анализ медленных запросов, профилирование под нагрузкой, сравнение «до/после», поиск «узких мест» (CPU, память, I/O).

Пример случая:

На проекте аналитической платформы API-отчёт выполнялся 12+ секунд из-за N+1 запросов (200+ SQL) и неоптимальных алгоритмов.

С помощью Blackfire.io выявили:

• 75% времени — работа с БД,

• рекурсивная функция для построения дерева категорий.

Оптимизации:

1. Заменили N+1 на агрегирующие запросы с JOIN.

2. Добавили кэш Redis для промежуточных данных.

3. Переписали рекурсивный алгоритм на итеративный с хеш-таблицами.

4. Настроили составные индексы в БД.

Результат: Время выполнения сократилось до 400–600 мс, количество запросов к БД — с 200+ до 3–5, потребление памяти уменьшилось в 6 раз.

Вопрос 11. Задача на сортировкуслияние массивов

Дано два отсортированных массива целых чисел.

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

Сделать алгоритм с минимальной сложностью.

Краткое объяснение алгоритма:

Алгоритм «двух указателей» (two pointers):

1. Инициализируем два указателя/индекса — один для начала первого массива (i), другой для начала второго (j).
2. Сравниваем текущие элементы обоих массивов на позициях i и j.
3. Добавляем в результат меньший из двух элементов и сдвигаем соответствующий указатель на следующий элемент.
4. Повторяем шаги 2-3, пока не дойдём до конца хотя бы одного массива.
5. Добавляем оставшиеся элементы из не полностью пройденного массива.

Простая аналогия:
Представьте две упорядоченные колоды карт.

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

Сложность: O(n + m), где n и m — длины массивов. Каждый элемент каждого массива обрабатывается ровно один раз.

Ключевые моменты:

• Использует факт того, что оба массива уже отсортированы
• Не требует сортировки после объединения
• Работает за линейное время — это минимально возможная сложность для данной задачи