Собеседование PHP-разработчика: вопросы, задачи и подготовка

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

В этом материале мы разберём полный цикл технического интервью для PHP-разработчиков уровней Junior, Middle и Senior. Внутри — типовые вопросы по PHP Core, Laravel и Symfony, разбор лайвкодинга и тестовых заданий, блок по SQL, API, безопасности и производительности, а также практические чек-листы для подготовки и переговоров об офере. Если вы хотите не просто «попробовать», а прийти на собеседование с чётким планом — читайте дальше.

Этапы собеседования PHP: что будет и как оценивают?

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

Типовой пайплайн выглядит так:

HR-скрининг → Техскрининг → Техническое интервью → Лайвкодинг / Тестовое → Финал → Оффер

На каждом этапе — своя логика и свои ловушки. Давайте пройдёмся по каждому.

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

Кто участвует и зачем

HR-скрининг — это первичный фильтр: проверяют соответствие ожиданий по грейду, стеку, локации и компенсации. Здесь важно говорить чётко и без лишней скромности. Техскрининг обычно проводит Senior-разработчик или тимлид — за 30–45 минут он проверяет базовый технический уровень и «общую вменяемость» кандидата. Техническое интервью — уже полноценный разговор: архитектура, подходы, опыт, обсуждение компромиссов. Финал чаще всего включает встречу с менеджером или продуктовой командой.

Ниже — сводная таблица по этапам:

Что считается «сильным сигналом»

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

Кирилл Мокевнин, CEO Hexlet: «Проблема большинства кандидатов на live-coding — это попытка решить задачу ‘в лоб’, не обсудив требования. Навык проектирования интерфейса функции до реализации — самый дефицитный навык на рынке.»

Лайвкодинг vs тестовое: что выбрать и как готовиться

Для кандидата лайвкодинг — это стресс-тест: вас видят в процессе, со всеми паузами и ошибками. Плюс — быстро, без домашней работы. Тестовое, напротив, даёт время подумать, но требует аккуратного оформления и занимает 3–8 часов реального времени.

Практика показывает, что большинство провалов на лайвкодинге — не из-за незнания алгоритмов, а из-за стресса и молчания. Поэтому первое правило: проговаривайте вслух всё, что делаете. «Я сейчас предполагаю, что входные данные — валидный массив, уточняю…» — это уже сильный сигнал. Второе правило: уточняйте требования до того, как написать первую строку кода. Третье: фиксируйте допущения — это снимает ответственность за «неправильное» решение правильно поставленной задачи.

К тестовому готовьтесь отдельно: структура репозитория, README, запуск через Docker — об этом подробнее поговорим в разделе про задачи.

Вопросы по PHP Core: что спросят у Junior/Middle/Senior?

PHP-интервью редко сводится к вопросу «назовите все методы массива». Куда чаще вас попросят объяснить, почему вы выбрали один подход вместо другого, что произойдёт «под капотом» при конкретном вызове, и как бы вы решили задачу в условиях продакшена. Давайте разберём, что именно проверяют — и как отвечать так, чтобы это звучало как опыт, а не как пересказ документации.

PHP 8: что знать и как говорить об этом

PHP 8.x принёс достаточно изменений, чтобы незнание хотя бы основных фич сразу выдавало кандидата, который давно не обновлял картину мира. Вот что проверяют чаще всего:

• Типизация и strict_types. Вопрос «зачем вообще declare(strict_types=1)?» — классика техскрининга. Правильный ответ включает не только «чтобы не было неявных приведений», но и понимание, что строгая типизация работает только в пределах файла, где объявлена. Union types (int|string), nullable types (?string), intersection types — всё это стоит уметь объяснять на примере реальной задачи, а не абстрактно.
• Fibers, match, named arguments, enums. Middle и Senior должны понимать не только синтаксис, но и когда применять. Например: match — это не просто «красивый switch», это строгое сравнение без приведения типов и с гарантией покрытия всех случаев.
• Итераторы и генераторы. Типичный вопрос на Middle+: «В чём разница между Iterator и Generator? Когда вы бы выбрали генератор?». Ответ должен включать практику: генераторы экономят память при обработке больших наборов данных, потому что не загружают весь результат в массив. Хороший ответ звучит примерно так: «Мы использовали генераторы при построчном чтении CSV-файлов на несколько сотен тысяч строк — это позволило не упираться в memory_limit даже на бюджетных серверах».

ООП: не теория, а компромиссы

