Давай зададим дополнительные вопросы:
1) что тебе больше нравится? однообразие узкого специалиста в "вечной«(якобы) сфере или разнообразие и широкий опыт в современных технологиях, за которыми будущее?
Для сравнения можно взять С++: вроде как вечен, но есть нюанс....
Его роль свелась к узкой сфере — к инфраструктурным проектам: графика, финансы, системное программировние.
Даже на уровне операционных систем уже наметился активный переход на современный Rust: всё новое для винды пишут на нем.

2) вот, что советует Джемини:
Якщо вас лякає «вузькість» UiPath, подивіться на AI Agents / Python Engineering. Замість того, щоб бути прикованим до одного вендора, вчіться будувати автоматизації на стеку Python + LLM API + Vector Databases. Це дає той самий овнершіп і драйв стартапу, але ви не залежите від того, чи буде популярним UiPath через 3 роки.

3) вопрос получения опыта. Слишком большая зацикленность на однотипном анализе данных — очень сужает кругозор и ухудшает перспективы.
Еще важно учитывать, что через 2-3 года оно может надоесть до тошноты и — что делать тогда? Ставить все на это — на всю жизнь — тоже неудачное решение, если глаза в эту сторону не горят.

В целом, я бы делал ставку на все, где есть использование ИИ и питон. К данным ИИ тоже придет.
Еще можно рассмотреть направление DevOps — их ИИ не заменит, они более редки, чем разработчики и аналитики.

😂😂😂😂👍

Реальность в 2026 году наглядно ломает сказки о «серверах под Кремлем». Достаточно посмотреть на тотальные блокировки Телеграма в РФ, замедление трафика и бан звонков Роскомнадзором.

Включаем базовую логику: если бы ТГ полностью и безропотно сливал все данные в ФСБ, силовикам не было бы вообще никакого смысла уничтожать этот инструмент внутри страны. Зачем спецслужбам ломать то, откуда они и так якобы беспрепятственно всё читают?

Нынешняя война Кремля против Телеграма как раз и доказывает, что полного контроля они не получили, и мессенджер остался для системы костью в горле. Да, риски перехвата SMS через СОРМ или деанонимизации через боты никуда не делись, но теории о «прямом пульте управления ФСБ над серверами ТГ» полностью разбиваются о реальность этих блокировок

В итоге, если цель — добраться до технического собеседования, то задача сводится к обычной максимизации функции:

max_резюме P(Тех_собес | резюме, вакансия/рекрутер)

Где мы максимизируем вероятность [P] получить инвайт, подгоняя параметры резюме под констрейнты системы (жесткий булевый отбор ATS по ключевым словам + 6-секундный эвристический фильтр взгляда рекрутера). Чистый реверс-инжиниринг и оптимизационная задача для LLM на пару часов, без магии и эмоций.

Мой пост как раз и был о том, что все рекрутеры — разные. Загонять их ВСЕХ под один шаблон — тоже не совсем верно, хоть явление и довольно распространенное.

Можно взглянуть на это под другим углом. Если делаешь визуальный интерфейс для приложения или онлайн-сервиса — это ведь логично: изучить, как эти самые интерфейсы выглядят у других? Чем в этом смысле отличается резюме? Просто целевая аудитория у него — рекрутеры.

Плюс известный факт, что резюме часто проходят ATS — автоматическую систему, которая произведет отсев всех тех, кто не упомянул заветные слова: кунг-фу, карате, тхэквондо. Или, точнее, ключевые buzzwords, которые указаны в этой и похожих вакансиях.

Откуда их взять? Надо изучить, что пишут в вакансиях, что пишут в резюме другие, что ищут рекрутеры и что сканирует ATS. Обычная продуктовая задачка на пару часов с использованием Gemini, Claude или Grok.

Лично я не встречал собесов по телефону. Обычно Google Meet.
Надо еще учитывать на какую позицию подается человек.

Собеседование на чистого FullStack технаря — это набор библиотек, фреймворков, и языков. И часто отсутствие нужного фреймворка — оказывает крайне негативный опыт с HR. Неважно, что они все примерно похожи: знаешь два — в третьем тоже разберешься. С точки зрения того, кто с этим работал — это так. С точки зрения того, кто проводит собес: вы красили деревянные стулья зеленой краской, а вот опыта с белой краской и металлическими стульями — у вас, увы, нет...