Раз уж блог продолжает жить, напишу о наболевшем. Наверное каждый человек, который готовится к техническому интервью хотел бы заранее знать о чем его будут спрашивать. Недавно я проходила с десяток интервью как PHP разработчик, т.к моя семья переехала в Берлин и мне нужна была местная работа. И все они были в чем-то похожи.
Кстати, т.к теперь я живу не в Узбекистане, готова передать этот сайт/блог в заботливые руки. Если у вас есть идея, что можно сделать на таком звучном домене — напишите мне (оставьте контакты в комментах).
Важно понимать, что интервью это не только вопросы к вам, но и возможность для вас узнать с чем придется иметь дело, согласись вы работать в этой компании. И вопросы которые задают вам — это отличный сигнал о качестве кода и команды. Уровень вопросов в том числе показывает и уровень знаний человека, проводящего интервью с вами, а так же косвенно указывает на средний уровень команды. Чем интереснее вопросы и обсуждение, тем интереснее в дальнейшем будет работа в такой команде.
Например, базовые вопросы про ООП, типа чем класс отличается от объекта, вопросы про наследование, инкапсуляцию и полиморфизм, которые имели смысл лет 15 назад, когда большая часть PHP все еще была функционально-ориентированной, сейчас актуальны разве что для джуниоров. Туда же отправляем вопросы про private, protected и public методы и свойства.
Чуть более интереснее звучит вопрос про разницу абстрактных классов и интерфейсов. Самое время пофилософствовать про сomposition over inheritance и посмотреть на реакцию интервьюера. Можно поговорить о других способах переиспользования кода, таких как threads и их недостатках, спросить о множественном наследовании, множественных интерфейсах и имплементации множества абстрактных классов (что из этого возможно в мире PHP). Еще можно поговорить о плюсах и минусах final классов и методов.
Однажды на тех. интервью, тех лид одной компании сказал, что его волевым решением, все классы в их системе final! 🤦 На мой вопрос как же они их тогда тестируют, тех лид ответил что они делают копии всех классов и покрывают тестами эти копии. 🤦 После интервью, я написала рекрутеру что не хочу продолжать процесс, т.к уже приняла другое предложение. По сути, если такие «гениальные» идеи тех лида всплыли на интервью, то что будет дальше?!
Про ООП мне больше всего нравится вопрос про разницу между new static() и new self(). А вы знаете ответ?
Редкое интервью проходит без обсуждения паттернов. И тут важно просят вас их просто назвать или написать их быструю имплементацию. Чаще всего это зависит от того, насколько хорошо их знает сам интервьювер. Так же важно какой именно патерн с вас спросили. Более интересны вопросы про сравнения паттернов. Ведь для того, чтобы их не только на интервью «знать», но и в работе использовать, важно понимать разницу в их назначении и применении. Например в чем разница между декоратором и адаптером, стратегией и цепочкой обязанностей.
Другой вопрос без которого не обходится ни одно интервью: принципы SOLID. Можно поговорить про DI (Dependency Injection) и DIP (Dependency Inversion), про Liskov substitution с привязкой к Open-closed принципу.
Мне нравятся вопросы про чистый код. Чем их больше, тем выше вероятность работать в хорошей команде с хорошим кодом. Вы не поверите, но мне доводилось работать с тех лидом, который был ярым противником DRY (don’t repeat yourself), считая, что это самый переоцененный принцип программирования. Логика было в том, что пытаясь следовать DRY, в итоге программисты наращивают количество передаваемых параметров и методы разрастаются. Вот только если программисты помимо DRY соблюдают Single Responsibility, этого не случается! А общий функционал все равно лучше вынесли в приватный метод и не жить сегодня будущим (YAGNI — You Aren’t Gonna Need It). Чем меньше кода, тем легче его поддерживать, тем проще его масштабировать. Вот после работы с таким тех лидом, я теперь внимательнее отношусь к «звоночкам» на интервью 🙂
Поговорили про код, поговорим про тесты. К сожалению в мире PHP до сих пор для многих проектов unit тесты это больше утопия и вопрос для интервью, чем жесткое требование к каждому pull request. Я бы просила написать тесты для заранее подготовленного класса, чтобы посмотреть что и как человек покрывает тестами. Но на всех интервью, на которых мне доводилось быть, вопросы ограничивались умением писать тесты и знанием о существовании mock и stub.
Мне нравятся вопросы про оптимизацию кода. Это куда интереснее чем писать SQL join, который впрочем с современными фреимворками с ORM, возможно для кого-то и представляет проблему. Оптимизация это не только про SQL и индексы (особенно интересны задания где для разгона запроса индекс нужно удалить, а не добавить), это еще и про умение видеть картину шире. Иногда менять нужно не запрос, а логику, для которой такой монстреозный запрос написали. Но это тема для отдельной статьи.
Кажется все обсудили? Напишите в комментариях какой самый интересный вопрос вам задавали на техническом интервью. Так же смело пишите в комментарии про какие темы вам было бы интересно почитать.
PS: я НЕ ищу работу. Я успешно ее нашла.