Вопросы по ООП — это зона, где кандидаты чаще всего дают «правильные» ответы, которые звучат как учебник, но не как опыт. Разберём, что реально проверяют.

• Инкапсуляция, полиморфизм, наследование. Эти слова должны сопровождаться примером из практики, а не определением. Если вас спрашивают про полиморфизм — расскажите про конкретный случай, когда единый интерфейс позволил подключить новый тип обработчика без изменения основного кода.
• Интерфейсы vs абстрактные классы. Правильный ответ: интерфейс — контракт без реализации, абстрактный класс — частичная реализация с возможностью переопределения. Но более зрелый ответ добавляет: «В PHP класс может реализовывать несколько интерфейсов, но наследовать только один класс — это влияет на архитектурные решения».
• Композиция vs наследование. Senior-вопрос, который проверяет понимание долгосрочных последствий. Наследование создаёт жёсткую связь, которую сложно разорвать. Композиция — гибче, но требует больше кода. Хороший ответ включает: когда именно вы предпочли бы одно другому, и чем это обернулось на практике.
• SOLID на примерах. Не пересказывайте акроним — покажите, как принципы проявляются в реальном коде. Например, принцип единственной ответственности (SRP) часто нарушается, когда контроллер одновременно валидирует данные, обращается к базе и формирует ответ. Разделение этих обязанностей на отдельные слои — это и есть SRP в действии.

Матрица ожиданий по грейдам

Экосистема: Composer, PSR и автозагрузка

Этот блок чаще всего недооценивают Junior-кандидаты — и зря. Вопрос «как работает автозагрузка в Composer?» встречается на техскрининге регулярно. Правильный ответ: Composer генерирует autoload_classmap.php и autoload_psr4.php, которые PHP использует через spl_autoload_register для подгрузки классов по требованию. Знание PSR-4 (автозагрузка), PSR-7 (HTTP-сообщения), PSR-19 (стиль кода) и PSR-3 (логирование) — обязательный минимум для Middle.

Три примера хороших ответов

Вопрос: «Что такое traits и когда их использовать?» Слабый ответ: «Traits — это способ повторно использовать код в нескольких классах». Сильный ответ: «Traits решают проблему горизонтального переиспользования кода там, где наследование неуместно. Мы применяли trait для логирования действий пользователя — он подключался к нескольким сервисам без создания общего предка. Минус: traits усложняют понимание класса, если их несколько, поэтому мы ограничивались одним trait на класс и документировали, зачем он здесь».

Вопрос: «В чём разница между == и === в PHP?» Слабый ответ: «Тройное равно проверяет тип». Сильный ответ: «== выполняет нестрогое сравнение с приведением типов — это источник неочевидных багов, например 0 == «a» вернёт true в PHP 7. В PHP 8 это поведение изменили, но мы всё равно используем === по умолчанию в продакшен-коде как явную защиту от подобных сюрпризов».

Вопрос: «Как вы обрабатываете исключения в приложении?» Слабый ответ: «Оборачиваем в try/catch». Сильный ответ: «Мы выстраивали иерархию исключений: базовый AppException, от него наследовались ValidationException, NotFoundException и так далее. На уровне фреймворка — глобальный обработчик, который форматировал ответ в зависимости от типа исключения. Это позволило убрать дублирующийся код из контроллеров и централизовать логику формирования ошибок».

Laravel/Symfony: частые вопросы и как закрыть «разрыв опыта»

Фреймворковые вопросы — это отдельная игра. Здесь важно не просто знать API конкретного инструмента, но и понимать концепции, которые за ним стоят. Потому что именно концепции переносятся между фреймворками — а синтаксис гуглится за пять минут. Давайте разберём, что проверяют в каждом случае, и отдельно поговорим о ситуации, когда в вакансии написано Symfony, а у вас за плечами три года Laravel.

Laravel: что проверяют и что показать ответом

