Вопросы на собеседовании PHP-разработчика

Пример сильного ответа

readonly-свойство можно присвоить только один раз — при объявлении или в конструкторе, дальше любая запись вызывает ошибку. Это удобно для value-объектов: DTO, денежные суммы, идентификаторы, конфиги, где важна неизменяемость и предсказуемость. readonly-класс помечает так все свойства сразу и убирает повторяющийся код. В проекте с интеграцией платежей перевод DTO на readonly-классы убрал целый класс ошибок с неявной мутацией: инцидентов, связанных с изменением объекта после валидации, стало примерно вдвое меньше. Ограничение ровно одно — после инициализации объект не меняется, поэтому там, где нужны постепенное наполнение и сеттеры, использую обычные классы.

• Сначала суть механики, потом практика применения
• Приведён измеримый результат из собственного опыта
• Честно названо ограничение подхода

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

Пример сильного ответа

Директива включает строгий режим проверки типов для аргументов и возвращаемых значений в этом файле: вместо неявного приведения PHP выбрасывает TypeError. Это ловит ошибку в момент вызова, а не через несколько слоёв логики, и строка или число больше не превращаются молча во что-то неожиданное. В команде из пяти разработчиков строгий режим — стандарт с первого дня: файл без него просто не проходит код-ревью. После включения в основном сервисе доля багов, доходящих до тестировщиков, снизилась примерно на четверть, а отладка ускорилась, потому что стек указывает на конкретное место. Компромисс — иногда приходится приводить типы явно, но от этого код только понятнее.

• Объяснена механика, а не только польза
• Показан командный стандарт и его эффект в цифрах
• Назван компромисс — ответ звучит взвешенно

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

Пример сильного ответа

Класс с константами — это просто именованные значения: он не мешает подставить произвольную строку, не даёт перебрать все варианты и не несёт поведения. Enum задаёт закрытое множество значений, и тип в сигнатуре гарантирует, что придёт один из вариантов, а не что угодно. Экземпляры единственны в своём роде, их удобно сравнивать напрямую, использовать в match без ветки по умолчанию и в readonly-свойствах. Enum умеет методы и интерфейсы, а backed enum хранит значение для базы. В проекте перевод статусов заказа с констант на enum убрал ручные проверки валидности и сократил объём кода обработчиков примерно на треть.

• Сравнение построено по конкретным критериям
• Упомянуты match, интерфейсы и хранение в базе
• Есть результат: меньше кода и проверок

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

Пример сильного ответа

Composer — менеджер зависимостей: он читает composer.json, подбирает версии с учётом требований всех пакетов и складывает код в vendor. composer.lock фиксирует точный набор версий, поэтому у всех участников и на сервере получается одинаковый результат: в CI и на деплое запускаю install по lock-файлу, а update — только осознанно и с проверкой тестами. Автозагрузка PSR-4 сопоставляет пространство имён с каталогом, и Composer генерирует карту классов, так что require вручную не нужен. Папку vendor не коммитят: это результат установки, она раздувает репозиторий и провоцирует конфликты. В текущем проекте около сорока зависимостей, и такой порядок экономит часы на каждом релизе.

• Ответ идёт от общего механизма к деталям
• Показано различие install и update на практике
• Объяснено, почему lock-файл важнее папки vendor

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

Пример сильного ответа

Чаще всего применяю constructor property promotion, readonly-свойства и enum — они убирают шаблонный код в DTO и доменных моделях. Named arguments помогают делать вызовы читаемыми, когда у метода много необязательных параметров. Nullsafe-оператор и match заметно сокращают проверки на null. В одном проекте после перехода на эти возможности объём служебного кода в слое DTO сократился примерно на треть, а число замечаний по типам на ревью заметно упало. Новые версии внедряю постепенно: сначала статические анализаторы и тесты, потом рефакторинг небольшими порциями, чтобы не ломать релизы и не смешивать обновление языка с изменением логики.

• Показана практика, а не перечисление фич
• Есть измеримый результат перехода
• Видно осторожное отношение к внедрению

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

Пример сильного ответа

