Глава «Тинькофф» Станислав Близнюк рассказал о «жутком» дефиците ИТ-специалистов Статьи редакции
По его мнению, это ведёт к снижению качества работы при росте зарплат.
- О серьёзной нехватке ИТ-кадров на российском рынке Близнюк заявил в рамках форума «Финополис». Специалисты, которые начинают искать работу, сразу получают множество предложений, отметил он.
Когда человек выходит на рынок ИТ, он через три дня получает пять-семь офферов, причем с повышением. Просто жуткий дефицит. К чему это приводит? Одно последствие — это что цена подрастет, это вызов для многих компаний.
Вторая проблематика — когда у тебя супердефицит, то у тебя и качество кадров ухудшается. Потому что, в общем и целом, зачем учиться, если и так тебя возьмут при нескольких накаченных скиллах.
- При этом «Тинькофф» пока не столкнулся с этой проблемой, пояснил Близнюк. Он ожидает, что банк почувствует её в перспективе трёх-пяти лет.
- В августе 2023 года глава Минцифры Максут Шадаев оценивал дефицит разработчиков в России в 500-700 тысяч человек. Всего в российской ИТ-сфере, по данным ведомства, работают почти 740 тысяч специалистов.
48K
показов
40K
открытий
1
репост
У меня опыт в айти 3 года аналитиком. Щас вышла на рынок поменять место работы. Даже не на высокую зарплату, просто шило на мыло. Так такие запросы у работодателя, ищут нобелевского лауреата нафиг, с опытом во всех сферах аналитики. Из 5 собесов ни один не прошла на этапе решения задачек. Дефицит не из-за нехватки кадров, а из-за нехватки адекватных руководителей.
Вы абсолютно правы
"Нужны синьёры, чтобы гонять json-ы"
При этом на собесе спросят и сложности алгоритмов и структуры данных и сможешь ли развернуть кубер левой рукой, правой набирая код на Java/Kotlin/Python/Rust (причем одновременно). Но даже если ты прошел собес, это еще не все: выяснится, что твою зарплату надо согласовать с HRD, СБ проверит тебя до восьмого колена, получить доступы и много-много-много другой ебанины, пока ты наконец доберешься уже до кода или проекта или аналитики
Ага, а там java 6 и костыли паутиной покрылись
За json можно подумать об уволтнении лида, а за soap/xtml- вообще ссаными тряпками гнать... за из легаси такое 🤮😡🤬👹
Смотря что и где храним или передаем в json.
proto по умолчанию "легче" и строготипизирован 😍, чего нет у упомянухых выше протоколах....
Даже на grpc , можно не переходить, оставить rest, но передавать байты с типами 🥰
К счастью, любой нормальный бизнес уволит прежде всего вас, потому что детей, дошедших до программирования, у которых технология становится не "модной" и надо всё переписать увольняют легко и без проблем.
Не то чтобы я был против grpc protobuf, graphql, msgPack и прочих, работал со всем и мне нормально, но это инструменты и они решают свою задачу.
Я бы посмотрел как бы вы парсили API без схемы (есть способы, но оно требует обычно намного больше кода) или про легкость, ваш веб фреймворк https://web-frameworks-benchmark.netlify.app/result тут на каком месте чтобы говорить о каких-то цифрах?
Пф... если апиха не меняла версию у вас....🙊🙉🙈
И да, относительно разбора ответа от бэка.... ..... вы же понимаете, что генерировать dto и интерфейс для сервиса grpc это 1 строка кода...
4 слова: контрагент/клиент, mongodb, schemaless.
Хотя наверное и mongodb легаси, а клиенту скажем что он плохой, но я бы лучше уволил вас, так как json для вас легаси и почему-то плохо его использовать и взял бы нормального программиста.
Nosql ....если это монолит.... а не один из сервисов (хотя , почти всегда sql лучше, особо в паре с reddis)
Нормальный человек- сразу сбежит от вас =)
1. Каким образом Nosql связан с монолитной архитектурой?
почти всегда sql лучше, особо в паре с reddis2. Если проект является монолитом вроде Jira, Gitlab, тысячи их, то это плохие проекты, потому что они имеют такую архитектуру? Надо нарисовать им гейтвеев, оркестраторов, циркуит брейкеров, сервис дискавери?
Монолит это тоже инструмент, он не плохой и не хороший, он просто иногда подходит, иногда нет и тогда лучше пилить на внутренние модули. Конечно, сейчас часто ставят контейнеры и стало проще быть микросервисами, но опять же, зависит от типа приложения, ибо даже веба великое множество.
3.
a)Специализированные данные(статистика, графы)? b)Данные которые в SQL ушли бы в толстые joinы(можно конечно хранить в json типе, но ох какое удовольствие это всё джойнить особенно когда много внутренних сущностей)?
c)Неструктурированные данные?
И конечно умиляет ошибка в написании redis;
4. Нормальный человек убежит, если у какого-то клиента неупорядоченные данные в api со schemaless и надо с ними работать? Некоторые бизнесы строятся на упорядочивании данных.
Рановато вам лидов увольнять.
Upd: границы "нормальности" естественно у всех свои =)
Не по мне ваш подход...
Особенно, если вы поддерживаете апп/сервис
ну а нахрен мне нанимать через чур разборчивого разработчика, который еще будет нос воротить, если столкнется с каким-то «не идеальным» источником информации? разраб должен деливерить результат в бизнес
И микросервисы, обязательно добавьте микросеврисы 😍🥰🙉
только не говорите мне, что вы бинарники protobuf кладете в БД (не важно какую)