Рынок труда в ИТ действительно сжался, но и спрос сместился — теперь нужны не просто «трудолюбивые новички», а быстрообучаемые, самостоятельные и многофункциональные ребята, даже на старте. Тех, кого сократили, компании тоже разбирают выборочно: не всех, а тех, кто вписывается в новый бюджет и умеет работать в условиях ограничений.
У джуна здесь есть мощное преимущество перед сеньорами: он дешевле и часто готов на задачи, которые опытные специалисты считают не своим уровнем. Если джун показывает, что может быстро учиться, не боится рутины (в том числе с ИИ) и уже имеет хотя бы пет-проекты — его возьмут не вместо сеньора, конечно, а на параллельную позицию, куда опытному специалисту идти уже невыгодно
В основном, малый и средний бизнес, стартапы и студии, где меньше бюрократии и больше нужды в гибких руках. Крупные компании экономят, но аутсорсеры иногда берут под проекты с менторами. А в малом и среднем джуны окупаются за 3–6 месяцев реальными тасками. Если стек востребованный (JS/Python), шансы растут
Действительно, это так. И в этом есть парадокс. Мы рекомендуем сместить фокус с «написания кода» на «решение проблемы».
Учитесь не просто на курсах с типовыми TODO-листами, а на реальных продуктах. Выберите опенсорс-проект, который вам интересен, изучите его issues (особенно с labels «bug» или «enhancement»). Попробуйте разобраться в кодовой базе и предложите фикс.
Это и будет решением «сложной» задачи — нужно понять чужой контекст, архитектуру, договориться с мейнтейнерами. Именно этот навык — разбираться в неизвестном — и ценится.
Ментором на этом этапе может стать комьюнити, код-ревью в пулл-реквесте и собственное упорство
Проактивность и командную работу можно прокачивать соло или в «виртуальных» командах — без полноценной компании. Начните с опенсорса на GitHub: ищите issues с меткой good first issue, коммитьте, решайте мёрдж-конфликты, общайтесь в PR-ревью. Это даёт опыт фидбека, дедлайнов и коллаборации с незнакомцами.
Ещё можно попробовать хакатоны и митапы: там вы в команде 48 часов, распределяете роли, толкаете фичи под давлением. Помним и про волонтёрство.
2–3 месяца, и на собесе видно, что вы не только теорией владеете.
Практически нет. Действительно, курсы дают скорость и харды, не делая упор на софтах. Но их догоняют практикой в команде. Так что если есть желание и мотивация развивать софты — всё получится
Согласны, куча мелких коммитов в main усложняют чтение истории. Можно перед Pull Request выполнить git rebase -i HEAD~10 и объединить их в 1-2 содержательных коммита. Или настроить в GitHub опцию Squash and merge — история останется чистой
Всё-таки для force push лучше revert, чтобы не ломать историю команды. Но про Reflog отличный совет, спасибо) добавим в обновление. git reflog покажет все действия за сессию, git reset --hard <хеш> вернёт состояние
Conventional Commits внедряем через шаблоны в GitHub (.github/pull_request_template.md) и хуки pre-commit. Плюс, мы обычно проводим код-ревью с фидбеком — так что все уже привыкли
Понятно, что в моменте это кажется излишней душнотой, но полное описание коммита — некая инвестиция в будущее. Через год, когда нужно будет найти «когда мы добавили ту кнопку», «фикс» нам не скажет ничего. Мы, например, пишем: «fix: убрали дублирование кнопки в футере»
Вообще, сложнее, чем хотелось бы. Если уже запушили — используйте git revert хеш_коммита, чтобы создать новый коммит, который удалит пароли. Если ещё локально — git reset HEAD~1, отредактируйте файл и сделайте новый коммит
Тут и правда есть такой стажерский вайб Вообще, если хорошо знаешь проект, то быстрее действительно написать тест руками — ИИ тут не волшебная палочка. Cursor не экономит время на простых кейсах, но выручает, когда нужно быстро покрыть тестами большой кусок кода, особенно незнакомый или с кучей зависимостей
Да, в проектах на Kotlin Cursor реально может пойти вразнос, если дать ему слишком широкое задание без ограничений. Он не всегда корректно учитывает паттерны типа MVVM или Clean Architecture — особенно при многослойных структурах.
В общем, лучше задавать максимально чёткий контекст и явно описывать, какие файлы менять можно, а какие нет
С безопасностью всё ок: в обычном облачном режиме часть контекста уходит на сервера. Для строгой политики безопасности есть on-premise — можно держать всё у себя и полностью отключить внешние соединения
Рынок труда в ИТ действительно сжался, но и спрос сместился — теперь нужны не просто «трудолюбивые новички», а быстрообучаемые, самостоятельные и многофункциональные ребята, даже на старте. Тех, кого сократили, компании тоже разбирают выборочно: не всех, а тех, кто вписывается в новый бюджет и умеет работать в условиях ограничений.
У джуна здесь есть мощное преимущество перед сеньорами: он дешевле и часто готов на задачи, которые опытные специалисты считают не своим уровнем. Если джун показывает, что может быстро учиться, не боится рутины (в том числе с ИИ) и уже имеет хотя бы пет-проекты — его возьмут не вместо сеньора, конечно, а на параллельную позицию, куда опытному специалисту идти уже невыгодно
В основном, малый и средний бизнес, стартапы и студии, где меньше бюрократии и больше нужды в гибких руках. Крупные компании экономят, но аутсорсеры иногда берут под проекты с менторами. А в малом и среднем джуны окупаются за 3–6 месяцев реальными тасками. Если стек востребованный (JS/Python), шансы растут
Действительно, это так. И в этом есть парадокс. Мы рекомендуем сместить фокус с «написания кода» на «решение проблемы».
Учитесь не просто на курсах с типовыми TODO-листами, а на реальных продуктах. Выберите опенсорс-проект, который вам интересен, изучите его issues (особенно с labels «bug» или «enhancement»). Попробуйте разобраться в кодовой базе и предложите фикс.
Это и будет решением «сложной» задачи — нужно понять чужой контекст, архитектуру, договориться с мейнтейнерами. Именно этот навык — разбираться в неизвестном — и ценится.
Ментором на этом этапе может стать комьюнити, код-ревью в пулл-реквесте и собственное упорство
Проактивность и командную работу можно прокачивать соло или в «виртуальных» командах — без полноценной компании. Начните с опенсорса на GitHub: ищите issues с меткой good first issue, коммитьте, решайте мёрдж-конфликты, общайтесь в PR-ревью. Это даёт опыт фидбека, дедлайнов и коллаборации с незнакомцами.
Ещё можно попробовать хакатоны и митапы: там вы в команде 48 часов, распределяете роли, толкаете фичи под давлением. Помним и про волонтёрство.
2–3 месяца, и на собесе видно, что вы не только теорией владеете.
Практически нет. Действительно, курсы дают скорость и харды, не делая упор на софтах. Но их догоняют практикой в команде. Так что если есть желание и мотивация развивать софты — всё получится
зависит от компании) если инхаус-проект, то да - убирают тех, кто много зарабатывает. Если аутсорс, то всех, кто на бенче - тут нет дела до грейда.
Согласны, куча мелких коммитов в main усложняют чтение истории. Можно перед Pull Request выполнить git rebase -i HEAD~10 и объединить их в 1-2 содержательных коммита. Или настроить в GitHub опцию Squash and merge — история останется чистой
😁😁😁
Всё-таки для force push лучше revert, чтобы не ломать историю команды. Но про Reflog отличный совет, спасибо) добавим в обновление. git reflog покажет все действия за сессию, git reset --hard <хеш> вернёт состояние
Conventional Commits внедряем через шаблоны в GitHub (.github/pull_request_template.md) и хуки pre-commit. Плюс, мы обычно проводим код-ревью с фидбеком — так что все уже привыкли
Git blame <файл> покажет автора строки с хешем. Тыкнете хеш — откроется коммит с @author. Интегрируем с Jira через GitHub apps для трекинга
Понятно, что в моменте это кажется излишней душнотой, но полное описание коммита — некая инвестиция в будущее. Через год, когда нужно будет найти «когда мы добавили ту кнопку», «фикс» нам не скажет ничего.
Мы, например, пишем: «fix: убрали дублирование кнопки в футере»
Вообще, сложнее, чем хотелось бы. Если уже запушили — используйте git revert хеш_коммита, чтобы создать новый коммит, который удалит пароли. Если ещё локально — git reset HEAD~1, отредактируйте файл и сделайте новый коммит
говорят, поколение альфа сейчас использует 4 пальца, чтобы давить на кнопки. вся надежда на них
Хоронят наш любимый Flutter действительно ежегодно, спасибо автору, что поднимает снова эту тему. В прошлом году делали подобный ресерч.
Ответим в отдельной статье, спасибо за вопрос.
Тут и правда есть такой стажерский вайб
Вообще, если хорошо знаешь проект, то быстрее действительно написать тест руками — ИИ тут не волшебная палочка. Cursor не экономит время на простых кейсах, но выручает, когда нужно быстро покрыть тестами большой кусок кода, особенно незнакомый или с кучей зависимостей
Из интеграций — Figma, Git, GitHub, Jira уже работают. Notion частично, конфа вроде в планах
Да, в проектах на Kotlin Cursor реально может пойти вразнос, если дать ему слишком широкое задание без ограничений. Он не всегда корректно учитывает паттерны типа MVVM или Clean Architecture — особенно при многослойных структурах.
В общем, лучше задавать максимально чёткий контекст и явно описывать, какие файлы менять можно, а какие нет
С безопасностью всё ок: в обычном облачном режиме часть контекста уходит на сервера. Для строгой политики безопасности есть on-premise — можно держать всё у себя и полностью отключить внешние соединения