match — это выражение, оно возвращает значение, сравнивает строго и не проваливается в следующую ветку. Если ни одна ветка не подошла, выбрасывается ошибка, поэтому забытый случай виден сразу, а не превращается в тихий баг. switch удобнее там, где нужны побочные эффекты и сложные условия с break. match предпочитаю для маппинга enum в текст, статусов, кодов ответа и любых преобразований «значение — результат». В одном сервисе перевод статусов на match убрал десяток лишних break, сделал функцию заметно короче, а тесты перебора сразу показали варианты, которые раньше просто не обрабатывались.

• Точное сравнение по существу, а не по синтаксису
• Назван рабочий кейс со статусами
• Сказано, когда switch уместнее

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

Пример сильного ответа

Больше опыта у меня с Laravel, но проекты на Symfony тоже были, поэтому сравниваю осознанно. Laravel — про скорость разработки: готовые решения из коробки, Eloquent, фасады, единый стиль, поэтому MVP собирается быстро. Symfony — про конфигурируемость и строгую архитектуру: явные сервисы, контейнер зависимостей, компонентность, легко подключить только нужное. Для небольшой команды и продукта с частыми релизами чаще выбираю Laravel. Там, где важны долгоживущая кодовая база, гибкость и много интеграций, сильнее выглядит Symfony. Опыт обоих фреймворков помогает переносить практики: строгие сервисы в Laravel, а скорость и удобство — в Symfony.

• Честный ответ про оба фреймворка, без спора
• Есть критерии выбора под задачу
• Показана зрелость взгляда на стек

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

Пример сильного ответа

N+1 — это когда на список из N сущностей ORM делает один запрос за списком и ещё N запросов за связанными данными. Нахожу через лог запросов и профайлер: смотрю число однотипных SQL на одну страницу и сверяю с количеством элементов в ответе. Дальше жадная загрузка связей, выборка только нужных колонок, иногда join или агрегат вместо обхода в цикле. На одном каталоге страница отдавала около девятисот запросов и отвечала примерно две секунды; после жадной загрузки осталось порядка двенадцати запросов и около двухсот миллисекунд. Такие места закрываю тестами на количество запросов.

• Дано чёткое определение проблемы
• Названы инструменты поиска и приёмы лечения
• Есть цифры до и после оптимизации

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

Пример сильного ответа

Миграции держу в репозитории: они версионируются вместе с кодом и прогоняются в том же пайплайне, что и деплой. Схему меняю по принципу «расширение — сжатие»: сначала добавляю новую колонку или таблицу как необязательную, потом постепенно, батчами заполняю данные, затем код начинает писать в оба места, читать из нового, и только после этого старые объекты удаляются. Тяжёлые изменения применяю через инструменты онлайн-миграции, чтобы не блокировать таблицу. На таблице в десятки миллионов строк такой подход позволил обновлять схему без остановки сервиса: пользователи не заметили ни одного перерыва в работе.

• Описан безопасный паттерн расширение-сжатие
• Учтены объём данных и блокировки
• Результат — обновление без простоя

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

Пример сильного ответа

Транзакция для меня — инструмент там, где несколько записей должны измениться как единое целое: списание баланса, создание заказа с позициями, перенос данных. Мне приходилось вести проект, где на оплатах проскакивали двойные списания: после того как связка записей оказалась в одной транзакции и добавилась блокировка строки, число обращений в поддержку упало с нескольких десятков в месяц до нуля. Уровни знаю: read uncommitted, read committed, repeatable read, serializable — выбираю по задаче: для массовых отчётов достаточно мягкого, для денежных операций строже. Правила держу простыми: транзакция короткая, без внешних вызовов внутри, дедлоки ловлю и повторяю операцию.

• Показан конкретный эффект: двойные списания ушли
• Перечислены все четыре уровня изоляции
• Правила коротких транзакций и обработки дедлоков

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

Пример сильного ответа

Начинаю с фактов: включаю медленный лог базы, снимаю реальные планы через EXPLAIN, ищу полный перебор строк и временные таблицы. Чаще всего помогает составной индекс в правильном порядке, отказ от SELECT * и от вычислений над индексируемым полем; отдельно проверяю N+1 на стороне приложения. На одном проекте список заказов открывался около четырёх секунд: после составного индекса и ухода от N+1 уложились в двести миллисекунд. Большие выборки перевожу на постраничный вывод по ключу, тяжёлые агрегаты — в кэш. После каждого изменения сравниваю план и время до и после.