• Сервис-контейнер и dependency injection. Это сердце Laravel, и непонимание этой темы сразу видно. Типичный вопрос: «Как работает bind и singleton в контейнере?». Правильный ответ объясняет разницу: bind создаёт новый экземпляр при каждом разрешении зависимости, singleton — один раз и далее возвращает тот же объект. Сильный ответ добавляет: «Мы использовали singleton для сервисов, которые инициализируют соединение с внешним API — чтобы не создавать новое соединение на каждый запрос».
• Middleware. Вопрос «как работает middleware в Laravel?» проверяет понимание пайплайн-паттерна: запрос проходит через цепочку обработчиков, каждый из которых может либо передать запрос дальше, либо вернуть ответ. Важно упомянуть порядок регистрации и разницу между глобальными, роутовыми и группированными middleware.
• Очереди и Jobs. Middle+ вопрос: «Как вы обрабатываете долгие операции в Laravel?». Здесь ожидают не просто «через Queue», а понимание: драйверы (Redis, database, SQS), retry-логика, failed jobs, горизонтальное масштабирование воркеров. Хороший ответ включает конкретный кейс — например, вынос отправки email или генерации отчётов в фоновые задачи.
• События и листенеры. Проверяют понимание паттерна Observer в контексте фреймворка. Важный нюанс, который стоит упомянуть: события могут быть синхронными и асинхронными (через очередь) — и выбор между ними влияет на поведение системы под нагрузкой.
• Eloquent relationships и N+1. Классический вопрос на Middle: «Что такое проблема N+1 и как вы с ней боретесь в Eloquent?». Ответ должен включать eager loading через with(), понимание когда использовать load() vs with(), и — в идеале — упоминание Laravel Debugbar или Telescope как инструментов диагностики.
• Кеширование. Проверяют знание драйверов (Redis, Memcached, file), понимание инвалидации кеша и паттерна cache-aside. Сильный ответ: «Мы кешировали результаты тяжёлых агрегирующих запросов с TTL 5 минут и инвалидировали тег при изменении связанных данных — это позволило снизить нагрузку на БД на пиковые периоды».

Symfony: что проверяют и что показать ответом

• DI-контейнер и сервисы. В Symfony контейнер — это компилируемая система: сервисы описываются в конфигурации (YAML/PHP), контейнер собирается при деплое и кешируется. Вопрос «чем отличается public и private сервис?» встречается регулярно. Важно понимать autowiring: Symfony автоматически разрешает зависимости по типу аргумента — это удобно, но требует аккуратности при неоднозначных биндингах.
• Конфигурация и окружения. Symfony использует систему окружений (dev/prod/test) с отдельными конфигами и бандлами. Вопрос «как вы управляете конфигурацией между окружениями?» проверяет понимание .env, secrets и иерархии конфигов.
• EventDispatcher. Концептуально похож на Laravel Events, но с важным отличием: в Symfony события — это объекты, подписчики регистрируются через тег или реализацию интерфейса. Понимание разницы между EventSubscriber и EventListener — хороший сигнал на техинтервью.
• Doctrine ORM. Это отдельный мир по сравнению с Eloquent. Проверяют: понимание Unit of Work (изменения накапливаются и сбрасываются через flush()), разницу между EntityManager и репозиториями, DQL vs QueryBuilder, и — обязательно — как Doctrine решает проблему N+1 (через JOIN FETCH или addSelect).
• HTTP Kernel и обработка запроса. Senior-вопрос: «Как Symfony обрабатывает входящий HTTP-запрос?». Ответ: HttpKernel диспатчит события (kernel.request, kernel.controller, kernel.response), что позволяет встраиваться в цикл запроса через EventListener — это аналог middleware, но реализованный через систему событий.

Laravel vs Symfony: соответствие понятий

Стратегия для тех, у кого «в вакансии Symfony, а опыт Laravel»

Это распространённая ситуация — и она не приговор. Практика найма показывает, что опытный Laravel-разработчик осваивает Symfony за 4–8 недель продуктивной работы, потому что фундамент общий: HTTP-цикл, DI, события, ORM, тесты, очереди. Разница — в синтаксисе и философии.

Как говорить об этом на интервью? Честно и структурно. Примерная формулировка: «У меня три года на Laravel — я хорошо понимаю DI, очереди, события и тестирование. С Symfony работал меньше, но за последние две недели прошёл документацию по DI-контейнеру и Doctrine, сделал небольшой учебный проект. Вижу концептуальное сходство и готов закрыть разрыв в первые недели — вот конкретный план».

Три вещи, которые усиливают эту позицию: показать учебный проект на Symfony (даже небольшой), сформулировать конкретный план онбординга («за первый месяц — Doctrine и HTTP Kernel, за второй — специфика вашего стека»), и задать умные вопросы про технический долг и код-ревью — это сигнализирует об инженерной зрелости независимо от фреймворка.

Задачи и тестовые: как решать и сдавать так, чтобы взяли?

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

Типы задач: что встречается чаще всего

• Алгоритмические задачи. Не ждите LeetCode Hard на позицию PHP Middle — чаще всего это задачи на базовые структуры данных и логику. Типичные примеры: найти дубликаты в массиве за O(n), развернуть строку без встроенных функций, реализовать простой кеш с вытеснением по LRU. Цель — не проверить знание алгоритмов как таковых, а посмотреть, умеете ли вы думать об эффективности и объяснять свои решения.
• SQL-задачи. Встречаются почти везде, независимо от грейда. Junior попросят написать JOIN между двумя таблицами и посчитать агрегат. Middle — оптимизировать запрос с подзапросом или объяснить, почему он работает медленно. Senior — разобрать план выполнения и предложить индексную стратегию. Подробнее про SQL — в следующем разделе, здесь важно понять: SQL-задачи на интервью почти всегда проверяют не синтаксис, а понимание того, что происходит в базе.
• API-задачи. Обычно это «спроектируй REST API для такой-то сущности» или «что не так с этим эндпоинтом». Проверяют: правильные HTTP-статусы, структуру ответа, валидацию, версионирование, обработку ошибок. Частая ловушка — кандидат проектирует красивый API, но забывает про авторизацию и rate limiting.
• Рефакторинг. Дают кусок «живого» кода с очевидными проблемами: God Object, нарушение SRP, магические числа, отсутствие обработки ошибок. Задача — не переписать с нуля, а последовательно улучшить, объясняя каждый шаг. Хороший кандидат сначала называет проблемы, потом расставляет приоритеты, потом решает — и не пытается сделать всё идеальным за 20 минут.
• Багфикс. Дают код с неочевидной ошибкой — например, неправильная работа с состоянием, race condition в очереди или утечка памяти в цикле. Проверяют способность читать чужой код и системно искать причину, а не симптом.

Тактика лайвкодинга: шаг за шагом

Схема, которая работает независимо от типа задачи:

Уточнить требования → Зафиксировать план → Решение v1 (базовое) → Edge cases → Простые тесты → Улучшения → Итог

Разберём каждый шаг.

• Уточнить требования — это признак не слабости, а инженерной культуры. Спросите: какой формат входных данных? Могут ли они быть пустыми или некорректными? Есть ли ограничения по памяти или времени? Нужна ли обработка конкурентного доступа? Две минуты на уточнения экономят десять минут переделки.
• Зафиксировать план — проговорите вслух, как будете решать, до того как напишете первую строку. «Я планирую использовать хеш-таблицу для отслеживания уже встреченных элементов — это даст O(n) по времени и O(n) по памяти. Альтернатива — сортировка за O(n log n), но тогда теряем исходный порядок». Это показывает, что вы думаете о компромиссах, а не просто пишете первое, что пришло в голову.
• Решение v1 — пишите рабочий, читаемый код, а не оптимальный. Сначала — чтобы работало. Потом — чтобы работало хорошо. Интервьюер хочет видеть рабочее решение раньше, чем идеальное незавершённое.
• Edge cases — пройдитесь по граничным случаям: один элемент, пустой массив, отрицательные числа, все элементы одинаковые, null. Называйте их вслух: «проверю, что будет, если передать пустую строку».
• Простые тесты — напишите 2–3 assert или псевдотеста прямо в коде. Это сигнал зрелости, даже если тесты минимальны.
• Улучшения — после рабочего решения обсудите, что можно улучшить: производительность, читаемость, обработку ошибок. Не обязательно реализовывать — достаточно назвать и объяснить, почему вы оставили это «на потом».

Григорий Петров, DevRel Evrone, эксперт по нейрофизиологии обучения: «Лайвкодинг — это не проверка знаний, а проверка стрессоустойчивости. Мы часто отсеиваем гениальных инженеров, которые просто не могут писать код под присмотром. Компании, которые делают упор только на этот этап, рискуют нанять ‘шоуменов’, а не глубоких разработчиков.»

Чек-лист перед лайвкодингом

• Уточнить формат входных и выходных данных.
• Спросить об ограничениях (память, время, размер входа).
• Попросить пример входа и ожидаемого выхода.
• Назвать граничные случаи до начала решения.
• Оценить сложность выбранного подхода (O-нотация).
• Написать хотя бы один тест-кейс.
• Проговорить допущения явно.

Оформление тестового: как сдать «как взрослый»

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

Вот минимальный стандарт, ниже которого лучше не сдавать:

• README — обязателен. Должен содержать: краткое описание задачи, инструкции по запуску, описание структуры проекта, известные ограничения и что вы бы улучшили при большем времени. Последний пункт особенно важен — он показывает, что вы видите картину шире, чем текущее решение.
• Docker — если задание предполагает запуск приложения, docker-compose up должен поднять всё с нуля без дополнительных инструкций. Интервьюер не обязан настраивать ваше окружение.
• Миграции и .env.example — база должна разворачиваться автоматически. .env.example с заполненными дефолтными значениями — стандарт, который сигнализирует об опыте работы в команде.
• Линтер и статический анализ — подключённый PHP CS Fixer или PHPStan (хотя бы на базовом уровне) говорит о культуре кода. Это занимает 15 минут, но сильно влияет на впечатление.
• Базовые тесты — не нужно 100% покрытие. Нужны на основные сценарии и хотя бы один на граничный случай. Отсутствие тестов  — один из самых частых поводов для отказа на Middle+ позициях.

Чек-лист «сдать тестовое как взрослый»

• README с описанием, запуском и известными ограничениями.
• docker-compose или чёткие инструкции по запуску.
• Миграции, запускающиеся автоматически.
• .env.example с рабочими дефолтами.
• Линтер или статический анализ (PHP CS Fixer / PHPStan).
• Базовые тесты на ключевые сценарии.
• Чистая структура директорий без мусорных файлов.
• Раздел «что улучшил бы дальше» в README.

Про таймбокс: как не утонуть в перфекционизме

Практика показывает, что кандидаты, которые тратят на тестовое 15–20 часов, не получают офер чаще, чем те, кто потратил 5–6. Причина: за 20 часов человек успевает переусложнить решение, добавить абстракции ради абстракций и потерять читаемость. Работает правило таймбокса: выделите фиксированное время (обычно 4–6 часов для Middle), сделайте рабочее и аккуратное решение, зафиксируйте в README что бы улучшили — и сдайте. Незавершённое, но честно описанное решение лучше, чем перегруженное «идеальное».

Критерии, по которым реально оценивают тестовое

SQL + API + безопасность + производительность: блок «must-know»

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

SQL: индексы, транзакции и всё, что между ними

JOIN и агрегация. Базовый уровень — уметь написать INNER, LEFT и RIGHT JOIN и объяснить разницу. Средний уровень — понимать, как JOIN влияет на производительность: декартово произведение до фильтрации, важность порядка таблиц, когда JOIN медленнее подзапроса (и наоборот). Сильный ответ на вопрос «объясните разницу между LEFT JOIN и INNER JOIN» включает не только определение, но и пример из практики: «Мы использовали LEFT JOIN для построения отчёта, где нужно было показать все заказы, включая те, у которых нет связанных платежей — INNER JOIN их бы отфильтровал».

Диаграммы Венна для различных типов JOIN визуализируют, как база данных объединяет таблицы и какие данные в итоге попадают в выборку. Каждая схема четко демонстрирует разницу между INNER, LEFT и RIGHT JOIN с русскими подписями.

Индексы. Самая частая тема на Middle+. Проверяют: понимание B-tree индексов, составных (порядок колонок имеет значение), покрывающих, и — обязательно — когда индекс не помогает (функция над колонкой в WHERE, LIKE с ведущим символом %, низкая селективность). Типичный вопрос: «Почему запрос работает медленно, даже если индекс есть?». Правильный ответ начинается с: «Смотрю EXPLAIN и проверяю, используется ли индекс на самом деле».

Скриншот плана выполнения SQL-запроса. Показывает реальный вид execution plan. Это помогает визуально понять, как база данных анализирует запрос и почему важно использовать EXPLAIN.

Транзакции и уровни изоляции. Это зона, где уверенные, но неправильные ответы ломают оффер чаще всего. Четыре уровня изоляции (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) — не просто список для зазубривания. Важно понимать, какие аномалии каждый уровень допускает: грязное чтение, неповторяемое, фантомное . Практический вопрос: «Какой уровень изоляции используется в MySQL по умолчанию и почему это важно?». Ответ: REPEATABLE READ — и это означает, что при работе с длинными транзакциями нужно учитывать риск устаревших данных.

