Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение

Пожелаю автору не бросать попытки, раз уж есть ощущение что айти это твое, нужно дожимать ситуацию как минимум до первого реального трудоустройства. Поделюсь своим опытом, сам был в похожей ситуации, конечно конечно рынок для джунов/стажеров сейчас намного менее благоприятный чем 6 лет назад. Возраст - это объективно (для работодателя) минус, хотя я входил в айти в возрасте 40+ и вполне успешно за год-два дорос до миддла, в текущей позиции условно синьор-техлид (все эти грейды относительны и применимы только к определенной, часто узкой области), однако наблюдая/стажируя гораздо более молодых коллег, замечал что скорость усваивания знаний - а это определяющий критерий для джунов - довольно рандомная величина и особо не зависит от возраста. Что касается софт скиллов - на этом этапе они только вредят (особенно если начинаешь ими козырять), от джуна ожидают гибкости, как справедливо заметил кто-то в комментах. Безусловно опыт и софт скиллы пригодятся и сыграют свою роль - но гораздо позже, на уровне мидла, синьора. Еще момент - возможно стоит рассмотреть стажировки (без оплаты или с минимумом). Даже в благополучные времена, для человека возрастного (для айти) вкатываться было проблематично, главное на этом этапе - получить реальный опыт работы над реальными проектами/задачами. Однако основной критерий успеха для любого возраста/уровня - даже не иметь желание, а именно любить программирование и все что с этим связанно. Я наблюдаю множество людей которые делают это только ради денег - и их много, но среди них практически нет синьоров/техлидов - только крепкие середнячки. Так что если есть такие ощущения - нужно дерзать и все получится

Честно говоря статья написана или переведена отвратительно (а скорее и то и другое). Не раскрыты полностью все преимущества gPRC (скорость, упаковка, быстрая сериализация, стриминг, генерация под все языки и конечно http2 - и вытекающие из него ). По-моему у gPRC отличные перспективы как у языка межсервисного взаимодействия. Например по следующей схеме: фронт общается со шлюзом через GraphQL (Federation если много данных) а шлюз с микросервисами и они-же между собой посредством gRPC. Таким образом куча микросервисов написанная разными командами на разных языках (в проекте сотни микросервисов на GO, PHP, Java и Node), DTO из proto файлов централизованно генерятся во все используемые языки. Не вдавался как реализованы клиенты для GO, JAVA, PHP но для микросервисов на ноде нет никаких сложностей - все решения и библиотеки вполне зрелые, работают весьма шустро, давно в проде. Есть некоторые сложности связанные с балансировкой микросервисов с gRPC на k8s но это решатся сторонними прокси, тот же Envoy. Так же есть сложности связанные с ошибками в gRPC, но все решаемо (metadata). По сравнению с thrift а тем более с REST гораздо более быстрое и экономное решение.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность