Про merge и rebase тоже не совсем верно, основная фишка rebase он историю твоих коммитов кладет поверх той ветки, куда делается rebase, из-за чего у всех твоих коммитов изменится хэш, дата коммита останется старой, но дата правок будет текущей. Преимущество такого подхода, то что master может смерджится с этой веткой без merge коммита, через fast-forward и риск получения конфликтов минимален.
Я бы на 7 вопрос ответил так: 1-ый вариант: создать таблицу с топ-100 пользователей, 2-ой вариант: добавить в таблицу юзеров индексируемое поле "топ-100"; Насколько это хуже, чем предложенный собеседуемым варианты?
Соискатель явно знал решение задачи, не видно ход мысли, просто выдал код. Или он гений и задача совсем легкая? Ну и соответственно не оценил сложность задачи (. А еще где тайп-хинтинг, у сеньера она уже автоматом отбивается :D
На 7 вопрос бы, я бы всегда помнил очки сотого(последнего) пользователя и делал выборку используя это значение, то есть искать все что больше этого значения, включая само значение. Но должно быть условие что очки пользователей не могут уменьшаться, тем самым я уверен что запрос бы ускорялся прилично
тут все очень относительно, по мне наверное можно назвать сеньором того, кто хорошо разбирается в построение архитектуры, кто много перепробовал на практике.
В редких компаниях есть четкие критерии оценки (типа Яндекса), в большинстве компаний оценка делается на глазок, а озвучивается с занижением для того чтобы сбить цену спеца
Явно не сеньор. Я бы не доверил ему техлида на серьезном проекте. Иначе будут тратить месяцы и миллионы на монгодб, что бы понять, что в этом нет смысла. Больно так же смотреть код на php7 без psr-12
Перепутал профайлер с дебагером, называет xhprof приложением, ничего не сказал про кластерный индекс в контексте первичного ключа, ничего не сказал про менеджмент процессов в fpm и даже не попытался рассказать про отличия cgi от fast cgi. Короче, такой себе из тебя сеньер
Ну зачем вы в 2024 году сортируете все руками. За вас отсортировали все еще в 60-х годах прошлого века и реализовали вам все сортировки на уровне stl любого языка. Вы точно на проекте будете сортировать все руками, да еще в таких объемах, где важна сложность?
ну, там речь шла о десятках мтллионов записей. возмоюно, на слабеньком сервере сложность для такого случая уже важна. а, хотя 50 ли млн операций или 2.5 * 10^14. какая разница.
@NOname-zb5hu я вроде ни про каких конкретных Олеш не говорил по моему опыту, сам по себе фреймворк yii не плох проблемы именно с yii разработчиками, доводилось с несколькими работать и картина плюс-минус одна и та же - низкие хард-скиллы + уверенность в своей правоте, указываешь на откровенный проеб в его коде или архитектуре - но он тебя не понимает, не видит проблем))
Про merge и rebase тоже не совсем верно, основная фишка rebase он историю твоих коммитов кладет поверх той ветки, куда делается rebase, из-за чего у всех твоих коммитов изменится хэш, дата коммита останется старой, но дата правок будет текущей. Преимущество такого подхода, то что master может смерджится с этой веткой без merge коммита, через fast-forward и риск получения конфликтов минимален.
уже подумал, что на вопрос чем отличается мердж от ребейза, тоже будет ответ "надо эксперементировать" :D
Primary key тоже может быть составным. Например в таблице много ко многим
да точно
Я бы на 7 вопрос ответил так: 1-ый вариант: создать таблицу с топ-100 пользователей, 2-ой вариант: добавить в таблицу юзеров индексируемое поле "топ-100"; Насколько это хуже, чем предложенный собеседуемым варианты?
тут главное проверить метрики и если время обработки ускорится, то задача решена
создавать индексы в таблицу с интенсивной записью стремно, индекс будет постоянно перестраиваться и будет теряться производительность при записи
Соискатель явно знал решение задачи, не видно ход мысли, просто выдал код. Или он гений и задача совсем легкая? Ну и соответственно не оценил сложность задачи (.
А еще где тайп-хинтинг, у сеньера она уже автоматом отбивается :D
Задача на самом деле крайне лёгкая, не синьерская.
@@АртемВирский да-да зато на систем дизайне вы пук-среньк(
Он 100% откуда-то переписал готовое решение. Вот эти хитрые условия в while, подсчёт остатков и всякие посткременты сходу просто так не пишутся.
На 7 вопрос бы, я бы всегда помнил очки сотого(последнего) пользователя и делал выборку используя это значение, то есть искать все что больше этого значения, включая само значение. Но должно быть условие что очки пользователей не могут уменьшаться, тем самым я уверен что запрос бы ускорялся прилично
мм, то есть хотя бы разок придется запустить запрос на получения топ-100 и хранить сотого в кеше?
а кто сказал, что число в критерии не может уменшаться?
Может сделать отдельную табличку для топ-100 и обновлять её при изменении количества очков игроков?
А по каким конкретно критериям Вы определяете, является ли этот разработчик middle или senior?
тут все очень относительно, по мне наверное можно назвать сеньором того, кто хорошо разбирается в построение архитектуры, кто много перепробовал на практике.
по критерию "мне похуй, я так чувствую"
В редких компаниях есть четкие критерии оценки (типа Яндекса), в большинстве компаний оценка делается на глазок, а озвучивается с занижением для того чтобы сбить цену спеца
Явно не сеньор. Я бы не доверил ему техлида на серьезном проекте. Иначе будут тратить месяцы и миллионы на монгодб, что бы понять, что в этом нет смысла. Больно так же смотреть код на php7 без psr-12
Перепутал профайлер с дебагером, называет xhprof приложением, ничего не сказал про кластерный индекс в контексте первичного ключа, ничего не сказал про менеджмент процессов в fpm и даже не попытался рассказать про отличия cgi от fast cgi. Короче, такой себе из тебя сеньер
10:25 зачем в конструкторе делать присваивание свойства?
Достаточно его указать в аргументах конструктора и произойдет магия, биндинг.
ещё и без интерфейса указал или впрямую типа
Это вы в модных php 8 версиях увидели. А человек мог прийти с какого-нибудь проекта с php 7
Это точно на сеньера? Вопросы, как из универа.
а были на реальных собеседованиях сеньоров ?? как представляете вопросы там ?
Ну зачем вы в 2024 году сортируете все руками. За вас отсортировали все еще в 60-х годах прошлого века и реализовали вам все сортировки на уровне stl любого языка. Вы точно на проекте будете сортировать все руками, да еще в таких объемах, где важна сложность?
ну, там речь шла о десятках мтллионов записей. возмоюно, на слабеньком сервере сложность для такого случая уже важна. а, хотя 50 ли млн операций или 2.5 * 10^14. какая разница.
Я бы сказал что соискатель тянет на крепкого джуна, а интервьюер вообще не в теме (просто говорящая голова).
Не хотелось бы устраиваться к Вам на работу
user_sex)) Вообще-то, есть общепринятое gender.
Это теперь разные понятия. Пола всего два, а вот гендеров 200+ уже 8)
yii синьор = джун на симфони
@NOname-zb5hu я вроде ни про каких конкретных Олеш не говорил
по моему опыту, сам по себе фреймворк yii не плох
проблемы именно с yii разработчиками, доводилось с несколькими работать и картина плюс-минус одна и та же - низкие хард-скиллы + уверенность в своей правоте, указываешь на откровенный проеб в его коде или архитектуре - но он тебя не понимает, не видит проблем))
Гон.