• Виден системный порядок: лог, план, индекс, проверка
• Есть измеримый результат до и после
• Упомянуты N+1 и постраничный вывод

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

Пример сильного ответа

В одной из моих задач очереди обрабатывали оплату и уведомления — до 40 тысяч задач в сутки. Подход такой: сначала идемпотентность — у каждой операции свой ключ, результат сохраняется в таблице, повторная обработка того же ключа просто возвращает готовый ответ. Повторные попытки делаю с экспоненциальной задержкой и лимитом попыток, например три-пять, а после — отдельная очередь для разбора, чтобы не терять задачи. Задержки — через отложенные сообщения: не блокирую воркер, а планирую. В итоге доля ручных разборов упала примерно на 70 процентов, а дубли списаний исчезли.

• Идемпотентность, ретраи и задержки разобраны по отдельности — видно систему
• Есть свои цифры: 40 тысяч задач в сутки и минус 70% ручных разборов
• Речь практика: ключ, лимит попыток, отложенные сообщения, разбор ошибок

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

Пример сильного ответа

OPcache хранит скомпилированный байт-код в общей памяти, поэтому PHP не разбирает одни и те же файлы на каждом запросе: на тяжёлых фреймворках выигрыш по времени отклика заметный. В продакшене включаю его полностью, память выделяю с запасом по числу файлов, лимит кэшируемых скриптов ставлю выше реального количества — иначе часть файлов не попадает в память. На проекте около двух тысяч файлов, и кэш стабильно держит их целиком. Проверку времени изменения файлов отключаю и сбрасываю кэш при деплое, иначе теряется смысл ускорения. Слежу за долей попаданий и за перезапусками: рост перезапусков — сигнал, что памяти мало.

• Объяснён механизм кэша байт-кода простыми словами
• Есть продакшен-акценты: сброс при деплое, память
• Приведена метрика доли попаданий

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

Пример сильного ответа

Сначала цифры, потом оптимизация. Локально и на тестовой среде профилирую Xdebug или xhprof, в продакшене держу сбор метрик и лог медленных запросов. Первым делом смотрю p95 и p99 времени ответа, долю ошибок, пиковое потребление памяти, число запросов к базе на один запрос приложения и загрузку процессора. На одном проекте p95 держался около восьмисот миллисекунд: профиль показал тяжёлый сериализатор и лишние обращения к базе, после правок уложились в двести пятьдесят. Профилировщик включаю точечно и на выборке трафика, чтобы не ронять производительность на бою.

• Сначала метрики, потом оптимизация — зрелый подход
• Названы p95, p99 и число запросов к базе
• Есть результат с измеримым улучшением

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

Пример сильного ответа

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

• Сразу видно приоритет: сначала анализ боли, потом рефакторинг
• Тесты как страховка — сигнал инженерной зрелости
• Конкретные цифры результата вместо общих слов

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

Пример сильного ответа

Redis использую для кэша горячих выборок, счётчиков, очередей и блокировок. Ключи строю по понятной схеме с префиксом и версией, чтобы их можно было группировать и находить. По инвалидации придерживаюсь правила: либо у ключа есть TTL и данные не критичны к задержке, либо запись идёт через явное удаление связанных ключей при изменении сущности. От «сбросить всё» стараюсь уходить — это скрывает ошибки. Плюс добавляю разброс по TTL, чтобы не было лавины. В одном проекте такой подход снизил нагрузку на базу примерно на 60 процентов и убрал жалобы на устаревшие данные.

• Показано понимание схемы ключей и роли TTL
• Есть trade-off между простотой и точечной инвалидацией
• Число про нагрузку на базу делает ответ предметным

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

Пример сильного ответа

Чаще всего в PHP-приложениях встречаю инъекции, XSS, CSRF, подмену идентификаторов объектов, небезопасную десериализацию и проблемы с загрузкой файлов. Защита у меня выстроена по слоям: доступ к базе только через подготовленные выражения, вывод экранируется в шаблоне, права проверяются на сервере для каждой сущности, а не в интерфейсе. Для форм — токены и проверка источника запроса, для загрузок — белый список расширений и хранение вне корня сайта. Дополнительно прогоняю зависимости через анализатор известных уязвимостей. В одном проекте такой разбор дал 14 проблемных мест, и все они закрыты до релиза.

