Backend: C#, .NET, MS SQL — серьёзный стек, требующий хотя бы минимального продакшен-опыта. Frontend: Vue.js, JavaScript — фронтенд, желательно красиво и с адаптивом. Mobile: Kotlin («в том числе учебные проекты») — значит ещё и андроид-разработку надо осиливать. B2B и B2C: То есть реальный бизнес, а не «песочницы». Система аналитики и отчётности: это уже намёк на BI или хотя бы работу с графиками, дашбордами, отчётами, что требует аналитического подхода и понимания бизнеса.
возьмем часть про анализ вакансии
Первое - обычный стек и ожидания - джун должен быть с ним знаком, ни слова в вакансии про продакшен опыт нет
Котлин - необычное требование, но сразу сказано что учебные проекты это окей, что соответствует джуну
B2B B2C и системы аналитики - это не требования, а обязанности - то, чем все на работе и занимаются
В общем нормальная вакансия для джуна (ну кроме зарплаты), что не так?
Если вчитаться в детали, в статье полно таких проблем.
Ставка была не за час, а за студента в группе в месяц, я вел группы. Переводил в час в уме сам. Глянул записи: 45к - 65к в месяц при нагрузке часа 4 в неделю. Правда, конечно, первые месяцы нагрузка была сильно выше, пока ты знакомишься с курсом сам.
наставники становятся крайними — и получают за свою работу сущие копейки
Я был ментором по питону в 21-22 годах, парт-тайм. Шел ради идеи, но в итоге ставка в пересчете на рабочий час - соизмерима со ставкой тимлида. От окружающих слышал такие же истории про то, что это достаточно выгодно. Поэтому хзхз
она основана на ложном допущении, что вместо того чтобы убирать необходимость постоянно погружаться в детали реализации, лучше облегчить возможность такого погружения.
не совсем так, но близко я согласен что правильнее и эффективнее. Просто на практике я почти никогда этого не видел. Постоянно добавляя фичи или в процессе дебага мне приходится разворачивать все уровни абстракций. Код не идеален и никогда не будет идеальным. То есть то, что вы описываете - будет работать, но только при высоком качестве кода. Которого почти нигде нет, потому что люди не идеальны и ошибаются. В итоге получаем то, что получаем.
так и в статье, и я говорю ровно об этом - в большинстве задач эта дополнительная сложность не требуется
но конечно есть проекты, где требуется. Если вы реализуете такой - вы почти всегда это заранее знаете и подходить нужно иначе. Но такие проекты - скорее исключение в индустрии.
Считаю что нет, любой дополнительный элемент (а в нашем случае слой абстракции) - увеличивает сложность. В каких-то случаях оно окупается.
Плохо продуманная абстракция, конечно добавляет сложности больше, чем хорошо продуманная.
Что до держания в голове реализации - это ведь не так? Когда реализация не важна, ты смотришь только сигнатуры, а это по сути тот же интерфейс. В обратном же случае - всегда, сталкиваясь с интерфейсом, приходится смотреть, помнить и проверить, что у него могут быть больше одной реализации.
да, такой есть плюс, но актуален ли он где-либо? Автор говорит о том, что почти всегда нет. Мой лично опыт такой же - почти никогда ничего никто не переиспользуется. Соответственно не оверинжиниринг ли предусматривать возможность переиспользования того, что не будет переиспользоваться?
проблема в когнитивной сложности, она растет с каждым новым элементом. Это тот самый налог из статьи. И абстракции это одни из самых больших вкладов в когнитивную сложность. А все-таки код мы больше читаем, чем пишем.
И я подумал еще про привычку - я не раз видел, что абстракции использовались там, где например композиция была бы заметно проще. Думаю потому, что люди привыкает использовать такой абстракции и делают это автоматически. Проект полон абстракций -> все к ним привыкают -> они появляются еще чаще тк это привычный паттерн -> код становится еще сложне.
Часть аргументов очень сомнительная. А оставшаяся - крайние случаи. Да, так бывает, но так в любой профессии - бывают крайние неприятный случаи и они разные. В среднем же профессия/специальность о другом
а тимлидам сложнее, ведь позиций для них на рынке мало, а для обычных ролей требуются хард-скиллы, которые вы утратили.
по моему опыту - намного сложнее найти тимлида, чем сеньора, на открытом рынке. Думаю можно поднять статистику где-нибудь по скорости закрытия позиций
Самое забавное, что тимлидство редко приносит значительное увеличение зарплаты по сравнению с обычной позицией сеньора.
вопрос что значит "значительнее", но обычно вилки выше там, где выше ответственность. И с лидами так же. Но становиться лидом - не единственный способ расти в зарплате
Чем дольше тимлид работает, тем сильнее он привязывается к специфическим процессам своего текущего работодателя. Он начинает выполнять задачи, нужные только внутри компании, и нигде больше на рынке.
это намного более выражено у инженеров, тк какая-то специфичная технология одной компании - частая штука. А у лида что такое может быть, мне даже сходу сложно придумать.
Потеря хард-скиллов
это задумано по-умолчанию, ты переходишь в ветку другую - получаешь новые скилы, теряешь старые. В совокупности широкий опыт как по мне, выгоднее, чем узкоспециализированный
Если вдуматься в идею без деталей (уровня зарплаты и условий) - она ведь крутая. Это классика, что посредник берет на себя риски, облегчая жизнь обоим сторонам, получая за это деньги. Так работают риелторы, агрегаторы, аутсорс и тд и тп.
Детали грустные, но обсуждать их сейчас думаю нет смысла - чуваки запускают закрытый эксперимент, видимо ищут работающие варианты. Интересно посмотреть на условия с обоих сторон, когда это полноценно запустится. И на то как оно будет работать -- тот же метод отбора, потому что действительно есть риски
Что до последних тезисов - если про "менторство с оплатой после трудоустройства" еще можно подискутировать. Менторство это замечательно, но фокус на результате сдвигает работу в сторону от обучения. То "накрутка опыта" и "шадоу‑мод" - неэтично и надеюсь никогда с такими людьми не встречусь.
приглашения на собеседования в офис, это, вообще, полный треш в такое время. Когда на дню по 5-10 собеседований может проходить
Мне кажется это вполне логично, если это офлайн работа. Хотя со времен ковида и звучит странно. Я сам бы был не против сходить в офис в компанию, где действительно хочу работать.
Частенько просят включить вебку.
когда видишь человека - его лучше понимаешь и это работает в обе стороны. Считаю это поведением по-умолчанию, очень удивлюсь кандидату без камеры.
Был со стороны найма в одной из таких компаний. Есть плюсы - ты видишь этапы собеседований кандидата от разных участников и картинка становится более объективной. Не идеально конечно, но всё же Минусы - долгий найм (а тебе нужен человек в команду уже сейчас), не всем нравится и проч, что в общем в статье и описано
Но хз, не согласен с выводом что это для экономии. Имхо основная цель - выравнивание ожиданий по компании в том, что такое middle инженер например. Хз стоит ли оно того
Согласен в целом с позицией, и сам был лидом и пишущим код, и не пишущим. Но при этом не со всеми аргументами согласен. Лид, который не пишет код != лид без технической квалификации. Часть поднятых проблем касается только второго, но не первого.
второе - да, это добавляет и сложности в работу, и стресса. А еще надо уметь игнорировать часть таких проблем, и правильно угадывать какую часть нужно игнорировать) Просто я бы не назвал это минусом)
Как-то очень поверхностно, по заголовку ожидал чего-то совсем другого
Вакансии и деньги
Мой личный опыт конечно лишь одна точка, но найти лида намного сложнее, чем инженера. Кандидатов почти нет. Проверял на python lead и qa lead в РФ в любом городе
Теперь нет не ваших проблем
Не понимаю тут минуса. По-моему это как "минус позиции разработчика - писать код". Это же основная суть позиции.
Роль наставника на курсах — это далеко не то же самое, что быть наставником джуна на работе. На курсы часто приходят люди немотивированные, ожидающие легких денег в IT. Уверен, кто‑то находит себя в этом ремесле. Я же решил, что буду работать только с мотивированными и осознанными разработчиками.
Считаю, что слишком большое обобщение, но думаю зависит от курсов. Около года я был ментором на курсах по питону для начинающих - и в среднем студенты были или "норм", или заметно мотивированные. Но тут видимо зависит больше от школы и того, как она продает. Вайба легких денег ни разу не заметил ни у кого.
Если говорить о наставничестве как о способе заработать, то тоже нет. Наставникам платят откровенно копейки. Видимо, все ушло на маркетинг ? Чтобы заработать обещанные 150к, нужно было бы бросать основную работу.
И тут у меня было иначе - в пересчете на час выходило соизмеримо с зп сениора/лида. После онбординга и того, как я весь курс сам осознал) Но тут возможно мой личный кейс скорости работы.
Отличная статья и опыт, спасибо
один вопрос возник при чтении
а точно ли аудитория, что читала ваши релизы - это ЦА? Ну то есть можно ли верить этой обратной связи
Отличная статья, спасибо!
Странная статья
возьмем часть про анализ вакансии
Первое - обычный стек и ожидания - джун должен быть с ним знаком, ни слова в вакансии про продакшен опыт нет
Котлин - необычное требование, но сразу сказано что учебные проекты это окей, что соответствует джуну
B2B B2C и системы аналитики - это не требования, а обязанности - то, чем все на работе и занимаются
В общем нормальная вакансия для джуна (ну кроме зарплаты), что не так?
Если вчитаться в детали, в статье полно таких проблем.
Ставка была не за час, а за студента в группе в месяц, я вел группы. Переводил в час в уме сам. Глянул записи: 45к - 65к в месяц при нагрузке часа 4 в неделю.
Правда, конечно, первые месяцы нагрузка была сильно выше, пока ты знакомишься с курсом сам.
Я был ментором по питону в 21-22 годах, парт-тайм. Шел ради идеи, но в итоге ставка в пересчете на рабочий час - соизмерима со ставкой тимлида.
От окружающих слышал такие же истории про то, что это достаточно выгодно.
Поэтому хзхз
Очень крутой проект! Спасибо за вашу работу
не совсем так, но близко
я согласен что правильнее и эффективнее. Просто на практике я почти никогда этого не видел. Постоянно добавляя фичи или в процессе дебага мне приходится разворачивать все уровни абстракций.
Код не идеален и никогда не будет идеальным. То есть то, что вы описываете - будет работать, но только при высоком качестве кода. Которого почти нигде нет, потому что люди не идеальны и ошибаются. В итоге получаем то, что получаем.
так и в статье, и я говорю ровно об этом - в большинстве задач эта дополнительная сложность не требуется
но конечно есть проекты, где требуется. Если вы реализуете такой - вы почти всегда это заранее знаете и подходить нужно иначе. Но такие проекты - скорее исключение в индустрии.
Считаю что нет, любой дополнительный элемент (а в нашем случае слой абстракции) - увеличивает сложность. В каких-то случаях оно окупается.
Плохо продуманная абстракция, конечно добавляет сложности больше, чем хорошо продуманная.
Что до держания в голове реализации - это ведь не так? Когда реализация не важна, ты смотришь только сигнатуры, а это по сути тот же интерфейс.
В обратном же случае - всегда, сталкиваясь с интерфейсом, приходится смотреть, помнить и проверить, что у него могут быть больше одной реализации.
да, такой есть плюс, но актуален ли он где-либо? Автор говорит о том, что почти всегда нет. Мой лично опыт такой же - почти никогда ничего никто не переиспользуется. Соответственно не оверинжиниринг ли предусматривать возможность переиспользования того, что не будет переиспользоваться?
проблема в когнитивной сложности, она растет с каждым новым элементом. Это тот самый налог из статьи. И абстракции это одни из самых больших вкладов в когнитивную сложность. А все-таки код мы больше читаем, чем пишем.
И я подумал еще про привычку - я не раз видел, что абстракции использовались там, где например композиция была бы заметно проще. Думаю потому, что люди привыкает использовать такой абстракции и делают это автоматически. Проект полон абстракций -> все к ним привыкают -> они появляются еще чаще тк это привычный паттерн -> код становится еще сложне.
Часть аргументов очень сомнительная. А оставшаяся - крайние случаи. Да, так бывает, но так в любой профессии - бывают крайние неприятный случаи и они разные. В среднем же профессия/специальность о другом
по моему опыту - намного сложнее найти тимлида, чем сеньора, на открытом рынке. Думаю можно поднять статистику где-нибудь по скорости закрытия позиций
вопрос что значит "значительнее", но обычно вилки выше там, где выше ответственность. И с лидами так же. Но становиться лидом - не единственный способ расти в зарплате
это намного более выражено у инженеров, тк какая-то специфичная технология одной компании - частая штука.
А у лида что такое может быть, мне даже сходу сложно придумать.
это задумано по-умолчанию, ты переходишь в ветку другую - получаешь новые скилы, теряешь старые. В совокупности широкий опыт как по мне, выгоднее, чем узкоспециализированный
ну и тд
Прочитал статью - дичь какая-то често сказать.
Если вдуматься в идею без деталей (уровня зарплаты и условий) - она ведь крутая. Это классика, что посредник берет на себя риски, облегчая жизнь обоим сторонам, получая за это деньги. Так работают риелторы, агрегаторы, аутсорс и тд и тп.
Детали грустные, но обсуждать их сейчас думаю нет смысла - чуваки запускают закрытый эксперимент, видимо ищут работающие варианты. Интересно посмотреть на условия с обоих сторон, когда это полноценно запустится. И на то как оно будет работать -- тот же метод отбора, потому что действительно есть риски
Что до последних тезисов - если про "менторство с оплатой после трудоустройства" еще можно подискутировать. Менторство это замечательно, но фокус на результате сдвигает работу в сторону от обучения.
То "накрутка опыта" и "шадоу‑мод" - неэтично и надеюсь никогда с такими людьми не встречусь.
Мне кажется это вполне логично, если это офлайн работа. Хотя со времен ковида и звучит странно. Я сам бы был не против сходить в офис в компанию, где действительно хочу работать.
когда видишь человека - его лучше понимаешь и это работает в обе стороны. Считаю это поведением по-умолчанию, очень удивлюсь кандидату без камеры.
Был со стороны найма в одной из таких компаний.
Есть плюсы - ты видишь этапы собеседований кандидата от разных участников и картинка становится более объективной. Не идеально конечно, но всё же
Минусы - долгий найм (а тебе нужен человек в команду уже сейчас), не всем нравится и проч, что в общем в статье и описано
Но хз, не согласен с выводом что это для экономии. Имхо основная цель - выравнивание ожиданий по компании в том, что такое middle инженер например. Хз стоит ли оно того
хочу просто написать - имхо вы задаете правильные вопросы
статья на эмоциях читается довольно однозначно - компания плохая, обманула. Но для объективности нужен и взгляд с другой стороны.
Согласен в целом с позицией, и сам был лидом и пишущим код, и не пишущим.
Но при этом не со всеми аргументами согласен.
Лид, который не пишет код != лид без технической квалификации. Часть поднятых проблем касается только второго, но не первого.
второе - да, это добавляет и сложности в работу, и стресса. А еще надо уметь игнорировать часть таких проблем, и правильно угадывать какую часть нужно игнорировать)
Просто я бы не назвал это минусом)
Как-то очень поверхностно, по заголовку ожидал чего-то совсем другого
Мой личный опыт конечно лишь одна точка, но найти лида намного сложнее, чем инженера. Кандидатов почти нет. Проверял на python lead и qa lead в РФ в любом городе
Не понимаю тут минуса. По-моему это как "минус позиции разработчика - писать код". Это же основная суть позиции.
Жаль видеть такие выводы
Считаю, что слишком большое обобщение, но думаю зависит от курсов. Около года я был ментором на курсах по питону для начинающих - и в среднем студенты были или "норм", или заметно мотивированные. Но тут видимо зависит больше от школы и того, как она продает. Вайба легких денег ни разу не заметил ни у кого.
И тут у меня было иначе - в пересчете на час выходило соизмеримо с зп сениора/лида. После онбординга и того, как я весь курс сам осознал) Но тут возможно мой личный кейс скорости работы.