Цифровой профессиональный след

Яркая новинка HR-сезона 2026 — понятие цифрового профессионального следа. Я начал встречать его упоминания в феврале в HR-каналах и в вакансиях. В чём суть явления?

Эйчары не доверяют опыту, описанному в резюме, или записям в трудовой книжке. Но им надо разбирать отклики от кандидатов, надо на что-то полагаться. Поэтому им нужна хоть какая-то опора.

Цифровой профессиональный след и есть эта опора. По сути, это набор внешних, объективных, достоверных подтверждений (пруфов) либо опыта, либо уровня скилов кандидата. Важно, чтобы кандидат не мог повлиять на этот пруф.

Идеальный пример ЦПС — это доклад на конференции. Описание доклада висит на сайте конференции, и кандидат не может его изменить. По докладу можно понять уровень докладчика, сколько у него лет опыта, где он работал.

Вроде бы идея с цифровым следом здравая. Но есть проблема — хороших источников цифрового следа мало. Что ещё можно исползовать как цифровой след? Накидайте вариантов.

И ещё одна проблема. Теперь каждому разработчику с самого начала карьеры надо вести дневничок и собирать портфолио наград и грамот, как в школе? Вы готовы к этому, дети? Да, капитан!

Намедни меня упрекнули в том, что на канале слишком много информации о поиске работы и карьере.
Я пришла к выводу, что это звучит справедливо, и подумываю создать отдельный канал про карьеру и поиск работы — в этом останется только про разработку. Но не уверена, что стоит плодить каналы.
Вы как считаете?

Накрутка опыта и шантаж

На днях телеграмм облетела история анонима, накрутившего опыт при помощи ментора, а потом столкнувшегося с шантажом от этого самого ментора.
Народ в комментариях разделился на две группы: тех, кто надеется, что автора навечно забанят в айти, и тех, кто делает круглые глаза и вопрошает “ачотакова”.

Моя точка зрения проходит между радикальностью первых и поразительной незамутненностью вторых. Мне категорически не нравится накрутка опыта и я считаю, что усилиями блоггеров и менторов, на ней нажившихся, поиск работы для миддлов (а тем более для джунов) стал напоминать борьбу с многоголовой гидрой — ведь теперь им приходится конкурировать не с такими же миддлами, а с сыновьями маминой подруги, у которых в резюме идеально отполированная фантазия. Честные результаты всегда хуже выдуманных сверхдостижений. В итоге честные ребята тоже вынуждены крутить, чтобы не казаться хуже, и весь этот снежный ком лжи набирает обороты, заставляя всех и каждого сомневаться в себе и своем резюме.

Этот театр теней, в котором мы все оказались благодаря массовой накрутке, влияет на каждого из нас. Во фронтенде, по моим ощущениям, крутит каждый второй (среди миддлов — почти все, среди сеньоров существенно меньше, в среднем по больнице каждый второй). В то время как одни начали крутить, наслушавшись сказок про автофильтры и несправедливый найм, другим пришлось крутить, чтобы быть не хуже первых. Теперь уже и не разберешь, кто что первый начал, но большинство миддлов оказались в ситуации, когда кроме них все остальные накрутили — и вынуждены не отставать. Несправедливо наказывать конкретных людей за то, что делают вообще все вокруг.

Если вы оказались в такой же ситуации, как автор, помните — ответственности за накрутку опыта в законе не предусмотрено. Вас не могут за это уволить. Не вы первый, не вы последний. Очень много людей сейчас в такой же ситуации, как вы, и многие из них переживают и боятся быть обнаруженными. Пострадаете вы или нет, во многом зависит от вашего дальнейшего поведения.

Не будьте наивными и не думайте, что ваши коллеги будут в восторге от этой новости. Скорее всего, им не понравится. Сюрприз, но даже сторонники накрутки не любят, когда обманывают их самих. (Вспомните хотя бы вот эту историю, как Клара у Карла украла кораллы, оставаясь, строго говоря, в рамках закона!). Важно понимать, что доверию нанесен ущерб, но увольнять вас — это уже перебор. Я считаю, что в такой ситуации важно извиниться за обман, и объяснить, что вы были вынуждены крутить, так как сейчас этим занимаются все и это де-факто стандарт рынка. Но на все предложения уволиться нужно отвечать категорическим отказом, дополняя его своими фактическими достижениями и закрытыми задачами. Со временем, при условии вашего добросовестного поведения, этот конфликт будет исчерпан.

