Comments 107
Вопросы и ответы на них очень хорошие, вот только применять их к собеседованиям я бы не стал, слишком большой акцент на различия в версиях и фичи появившиеся в последних версиях. Опытный разработчик, у которого многие наработки уже сушествуют десяток лет может быть достаточно консервативен и сторонится использования недавно введенных функций, учитывая задержку обновления версий на популярных хостингах и т.п., при этом несмотря на игнорирование этих новшеств он может быть на порядок эффективнее в решении задач с точки зрения бизнеса.
Само-собой, можно не применять на практике многие возможности из последних версий, но знать о том, что происходит с языком, как он развивается, я думаю, полезно.
Я отношусь к этим вопросам как к списку хороших тем для обсуждения.
Я отношусь к этим вопросам как к списку хороших тем для обсуждения.
Опытный разработчик, у которого многие наработки уже сушествуют десяток лет
Мне кажется, эта фраза потеряла актуальность лет 5 назад. Сейчас во-первых, опытный разработчик скорее всего не будет работать с шаредами в принципе (коробочные продукты да — ориентированы как раз на шареды, но их относительно мало, и по большей части там сейчас не ведется активная разработка, да и не интересны они опытным). Во-вторых, если человек перестал развиваться, не изучает и не пользуется новыми фичами PHP (здесь особенно важно понимать, что после 5.2 каждая версия приносит пачку важных и нужных фич, которые обязательно надо использовать вместо тех костылей, что были до них), не интересен.
Да, сейчас есть движение в направлении всяких digitalocean, где проблемы типичных шаредов не столь актуальны, но по мне оно только начинается и уж точно говорить нельзя что оно успешно закончилось 5 лет назад.
Что изучение новых фич должно интересовать тут вопросов нет, я абсолютно согласен с позицией автора, которую он обозначил в комменте выше — в качестве тем для обсуждения между разработчиками это отличные вопросы. Вот только «Руководство по собеседованию» это несколько другое, если дать такое руководство человеку слабо знаюшему PHP и послать его нанимать програмистов ничего хорошего не выйдет… или вы правда считаете, что человек услышав вопрос «Объясните назначение ключевого слова static» должен начать свой ответ с того, что «В PHP, начиная с версии 5.3, реализовано позднее статическое связывание. »?
Что изучение новых фич должно интересовать тут вопросов нет, я абсолютно согласен с позицией автора, которую он обозначил в комменте выше — в качестве тем для обсуждения между разработчиками это отличные вопросы. Вот только «Руководство по собеседованию» это несколько другое, если дать такое руководство человеку слабо знаюшему PHP и послать его нанимать програмистов ничего хорошего не выйдет… или вы правда считаете, что человек услышав вопрос «Объясните назначение ключевого слова static» должен начать свой ответ с того, что «В PHP, начиная с версии 5.3, реализовано позднее статическое связывание. »?
Да по мойму как раз таки последние лет 5 все перебираются на VDS. Последние года 3-4 так точно. Я лично не знаю никого кто бы все еще сидел на шаредах.
Что до static, в ответе определенно должно фигурировать «позднее статическое связывание». Ну и да, судя по характеру статьи, ориентирована она все же больше на тех кто хочет пройти собеседование, а не вести его.
Что до static, в ответе определенно должно фигурировать «позднее статическое связывание». Ну и да, судя по характеру статьи, ориентирована она все же больше на тех кто хочет пройти собеседование, а не вести его.
Тема поиска PHP-программиста раскрыта. Тема поиска хорошего программиста — нет.
Не умаляя ценности статьи, хочу заметить, что бОльшая часть людей, называющих себя разработчиками на PHP, отсеивается на гораздо более простых вопросах, не доходя до трейтов, SPL и LSB.
Вот мой топ вопросов-детекторов понимания духа и буквы PHP:
1. Что такое «передача по ссылке» и «передача по значению», как эти термины связаны с понятием «область видимости», как в PHP передаются разные типы аргументов?
2. Что такое «ссылка» в контексте «переменная-ссылка» в отличие от вопроса №1? Как вообще в PHP работают ссылки?
3. Зачем в PHP отдельный оператор конкатенации строк, если JS прекрасно обходится оператором "+" и почему для разделения пространств имен был выбран "\", а не уже имевшийся символ "::"?
4. Продемонстрируйте несколько (как можно больше) способов умножить все значения в массиве на 2, с рассказом об обоснованности применения каждого способа
5. Зачем в PHP нужны интерфейсы, если есть абстрактные классы?
Но за статью все равно спасибо, забрал в избранное.
Вот мой топ вопросов-детекторов понимания духа и буквы PHP:
1. Что такое «передача по ссылке» и «передача по значению», как эти термины связаны с понятием «область видимости», как в PHP передаются разные типы аргументов?
2. Что такое «ссылка» в контексте «переменная-ссылка» в отличие от вопроса №1? Как вообще в PHP работают ссылки?
3. Зачем в PHP отдельный оператор конкатенации строк, если JS прекрасно обходится оператором "+" и почему для разделения пространств имен был выбран "\", а не уже имевшийся символ "::"?
4. Продемонстрируйте несколько (как можно больше) способов умножить все значения в массиве на 2, с рассказом об обоснованности применения каждого способа
5. Зачем в PHP нужны интерфейсы, если есть абстрактные классы?
Но за статью все равно спасибо, забрал в избранное.
А можно увидеть ответ на пятый вопрос именно в контексте php? Когда интерфейсы и уж тем более абстрактные классы реально необходимы (учитывая динамическую типизацию)?
Интерфейсы необходимы в нескольких случаях.
1. Интерфейс — это контракт, который заключается с разработчиком класса. И этот контракт гарантирует, что разные классы из разных библиотек будут выполнять этот контракт и иметь одинаковый интерфейс (вот такая тавтология). Самый хороший для этого пример — github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md
2. Для обхода отсутствия множественного наследования. Нельзя отнаследоваться от двух классов, но можно реализовать два интерфейса. Собственно в этом и есть принципиальная разница.
Если на собеседовании будет отвечено примерно так, пусть даже своими словами — это зачёт.
1. Интерфейс — это контракт, который заключается с разработчиком класса. И этот контракт гарантирует, что разные классы из разных библиотек будут выполнять этот контракт и иметь одинаковый интерфейс (вот такая тавтология). Самый хороший для этого пример — github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md
2. Для обхода отсутствия множественного наследования. Нельзя отнаследоваться от двух классов, но можно реализовать два интерфейса. Собственно в этом и есть принципиальная разница.
Если на собеседовании будет отвечено примерно так, пусть даже своими словами — это зачёт.
Это понятно для статических языков, но вроде бы в PHP можно просто добавить классу нужные методы и все и так взлетит. Тот же JavaScript вроде бы с интерфейсами не заморачивается вообще.
JS порой с банальной логикой не заморачивается, а Вы про интерфейсы…
На самом деле настоящее понимание того, зачем нужны интерфейсы, приходит при проектировании системы, чуть более сложной, чем личный бложег. И я допускаю, что программист, не занимающийся проектированием, вполне может до конца и не понимать. Но вот знать — обязан. Хотя бы потому, что ему придется часто разбираться с чужим кодом.
На самом деле настоящее понимание того, зачем нужны интерфейсы, приходит при проектировании системы, чуть более сложной, чем личный бложег. И я допускаю, что программист, не занимающийся проектированием, вполне может до конца и не понимать. Но вот знать — обязан. Хотя бы потому, что ему придется часто разбираться с чужим кодом.
Еще раз поясню. Я не спорю с тем, что надо в принципе знать, что такое интерфейс. Я просто пока не понял, зачем он нужен как синтаксическая конструкция в динамическом PHP. Если объявить класс, реализующий некий интерфейс, а потом интерфейс убрать (а методы не трогать), то ничего не рассыпается. Либо есть случаи, когда не так, либо интерфейс как конструкция языка не нужен.
Как пример можно привести унификацию при разработки каких-либо драйверов. Тот же класс для кеширования. Можно использовать MemCache, APC, file based and etc. К примеру нужно реализовать еще один драйвер. Подключаем интерфейс с «правилами» и пишем драйвер «ничего не забыв»…
В PHP интерфейсы, как и классы, можно использовать для тайпхинтинга.
Я Вам выше привел пример с LoggerInterface. Чем не устраивает?
Интерфейс, имхо, это не синтаксическое, но архитектурное понятие, воплощенное в синтаксисе языка.
Интерфейс, имхо, это не синтаксическое, но архитектурное понятие, воплощенное в синтаксисе языка.
как не рассыпется?
если в коде подключается какой-либо драйвер или мейлер (мы точно не знаем, с чем именно будет работать код, а только знаем, что это нечто должно реализовывать некоторую логику, методы), то в нормальном коде обязательно проверяется if ($object instanceof Interface).
если потом интерфейс убрать, то всё рассыпется
если в коде подключается какой-либо драйвер или мейлер (мы точно не знаем, с чем именно будет работать код, а только знаем, что это нечто должно реализовывать некоторую логику, методы), то в нормальном коде обязательно проверяется if ($object instanceof Interface).
если потом интерфейс убрать, то всё рассыпется
Просто PHP пока не понял, в каком направлении он движется. Вроде бы язык динамической типизации, а есть тайпхинтинг для объектов и массивов. Плюс постоянно поднимается вопрос о тайпхинтинге для скаляров. Вся эта кухня только добавляет рассогласованности в и так довольно сумбурный язык (highstask, needle VS needle, highstask и strpos VS str_replace etc...).
Скорее интерфейс как конструкция языка обязывает разработчика реализовать все имеющиеся в нем методы. Необходимость в этом возникает, когда критична верная работа приложения. (Пусть лучше совсем не поднимется, чем отработает на половину).
В примере конечно использование интерфейса излишне, но в реальных системах, с большой кодовой базой интерфейсы практически незаменимы
Пример
Тест код:
Все просто, в данном примере реализация класса AnimalsController обязывает любого разработчика работающего с кодом, в качестве животного передавать класс реализующий одноименный интерфейс (Animals).
Таким образом написанный на коленке код класса собаки (не реализующий интерфейс) вызовет ошибку:
А если разработчик пишет код к np++ и забыл описать реализацию одного из методов, но привязал интерфейс:
то все равно работать не будет:
interface Animals
{
public function tease();
public function play();
}
class Dog
{
public function tease()
{
echo 'tease';
}
}
class Cat implements Animals
{
public function tease()
{
echo 'tease';
}
public function play()
{
echo 'play';
}
}
class AnimalsController
{
private $animal;
public function __construct(Animals $animal)
{
$this->animal = $animal;
}
public function Run()
{
$this->animal->tease();
$this->animal->play();
}
}
Все просто, в данном примере реализация класса AnimalsController обязывает любого разработчика работающего с кодом, в качестве животного передавать класс реализующий одноименный интерфейс (Animals).
Таким образом написанный на коленке код класса собаки (не реализующий интерфейс) вызовет ошибку:
PHP Catchable fatal error: Argument 1 passed to AnimalsController::__construct() must implement interface Animals, instance of Dog givenА если разработчик пишет код к np++ и забыл описать реализацию одного из методов, но привязал интерфейс:
class Dog extends Animals
то все равно работать не будет:
Fatal error: Class Dog cannot extend from interface AnimalsВ примере конечно использование интерфейса излишне, но в реальных системах, с большой кодовой базой интерфейсы практически незаменимы
Первый практический опыт интерфейсов можно почерпнуть из фреймворков.
Автор пишет интерфейс для работы с кешом. Сообщество наследует этот интерфейс и пишет свои классы для сохранения кеша в файликах/мемкеше итд.
Если очень грубо, то это документация, которая кинет эксепшн, если ты с ней не согласишься.
Очень круто интерфейсы пригождаются при массовой разработке, чтобы уже работающие методы продолжили работать.
Автор пишет интерфейс для работы с кешом. Сообщество наследует этот интерфейс и пишет свои классы для сохранения кеша в файликах/мемкеше итд.
Если очень грубо, то это документация, которая кинет эксепшн, если ты с ней не согласишься.
Очень круто интерфейсы пригождаются при массовой разработке, чтобы уже работающие методы продолжили работать.
3. Вопрос для языковых гиков, не имеющий ни малейшего отношения к реалиям прикладной разработки. Или вы набираете людей в команду для разработки Zend Engine?
5. Интерфейс зачастую определяет только один аспект поведения реализующего его класса, в то время как абстрактный класс определяет саму суть (природу) объектов его подклассов. По информации, что какой-то объект instanceof MyInterface ничего конкретного об этом объекте сказать нельзя (кроме того, что у него точно есть пара методов, определенных в MyInterface). Например, интерфейс может называться Comparable, а реализовывать его могут классы Money, User и Rating. Каждый из этих классов — обособленная сущность предметной области, все они разной природы. Если же есть информация, что какой-то объект instanceof MyAbstractClass, это всегда должно означать что мы имеем дело с иерархией объектов одной природы. Например, абстрактный класс может называться Car, тогда все его наследники 100% должны быть также машинами. Рассматривать абстрактные классы как замену интерфейсам (и наоборот) в корне некорректно в силу их абсолютно разного назначения.
5. Интерфейс зачастую определяет только один аспект поведения реализующего его класса, в то время как абстрактный класс определяет саму суть (природу) объектов его подклассов. По информации, что какой-то объект instanceof MyInterface ничего конкретного об этом объекте сказать нельзя (кроме того, что у него точно есть пара методов, определенных в MyInterface). Например, интерфейс может называться Comparable, а реализовывать его могут классы Money, User и Rating. Каждый из этих классов — обособленная сущность предметной области, все они разной природы. Если же есть информация, что какой-то объект instanceof MyAbstractClass, это всегда должно означать что мы имеем дело с иерархией объектов одной природы. Например, абстрактный класс может называться Car, тогда все его наследники 100% должны быть также машинами. Рассматривать абстрактные классы как замену интерфейсам (и наоборот) в корне некорректно в силу их абсолютно разного назначения.
Ну привет, приехали, вопрос про то, что в PHP тип результата операции определяется оператором, а не операндами — для гиков…
Без понимания сути этого вопроса не будет понимания системы типов и типизации в языке. То есть не будет понимания языка в принципе.
А прикладная разработка в стиле (как говорил мой дед) «тяп-ляп-насрал-и-стартап-гречневая-каша» мне не нужна.
А вот здесь Вы совершенно правы. Поэтому и нужен такой вопрос.
Без понимания сути этого вопроса не будет понимания системы типов и типизации в языке. То есть не будет понимания языка в принципе.
А прикладная разработка в стиле (как говорил мой дед) «тяп-ляп-насрал-и-
Рассматривать абстрактные классы как замену интерфейсам (и наоборот) в корне некорректно в силу их абсолютно разного назначения.
А вот здесь Вы совершенно правы. Поэтому и нужен такой вопрос.
Странный у вас топ вопросов. Пункт 3 — сугубо философский. Всем вообще наплевать, каким оператором используется конкатенация и почему именно таким. Потому, что конвеншн. Если вы пишете на нескольких языках, вы просто используете регламентированный синтаксис. Почему JS использует +? Так исторически сложилось.
4й вопрос вообще относится к наиболее неудачным вопросам на собеседовании. Потому что вы его тщательно придумали и ожидаете какой-то неведомый обществу ответ, сложившийся именно в вашей голове. Если кандидат не нащупает интуитивно какой-то из вариантов, с которыми вам почему-то довелось столкнуться, он проиграл. Статья в этом плане предлагает куда более удобные и чистые для понимания вопросы.
4й вопрос вообще относится к наиболее неудачным вопросам на собеседовании. Потому что вы его тщательно придумали и ожидаете какой-то неведомый обществу ответ, сложившийся именно в вашей голове. Если кандидат не нащупает интуитивно какой-то из вариантов, с которыми вам почему-то довелось столкнуться, он проиграл. Статья в этом плане предлагает куда более удобные и чистые для понимания вопросы.
>> Пункт 3 — сугубо философский.
Неверно. Он имеет самое прямое отношение к архитектуре языка. В данном случае — к системе типов. Не понимаете почему точка — не понимаете язык.
>>4й вопрос вообще относится к наиболее неудачным вопросам на собеседовании. Потому что вы его тщательно придумали и ожидаете какой-то неведомый обществу ответ
Неверно. Я ожидаю умение пользоваться базовыми конструкциями языка. Как минимум — циклом foreach, ссылками, базовой функциональщиной на примере банальной функции array_map и анонимными функциями. Одного даже упоминания вслух об этих возможностях уже достаточно для «зачёта» по этому вопросу. Будет что-то еще — отлично, но необязательно.
Неверно. Он имеет самое прямое отношение к архитектуре языка. В данном случае — к системе типов. Не понимаете почему точка — не понимаете язык.
>>4й вопрос вообще относится к наиболее неудачным вопросам на собеседовании. Потому что вы его тщательно придумали и ожидаете какой-то неведомый обществу ответ
Неверно. Я ожидаю умение пользоваться базовыми конструкциями языка. Как минимум — циклом foreach, ссылками, базовой функциональщиной на примере банальной функции array_map и анонимными функциями. Одного даже упоминания вслух об этих возможностях уже достаточно для «зачёта» по этому вопросу. Будет что-то еще — отлично, но необязательно.
Всё что ниже, сугубо моё мнение.
Всё же я бы рекомендовал вам отказаться от эти вопросов и найти более уместные для проверки тех же самых знаний. Вам кажется, что люди будут отвечать про анонимные функции. На самом деле человек может решить, что от него требуется знание какой-то магии, и пытаться ответить совсем не в ожидаемом ключе. Хотите узнать про лямбду — спросите про замыкание. Вообще, из моего опыта собеседований и с той, и с другой стороны, могу утверждать, что необходимо избегать любой двусмысленности. Как в вопросах, так и в ответах.
В вопросе 3 уберите сравнение с JS, так на самом деле далеко не все бекенд разработчики программировали на JS хоть что-нибудь без использования Jquery и подобных фреймворков и об основах этого языка знать в целом не обязаны (если вы, конечно, не ищите full stack или разработчика ещё и под nodejs). Ну и метод «не понимаете точку — не понимаете язык» — не лучший способ искать программистов.
Всё же я бы рекомендовал вам отказаться от эти вопросов и найти более уместные для проверки тех же самых знаний. Вам кажется, что люди будут отвечать про анонимные функции. На самом деле человек может решить, что от него требуется знание какой-то магии, и пытаться ответить совсем не в ожидаемом ключе. Хотите узнать про лямбду — спросите про замыкание. Вообще, из моего опыта собеседований и с той, и с другой стороны, могу утверждать, что необходимо избегать любой двусмысленности. Как в вопросах, так и в ответах.
В вопросе 3 уберите сравнение с JS, так на самом деле далеко не все бекенд разработчики программировали на JS хоть что-нибудь без использования Jquery и подобных фреймворков и об основах этого языка знать в целом не обязаны (если вы, конечно, не ищите full stack или разработчика ещё и под nodejs). Ну и метод «не понимаете точку — не понимаете язык» — не лучший способ искать программистов.
Услышал Вас и Ваши рекомендации. Но остался при своём сугубом мнении. Мне не нужны битрикс-boys, мне нужны программисты в лучшем значении этого слова. С инженерным мышлением, со стремлением знать, почему и зачем, а не просто пользоваться готовыми инструментами.
То, что вы ошибочно считаете «двусмысленностью» — это просто неявный тест на понимание базовых вещей, без которых программиста нельзя назвать таковым.
То, что вы ошибочно считаете «двусмысленностью» — это просто неявный тест на понимание базовых вещей, без которых программиста нельзя назвать таковым.
Я правильно понимаю, что сравнение с JS было в вопросе не зря? Ведь в отличии от того же JS в PHP строки «2» + «2» = 4, a в JS «2» + «2» = «22». Динамическая пыха часто может неверно интерпретировать наши желания, и поэтому для явности указания существует отдельный оператор конкатенации «точка»? Просто этот вопрос заинтересовал и хотелось бы услышать ваши на него ожидания. Спасибо
Наиболее близкий к истине ответ в том, что в PHP тип результата операции полностью определяется оператором. То есть "+" — это всегда сложение, а "." — всегда конкатенация, вне зависимости от контекста, в отличие от того же JS.
Употребление в ответе слова «пыха» вряд ли увеличит ваш вес в глазах собеседующего, поверьте мне.
Употребление в ответе слова «пыха» вряд ли увеличит ваш вес в глазах собеседующего, поверьте мне.
Благодарю за ответ!)
То есть "+" — это всегда сложение
['foo', 'bar'] + ['baz']другое дело что в JS любое выражение вернет вам что-то а в PHP на совсем уж чушь вы хотя бы получите notice (который к тому же нельзя перехватить и обработать, так что разница не значительна).
Перегрузка плюса для массивов — исключение, которое несложно запомнить.
И с чего вы это взяли, что E_NOTICE нельзя перехватить и обработать? php.net/function.set-error-handler
И с чего вы это взяли, что E_NOTICE нельзя перехватить и обработать? php.net/function.set-error-handler
Мне кажется, что если человек ответит на все вопросы, то это уже не php программист в обычном понимании. Если человек знает как устроен массив, что такое список, знает про сложность алгоритмов, позднее связывание и т.п., то скорее всего он универсал, которому в целом пофигу на чем писать, был бы stackoverflow под рукой. И у таких людей php обычно совсем не на первом месте в списке любимых языков.
Чему будет равен $x после выполнения выражения $x = 3 + «15%» + "$25"?
У вас в вопросе "«15%»" а в ответе разбирается пример c ''15%''
$x = 3 + ''15%'' + "$25"
Это сбивает.
Спасибо за перевод — так и не дочитал в оригинале, и не перевел сюда из-за объема.
«перезагрузка свойств», странное понятие, возможно имелась в виду «перегрузка свойств»?
Много знакомых вопросов, которые попадаются во всяких предварительных тестах на собеседования.
Самое большое недоумения вызывают вопросы, которые затрагивают отвратительные практики программирования, вроде «как используется global» или "$x = 3 + ''15%'' + "$25".
Зачем это нужно знать, если в трезвом уме никогда такую фигню писать не станешь?
Самое большое недоумения вызывают вопросы, которые затрагивают отвратительные практики программирования, вроде «как используется global» или "$x = 3 + ''15%'' + "$25".
Зачем это нужно знать, если в трезвом уме никогда такую фигню писать не станешь?
А как же поддержка legacy-кода, в котором много что использоваться может?
Знать и понимать фичи языка нужно, но следовать «отвратительным практикам» никто не заставляет.
Знать и понимать фичи языка нужно, но следовать «отвратительным практикам» никто не заставляет.
Но все-таки вопросы странные, заставляют задуматься об адекватности работодателя.
Я бы из принципа ответил что-то вроде: «не помню, ибо не использую/никогда так не делаю/var_dump() „
и, если после этого этот работодатель мной не заинтересуется — я точно не буду расстроен.
Я бы из принципа ответил что-то вроде: «не помню, ибо не использую/никогда так не делаю/var_dump() „
и, если после этого этот работодатель мной не заинтересуется — я точно не буду расстроен.
Расстроены вы будете, когда ответите на все вопросы, получите работу, а там вам дадут сервер с PHP 5.2, на котором ничего из этого не заработает.
По-моему нужно стараться избегать работ, где нужно всего лишь поддерживать некий старый код, который не будет развиваться.
А так непонятная ситуация, зачем работодателю думать какой там я PHP буду использовать для проекта, обычно работодателя интересует лишь сколько денег необходимо на сервера.
А так непонятная ситуация, зачем работодателю думать какой там я PHP буду использовать для проекта, обычно работодателя интересует лишь сколько денег необходимо на сервера.
С тредом согласен =). Я тут знаю как рабтают сервис локаторы и IoC, а меня спрашивают про global. Кстати на вопрос про глобал моя первая фраза была такой.
Значит читаю с листа:
В: зачем нужен global
О: наверное для того что бы писать говнокод, ну либо для оптимизации скорости, но выйграша при проигранной архитекктуре будет никакого.
И еще я про HTTP1.0 и HTTP1.1 не смог отличая назвать, хоть знаю как устроен протокол вдоль и поерек, а так же весь стек OSI наверх вплоть до того как кодируется самовосстанавливающиеся коды.
Короче я не понимаю работодателя. Считаю что к такому идти не надо.
Значит читаю с листа:
В: зачем нужен global
О: наверное для того что бы писать говнокод, ну либо для оптимизации скорости, но выйграша при проигранной архитекктуре будет никакого.
И еще я про HTTP1.0 и HTTP1.1 не смог отличая назвать, хоть знаю как устроен протокол вдоль и поерек, а так же весь стек OSI наверх вплоть до того как кодируется самовосстанавливающиеся коды.
Короче я не понимаю работодателя. Считаю что к такому идти не надо.
Буквально вчера эти вопросы видел. Понял что работодатель неадекватен, либо придется возиться с жудким легаси.
Я кстати удивлен почему в этих списках вопросов нет var_dump() — её я последний раз использовал чертикогда и только на API.
Я кстати удивлен почему в этих списках вопросов нет var_dump() — её я последний раз использовал чертикогда и только на API.
Дело в том, что если данные практики не применяются уже долгое время, то либо о них уже все забывают, либо даже никогда и не успевают столкнуться. Я например активно на php разрабатываю с 2011го года и с global познакомился только тогда, когда в руки передали очень старый проект, не имевший отношения к работе. А с 13го года я занимался разработкой исключительно на php 5.4 и 5.5. Ни за какие ковришки не пойду на проект, который меньше 5.4.
То есть тонкости знания древнего кода мне совершенно не интересны и если меня начинут спрашивать подобные вещи на собеседовании, то я не постесняюсь поинтересоваться образцами кода проекта данной компании, потому что один раз так я уже попал на быдлокодовый проект с 5.1 и сбежал очень быстро.
То есть тонкости знания древнего кода мне совершенно не интересны и если меня начинут спрашивать подобные вещи на собеседовании, то я не постесняюсь поинтересоваться образцами кода проекта данной компании, потому что один раз так я уже попал на быдлокодовый проект с 5.1 и сбежал очень быстро.
А если бы вам сказали «проект старый, нужен рефакторинг, время на это дело выделим в должном объеме», вы бы согласились?
При прочих нормальных условиях я думаю, что мог бы взяться.
Если это вопрос с тем, чтобы меня подвести к осознанию необходимости знания тонкостей старого кода, то всё равно я не считаю важным выносить это на собеседование. К примеру, в случае упомянутого краткого синтаксиса в echo, достаточно выполнить трассировку и получить промежуточный результат, в крайнем случае сделать декомпозицию, тем более что осуществляться будет рефакторинг.
Если это вопрос с тем, чтобы меня подвести к осознанию необходимости знания тонкостей старого кода, то всё равно я не считаю важным выносить это на собеседование. К примеру, в случае упомянутого краткого синтаксиса в echo, достаточно выполнить трассировку и получить промежуточный результат, в крайнем случае сделать декомпозицию, тем более что осуществляться будет рефакторинг.
Разве что для того, чтобы понять, что хотел сказать автор своим кодом, который, возможно, придется поддерживать. Большая часть вопросов на практике не особо применима.
Ответ на вопрос про замыкания, например, перечитал несколько раз, но так толком ничего из него и не понял. Когда увидел этот вопрос в списке, заинтересовался: понадеялся, что узнаю, какова их область применения непосредственно в PHP. А в итоге одно разочарование. Не увидел вообще ни намека на привычные мне замыкания. Какая-то каша про анонимные функции, которые вдруг почему-то стали замыканиями. Впрочем, в документации тоже «The Closure class — Class used to represent anonymous functions».
Как человек, практикующий написание кода на PHP, я понимаю, что тут своя атмосфера. Но конкретно это уже абсолютно вне моего понимания.
Ответ на вопрос про замыкания, например, перечитал несколько раз, но так толком ничего из него и не понял. Когда увидел этот вопрос в списке, заинтересовался: понадеялся, что узнаю, какова их область применения непосредственно в PHP. А в итоге одно разочарование. Не увидел вообще ни намека на привычные мне замыкания. Какая-то каша про анонимные функции, которые вдруг почему-то стали замыканиями. Впрочем, в документации тоже «The Closure class — Class used to represent anonymous functions».
Как человек, практикующий написание кода на PHP, я понимаю, что тут своя атмосфера. Но конкретно это уже абсолютно вне моего понимания.
ну например от пользователя может придти что-то подобное при очень кривой фильтрации данных.
Спорное утверждение. Приведение типов — очень важная часть РНР, и если человек знает, как оно работает, это позволяет писать намного более простой и чистый код. Знающий человек не станет без лишней надобности проверять, число у нас или строка в переменной, например, и уж тем паче писать код для перевода строки «15%» в число.
Знающий человек не станет без лишней надобности проверять, число у нас или строка в переменной
Знающий проверять не будет, потому что он будет знать заранее, какой тип там в переменной. И конструкции в коде, где так как в этом примере лепятся разные типы не допустит в принципе. Это плохой код как минимум потому, что сходу он непонятный (я про неявное приведение, когда сроки с числами перемешиваться через плюс).
Именно что использование неявного приведения типов делает код более сложным и грязным. Простота и чистота кода обычно плохо соотносится со стремлением написать всё покороче.
Мне кажется иногда на фоне знания типа «что такое плохо» лучше осознается «что такое хорошо». Как в жизни после какого то несчастья лучше эмоционально ощущается радость. Лучше, чем когда все монотонно и стабильно.
после 5 лет в PHP я не мог найти ничего более 40-50 кк руб
судьба привела меня к javascript
теперь за мной гоняются хедхантеры с предложениями 120 — 150 кк
PS тесты хорошие
судьба привела меня к javascript
теперь за мной гоняются хедхантеры с предложениями 120 — 150 кк
PS тесты хорошие
кк?
догнали?)
Весьма странно. Знакомые в Спб работают за 100к+
Сам работаю удаленно в районе сумм, с которыми за Вами гоняются хедхантеры.
Сам работаю удаленно в районе сумм, с которыми за Вами гоняются хедхантеры.
я же не говорю, что никто не рабоатет за 100+
но вакансий я вижу 12 штук
из них половина от 50к. так что я думаю 100 к они не преполагают. а типа от 50 но супер спецу 55
но вакансий я вижу 12 штук
из них половина от 50к. так что я думаю 100 к они не преполагают. а типа от 50 но супер спецу 55
Хм не знаю как в СпБ но в Москве найти приличного PHP программиста даже за 60-70 не очень просто
И за приличного в этом случае я бы считал такого кто ответит хотя бы на 3 вопроса из 14 в статье. Серьезно.
Хотя сами вопросы мне не понравились (потому что на половину я не знаю ответа хотя 10 лет в программировании хаха) — но все очень зависит от задач. Такие вещи которые нужно знать для ответа на эти вопросы — случайно не учат. Либо это очень углубленные познания либо прошлый опыт. Я же в первую очередь смотрю количество практики на разных проектах — ближе к реальности.
Вообще из-за низкого порога входа поиск пхп-шника тот еще ад — очень много самоучек которые считают что вполне уже могут работать на 100к а сами только-только коснулись SQL и классов
И за приличного в этом случае я бы считал такого кто ответит хотя бы на 3 вопроса из 14 в статье. Серьезно.
Хотя сами вопросы мне не понравились (потому что на половину я не знаю ответа хотя 10 лет в программировании хаха) — но все очень зависит от задач. Такие вещи которые нужно знать для ответа на эти вопросы — случайно не учат. Либо это очень углубленные познания либо прошлый опыт. Я же в первую очередь смотрю количество практики на разных проектах — ближе к реальности.
Вообще из-за низкого порога входа поиск пхп-шника тот еще ад — очень много самоучек которые считают что вполне уже могут работать на 100к а сами только-только коснулись SQL и классов
Черт возьми, Вы очень правы :(
А вы перестаньте искать программистов ДАЖЕ за 60-70 к и найдете нормальных.
Так я же на джуниора искал, никаких фантастических задач — поддержка уже работающих проектов, внесение изменений по уже отработанным методам, поиск ошибок. Но человек приходит на 60 и не может ответить на вопросы уровня лабораторных работ второго курса, о чем вы.
Например?
Например не может ответить как работать с куками через php, чем отличается $element от &$element, чем отличается LEFT и RIGHT JOIN в SQL, как в SQL производится выборка с 10 по 30 записи из запроса. Как обрабатывать глобальные перменные get/post запросов и файлов, каков принцип работы шаблонизаторов типа smarty, как в общих чертах сделать на сайте ЧПУ.
У меня в общем есть список вопросов которые я на джуниора веб-программиста таскаю — он очень простой и устный, охватывает сразу php/js/css/html/sql/jquery/bitrix и на многие вопросы есть несколько правильных ответов, но по тому как соискатели отвечают уровень виден сразу.
И оказалось что получить адекватные ответы хотя бы на 80% элементарных вопросов это уже неплохо.
У меня в общем есть список вопросов которые я на джуниора веб-программиста таскаю — он очень простой и устный, охватывает сразу php/js/css/html/sql/jquery/bitrix и на многие вопросы есть несколько правильных ответов, но по тому как соискатели отвечают уровень виден сразу.
И оказалось что получить адекватные ответы хотя бы на 80% элементарных вопросов это уже неплохо.
Из контекста же не было понятно, что речь о джуниорах. Джуниор + PHP — гремучая смесь. :)
Вообще из-за низкого порога входа поиск пхп-шника тот еще ад — очень много самоучек которые считают что вполне уже могут работать на 100к а сами только-только коснулись SQL и классов
Далеко ходить не надо. В этом же посте ниже спрашивают, зачем вообще нужно ООП, и это не сарказм.
То ли ещё будет, когда опыт перевалит за 10 лет :)
Потребности растут, а рынок иногда неожиданно просаживается.
Потребности растут, а рынок иногда неожиданно просаживается.
«APC Cache был заменён на OpCache» — разве это корректно? APC всегда был внешним модулем, а OpCache сейчас включили «по-умолчанию». А вообще мне показалось, что данный тест предполагает найти специалиста по конкретному языку, а не программиста, что обычно требуется. Странно, что global в купе с новшествами PHP 5.5 рассматриваются.
И придет такой человек, выучивший мануал или тупо подготовившейся к собеседованию, к вам, и будет писать жуткий говнокод, от которого волосы дыбом будут стоять.
Я сейчас на знания PHP, как языка/стандартной библиотеки, вообще ни одного вопроса не задаю (да, ищем не junior'ов). Слишком простой язык, чтобы там было на что спрашивать.
Я сейчас на знания PHP, как языка/стандартной библиотеки, вообще ни одного вопроса не задаю (да, ищем не junior'ов). Слишком простой язык, чтобы там было на что спрашивать.
Если честно, вопросы ни о чём, т.к. сугубо академичны. Я уже лет 15 как ведущий PHP разработчик и даже не стал бы на них отвечать. Не потому что я не знаю, а потому что это глупо. Некоторые вещи используются настолько редко, что быстро вылетают из головы, либо уже давно обёрнуты «высокоуровневыми прокладками». Достаточно провести один вечер над мануалом и это собеседование будет легко пройдено. Сколько я уже повидал зубрил, которые на собеседовании блещут теорией, а на практике не могут связать а и б… Дай мне сейчас листик бумаги и я не смогу написать там простой цикл. Я не знаю наизусть всех функций, как и порядка их аргументов, спасибо автокомплиту в IDE. Быть мне теперь Junior'ом? :)
ArrayObjects — это что вообще такое? Пишите как есть: ArrayObject
ArrayObjects — это что вообще такое? Пишите как есть: ArrayObject
В точку, в целом. Писал что-то подобное, но Вы опередили :).
Всем рулит Mr. Experience и культура программирования (как способность программиста придерживаться одного стиля и заданных правил внутри проекта вне зависимости от его личных убеждений :)).
Всем рулит Mr. Experience и культура программирования (как способность программиста придерживаться одного стиля и заданных правил внутри проекта вне зависимости от его личных убеждений :)).
ArrayObjects — это что вообще такое? Пишите как есть: ArrayObject
Опечатка. Поправили. Спасибо.
+100500, главное понимание, знание базовых алгоритмов, оценка сложности алгоритма и практические навыки проектирование. А как сделать $$var = 'name'; без одного вопроса как работать с базоы данных не даст ровным счетом ничего.
Вообще ничего нет про OOP как основу приложения, хотя бы на базовом уровне — чем отличается абстрактный класс от интерфейса, что такое IoC и тому подобное. Это тема другого собеседования или Вы считаете, что это не нужно?
Зато есть про суперглобальные переменные с одной стороны, и про трейты/генераторы — с другой. Имхо, как-то неконсистентно.
Зато есть про суперглобальные переменные с одной стороны, и про трейты/генераторы — с другой. Имхо, как-то неконсистентно.
объясните. зачем нужно ООП?
Мммм… Не сочтите за труд, объясните, как современному программисту PHP могут быть не нужны знания ООП. Это не сарказм. Я, наверно, чего-то не понимаю.
объясните. зачем нужно ООП?
Кажется, я смог определить, что ночью во сне меня убили и подменили на клона.
А вот бы кто-нибудь написал такие же вопросы про Python — я был бы рад, как начинающий питонист:)
А для кого собственно гайд? Кто «должен» задавать такие вопросы? Технический специалист, рекрутер, кто-то еще?
И что им проверяется? Уровень программиста, знание деталей языка, давно ли он «зубрил мануал», читал ли он этот пост или десятки ему подобных?
И что им проверяется? Уровень программиста, знание деталей языка, давно ли он «зубрил мануал», читал ли он этот пост или десятки ему подобных?
Насколько я понимаю, все вопросы предполагают не проверку знаний php, или адекватности, или зубрения мануала — а возможность ответа на вопрос насколько собеседуемый зашел в php internals. Другими словами тест предполагает — не отсеивание говнокодеров-жумлистов, а способность С-программистов изучивших движок максимально быстро извлечь из накопленной за изучением библиотеки знаний — быстро притворить ее в жизнь на php. Ну и те, кому из вышеуказанных, это покажется интересным — конечно же будут писать хороший и качественный код не задумываясь.
Мало знать мат.часть (ее тоже необходимо знать, не спорю), надо уметь применять эти знания в нужном месте в нужное время.
НО, если проект прост как 3 копейки, зачем «заморачиваться» и писать сложные функции.
Я считаю, что опыт — вот главный критерий при приеме на работу в данное время. Не раз убеждаюсь уже (не только на своем примере) — теория теорией, а опыт «не пропьешь» и не получишь читая просто книжки. Причем опыт должен быть именно не на своих любительских программах (хотя и там тоже есть свои плюсы), а работы в команде. Начинаешь лучше понимать принципы построения.
Статья хорошая — +автору.
НО, если проект прост как 3 копейки, зачем «заморачиваться» и писать сложные функции.
Я считаю, что опыт — вот главный критерий при приеме на работу в данное время. Не раз убеждаюсь уже (не только на своем примере) — теория теорией, а опыт «не пропьешь» и не получишь читая просто книжки. Причем опыт должен быть именно не на своих любительских программах (хотя и там тоже есть свои плюсы), а работы в команде. Начинаешь лучше понимать принципы построения.
Статья хорошая — +автору.
Мне всегда казалось, что идеальные вопросы по php это сильно утрированные, но реальные задачи из веба. Человек должен знать, как работает HTTP, GET/POST запросы, формы, сессии, куки.
Например скрипт, который выводит какую-то информацию и форму, он же отвечает за сабмит этой формы.
И просим человека рассказать что будет при сабмите формы. Формы в веб-приложениях есть почти всегда, и подобный вопрос по-моему обязателен.
Например скрипт, который выводит какую-то информацию и форму, он же отвечает за сабмит этой формы.
Пример
<?php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$post_id = $_POST['post_id'];
// save comment
//…
header('Location: /?post_id='. $post_id);
}
elseif (!empty($_GET['post_id'])) {
// print post
//…
}
?>
/>
/>
/>
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$post_id = $_POST['post_id'];
// save comment
//…
header('Location: /?post_id='. $post_id);
}
elseif (!empty($_GET['post_id'])) {
// print post
//…
}
?>
/>
/>
/>
Немного запутаем
<?php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$post_id = !empty($_POST['post_id'])? $_POST['post_id']: 30;
// save comment
//…
header('Location: /?post_id='. $post_id);
}
elseif (!empty($_GET['post_id'])) {
// print post
//…
}
?>
/>
/>
/>
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$post_id = !empty($_POST['post_id'])? $_POST['post_id']: 30;
// save comment
//…
header('Location: /?post_id='. $post_id);
}
elseif (!empty($_GET['post_id'])) {
// print post
//…
}
?>
/>
/>
/>
И просим человека рассказать что будет при сабмите формы. Формы в веб-приложениях есть почти всегда, и подобный вопрос по-моему обязателен.
Я вам больше скажу, чуть ли не половина кандидатов на вакансию PHP-джуниора отсеивается заданием «напишите функцию расчета факториала». Даже если рассказать, что такое факториал и как его считают.
Поэтому без выполнения тестового задания (пусть даже достаточно простого) на собеседование можно никого не приглашать :)
Поэтому без выполнения тестового задания (пусть даже достаточно простого) на собеседование можно никого не приглашать :)
А где вопрос про оператор три равно (===)? =)
Я, например, про него узнал не сразу, т.к. прийдя в РНР из C# даже не думал что такой оператор существует!
Я, например, про него узнал не сразу, т.к. прийдя в РНР из C# даже не думал что такой оператор существует!
UFO just landed and posted this here
Вот честно, я сходу не смогу рассказать всех нюансов работы == (во всяком случае не уверен), === то простое. Сравнение по значению и типу. А == коварно. Это как проверять наличие ключа через isset, ключи вроде есть, а вроде и нет. Вообще массивы в PHP то еще развлечение…
Сравнение типов из официальной документации PHP: php.net/manual/ru/types.comparisons.php
Как то раз один профессор по двигателям сдавал экзамен в ГАИ, ему попался вопрос «Принцип функционирования ДВС» (дословно не помню). Тот обрадовался, начал с формулами и выкладками рассказывать. И что Вы думаете, не сдал. Гаишник его просто не понял и сказал «что Вы мне тут голову морочаете».
Где гарантия того, что экзаменатор разбирается в задаваемыхвопросах лучше чем экзаменуемый? Их отличие, зачастую в том, что первый проштудировал эти вопросы заранее. Сколько раз уже тут писал, человека надо проверять не на то сколько тонкостей он знает а на то как он умеет быстро в них разобраться при необходимости. Примерно как Капица принимал экзамены в библиотеке, бери, читай что хочешь но покажи что ты ориентируешься где что искать и имеешь базу в этом разобраться. Ну и конечно глянуть на то что он уже делал (в код) не стесняясь спросить почему так а не иначе, не корча из себя всезнайку потому как может оказаться что человек разбирается в чем то лучше тебя и в итоге будешь выглядить глупо со своими проверками. Талантливый, приветливый, способный быстро учиться человек гораздо интереснее
сухаря спеца с которым никто не может работать в команде. Бывают конечно исключения, но Вы ж не гугл чтоб к Вам спецы толпой валили а Вы только отсеивали. Потому подходите к вопросу творчески а не формально.
Где гарантия того, что экзаменатор разбирается в задаваемыхвопросах лучше чем экзаменуемый? Их отличие, зачастую в том, что первый проштудировал эти вопросы заранее. Сколько раз уже тут писал, человека надо проверять не на то сколько тонкостей он знает а на то как он умеет быстро в них разобраться при необходимости. Примерно как Капица принимал экзамены в библиотеке, бери, читай что хочешь но покажи что ты ориентируешься где что искать и имеешь базу в этом разобраться. Ну и конечно глянуть на то что он уже делал (в код) не стесняясь спросить почему так а не иначе, не корча из себя всезнайку потому как может оказаться что человек разбирается в чем то лучше тебя и в итоге будешь выглядить глупо со своими проверками. Талантливый, приветливый, способный быстро учиться человек гораздо интереснее
сухаря спеца с которым никто не может работать в команде. Бывают конечно исключения, но Вы ж не гугл чтоб к Вам спецы толпой валили а Вы только отсеивали. Потому подходите к вопросу творчески а не формально.
Те задачи, которые должен решать PHP, требуют его развития всего лишь в 3 направлениях
1) SPL, а именно его дополнение такими замечательными вещами как FixedArray
2) OpCache
3) Рождение процесса, смерть и их регулировщики, в частности развитие php-fpm, который начал заметно проседать, ёклмн.
Всё остальное не играет и не сыграет никакой решающей роли ни в какой неэпически сложной архитектуре, ибо ниэпически сложную архитектуру обычно разбрасывают по модулям с REST и одним php (слава богу) ничего не ограничивается.
Поэтому вся эта (прости господи) срань господня в виде трэйтов, интерфейсов и прочего прелестного, становиться похожа на кучку беспомощных котят, когда весь input-output начинает безжалостно сегфолтиться, мемликать, просить set_time_limit(0), max-input-time over9000, memory_limit(+100500).
И вот такими статьями воспитывается поколение программистов PHP ради PHP.
Ни в коем случае нельзя оформлять такие статьи, как то, что вы должны знать на собеседовании.
Это задаст ложное направление свежей пачке выпускников от мира web разработки.
Это всегда должно преподноситься, как «это интересно, это поможет тебе в этом и вот в этом, избавит от этого и от этого.» И конкретные примеры плохих, именно ужасно (а не допустимо-) плохих практик.
А если в бизнесе вас начинает волновать, в курсе ли человек в первую очередь про то, когда умер 5,2 и что такое разница abstract и interface, а не то, что его зарабатывающую деньги страничку или терминал видят только 10 человек из 100, по причине «facially yours, nginx», то у меня для вас плохие новости.
1) SPL, а именно его дополнение такими замечательными вещами как FixedArray
2) OpCache
3) Рождение процесса, смерть и их регулировщики, в частности развитие php-fpm, который начал заметно проседать, ёклмн.
Всё остальное не играет и не сыграет никакой решающей роли ни в какой неэпически сложной архитектуре, ибо ниэпически сложную архитектуру обычно разбрасывают по модулям с REST и одним php (слава богу) ничего не ограничивается.
Поэтому вся эта (прости господи) срань господня в виде трэйтов, интерфейсов и прочего прелестного, становиться похожа на кучку беспомощных котят, когда весь input-output начинает безжалостно сегфолтиться, мемликать, просить set_time_limit(0), max-input-time over9000, memory_limit(+100500).
И вот такими статьями воспитывается поколение программистов PHP ради PHP.
Ни в коем случае нельзя оформлять такие статьи, как то, что вы должны знать на собеседовании.
Это задаст ложное направление свежей пачке выпускников от мира web разработки.
Это всегда должно преподноситься, как «это интересно, это поможет тебе в этом и вот в этом, избавит от этого и от этого.» И конкретные примеры плохих, именно ужасно (а не допустимо-) плохих практик.
А если в бизнесе вас начинает волновать, в курсе ли человек в первую очередь про то, когда умер 5,2 и что такое разница abstract и interface, а не то, что его зарабатывающую деньги страничку или терминал видят только 10 человек из 100, по причине «facially yours, nginx», то у меня для вас плохие новости.
Очень спорно применимая статья, но интересная зато :) порадовало что хоть что-то я все-таки знаю. Спасибо
Прочитал все комментарии и удивлён тем, что есть очень много критикующих этот список вопросов с позиции «Эти вопросы не выявят хорошего программиста» и при этом всего лишь 4-5 комментариев с конкретными альтернативными вопросами к собеседованию. При этом основная позиция: видели мы тех, кто это знает, но ничего не умеет — они не хорошие программисты.
А вы возьмите и изложите в виде вопросов тот багаж знаний, которым обладаете и знакомство с которым выведет оппонента на собеседовании на уровень «я верю, он может».
P.S. Я из всех вопросов топика не смог ответить только на последний, потому что PHP 5.4 вот только недавно установил на виртуалку, и то не по своей воле, а потому что один из PHPшных фреймворков это потребовал. На практике ещё не приходилось сталкиваться с PHP 5.5 а про 5.6 я только краем уха слышал.
Вот мои альтернативные вопросы к собеседованию. Они выявляют не теоретиков, а практиков. Ну и не совсем чистого PHP программиста, а разработчика веб-приложений на базе PHP.
1. В каких случая индексы на таблицах — это хорошо, а в каких — плохо?
2. Аналогично про внешние ключи таблиц.
3. Каким образом практически может быть идентифицирован каждый уникальный пользователь веб-приложения?
4. Что и как потребуется настроить, чтобы AJAX запросы смогли проходить между разными доменами? Будет ли проще, если это домены или субдомены одного веб-приложения?
5. Что такое XSS инъекция и как с ней бороться? Есть ли универсальное решение?
6. Что такое SQL инъекция и, тоже, как с ней бороться? Есть ли универсальное решение?
7. Шаблоны проектирования. Но не все, а конкретно: MVC, Service Locator, Lazy initialization. И не нарисовать, а дать чужой или свой пример.
8. Что делать, если один HTTP запрос отрабатывает на сервере 15 минут, а надо 15 секунд или меньше?
9. Что будет, если не бороться за эти секунды? Когда это допустимо?
10. Что делать, если веб-сервер не справляется с 1 запросом в секунду (RPS). C 10 RPS? C 100 RPS? C 1000 RPS?
11. Сравни между собой по нескольким критериям следующие форматы данных: JSON, XML, CSV. Есть ли по каждому критерию ещё более эффективный формат данных?
12. Хорошо, давай про Legacy Code: напиши пример кода на PHP4, который не будет выполняться в PHP5. Хотя бы вспомни пару функций, по наличию которых в коде можно сказать, что этот проект на PHP 5 работать не сможет.
13. И вот тебе дали задачу переписать код небольшого проекта из двух десятков скриптов или классов с PHP4 на PHP5. Твой порядок действий?
14. Тебе дали задачу переписать код одной единственной гадкой функции, которая работает странно. Как выявить и устранить странность?
15. Ты выявил и готов исправить странность одной единственной гадкой функции, но помимо твоего веб-приложения этой функцией пользуются несколько неких сторонних веб-приложений посредством RPC, SOAP или иначе, причём именно недокументированными странностями. Как удовлетворить всех? ;)
16. Я могу утверждать, что у нас в коллективе все простой цикл и условие записывают вот так:
Как ты думаешь, почему это вдруг так?
17. В проекте приняты стандарты кодирования. Как бы ты поступил, если бы через 2 года нашёл в каком-нибудь месте проекта расхождение с принятыми стандартами?
18. Тебе дали задание: сделать новый проект на новом фреймворке и быстро. Причём с новым фреймворком ты и коллеги практически не сталкивались, а выбрали по принципу — «на хабре писали, что это самый новый/быстрый/маленький/большой/крутой/популярный»? Взялся бы за такое задание?
Не хватил ли я лишка в своих вопросах? :)
Может я пытаюсь найти умного, но ленивого гуру, а вашего проекта нужен всего лишь исполнительный программист на твердую «четвёрочку»?
А вы возьмите и изложите в виде вопросов тот багаж знаний, которым обладаете и знакомство с которым выведет оппонента на собеседовании на уровень «я верю, он может».
P.S. Я из всех вопросов топика не смог ответить только на последний, потому что PHP 5.4 вот только недавно установил на виртуалку, и то не по своей воле, а потому что один из PHPшных фреймворков это потребовал. На практике ещё не приходилось сталкиваться с PHP 5.5 а про 5.6 я только краем уха слышал.
Вот мои альтернативные вопросы к собеседованию. Они выявляют не теоретиков, а практиков. Ну и не совсем чистого PHP программиста, а разработчика веб-приложений на базе PHP.
1. В каких случая индексы на таблицах — это хорошо, а в каких — плохо?
2. Аналогично про внешние ключи таблиц.
3. Каким образом практически может быть идентифицирован каждый уникальный пользователь веб-приложения?
4. Что и как потребуется настроить, чтобы AJAX запросы смогли проходить между разными доменами? Будет ли проще, если это домены или субдомены одного веб-приложения?
5. Что такое XSS инъекция и как с ней бороться? Есть ли универсальное решение?
6. Что такое SQL инъекция и, тоже, как с ней бороться? Есть ли универсальное решение?
7. Шаблоны проектирования. Но не все, а конкретно: MVC, Service Locator, Lazy initialization. И не нарисовать, а дать чужой или свой пример.
8. Что делать, если один HTTP запрос отрабатывает на сервере 15 минут, а надо 15 секунд или меньше?
9. Что будет, если не бороться за эти секунды? Когда это допустимо?
10. Что делать, если веб-сервер не справляется с 1 запросом в секунду (RPS). C 10 RPS? C 100 RPS? C 1000 RPS?
11. Сравни между собой по нескольким критериям следующие форматы данных: JSON, XML, CSV. Есть ли по каждому критерию ещё более эффективный формат данных?
12. Хорошо, давай про Legacy Code: напиши пример кода на PHP4, который не будет выполняться в PHP5. Хотя бы вспомни пару функций, по наличию которых в коде можно сказать, что этот проект на PHP 5 работать не сможет.
13. И вот тебе дали задачу переписать код небольшого проекта из двух десятков скриптов или классов с PHP4 на PHP5. Твой порядок действий?
14. Тебе дали задачу переписать код одной единственной гадкой функции, которая работает странно. Как выявить и устранить странность?
15. Ты выявил и готов исправить странность одной единственной гадкой функции, но помимо твоего веб-приложения этой функцией пользуются несколько неких сторонних веб-приложений посредством RPC, SOAP или иначе, причём именно недокументированными странностями. Как удовлетворить всех? ;)
16. Я могу утверждать, что у нас в коллективе все простой цикл и условие записывают вот так:
foreach($someElements as $element)
{
if ($element->isGood())
{
$this->doSometing($element);
}
}
Как ты думаешь, почему это вдруг так?
17. В проекте приняты стандарты кодирования. Как бы ты поступил, если бы через 2 года нашёл в каком-нибудь месте проекта расхождение с принятыми стандартами?
18. Тебе дали задание: сделать новый проект на новом фреймворке и быстро. Причём с новым фреймворком ты и коллеги практически не сталкивались, а выбрали по принципу — «на хабре писали, что это самый новый/быстрый/маленький/большой/крутой/популярный»? Взялся бы за такое задание?
Не хватил ли я лишка в своих вопросах? :)
Может я пытаюсь найти умного, но ленивого гуру, а вашего проекта нужен всего лишь исполнительный программист на твердую «четвёрочку»?
Хорошие вопросы, точнее, темы для обсуждения с потенциальным кандидатом чтобы посмотреть его ход мыслей. Про PHP4 только вы загнули, 10 лет уже прошло как PHP5 вышел. На такой legacy code ни один вменяемый разработчик не пойдет. И в целом от вопросов веет «у нас проект на самописном движке десятилетней давности, сможешь ли ты его поддерживать и умудряться добавлять туда новые фичи?»
Нет, не 10ти летней давности. Ведь немногие в 2004 году бросились переписывать стабильно работающий говнокод с PHP4 на доселе неведомую почти-ООП 5.0. Я сам лично ещё долго писал совместимый с двумя версиями код — да мало ли кому понадобятся мои библиотеки, мало ли какой shared hosting у них будет.
Давайте переформулирую под современные реалии. В PHP 5.3, PHP 5.4, PHP 5.5 есть deprecated functions, при наличии которых код работать не будет.
Давайте переформулирую под современные реалии. В PHP 5.3, PHP 5.4, PHP 5.5 есть deprecated functions, при наличии которых код работать не будет.
12. Хорошо, давай про Legacy Code: напиши пример кода на PHP 5.3, который не будет выполняться в PHP 5.5. Хотя бы вспомни пару функций, по наличию которых в коде можно сказать, что этот проект на PHP 5.5 работать не сможет.
13. И вот тебе дали задачу переписать код небольшого проекта из двух десятков скриптов или классов с PHP 5.3 на PHP 5.5. Твой порядок действий?
Спасибо! Полезная статья. Узнал много нового со времен 4-ого PHP. Время летит...)
ЗЫ 6 вопрос:
По-моему, что-то не так…
ЗЫ 6 вопрос:
$_REQUEST – объединение пар ключ-значение из $_POST и $_getDog.
По-моему, что-то не так…
PHP 5.5… и добавлена удобная возможность обращения к символам в строке как к элементам массива (например, '6e5d4'[0] вернёт «6»).
тыщу лет был этот сахарок, кажется еще в пхп 4.3 уже было, пусть синтаксис такой красивый не был, но суть та же:
$array = "PHP";
echo $array[1];// выводит H
Sign up to leave a comment.
Руководство по собеседованию на вакансию PHP-программиста