N+1 и планы запросов. N+1 — классическая проблема ORM: вместо одного запроса с JOIN выполняется один запрос на список и по одному на каждый элемент. В контексте PHP-интервью проверяют: умеете ли вы диагностировать (через логи запросов, Debugbar, Telescope) и решать (eager loading, denormalization, кеширование). EXPLAIN / EXPLAIN ANALYZE — минимальный инструментарий для работы с медленными запросами: смотрят на тип сканирования (seq scan vs index scan), количество обрабатываемых строк, использование временных таблиц.

Панель запросов Laravel Debugbar.
Показывает, как выглядит список SQL-запросов во время выполнения запроса. Это помогает визуально объяснить проблему N+1.

API: контракты, ошибки и версионирование

• REST-контракты. Проверяют понимание идемпотентности (GET, PUT, DELETE — идемпотентны; POST — нет), правильного использования HTTP-методов и структуры URL. Типичная ловушка: кандидат проектирует POST /getUsers вместо GET /users — это сигнал о поверхностном понимании REST.
• HTTP-статусы. Знать наизусть все коды не нужно, но базовые группы — обязательно: 2xx (успех), 3xx (редиректы), 4xx (ошибка клиента), 5xx (проблема сервера). Частые ошибки на интервью: возвращать 200 с {«error»: «not found»} в теле, использовать 403 вместо 401 (или наоборот), возвращать 500 на валидационную ошибку. Правило простое: статус должен описывать результат HTTP-взаимодействия, а не бизнес-логику.
• Валидация и обработка ошибок. Проверяют, понимаете ли вы разницу между валидацией на уровне HTTP (типы, форматы, обязательность полей) и бизнес-валидацией (например, уникальность email в базе). Структура ответа об ошибке должна быть консистентной: поле errors с деталями, понятные сообщения, без внутренних стектрейсов в продакшене.
• Версионирование и пагинация. Версионирование API — через URL (/v1/users) или заголовки (Accept: application/vnd.api+json; version=1) — обе стратегии валидны, важно объяснить компромиссы. Пагинация: offset-based (простая, но деградирует на больших объёмах) vs cursor-based (сложнее, но стабильна при вставках/удалениях).

Безопасность: минимальный обязательный набор

• SQL-инъекции. Вопрос «как защититься от SQL-инъекции?» на Junior звучит как «используйте prepared statements». На Middle ожидают понимание: почему prepared statements работают (параметр и запрос передаются раздельно, БД не интерпретирует параметр как SQL), и что ORM не даёт автоматической защиты, если вы вставляете сырые данные через whereRaw или аналоги.
• XSS и CSRF. XSS — инъекция скрипта через пользовательский ввод, защита — экранирование при выводе (не при вводе). CSRF — подделка запроса от имени авторизованного пользователя, защита — CSRF-токен или проверка заголовка Origin. Типичная ошибка: путать XSS и CSRF, или считать, что «фреймворк всё делает сам» без понимания механизма.
• Хранение паролей и секретов. Пароли хранятся только в виде хеша через password_hash() с алгоритмом PASSWORD_BCRYPT или PASSWORD_ARGON2ID — не MD5, не SHA1, не самописный хеш. Секреты (ключи API, credentials) — только через переменные окружения, никогда в коде или в репозитории. .env файл не коммитится, .env.example — да.
• Rate limiting. Проверяют понимание зачем (защита от брутфорса, DDoS, злоупотребления API) и как (через middleware, Redis-счётчики, токен-бакет алгоритм). В Laravel это ThrottleRequests middleware, в Symfony — RateLimiter компонент.

Производительность: быстрые победы и системный подход

• Кеширование. Redis — стандарт для кеширования в PHP-экосистеме. Проверяют: понимание паттерна cache-aside (читаем из кеша, если нет — из БД, кладём в кеш), стратегий инвалидации (TTL, тегированный кеш, явная инвалидация при обновлении), и — важно — понимание того, что «кешируем всё» — это не стратегия, а путь к stale data и трудноуловимым багам.
• Очереди. Тяжёлые операции (отправка email, генерация PDF, вызов внешних API) не должны блокировать HTTP-ответ. Проверяют понимание: как работает воркер, что такое failed jobs и как с ними работать, как масштабировать обработку очереди горизонтально.
• Профилирование. Вопрос «как вы ищете узкие места в производительности?» проверяет наличие системного подхода. Минимальный инструментарий: EXPLAIN для SQL, Xdebug или Blackfire для профилирования PHP, логи медленных запросов в MySQL/PostgreSQL. Сильный ответ описывает последовательность: сначала измеряем, потом оптимизируем — а не наоборот.
• «Быстрые победы» в типичном PHP-приложении. Практика показывает, что большинство проблем с производительностью решается в четырёх местах: N+1 запросы (eager loading или денормализация), отсутствующие индексы на frequently queried колонках, синхронные операции, которые можно вынести в очередь, и избыточные данные в ответе API (выбирайте только то что вам нужно).