В комментариях к оригинальному посту проскальзывали советы сослаться на дипфейк, а то и вовсе подделать такие же “доказательства” для коллег, чтобы имитировать массовую рассылку. Не занимайтесь подставами, не закапывайте себя еще глубже. Как минимум, это будет подозрительно, а как максимум, кто-нибудь из сообразительных коллег шустро накидает на вас досудебку за клевету, но будет готов отказаться от претензий, разумеется, не за спасибо. Тогда неприятным разговором вы не отделаетесь.

От резюме к доказательному найму

Рынок найма сломан двумя кризисами: экономическим и кризисом доверия. Они наложились друг на друга и бьют даже по сильным специалистам.

Новый дефолт рынка — нулевое доверие к кандидатам. И это надолго.

Резко выросла ценность цифрового профессионального следа — пруфов, которые подтверждают опыт и уровень навыков. Рынок движется к доказательному найму.

У большинства разработчиков таких доказательств нет. А нарабатывать их долго и дорого.

Поэтому появляются форматы, которые дают достоверное подтверждение уровня, сопоставимое по силе с докладом на технической конференции.

Один из таких форматов — чемпионат по вёрстке для мидлов от @htmlacademy. Он изначально строился как доказательный формат и включает:

– сложное задание с высоким потолком скила;
– двухнедельный формат, в котором можно показать свой максимум;
– ручную проверку работ;
– сильных проверяющих — синьоров из бигтеха и крупных продуктовых компаний;
– публикацию результатов в публичном рейтинге качества фронтенд-разработки.

Старт — 30 марта. Если у вас есть коммерческий опыт в разработке, это способ получить публичный пруф своего уровня.

Записаться на чемпионат

Женя Кучерявый написал гайд, как программировать без интернета. Эта статья вызывала у меня широкий спектр эмоций, начиная от смеха со слезами и заканчивая ностальгией по университетским годам, когда быстрый интернет в корпусе был скорее исключением, чем правилом (что, впрочем, нас не останавливало). Поскольку сегодня среда, мои чюваки, не могу лишить вас возможности насладиться гайдом!

https://kucheriavyi.ru/articles/coding-without-internet

P.S. Этот пост не предназначен для того, чтобы его восприняли слишком серьезно. Он здесь шутки ради.

Ситуация в найме ахтунг. Все и так все понимают.

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

НИЧЕГО не ставьте на комп связанное с работой до последнего.

- ни для тестового задания!
- ни для интервью!
- ни для работы в первый день (если работаете неофициально)!

Ни приложения, ни установки "пакетов содержащих апи" НИ ЧЕ ГО.

Если вас вынуждают, то используйте:
- дев окружения: CodeSandbox, Stackblitz и тп
- если все же нужно со своего и хоть какое-то доверие есть, то используйте Dev Container или как самый минимум просто докер
- для выхода на новой работе тоже лучше соблюсти меры предосторожности, особенно если никаких реальных документов вы не заключали. Докер, в идеале отдельная система и отдельный пользователь, чтобы даже в случае проблемы вы не потеряли доступ к устройству и данным.

Также рассказали о новом виде скама с логином в iCloud. Со своего ПК не лезьте и не логиньтесь никуда. Если дают какой-то сервис, то лучше зайти с инкогнито + сгенерировать рандомный пароль (понимаю, что это базовая сейчас рекомендация по безопасности, но пароли многие все еще пишут руками по паттерну).

Век живи — век учись. Сегодня я узнала, что ts инферит переменную со значением null к any.

Начала писать для вас стопку технических постов и пока все лежит в драфтах. Чтобы вы сильно не скучали, приношу вам плейлист стримов где мы с ребятами из @moscowqa обсуждаем #typescript. Я рассказываю про базовую и продвинутую типизацию, немного потрогали загадочный тип never, а также ковариантность и контрвариантность. Все вопросы можете написать прямо сюда, я постараюсь как можно детальнее на все ответить.

А вы тоже иногда путаетесь в куче логов в консоли?

Чтобы облегчить себе жизнь, логи можно раскрашивать. Например, вот так:

console.log('%cSESSION_START', 'background-color: red; color: white; padding: 10px 30px');

console.log('%c[User] Get data...', 'color: yellow');

console.log('%c[Products] Я точно не пропущу этот лог', 'font-size: 25px;');

console.log('%cSESSION_END', 'background-color: red; color: black; padding: 10px 30px');

Сегодня на консультации обсуждали резюме.

— Ну, вообще, в этом проекте у меня были вебсокеты, и еще я делал вот такую классную задачу.
— Но почему этого нет в резюме?
— Посмотрел резюме ребят, которые крутят опыт, многие пишут в резюме такого рода задачи и вебсокеты. Поэтому убрал, чтобы не думали, что я тоже накрутил.

