уже подумал, что на вопрос чем отличается мердж от ребейза, тоже будет ответ "надо эксперементировать" :D

Primary key тоже может быть составным. Например в таблице много ко многим

Про merge и rebase тоже не совсем верно, основная фишка rebase он историю твоих коммитов кладет поверх той ветки, куда делается rebase, из-за чего у всех твоих коммитов изменится хэш, дата коммита останется старой, но дата правок будет текущей. Преимущество такого подхода, то что master может смерджится с этой веткой без merge коммита, через fast-forward и риск получения конфликтов минимален.

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

Задача по объединению. массивов разве не решается обычным array_merge() ? В том виде, как представлены вводные данные [1,2,3] и [4,5,6] результат будет точно тот же.

10:25 зачем в конструкторе делать присваивание свойства? Достаточно его указать в аргументах конструктора и произойдет магия, биндинг.

А по каким конкретно критериям Вы определяете, является ли этот разработчик middle или senior?

Соискатель явно знал решение задачи, не видно ход мысли, просто выдал код. Или он гений и задача совсем легкая? Ну и соответственно не оценил сложность задачи (. А еще где тайп-хинтинг, у сеньера она уже автоматом отбивается :D

yii синьор = джун на симфони

Для сеньора вопросы слабоваты. Нет ничего по теории БД - ACID, уровни изоляции транзакций, нормальные формы. Нет хитрых вопросов про ООП, типа "Signature compatibility rules", нет код ревью с характерными ошибками всех спектров. Про устройство и особенности реализации zval тоже ничего. Собеседование на уровень middle-.

user_sex)) Вообще-то, есть общепринятое gender.