Расскажите, как вы перешли на другой стек

Страшно читать про фразы «не лезь в базку, у тебя написано в тайтле фронт»)

Расскажу из своего опыта с обеих сторон:

Я бы советовал поговорить с руководителем, можно честно обозначить, что подустал от перекраски кнопок и хотел бы брать новые задачи. Обговорить с лидом условия, когда от этого не страдает проект, но при этом ты получаешь новые навыки и развитие.

Это, конечно, сильно зависит от компании, но обычно лучше дать человеку расти внутри, чем зажимать его так, чтобы он ушёл. В этом случае компания все равно теряет (если это не унылый бодишоп с безумной текучкой)

Но, иногда (например, в продукте), может просто не быть задач под ещё одного бека. Тогда надо обсудить перспективы и, если желание есть, искать работу.

Кстати, опыт можно набирать и на фрилансе. Заказы будет искать нелегко, но реально.

Второй совет - хочешь писать бек - пиши бек) придумай пет проект, заодно будет что показать на гитхабе. Изучай новые языки, смотри технологии или курсы ну и так далее.

Лично мой путь был довольно простой. Работал в аутсорсере, имея базовые знания бека - пришёл на фронт. Потом обратно на бек. Так, по-немногу, и набрался туда-сюда. В аутсорс компаниях такое бывает, насколько я понимаю - не так уж редко. Там и проекты под это обычно есть (а вот в продукте может и не быть)

П.С. Ещё нужно подумать, а надо ли оно тебе. Перекладывание json вместо перекраски кнопок только звучит увлекательно)

Пс2. Знаю успешный кейс ухода с реакт нейтив на позицию раст бекенд разработчика, нужно желание и хотя бы небоевой опыт)

Менял стэк уже дважды, оба раза без потери в деньгах и один раз с переездом. RoR -> NodeJS -> Elixir.

Если очень кратко: сначала набрал ~3 года в рельсовой разработке. Потом устроился в компанию где на рельсах был бэк, а на фронте реакт. Поскольку я хотел выучить JS я начал волонтерить в фронтендерских тасках, а со временем и вовсе заменил фронтендера - старый ушел, а дать мне задачи проще чем нанимать нового. После этого устроился уже в компанию где не было руби вообще а бэкенд был на JS. Это был прыжок с места в карьер потому что бекенд на JS и монгодб мне пришлось учить по ходу дела. Ну а там компания параллельно начала делать Эликсир и я используя в основном JS все больше и больше писал эликсир + менеджерил и все полагающееся. Сейчас я опять сменил компанию и пишу эликсир 90% времени иногда помогая людям на JS стороне.

По моему опыту работы в средних компаниях (100-400 человек, когда уже не стартап но еще не нужна таска в джире что бы строчку поправить) все совершенно не против того что ты залезаешь на новые территории до тех пор пока ты решаешь проблемы. Поэтому мне всегда было достаточно проявлять инициативу и брать на себя ответственность, а уже в следующей компании можно бравировать опытом.
Будучи лидом я поступал так же - если фронтендер хотел поковыряться в бэке я скидывал ему простые таски на бэк когда фронт не горел. Ну и так шаг за шагом потихоньку.

Я менял язык один раз, при этом были офферы на Java, Kotlin и Go (сам я писал до этого на Python и целенаправленно хотел переключиться).

Если ты идёшь в компанию, которую не интересует привязка к языку, то нужно быть готовым доказывать свои компетенции другим образом. В моем случае это были задачи с литкода (но везде они требовали просто сообразительности), общение за жизнь с целью проверки софт скиллов (вообще сложилось ощущение что они составляли 30-50% успеха в зависимости от компании) и общие вопросы без привязки языку (системный дизайн в разных проявлениях).

Чтоб я советовали почтитать при переключении на бекенд (это ИМХО сложнее просто смены языка) - базы данных в первую очередь, по-моему это то, чего не хватает многим бекендщикам, ну и дизайн распределенных систем - просто что бы понимать проблематику. В
идеале послушать лекции Мартина Клепмана, он доступно излагает очень много интересных вещей. У него же есть книга Designing Data Intensive Applications, если ее осилить можно многим ребятам с бекенда давать фору.

