Про merge и rebase тоже не совсем верно, основная фишка rebase он историю твоих коммитов кладет поверх той ветки, куда делается rebase, из-за чего у всех твоих коммитов изменится хэш, дата коммита останется старой, но дата правок будет текущей. Преимущество такого подхода, то что master может смерджится с этой веткой без merge коммита, через fast-forward и риск получения конфликтов минимален.
Перепутал профайлер с дебагером, называет xhprof приложением, ничего не сказал про кластерный индекс в контексте первичного ключа, ничего не сказал про менеджмент процессов в fpm и даже не попытался рассказать про отличия cgi от fast cgi. Короче, такой себе из тебя сеньер
Соискатель явно знал решение задачи, не видно ход мысли, просто выдал код. Или он гений и задача совсем легкая? Ну и соответственно не оценил сложность задачи (. А еще где тайп-хинтинг, у сеньера она уже автоматом отбивается :D
Я бы на 7 вопрос ответил так: 1-ый вариант: создать таблицу с топ-100 пользователей, 2-ой вариант: добавить в таблицу юзеров индексируемое поле "топ-100"; Насколько это хуже, чем предложенный собеседуемым варианты?
Явно не сеньор. Я бы не доверил ему техлида на серьезном проекте. Иначе будут тратить месяцы и миллионы на монгодб, что бы понять, что в этом нет смысла. Больно так же смотреть код на php7 без psr-12
@NOname-zb5hu я вроде ни про каких конкретных Олеш не говорил по моему опыту, сам по себе фреймворк yii не плох проблемы именно с yii разработчиками, доводилось с несколькими работать и картина плюс-минус одна и та же - низкие хард-скиллы + уверенность в своей правоте, указываешь на откровенный проеб в его коде или архитектуре - но он тебя не понимает, не видит проблем))
Для сеньора вопросы слабоваты. Нет ничего по теории БД - ACID, уровни изоляции транзакций, нормальные формы. Нет хитрых вопросов про ООП, типа "Signature compatibility rules", нет код ревью с характерными ошибками всех спектров. Про устройство и особенности реализации zval тоже ничего. Собеседование на уровень middle-.
@@mgsfdgsfdgsgssdgrsdgdrgsr16 Для джуниора не нужен. А если сеньор совершит глупую ошибку, будет обидно. А он её однажды совершит, если не знает устройство zval.
тут все очень относительно, по мне наверное можно назвать сеньором того, кто хорошо разбирается в построение архитектуры, кто много перепробовал на практике.
В редких компаниях есть четкие критерии оценки (типа Яндекса), в большинстве компаний оценка делается на глазок, а озвучивается с занижением для того чтобы сбить цену спеца
Ну зачем вы в 2024 году сортируете все руками. За вас отсортировали все еще в 60-х годах прошлого века и реализовали вам все сортировки на уровне stl любого языка. Вы точно на проекте будете сортировать все руками, да еще в таких объемах, где важна сложность?
ну, там речь шла о десятках мтллионов записей. возмоюно, на слабеньком сервере сложность для такого случая уже важна. а, хотя 50 ли млн операций или 2.5 * 10^14. какая разница.
На 7 вопрос бы, я бы всегда помнил очки сотого(последнего) пользователя и делал выборку используя это значение, то есть искать все что больше этого значения, включая само значение. Но должно быть условие что очки пользователей не могут уменьшаться, тем самым я уверен что запрос бы ускорялся прилично
Задача по объединению. массивов разве не решается обычным array_merge() ? В том виде, как представлены вводные данные [1,2,3] и [4,5,6] результат будет точно тот же.