Таблица-шпаргалка: must-know по областям

Что реально ломает оффер в этом блоке — не незнание деталей, а уверенные неправильные ответы. Сказать «я не работал с Serializable изоляцией на практике, но понимаю теоретически» — это нормально. Уверенно перепутать REPEATABLE READ и READ COMMITTED и не заметить подвоха — это сигнал об опасном пробеле.

Подготовка, самопрезентация и переговоры: план + чек-листы

Технические знания — необходимое, но не достаточное условие оффера. Практика найма показывает, что кандидаты с сопоставимым уровнем знаний получают разные результаты — и разница почти всегда в том, как они себя преподносят, какие вопросы задают и как ведут себя в финальной части процесса. Разберём всё по порядку.

План подготовки на 7–14 дней

Главная ошибка при подготовке — попытка «повторить всё». Это путь к тревоге и поверхностному охвату. Работает другой подход: фиксированный таймбокс на каждую тему, конкретный критерий готовности («могу объяснить это вслух без подсказок»), и обязательная практика — не чтение, а решение задач.

Чек-лист подготовки

• PHP Core: типизация, ООП, SOLID, генераторы, исключения, Composer/PSR.
• Фреймворк: DI-контейнер, middleware/события, ORM, очереди, кеширование.
• SQL: JOIN, индексы, транзакции/изоляция, N+1, EXPLAIN.
• API: REST-контракты, статусы, валидация, версионирование, пагинация.
• Безопасность: SQLi, XSS, CSRF, хранение паролей, rate limiting.
• Тесты: PHPUnit, базовые паттерны (arrange-act-assert), моки.
• Лайвкодинг: 3 решённые задачи вслух по схеме.
• Тестовое: 1 мини-проект с полным оформлением.
• История проектов: 3 кейса по структуре.
• Вопросы работодателю: минимум 7–10 конкретных вопросов.

Самопрезентация: структура рассказа о проекте

Вопрос «расскажите о самом сложном проекте» — один из самых частых и плохо отрабатываемых. Большинство кандидатов либо уходят в технические детали без контекста («мы использовали Redis и Kafka»), либо дают настолько общий ответ, что он ничего не говорит о реальном вкладе. Работает следующая схема:

Контекст → Роль → Решение → Результат (цифры) → Выводы

• Контекст — что за продукт, какая была проблема или задача, почему она была нетривиальной. Одно-два предложения.
• Роль — что конкретно делали вы, а не команда. «Мы сделали» — слабый ответ. «Я отвечал за проектирование схемы данных и интеграцию с внешним API, команда параллельно делала фронт» — сильный.
• Решение — какие технические действия приняли, почему именно такие, какие альтернативы рассматривали и почему отказались. Компромиссы здесь — это ваш главный актив.
• Результат — в идеале цифры: «снизили время ответа API с 800мс до 120мс», «сократили количество ошибок в продакшене на 60% за квартал», «система выдержала нагрузку в 10 000 одновременных пользователей». Если цифр нет — качественный результат: «позволило команде деплоить без страха регрессий».
• Выводы — что узнали, что бы сделали иначе. Этот пункт показывает зрелость: человек, который ничего бы не изменил в прошлом проекте, либо не рефлексирует, либо не развивается.

Сложные вопросы: шаблоны ответов

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

• «Расскажите о своём провале или ошибке». Слабый ответ: «Однажды я немного задержал задачу, но потом всё сделал». Это не провал, это рабочая ситуация. Сильный ответ: «Я недооценил сложность миграции данных и не заложил rollback-план. В итоге деплой занял вдвое дольше запланированного и затронул пользователей. После этого мы ввели обязательный rollback-скрипт для любой миграции и добавили этап ревью деплой-плана. С тех пор подобных ситуаций не было».
• «Почему вы уходите с текущего места?» Правило: говорите про движение к чему-то, а не бегство от чего-то. «Хочу работать с более сложными задачами и расти в архитектурном направлении» — нормально. «Там всё плохо и менеджер некомпетентный» — токсично, даже если правда.
• «Был ли конфликт с коллегой или менеджером?» Здесь проверяют эмоциональный интеллект. Формула: опишите ситуацию нейтрально, объясните свою позицию, расскажите как разрешили, сделайте вывод. Без осуждения другой стороны.