Выводы из этой истории делайте сами.

Тип-пересечение (Intersection Types)

Тип-пересечение, как следует из названия, соответствует пересечению множеств, которые его образуют. Декларируется при помощи оператора &.

type C = A & B

Это видно на картинке: у нас есть два множества, которые пересекаются, и их пересечение образует подмножество. Если два множества не пересекаются, мы все равно можем получить тип-пересечение, но оно будет пустым (never).

type X = string & number // never

Важно понимать, что использование типа-пересечения в коде целесообразно тогда, когда составляющие его типы используются по отдельности. Например:

type Product = { id: number; name: string; }
type Priced = { price: number; }

type PricedProduct = Product & Priced

Типы в коде выше имеют смысл, когда в нашем проекте могут быть заведены товары без цены (например, только поступили на склад и цена еще не определена). Если же в нашей системе товары всегда содержат цены, то в этом случае подобная конструкция типов нам не нужна, целесообразнее использовать вот такой тип:

type Product = { id: number; name: string; price: number; }

#typescript

Как я на go в продакшн писала

История была год назад. Нашей команде достался проект с жестким дедлайном. Я уже заканчивала фронтенд, а бекендеры все сдвигали свои сроки и, в конце концов, признались, что не успевают — слишком много задач помимо этого проекта. Тогда я сказала, что я все сделаю сама, только дайте доступ. Лид удивился и возразил мне тем, что в моем резюме написано “frontend-разработчик”. Как вы, наверное, помните, мне в целом не очень импонируют все эти надуманные ограничения вроде “фронтендер не может закрывать таски на бекенде”, тем более я не на лиспе писать собралась, а на еще одном c-like языке. Доступ мне дали. Бекенд оказался на go.

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

После этого меня ждал новый сюрприз: абсолютно пустой readme и огромный makefile с богатым разнообразием команд. Я решила не гадать на кофейной гуще и спросить у лида, как стартануть проект. А никак, — ответил лид, — он локально не запускается, в CI можно стенд собрать. На этом моменте я на все плюнула и пошла в спортзал тягать железки.

День два. Я решила, что даже если я не могу проверить свой код, написать-то я его все равно могу, логично? Начала читать таску и обнаружила, что аналитик любезно все описал, включая таблицы БД, которые нужно добавить/изменить, и какие поля добавить в эндпойнты. Осталось всего лишь перевести это все в код, что, как вы понимаете, изян задача.

Еще несколько дней я убила на миграции и тесты. Стало понятно, почему ребята не парились из-за невозможности локального запуска — тесты и CI/CD проверки хорошо покрывали кодовую базу, и у меня несколько дней реально ушло на то, чтобы добиться прохождения тестов и пайплайна. Попутно я разобралась, как это правильно делать.

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

Ну а потом я перешла в другую команду и моя славная карьера go-разработчика закончилась. В новой команде я уже больше полугода пишу на Svelte. Позже расскажу, с какими сложностями я столкнулась после того, как перешла с React на Svelte (спойлер: ни с какими, две недели немножко неудобно, а потом привыкаешь).

Помните, я писала о том, как делать сопроводительные на hh? В общем, можно больше не тратить на это время, смысл сопроводительных окончательно утрачен.

Кхэ-Кхэ ру выкатил обновление для соискателей и представил новую функцию "AI-генерация сопроводительного письма"🤦🏻‍♂️

Вот теперь точно AI будет отбирать AI... а работать-то кто потом будет?🫣

Дублирование на уровне кода - один из основных источников технического долга. Говоришь себе "ну сейчас быстро сделаю копи-паст, а потом на этапе рефакторинга раскидаю как надо".

Обычно этап рефакторинга так и не наступает, поэтому в коде остается несколько источников правды, которые в будущем создают проблемы.

Хуже всего то, что спустя время ты успешно забываешь, какие правки нужно было сделать, дополнительно успеваешь накидать на старый код еще пяток другой патчей, которые усложняют рефакторинг и тем самым закрепляют плохие практики, превращая кодовую базу в дремучее легаси.

Легаси неизбежно, поэтому хорошего кода в мире очень мало, а плохого сколько угодно много. Получается, что с большой вероятностью код, который был использован при обучении LLM, был не самого лучшего качества, а значит, это мы с вами, ленясь выполнять своевременный рефакторинг, научили ИИ "плохому".

Может быть, это и к лучшему, потому что мы с вами еще можем научиться красиво и грамотно писать код, проектировать и продумывать наши системы, а ИИ будет продолжать плодить легаси.

Воистину, лень оказалась лучшей инвестицией, которая поможет нам конкурировать с ИИ.