Это зависит от города и стека технологий. Если город не миллионник, или стек не самый попсовый, то удалённых вакансий скорее всего окажется больше, чем офисных.
Так штатный режим заключался в том, что в заранее известную дату компания обращается к нему за тех.поддержкой, он меняет дату и получает оплату. И тут он сам лишил себя возможности поменять дату...
Да всё гораздо проще: когда вас нанимают, чтобы сделать конкретный, заранее оговоренный объём работы за указанный срок и деньги — это фриланс. Офис, удалённо — не суть важно. Во всех остальных случаях — это не фриланс.
Должен, только уже осознанно. Просто инвертируйте условия в предыдущем комментарии и получится:
Писать код, выяснив какова его роль в удовлетворении пользовательской потребности. При сомнениях в архитектурных решениях, обсуждать эти вопросы с архитектором или с CTO, или при их отсутствии с другими сеньорами.
P.S. Роль сеньора — это уже про ответственность по отношению к написанному коду. Поэтому проявления безответственности можно и нужно называть нарушением профессиональной этики.
P.P.S. Кстати, часть пользовательских задач вполне может решиться и без написания кода, когда выяснишь, что по факту нужно. А, как известно, лучший код — ненаписанный код. Такие кейсы, конечно, редко дойдут до сеньора, но с другой стороны не во всех компаниях есть архитекторы.
Можно много разделений придумать, но есть же уже Junior/Middle/Senior.
Если первые 2 могут не понимать что-то из-за нехватки опыта и знаний, то Senior должен быть способен понять и осознанно обсудить задачу, даже если путь её решения уже прописан архитектором или CTO. Тут уже нет места реактивному поведению.
а схему в миддлеваре не проверишь, про неё только бд знает
Миддлвара вполне может спрашивать что-то у сервиса с доступом к БД.
Ну да ладно, не будем вдаваться в детали. Единственное, что я хочу Вам сказать, что жёстко связывать проверку доступа и сами запросы на получение/изменение данных — не очень хорошая идея. И лучше подумать, как развязать эти ответственности (с учётом специфики вашего проекта) до того, как это станет большой проблемой.
Решать задачи на интервью — это уже нарушение профессиональной этики? :)
Смотря, что вы имеете в виду под решением задач.
Писать код, не выяснив какова его роль в удовлетворении пользовательской потребности, — да, нарушение профессиональной этики.
Писать код, который опирается на крайне неподходящую архитектуру, которая не является legacy, а просто потому что так сказали — да, нарушение профессиональной этики.
Если программист перестаёт задаваться вопросами "зачем?" и "почему так?", то ему лучше закрыть редактор кода и больше не открывать.
С другой стороны, вон кто-то и бездумных кодеров ищет, которым скажешь, что города хранятся в массиве и они не удивятся почему, а тупо примут как данность и будут что-то писать xD
Тут широкое пространство для манёвра. Вы ведь можете performance-проблемы раскидать по куску кода самыми разными способами. Какие-то явно будут заметны, даже если кандидат не эксперт по конкретному ЯП, но хотя бы может его читать. Какие-то могут быть с SQL связаны. А если ищете с хорошим знанием конкретного стека, то тут можно и что-нибудь framework-специфичное заложить.
Всякие цепочки построения запросов — это понятно, бывает сплошь и рядом. Но возможность просунуть в них raw SQL должна оставаться, иначе момент, когда ORM начнёт вставлять палки в колёса — лишь вопрос времени.
автоматически на все запросы навешивает права вида
Хм, ну это как-то сильно на любителя. Почему ACL нельзя на уровне контроллеров оставить? Middleware какую-нибудь, которая будет отсекать роуты, которые совсем недоступны, а где нужна более высокая гранулярность — запоминать уровень доступа юзера, репозиториям останется лишь проверять этот уровень, не вмешиваясь в SQL всех запросов подряд. Да в каких-то случаях, типа списка доступных записей, вам придётся записать условие выборки в явном виде, но имхо это только к лучшему.
Так это не типовое тестовое задание. Тут уже есть код, который можно запустить без доп.настройки на готовом сервере. И 1-2 часа, чтобы ускорить этот код. Что успел ускорить, то успел. Поэтому долго не будет.
Фишка еще в том, что запрос формируется не в SQL, а через ORM
Ну, это так себе фишка. Нет никакого оправдания городить днями костыли в угоду ORM для случаев, которые нормально решаются на SQL. Большинство ORM позволяют выполнить raw SQL или использовать его фрагменты в нужных местах. Если ORM этого не позволяет, то следует его отправить на другие 3 буквы ещё до старта проекта.
Если что, ветка про тестовое задание на оптимизацию, как альтернативу тупым задачкам. Или вы ожидаете, что кандидаты будут решать реальные проблемы вашего продакшена за 1 час?
В принципе задание на оптимизацию конкретной выборки — это тоже вариант. Даёте доступ к БД, медленный запрос и задание ускорить выборку. Но если Вы сами потратили 2 дня, то странно будет ожидать, что другой человек справится за 1 час. А если справится, компания готова ему платить в 10-15 раз больше, чем Вам?
В результате выход нашелся, добавил в order by фейковое условие, которое пустило оптимизатор по нужному следу.
Как-то костыльно и хрупко выглядит, где гарантия что после обновления минорной версии MS SQL сохранит нужное вам поведение? Я бы попробовал "сначала через хэш мерж склеить две других таблички" в подзапросе, чтобы у планировщика не было выбора, а потом уже поверх него добавить всё остальное.
У вас в финальном варианте $curr не определён при $n <= 3, и нет проверки что $n > 0
Ну и мемоизацию не помешало бы докрутить, а то нафига всю последовательность пересчитывать при каждом вызове xD
Это не разговор, это фантазии arheops. Вы такой код (завязанный на характеристики конкретных моделей железа) за пару часов не напишете, а если и напишете, то это будет говорить о вас с негативной стороны, если речь не идёт о разработке под микроконтроллеры.
По конфигурации нельзя понять, какой вариант из них имеет место
Можно. Характеристики конкретных моделей никто не скрывает.
Эм, а конфигурацию выписать и приложить к заданию сложно что-ли? Зачем гадать? Да и, по факту, не упрётесь вы в железо в рамках тестового задания. Что вы там собрались оптимизировать за 1-2 часа, чтобы модель процессора влияла на место вашего алгоритма в общей таблице результатов?
Он просто сделает задачку быстро и четко
String.Split(" "), цикл, String.Find()
Вы это в контексте данной задачки считаете решением?
Она же изначально сформулирована не как задача, а как проверка "конформизм vs профессионализм": прогнётся ли человек под вас в стрессовой ситуации, поступится ли профессиональной этикой, начав писать то, что вы просите?
Нет, с физ.лицом возможен и договор подряда. И это тоже будет фриланс, если договор не рамочный.
Размечтались… Их выгода в том, чтобы сделать разработку на Windows более удобной, а не сокращать неудобства запуска Windows-программ под GNU/Linux.
Это зависит от города и стека технологий. Если город не миллионник, или стек не самый попсовый, то удалённых вакансий скорее всего окажется больше, чем офисных.
Так штатный режим заключался в том, что в заранее известную дату компания обращается к нему за тех.поддержкой, он меняет дату и получает оплату. И тут он сам лишил себя возможности поменять дату...
Да всё гораздо проще: когда вас нанимают, чтобы сделать конкретный, заранее оговоренный объём работы за указанный срок и деньги — это фриланс. Офис, удалённо — не суть важно. Во всех остальных случаях — это не фриланс.
Я ещё не понял, если он заранее знал дату срабатывания, зачем он в отпуск то уехал на эту дату?
Должен, только уже осознанно. Просто инвертируйте условия в предыдущем комментарии и получится:
Писать код, выяснив какова его роль в удовлетворении пользовательской потребности. При сомнениях в архитектурных решениях, обсуждать эти вопросы с архитектором или с CTO, или при их отсутствии с другими сеньорами.
P.S. Роль сеньора — это уже про ответственность по отношению к написанному коду. Поэтому проявления безответственности можно и нужно называть нарушением профессиональной этики.
P.P.S. Кстати, часть пользовательских задач вполне может решиться и без написания кода, когда выяснишь, что по факту нужно. А, как известно, лучший код — ненаписанный код. Такие кейсы, конечно, редко дойдут до сеньора, но с другой стороны не во всех компаниях есть архитекторы.
Можно много разделений придумать, но есть же уже Junior/Middle/Senior.
Если первые 2 могут не понимать что-то из-за нехватки опыта и знаний, то Senior должен быть способен понять и осознанно обсудить задачу, даже если путь её решения уже прописан архитектором или CTO. Тут уже нет места реактивному поведению.
Миддлвара вполне может спрашивать что-то у сервиса с доступом к БД.
Ну да ладно, не будем вдаваться в детали. Единственное, что я хочу Вам сказать, что жёстко связывать проверку доступа и сами запросы на получение/изменение данных — не очень хорошая идея. И лучше подумать, как развязать эти ответственности (с учётом специфики вашего проекта) до того, как это станет большой проблемой.
Смотря, что вы имеете в виду под решением задач.
Писать код, не выяснив какова его роль в удовлетворении пользовательской потребности, — да, нарушение профессиональной этики.
Писать код, который опирается на крайне неподходящую архитектуру, которая не является legacy, а просто потому что так сказали — да, нарушение профессиональной этики.
Если программист перестаёт задаваться вопросами "зачем?" и "почему так?", то ему лучше закрыть редактор кода и больше не открывать.
С другой стороны, вон кто-то и бездумных кодеров ищет, которым скажешь, что города хранятся в массиве и они не удивятся почему, а тупо примут как данность и будут что-то писать xD
Тут широкое пространство для манёвра. Вы ведь можете performance-проблемы раскидать по куску кода самыми разными способами. Какие-то явно будут заметны, даже если кандидат не эксперт по конкретному ЯП, но хотя бы может его читать. Какие-то могут быть с SQL связаны. А если ищете с хорошим знанием конкретного стека, то тут можно и что-нибудь framework-специфичное заложить.
Всякие цепочки построения запросов — это понятно, бывает сплошь и рядом. Но возможность просунуть в них raw SQL должна оставаться, иначе момент, когда ORM начнёт вставлять палки в колёса — лишь вопрос времени.
Хм, ну это как-то сильно на любителя. Почему ACL нельзя на уровне контроллеров оставить? Middleware какую-нибудь, которая будет отсекать роуты, которые совсем недоступны, а где нужна более высокая гранулярность — запоминать уровень доступа юзера, репозиториям останется лишь проверять этот уровень, не вмешиваясь в SQL всех запросов подряд. Да в каких-то случаях, типа списка доступных записей, вам придётся записать условие выборки в явном виде, но имхо это только к лучшему.
Так это не типовое тестовое задание. Тут уже есть код, который можно запустить без доп.настройки на готовом сервере. И 1-2 часа, чтобы ускорить этот код. Что успел ускорить, то успел. Поэтому долго не будет.
Ну, это так себе фишка. Нет никакого оправдания городить днями костыли в угоду ORM для случаев, которые нормально решаются на SQL. Большинство ORM позволяют выполнить raw SQL или использовать его фрагменты в нужных местах. Если ORM этого не позволяет, то следует его отправить на другие 3 буквы ещё до старта проекта.
Это "static void Main" сокращенно, для тех, кто помнит что надо написать, но ему лень :-)
Если что, ветка про тестовое задание на оптимизацию, как альтернативу тупым задачкам. Или вы ожидаете, что кандидаты будут решать реальные проблемы вашего продакшена за 1 час?
В принципе задание на оптимизацию конкретной выборки — это тоже вариант. Даёте доступ к БД, медленный запрос и задание ускорить выборку. Но если Вы сами потратили 2 дня, то странно будет ожидать, что другой человек справится за 1 час. А если справится, компания готова ему платить в 10-15 раз больше, чем Вам?
Как-то костыльно и хрупко выглядит, где гарантия что после обновления минорной версии MS SQL сохранит нужное вам поведение? Я бы попробовал "сначала через хэш мерж склеить две других таблички" в подзапросе, чтобы у планировщика не было выбора, а потом уже поверх него добавить всё остальное.
У вас в финальном варианте $curr не определён при
$n <= 3, и нет проверки что$n > 0Ну и мемоизацию не помешало бы докрутить, а то нафига всю последовательность пересчитывать при каждом вызове xD
Это не разговор, это фантазии arheops. Вы такой код (завязанный на характеристики конкретных моделей железа) за пару часов не напишете, а если и напишете, то это будет говорить о вас с негативной стороны, если речь не идёт о разработке под микроконтроллеры.
Можно. Характеристики конкретных моделей никто не скрывает.
Эм, а конфигурацию выписать и приложить к заданию сложно что-ли? Зачем гадать? Да и, по факту, не упрётесь вы в железо в рамках тестового задания. Что вы там собрались оптимизировать за 1-2 часа, чтобы модель процессора влияла на место вашего алгоритма в общей таблице результатов?
Вы это в контексте данной задачки считаете решением?
Она же изначально сформулирована не как задача, а как проверка "конформизм vs профессионализм": прогнётся ли человек под вас в стрессовой ситуации, поступится ли профессиональной этикой, начав писать то, что вы просите?