Вопросы работодателю: что спрашивать и зачем

Отсутствие вопросов в конце интервью — один из самых недооценённых сигналов незаинтересованности. Хорошие вопросы делают две вещи одновременно: показывают вашу инженерную культуру и дают реальную информацию о том, куда вы идёте работать.

Технические вопросы:

— Как устроен процесс код-ревью? Кто ревьюит, каковы критерии?

— Есть ли CI/CD? Как часто деплоите?

— Какое покрытие тестами считается нормой в команде?

— Как принимаются архитектурные решения — есть ли RFC-процесс или всё решает тимлид?

— Какой технический долг есть сейчас и как команда с ним работает?

Вопросы про продукт и процессы:

— Что измеряете как успех продукта? Какие метрики важны команде?

— Как выглядит типичный спринт/цикл разработки?

— Как часто меняются приоритеты и как это влияет на работу разработчиков?

Вопросы про команду и онбординг:

— Из кого состоит команда, каков баланс Junior/Middle/Senior?

— Как выглядит испытательный срок? Какие ожидания на первые 30/60/90 дней?

— Есть ли культура внутренних докладов, обмена знаниями, конференций?

Переговоры об оффере: как не оставить деньги на столе

Переговоры — это не конфликт, это часть профессионального процесса. Компании закладывают вилку именно потому, что ожидают переговоров. Молчаливое согласие с первой цифрой — это, как правило, потеря.

Как говорить про вилку. Если спрашивают ожидания — называйте верхнюю границу своей реальной вилки, а не среднюю. Аргументируйте: опыт, конкретные компетенции, рыночный уровень. «По рынку Middle PHP с опытом в высоконагруженных системах находится в диапазоне X–Y, я ориентируюсь на Y с учётом моего опыта в…» — это нормальная профессиональная позиция.

Что уточнить в оффере до подписания: испытательный срок и условия его прохождения, пересмотр зарплаты (когда и по каким критериям), удалёнка/гибрид (зафиксировано ли это официально), оборудование, компенсация обучения, NDA и условия конкурентной оговорки.

Как фиксировать договорённости. Устные на финальном интервью — не договорённости. Просите фиксировать ключевые условия письменно: в оффере, в переписке, в трудовом договоре. Это не недоверие — это профессиональная гигиена.

Чек-лист red flags работодателя

Иногда важнее не получить оффер, а вовремя понять, что он не нужен. Вот сигналы, которые стоит воспринимать серьёзно:

• «Нам нужно срочно, буквально вчера» — хронический пожар как норма работы.
• Нет внятных критериев успеха на испытательном сроке.
• «Процессов особо нет, у нас стартап-культура» при штате 100+ человек.
• На вопрос про тесты: «Тесты пишем, когда время есть» (спойлер: времени нет никогда).
• «Код-ревью? Ну, иногда смотрим друг на друга» — отсутствие культуры качества.
• Агрессивная или пренебрежительная коммуникация на интервью — это не стресс-тест, это норма поведения.
• Неопределённая роль: «Ну, будешь делать всё, что нужно» без конкретики.
• Засекреченная вилка до последнего — часто означает, что она ниже рынка.

Заключение: как закрепить результат и ускорить оффер

Собеседование заканчивается не в момент, когда вы закрыли вкладку с Zoom. То, что вы делаете в течение 24–48 часов после финального этапа, нередко влияет на итоговое решение — особенно в ситуации, когда компания выбирает между двумя сопоставимыми кандидатами.

Напишите короткий follow-up: поблагодарите за уделённое время, кратко обозначьте, что вас зацепило в разговоре, и подтвердите интерес. Это не подхалимаж — это сигнал о том, что вы умеете закрывать коммуникацию профессионально. Если на каком-то вопросе вы споткнулись и потом вспомнили правильный ответ — можно добавить это в follow-up: «После нашего разговора я ещё раз обдумал вопрос про изоляцию транзакций — вот как бы я ответил точнее». Это показывает рефлексию, а не слабость.

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

И последнее: подготовка к собеседованию — это не спринт за неделю до интервью, а фоновый процесс. Решайте задачи на лайвкодинг раз в неделю, пишите код вне работы, участвуйте в код-ревью, читайте чужие RFC и постмортемы. Когда следующее интервью появится на горизонте, вам останется только освежить детали — а не начинать с нуля.

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