Кроме теоретического аспекта, есть ещё практический. Тут сложнее, конечно, имея теоретический бекграунд можно теоретизировать в целом, но вообще лучше найти смешанную позицию и переходить потихоньку.
Помогает подписаться на тематические рассылки/блоги на медиуме, что бы постоянно расширять контекст в конкретном направлении.

Ну и пет проекты, в идеале, смотреть как сделаны опен сорсные решения и пытаться пощупать как можно больше всего. Как по-мне в новом языке самое неочевидное поначалу это инструменты (где ставить third-party, где использовать библиотеку языка и почему). Тут, опять же, опен сорс как пример решений, пет проекты и тематическое чтение.

Прилинкую: Как правильно свичнуться в другую технологию?

"Менял стек" несколько раз. Из последнего: от работы с фронтом и картами перешёл в работу над бекендом (go,java). Есть несколько мыслей: (вёрстка в сообщении поехала и я хз как поправить)

1. Фундаментальные знания. Устройство компьютера, как работает процессор, отличие ОЗУ и ПЗУ, O(n), что значат буквы в ООП, чем отличается heap от stack, что такое указатель, как работают потоки в ОС, что значит "функция как значение", можешь примерно вспомнить про что CAP теореми, понимания отличия между "чистым кодом" и говногодом (и умении писать хорошо) и так далее. Эти знания универсальны и они отличают Senior Software Engineeer от увернного пользователя Github copilot. Эти знания нужно оттачивать всегда. При переходе на другой стек они остаются и помогают расти дальше, не откатываясь назад.

2. Софт скилы. Это про то как правильно послать человека в жопу, если он тебе говорит "эй лучше дай это делать другим ребятам, у тебя в тайтле написано фронтендер". Наша область не про написание кода, а про решение проблем. Умение планировать, делегировать, организовывать большие группы людей ценится намного больше умения сделать монаду или красиво привести тип.

3. Непосредсвенные инструменты и API. Язык, инструменты, другой софт (база данных или новый фронтенд фрейморк). Тут нужно максимально обмазаться спеками, учебниками, блогами, ютуб каналами. Всегда под рукой иметь документацию (я использую Dashapp) и инструментарий (я на время обучения слезаю с vim и переходу в vscode/idea). Очень хорошей практикой являются свои проекты. Берешь интересующую технологию и делаешь чтото (полу)полезное для себя.

4. Локальные (к стеку и команде) подходы, трюки, стиль. Хорошо, когда в компании есть записаный стайлгайд и строгая система ревью. Если нет, то просить коллег ревьюить код дотошно. Самому тоже смотреть чужой код, разбираться, если непонятно, то спрашивать.

Перекатывался из геймдева в web-бэк и это было относительно тяжеловато, потому что парадигмы все же отличаются.
Начинал с написания скриптов на Unity, потом постепенно перешел на более сложные скрипты и игровую логику, потом на написание бэка для игр (и это весьма интересное направление со своими приколами. Например тут stateful (да-да, храним данные прямо в памяти) приложения это вообще норма жизни ). Ну и параллельно стал понимать, что писать логику и перекладывать данные мне интересно, а писать шейдеры и делать красиво по графону - нет. Плюс на веб-бэкенд вакансий сотни-тысячи, а на геймдев - единицы и десятки (и почти везде надо хоть чутка шарить за графон).

В будущем вообще хочу перекатиться в трипл-фулстэк - backend, frontend, devops (фронт и девопс знаю на базовом уровне). Но очень мало кто на самом деле предоставляет такую возможность, почти везде отделы бэка, фронта и админов разделены (что, наверное, правильно).

Ну и концептуально заметил, что горизонтальное развитие в технологиях мне куда интереснее вертикального (больше кайфа изучить три технологии на базовом-среднем уровне, чем упороться максимально в одну).

1. Обучаюсь самостоятельно, но с норм курсами и менторами дело идет куда быстрее.
2. Открываю резюме и жду) Ну и сам раньше откликался тоже.
3. Всегда отвечаю честно, что нет. Но могу показать тестовые/пет проекты.
4. Если прям полностью именно менять стек (с Senior RoR-разраба на Senior .NET), то, наверное, вероятность мала. Но если переходить, условно с 100% PHP-разраба на компанию, где 30% PHP и 70% Go - думаю, вполне себе возможно.