• Перечислены реальные классы уязвимостей, а не общие слова
• Ответ про защиту по слоям, а не про один приём
• Есть измеримый итог: найденные и закрытые места

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

Пример сильного ответа

Начинаю с измерений, а не с догадок: смотрю время ответа на сервере и распределение, сколько запросов реально укладывается в норматив. Дальше профилировщик и лог медленных запросов: разбираю, что съедает время — база, внешние вызовы или самостоятельно PHP. Частая причина — N+1: в одном случае список из сотни заказов тянул больше тысячи запросов вместо трёх. После переписывания выборки и добавления индексов ответ уложился примерно в 200 миллисекунд. Результат закрепляю метрикой и тестом на нагрузку, чтобы регресс не вернулся.

• Сначала диагностика, потом гипотезы — правильный порядок
• Названа типовая причина и способ её проверки
• Есть цифры до и после оптимизации

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

Пример сильного ответа

План такой: сначала зафиксировать точку отсчёта — тесты, статический анализ и метрики ошибок, чтобы эффект был виден. Затем зависимости и расширения: без них переход бессмысленен. Дальше двигаюсь по промежуточным версиям, а не прыгаю сразу, включаю логирование устаревших вызовов и разбираю их по модулям. Ветка обновления живёт параллельно, CI собирает проект на двух версиях, поэтому разработка не встаёт. Релиз — канареечный, по частям трафика, с быстрым откатом. В похожей задаче переход занял около трёх недель, порядка 200 автотестов прошли зелёными, а доля ошибок в логах заметно снизилась.

• Есть последовательность этапов, а не лозунг «надо обновиться»
• Учтено, что разработка продолжается параллельно
• Названы сроки, тесты и эффект по логам

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

Пример сильного ответа

Обычно я не спорю с менеджером, а предлагаю вариант. Мне приходилось попадать в похожую ситуацию: до релиза два дня, объём — примерно пятнадцать эндпоинтов. Моя задача — выкатить ценность и не сломать прод. Поэтому предлагаю минимальный объём: критичные сценарии закрываю тестами на ключевую бизнес-логику, остальное выношу за фича-флаг и включаю сначала на часть трафика. Риски проговариваю письменно: что именно может сломаться и как откатываемся. В итоге релиз вышел в срок, а остаток тестов закрыли в течение недели.

• Показывает готовность искать компромисс, а не спорить
• Конкретный план снижения риска: тесты и фича-флаг
• Есть результат: релиз в срок и закрытый долг

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

Пример сильного ответа

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

• Чёткая структура: симптом, диагностика, причина, фикс
• Конкретные цифры: один из пятисот, ноль после фикса
• Виден системный подход вместо угадывания

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

Пример сильного ответа

Спокойно, для меня это нормальная часть работы. Мне приходилось переписывать решение после ревью тимлида, и это пошло на пользу: код стал короче примерно на сто строк. Моя задача — понять аргумент, а не защищать свой вариант. Если замечание про стиль, просто правлю. Если спорное — задаю вопросы: какие риски видит коллега, есть ли похожие примеры в кодовой базе. Когда аргументы сильнее моих, принимаю; когда нет — спокойно объясняю свою логику и предлагаю обсудить голосом. В итоге договорились о правиле для команды, и похожие споры почти ушли.

• Спокойная реакция на критику без обиды
• Различает стилевые замечания и спор по существу
• Заканчивает улучшением командных правил

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

Пример сильного ответа

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

• Понятная последовательность работы с legacy
• Ключевая идея — фиксировать текущее поведение тестами
• Есть цифра: с трёх дней до одного

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

Пример сильного ответа

Регулярно, но без фанатизма. У меня есть привычка раз в неделю просматривать changelog и список RFC по PHP — так понимаю, куда движется язык, а не узнаю о переменах на проде от других. Моя задача — отличать интересное от применимого: если нововведение упрощает код и есть поддержка в инфраструктуре, пробую его на небольшом проекте или в пет-проекте. Ещё читаю разборы и хожу на митапы, а полезное доношу до команды: например, внутренний доклад на сорок минут про типизацию, после которого коллеги стали активнее использовать строгие типы.

• Конкретная привычка вместо общих слов про саморазвитие
• Отличает применимое от модного
• Делится знаниями, есть измеримый эффект в команде

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