Первым длом полез в гугл. Зачем делать работу, которую уже наверняка кто-то сделал? Так и оказалось, сразу нашел довольно неплохой план собеседования (ссылки внизу). Взял из него большуючасть вопросов и добавил свои.

Естественно, что вопросов программисту PHP можно задать море. Особенно учитвая, что знать надо связанные области (БД, сети, HTML и иже с ним, Linux). Смысла задать все вопросы, какие только можно, конечно нету. Задача — определить уровень специалиста, чтобы принять решение: подходит он нам или нет. По-этому выбрал наиболее подходящие на мой взгляд вопросы, по которым я смогу оценить уровень кандидата.

Кроме того, конечно не одиними вопросами можно обойтись. Следует предложить пройти небольшие тесты по практическим моментам. Об этом ниже.

Вопросы

1. PHP и основы программирования
1.1. Почему PHP?
1.2. Что такое ООП, основные принципы ООП.
1.3. Понятие абстракции, наследования, инкапсуляции и полиморфизма.
1.4. Что такое MVC?
1.5. Какие паттерны проектирования вам известны?
1.6. Под какую версию PHP писали? В чем различия между четвертой и пятой версиями?
1.7. Какими сторонними библиотеками пользовались?
1.8. Опыт работы с различными Frameworks/CMS?
1.9. Типы данных в PHP? (string, int, float, object, resource, null, bool, array)
1.10. Назовите по памяти функции для работы с массивами, строками и объектами в PHP (хотя бы по 5 штук).
1.11. Что такое сериализация?
1.12. Чем отличается абстрактный класс от интерфейса?
1.13. В каких случаях лучше использовать статические методы и классы?
1.14. Можно ли создать приватный конструктор? Зачем?
1.15. Как сказывается большое количество объектов в коде на производительность?
1.16. Что такое хэш?
1.17. Что такое область видимости переменной?
1.18. Что такое PDO? Что такое ORM?
1.19. Что такое PEAR?
1.20. Когда лучше использовать mysql_pconnect?
1.21. Обязательно ли писать ?> в конце скрипта?
1.22. Как вы отлаживаете PHP-код?
1.23. Проводили когда-нибудь оптимизацию сайтов?
1.24. Какую IDE используете? Какие использовали ранее?
1.25. Что такое unit-test? Использовали?
2. Tools
2.1. Что такое Apache? mod_rewrite? nginx?
2.2. Аббревиатуры SVN и CVS о чем-нить говорят? А Git и Mercurial?
2.3. Багтрекинг системы? BugZilla? Mantis? Redmine? JIRA?
2.4 .Моделирование, UML использовали?
2.5. Что такое SSH? Какие есть варианты авторизации при входе по SSH?
3. Data Bases
3.1. Что такое реляционная база данных? Какие есть типы БД?
3.2. Нормализация, денормализация.
3.3. SQL. Join’ы, Union. Подзапросы.
3.4. Процедуры, тригеры.
3.5. Вьюшки.
3.6. InnoDB vs MyISAM.
3.7. Какие бывают индексы в MySQL?
3.8. В чем отличие MySQL от PostgreSQL?
3.9. Что такое SQL-инъекция? Приведите пример.
4. HTML + CSS
4.1. Нарисуйте простенькую форму для отправки файла.
4.2. Что такое CSS? В чем разница между записью #my и .my? Для каких атрибутов можно указать :hover?
4.3. Расшифруй вот такую запись в CSS table#a tbody td.odd {text-decoration:inherit}?
4.4. Что такое стандарты W3C?
5. JavaScript
5.1. Как работает наследование в JS?
5.2. Чем отличается хэш от объекта? (провокационный)
5.3. А хэш от массива?
5.4. Если ли опыт работы с Jquery, ExtJS? Какие фреймворки использовались?
5.5. Что такое Ajax? Есть ли опыт работы с ним?
5.6. Использовали ли FireBug? Drag-on-fly?
5.7. Что такое замыкания и как они работают?
6. Linux
6.1. С *nix знаком? Какие дистрибутивы? Почему?
6.2. Apache, PHP и СУБД устанавливали под *nix? Настраивали? Оптимизировали?
7. Networking
7.1. Что такое уровни модели OSI? Сколько их?
7.2. По какому протоколу осуществляется передача данных в сети Интернет?
7.3. Какие вообще есть сетевые протоколы?
7.4. Расскажите, что происходит, когда в строке браузера набираешь адрес и нажимаешь Enter?
7.5. Что такое WSDL & web-services? Есть опыт работы?
7.6. Что такое SSL? Как работает HTTPS? Какой принцип работы HTTPS? Какие есть варианты авторизации HTTP?
8. Что такое XSLT, XML? Есть ли опыт работы с ними?

Как отработает код?

1)
<?php
/* Что будет выведено на экран? */
$a = ‘true’;
if( 0 == $a || $a )
{
echo ‘yes’;
}

2)
<?php
/* Что будет выведено на экран? */
$a = 10;
echo $a– – - – - – - – - – - –$a;

3)

<?php
class A {private function __construct(){throw new Exception(”);} public function A(){return array(’a',’b',’c');} public static function I(){return new A();}}
/*
Как вывести на экран именно то ‘b’, которое определено в массиве выше, используя одну команду (одну строку кода)?
*/

4)
<?php

/*
Какая строчка выведется при исполнении скрипта?
Почему исполняется или не исполняется каждое из условий?
*/
$x = 1;
if ($x == ‘1′) {
echo ‘a’;
}
if ($x == true) {
echo ‘b’;
}
if((bool)$x === true){
echo ‘e’;
}
if ($x === true) {
echo ‘c’;
}
if((int)$x === true){
echo ‘d’;
}

5)
<?php
/*
Что выведет скрипт? (запускается непосредственно)
*/
error_reporting(E_ALL);
ini_set(’display_errors’,'0′);

print $x[0];
dddxxxx();

6)
<?php
/*
Для какой версии PHP будет работать этот скрипт?
Что выведет этот скрипт?
*/
class Test{

private $var;

function setMe($value){
$this->var = $value;
}
}

class More extends Test{
public $var;
}

$oTest = new Test;
$oMore = new More;

echo $oTest->setMe(’foo’);

echo $oMore->setMe(’foo’);

echo $oMore->var;

echo $oTest->var;

Тест на corp.mamba.ru

http://www.corp.mamba.ru/test/promo.phtml

Ссылки

А вот и те ссылки, которые помогли мне в составлении списка.

http://habrahabr.ru/blogs/php/21681/

http://habrahabr.ru/blogs/webdev/19964/

В идеале, в данном случае передавать необходимо только добавляемые и получаемые данные, так как весь антураж может быть сохранен и доступен в пределах офиса локально.

Для решения этой задачи можно использовать общую базу данных, которая будет располагаться на хостинге. На сервере в локальной сети поднять сайт, указать для подключения к СУБД параметры доступа к база на удаленном сервере. Таким образом, у вас будут 2 одинаковых сайта, параллельно работающих с одним источником данных.

В принципе это обычная схема для балансировки нагрузки на фронтэнд (web-сервер). Практику много фронтэндов — один бэкэнд (база) применяют довольно часто, а следующий этап разделения нагрузки (когда уже СУБД не выдерживает напора) — кластеризация серверов баз данных. Но это лирическое отступление.

Следуюет учесть три нюанса. Во-первых, так как сервера у нас теперь два, время на них может быть разное. Следовательно при записи в базу временные показатели будут для серверов расходиться и может возникнуть путаница. Чтобы этого избежать, проще всего брать время из СУБД. Делать это надо естественно 1 раз за запрос (кэшировать), а не при каждой необходимости (при условии, что запрос выполняется не более 1 секунды; если больше, значит ваша система нуждается в оптимизации). Таким образом время на всех серверах будет синхронизировано по времени на сервере с СУБД.

Второй нюанс заключается в том, что по сети информация между сервером на офисе и базой у провайдера будет ходить в открытом виде, что потенциально опасно. Так же опасно создавать пользователя, которому будет разрешено удаленно подключаться к сети с любого хоста, так как получив ваш пароль злоумышленник легко завладеет базой и сайтом (если IP статичский, второй аспект не актуален).

Решить эту проблему можно через подключение к СУБД по защищенному SSL-протоколу. Популярные СУБД поддерживают SSL (MySQL, PgSQL). Подключение клиента к серверу через SSL поддерживают родные C API этих СУБД, и PHP MySQL/PgSQL API тоже. Но SSL не поддерживается PDO (во всяком случае я не нашел информацию о поддержке), который в настоящее время очень популярен и который следует использовать. По этому вариант подключения к базе через SSL отпадает.

Остается другой, довольно простой для использования и сложный для настройки вариант — перегон трафика между офисом и хостингом через VPN. Сам VPN я уже описывал в своем блоге. После поднятия VPN-тоннеля необходимо прописать роут на IP вашего сервера (того сервера, где находится СУБД) через виртуальный интерфейс VPN-соединения. Таким образом весь трафик между PHP и СУБД будет ходить по безопасному зашифрованному каналу.

Третий нюанс заключается в кэшировании. Часто кэш некоторых элементов заводят пожизненно (или на долгое время), а сбрасывается он только при изменении данных редактором. В этом случае, при внесении изменений на одном из серверов, кэш не сбросится на втором и на неопределенный срок там останется неактуальная информация. Эта проблема решается через изменение стратегии кэширования, либо использование общего сервера кэширования и выходит за рамки данной статьи. Если именно этот вопрос для вас остается актуальным, ищите информацию в гугле, т.к. та же самая проблема существует при балансировке нагрузки путем “размножения” фронэндов.

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

Теперь редакторы сайта смогут пользоваться более быстрой локальной версией сайта, но все изменения будут отображаться в том числе и на сайте в сети.

Теперь рассмотрим преимущества реестра в применении к веб-сайту.

Во-первых, сайт — это по сути обычная многопользовательская система с удаленным доступом. Большинство сайтов имеют собственную пользовательскую подсистему (логин), а случаи доступа незалогиненных пользователей можно рассматривать как гостевой доступ (учетка guest).

Во-вторых, сайту, как и обычному приложению для ОС, требуется где-то хранить ряд своих настроек. Одни из них в процессе жизни сайта не меняются (такие настройки часто устанавливают прямо в коде в виде констант), другие можно менять (в CMS обычно есть страничка “настройки”; примерами таких настроек может служить информационное сообщение на всех страницах сайта или количество записей на одной странице в списках). Третье настройки зависят от текущего пользователя (обычно это какие-либо привилегии, часть которых часто реализуется в системе прав доступа, и персональные установки пользователя).

Настройки всегда касаются либо всего приложения в целом (например, путь к www_root), либо отдельных его компонентов (например, количество новостей в блоке на главной странице).

Когда разложена по полочкам классификация настроек, можно прикинуть предположительную структуру реестра настроек сайта:

• ветвь глобальных настроек приложения, которые касаются всех пользователей;
• ветвь локальных настроек модулей, которые касаются всех пользователей;
• ветвь настроек текущего пользователя (подставляется в зависимости от залогиненного пользователя);
• ветвь настроек пользователя по умолчанию (all users).

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

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

В ветви локальных настроек должны храниться такие настройки, которые нужны исключительно отдельным компонентам сайта, а при отсутствии этих компонентов они не имеют смысла.

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

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

Сделал скрин:

Сегодня вспомнил про старый скрин и решил посмотреть, исправлен ли баг за это время? :)

Оказалось, не исправлен.

Проверил на FF (самый тормозной браузер что дома, что на работе). Ровно то же самое. Скрин не делал — выглядит точно так же, как в опере. В IE не проверил по техническим причинам. Но думаю, эффект будет тот же.