Каким-то непонятным образом я стал участником дуэта, проводящего технические собеседования на должность PHP-программиста в нашей компании. После этого положение со специалистами в нашей сфере стало мне понятно более отчётливо.
В основном все кандидаты делятся на две большие группы.
Первая группа. Кандидаты, в резюме которых содержится опыт работы, интересы, сильные стороны, но не заявлен какой-либо статус или оценка своих знаний. На просьбу оценить свои знания обычно просят задавать конкретные вопросы, т.к. не во всех областях считают себя знатоками. Ответы обычно по существу, иногда в стиле "здесь можно поспорить о терминологии" или "я могу минуту подумать?" К сожалению, таких кандидатов не так много. Говорить с ними интересно, собеседование проходит в форме диалога, а не экзамена. В итоге такое собеседование приносит пользу и новые знания всем участникам.
Вторая группа. Кандидаты с заявленными 5/5 или 8+/10 знаниями PHP. Я считаю, что этот уровень знаний соответствует статусу "PHP-эксперт". Ответы кандидатов чаще всего в стиле "что-то слышал", "никогда не использовал, но могу быстро научиться", "ой, я так волнуюсь, что голова не работает", "знаю, но не уверен, что смогу объяснить".
О чём тут?
В теме поста первая группа кандидатов нам неинтересна. Мы обсудим вторую группу. Пост может помочь программистам не очень высокого уровня определить своё положение в профессии и пути дальнейшего развития, а также сделать ещё много интересных вещей, для которых есть не менее банальные штампы.
Как известно, большинство тонкостей логически выводятся из понимания более общих вещей. Я считаю, что хорошего программиста от плохенького кодера отличает желание и умение применять логику. Именно поэтому меня не так сильно интересует, знает ли кандидат ответ на мой вопрос. Меня больше впечатляет его умение вывести правильный ответ логически или логически объяснить то, что он знает.
Для этого у нас существуют три несложных вопроса.
Первый вопрос
- Можем ли мы отнаследоваться от абстрактного класса и не реализовать некоторые из его абстрактных методов?
Кажется, ответ лежит на поверхности. Но тем не менее, правильный ответ мы получаем очень редко, поэтому за вопросом обычно следуют наводящие вопросы:
- Давайте рассмотрим родительский класс, из чего он состоит?
- Свойства, реализация методов, абстрактные методы.
- Правильно, теперь представим, что в дочернем классе мы не реализовали какие-то из абстрактных методов. Из чего он состоит?
- Мы не можем этого сделать.
- Давайте представим, что можем. Тем более, я уверяю Вас, что мы можем.
- Из свойств, реализации методов и… Нет, здесь будет ошибка.
- Дочерний класс отнаследует абстрактные методы родительского, но не реализует их. Значит, какие это будут методы?
- Абстрактные.
- Правильно. Значит, дочерний класс у нас какой?
- Будет ошибка.
Максимум на этом месте (зависит от нашего настроения и наличия свободного времени) кандидат получает от нас правильный ответ, а первая проверка работы логики заканчивается провалом.
Второй вопрос
- Можем ли мы в классе реализовать интерфейс и не реализовать какие-то из описанных в нём методов?
Как ни странно, чаще всего ситуация повторяется. И снова следуют наводящие вопросы:
- Давайте вспомним прошлый вопрос.
- Так с интерфейсами всё по-другому.
- Почему?
- Мы не можем это сделать, потому что они не классы и мы изначально говорим, что мы их реализуем. Будет ошибка.
- Давайте представим, что можем. Тем более, я уверяю Вас, что мы можем.
- Я Вас не понимаю.
Вторая проверка работы логики заканчивается провалом.
Третий вопрос
- Класс синглтон. Сможете сходу сказать, какие элементы должен содержать класс, чтобы мы могли его считать синглтоном?
Тут часто отвечают правильно про то, что нужен метод получения экземпляра класса, переменная, в которую мы будем сохранять этот экземпляр и содержимое которой мы будем проверять при попытке получить экземпляр класса. При этом безбожно путают статические методы и свойства и методы и свойства объекта. Но сейчас не об этом.
- Хорошо, таким образом мы предоставляем возможность получать один и тот же экземпляр класса из любого места в приложении. Теперь нам нужно убедиться, что экземпляр класса будет только один.
- Ммм.
- Проще говоря, нам нужно убедиться, что экземпляр класса будут получать только через этот метод. Что нам нужно для этого сделать?
- В смысле?
- Какие у нас есть способы создания объекта?
- New.
- Правильно, а ещё?
- Не знаю.
- Ну ладно, не суть важно, ещё существует клонирование объектов.
- Что-то слышал, но не использовал.
- Так что нам нужно сделать, чтобы мы не могли создавать объект в обход статического метода получения экземпляра?
- Это Вы сейчас new имеете ввиду?
- Да, именно его.
- Нужно в конструкторе вызывать статический метод получения класса.
Дальше идёт такая каша, что до модификаторов доступа на конструктор и магический метод клонирования добраться удаётся не всегда. И эта проверка работы логики также не увенчалась успехом.
Вывод
Во-первых, не стоит переоценивать свои знания. Не стоит забывать затёртую до дыр фразу Сократа. Перед тем, как собираетесь поставить гордое "эксперт" в своей анкете откройте какой-либо глоссарий по PHP и ООП и оцените, какой процент терминов Вы знаете, какой процент Вам знаком и о каком проценте Вы никогда не слышали.
Во-вторых, включайте логику. Умение человека найти правильный ответ, основываясь на имеющихся знаниях, намного ценнее, чем наличие сертификатов и большой опыт работы, измеряемый в годах. Слушайте тех, кто Вам задаёт вопросы. Если слышите наводящий вопрос, прерывайте ход своих мыслей, вслушивайтесь в слова, которые Вам говорят.
В-третьих, слегка заниженная оценка своих знаний позволяет произвести более хорошее впечатление из-за умеренных ожиданий интервьюера. Здесь даже можно немножко слукавить. Но идеально, если Вы имеете чёткое представление о том, насколько Вы хороши.
В-четвёртых, запоминайте те вопросы, на которые Вы не смогли ответить. В тот же вечер берите книгу и изучайте эти вопросы, старайтесь найти логику в той или иной реализации, идее или принципе. Собственно, то же самое я делаю, когда не могу ответить на какие-то встречные вопросы кандидата или оценить альтернативную версию, предложенную им (а такое тоже бывает, и именно оно примиряет меня с тем временем, которое я трачу на проведение собеседований).
Вот такая вот первая статья на Хабре.
Update:
Ответы на вопросы (как я понял, не у всех получилось логически вывести):
1. Отнаследоваться от абстрактного класса и не реализовать некоторые из его абстрактных методов можно. Но только в том случае, когда дочерний класс также объявлен асбтрактным.
2. Реализовать интерфейс и не реализовать некоторые из его методов можно. Но только в том случае, когда класс объявлен абстрактным.
3. Тут помогут мануалы.
Update 2:
Привожу план собеседования.
PHP experiencePHP functions
- list of some (array, or string, or date) functions namesOOP
- 4 main techniques
- interface
- abstract class
- difference from interface
- extending without implementing every abstract method
- static methods, static variables
- patterns
- singleton
- fluent interface (methods chaining)
- list of some other patterns namesFrameworks
- list of frameworks you have experience with
- MVC
- ORM
- difference between DataMapper and ActiveRecord
- template engines, routing, acl, etc.Databases
- MyISAM
- InnoDB
- transactions
- foreign keys
- triggers
- INNER JOIN and LEFT JOINXML (just for fun)
- DOM
- SAXJavaScript
- frameworks
- MVC
- jQuery plugins
- closures
- what is the result of code execution? how to preserve "a" value?var a = 1;
setTimeout(function() {
alert(a);
}, 10);
a = 2;