Расходы компании связаны с тем, что стажеру надо всё равно выделить рабочее место, и самое затратное — выделить время квалифицированных сотрудников на то, чтобы проверять его работу, обучать в формате обратной связи, т.е. потратить в разы больше времени, чем требуется, чтобы сделать самому. По сути это скорее инвестиции в расчёте на то, что компания получит джуна, которому можно будет делегировать рутинную работу и в перспективе, может быть, даже мидла.
Бывают, конечно, компании, которые пишут код на выброс. Но в них нет резона задерживаться, на начальных уровнях вы там ничему толком не научитесь, а на высоких уровнях — самому противно будет в таком участвовать.
В приличных компаниях стажёры — это практически чистые расходы (даже если они бесплатно работают), джуниоры — околонулевой финансовый выхлоп, но возможность разгрузить более квалифицированных сотрудников от тривиальных задач. Сами стажеры и джуны с этим, конечно, не согласятся. В их представлении они уже вносят незаменимый вклад, но это банальный эффект Даннинга-Крюгера.
Самые выгодные по финансовому выхлопу на единицу зарплаты — мидлы и начинающие сеньоры. От тех, кто выше, уже процентное отношение прибыли становится меньше, но без них невозможно реализовать сложные проекты.
Стажёры всегда работают за еду и это нормально, они пока своей работой приносят компании больше расходов, чем доходов. И так же обычное дело за первые 3-5 лет карьеры увеличить свой доход в 5-10 раз в рамках одного региона. Автор этот первичный буст связал с переездом, что тоже вариант, но тут нужно учитывать, что переезд, как правило, и расходы увеличивает.
Вижу что можно местами и больше просить, но наглости уже не хватает…
И как вы с этим боретесь? Имхо, тут наглость не причём, просто у каждого есть какой-то психологический рубеж, за которым начинается синдром самозванца.
У меня типичная задача — перевести пожелания стейкхолдеров в архитектуру так, чтобы не убить при этом перформанс. Плюс мониторинг мест, которые превращаются в бутылочное горлышко, и их устранение.
Это зависит от города и стека технологий. Если город не миллионник, или стек не самый попсовый, то удалённых вакансий скорее всего окажется больше, чем офисных.
Так штатный режим заключался в том, что в заранее известную дату компания обращается к нему за тех.поддержкой, он меняет дату и получает оплату. И тут он сам лишил себя возможности поменять дату...
Да всё гораздо проще: когда вас нанимают, чтобы сделать конкретный, заранее оговоренный объём работы за указанный срок и деньги — это фриланс. Офис, удалённо — не суть важно. Во всех остальных случаях — это не фриланс.
Должен, только уже осознанно. Просто инвертируйте условия в предыдущем комментарии и получится:
Писать код, выяснив какова его роль в удовлетворении пользовательской потребности. При сомнениях в архитектурных решениях, обсуждать эти вопросы с архитектором или с 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 буквы ещё до старта проекта.
Расходы компании связаны с тем, что стажеру надо всё равно выделить рабочее место, и самое затратное — выделить время квалифицированных сотрудников на то, чтобы проверять его работу, обучать в формате обратной связи, т.е. потратить в разы больше времени, чем требуется, чтобы сделать самому. По сути это скорее инвестиции в расчёте на то, что компания получит джуна, которому можно будет делегировать рутинную работу и в перспективе, может быть, даже мидла.
Бывают, конечно, компании, которые пишут код на выброс. Но в них нет резона задерживаться, на начальных уровнях вы там ничему толком не научитесь, а на высоких уровнях — самому противно будет в таком участвовать.
В приличных компаниях стажёры — это практически чистые расходы (даже если они бесплатно работают), джуниоры — околонулевой финансовый выхлоп, но возможность разгрузить более квалифицированных сотрудников от тривиальных задач. Сами стажеры и джуны с этим, конечно, не согласятся. В их представлении они уже вносят незаменимый вклад, но это банальный эффект Даннинга-Крюгера.
Самые выгодные по финансовому выхлопу на единицу зарплаты — мидлы и начинающие сеньоры. От тех, кто выше, уже процентное отношение прибыли становится меньше, но без них невозможно реализовать сложные проекты.
Стажёры всегда работают за еду и это нормально, они пока своей работой приносят компании больше расходов, чем доходов. И так же обычное дело за первые 3-5 лет карьеры увеличить свой доход в 5-10 раз в рамках одного региона. Автор этот первичный буст связал с переездом, что тоже вариант, но тут нужно учитывать, что переезд, как правило, и расходы увеличивает.
Ахах, ну я, кстати, подумал, что можно нолик приписать для получения верхней границы. Так и получилось.
И как вы с этим боретесь? Имхо, тут наглость не причём, просто у каждого есть какой-то психологический рубеж, за которым начинается синдром самозванца.
Странно, что конкретные суммы, а не диапазоны.
У меня типичная задача — перевести пожелания стейкхолдеров в архитектуру так, чтобы не убить при этом перформанс. Плюс мониторинг мест, которые превращаются в бутылочное горлышко, и их устранение.
Нет, с физ.лицом возможен и договор подряда. И это тоже будет фриланс, если договор не рамочный.
Размечтались… Их выгода в том, чтобы сделать разработку на 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 буквы ещё до старта проекта.