Немного мыслей про performance review.

Amazon потребовала от сотрудников указывать в перформанс-ревью конкретные «достижения» на рабочем месте: минимум — три.

Мне казалось, что на западе уже давно смотрят на результаты и достижения сотрудников...

Однако у такого подхода есть обратная сторона: если руководство/бизнес не представило возможность для свершения тех самых достижений (наняли 20 сотрудников для подкраски одной кнопки, а больше целей у компании на квартал не было), то даже при всех стараниях, драках за задачи, можно так и не заработать медалей в копилку.

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

Сейчас читаю Александра Фридмана и у него есть цитата, которая отражает всю суть работы в больших компаниях:

попав в лидирующую компанию мирового уровня и получив доступ к многочисленным приятным бонусам, вы теперь должны «крутить педали», иначе работодатель быстро с вами распрощается

Если учесть, что сейчас по всему миру кризис и компании массово сокращают сотрудников, то теперь нужно не просто «крутить педали», а еще и успевать жонглировать на одноколесном велосипеде. 2026 год скорее всего отсеит многих слабых разработчиков и рынок IT перезагрузится. А пока стоит инвестировать в свои hard и soft skills и стараться как никогда, ведь конкуренция на рынке растет.

5 ошибок из-за которых не получают оффер

Всем доброго времени суток!

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

Я выделил 5 распространенных ошибок кандидатов уровня inter/junior/middle, из-за которых их не взяли.

Универсальное CV.

Кандидат отправляет одно и тоже резюме на разные вакансии не адаптируя его (например у него написано, что есть опыт Java разработки, однако подается он на go-разработку или на тестировщика. А в резюме про это ни слова!). В 2026 году 90% откликов и резюме в больших компаниях проходят отбор сначала через ML. Несовпадение резюме и отклика на вакансию уменьшают шанс рассмотрения кандидата. Но даже после прохождения ML отбора, если правильно не расставить акценты и не выделить ключевые достижения/навыки/технологии/фреймворки, интересующие нанимающего менеджер, резюме будет просто проигнорировано.

Медленный коддинг и незнание синтаксиса языка.

В 2026 году требования к стажерам/джунам более жесткие чем 5 лет назад: никто не собирается учить писать код. Этому учат в университете, на курсах, или самостоятельно. Придти на собеседование по python и не знать как объявить класс или придти на go разработку и не суметь дождаться ответа из горутины — red flag, после которого дальше разговаривать не будут. Сейчас надо владеть языком программирования и уметь на нем писать код быстро! Если не хватает практики — ищите ее сами: leetcode, opensource, pet проекты, … Набивайте руку!

Не подготовиться к собеседованию.

Понятно, что нельзя быть готовым ко всему, но как правило вопросы на собеседование вытекают из описания вакансии и технологий, с которыми придется работать. Пару видео на ютубе и статей закрывают 80% вопросов. Однако кандидаты пытаются выехать «на харизме».

Несистемный подход.

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

Наконец моя «любимая рубрика» — фродеры.

Я честно не знаю, что у этих людей в голове, и на что они рассчитывают. Может быть они себе представляют это как идеальный план как всех провести, но на практике это выглядит просто ужасно… Когда кандидат выдает ответ из нейронки, а потом не может его объяснить… Мало того, что они отнимают время на интервью, так еще и подрывают свою репутацию навсегда! Компания вносит таких людей в черный список (да-да, есть такие списки), и, скорее всего, в будущем HR даже не будут разговаривать с ними. А с учетом того, что Big Tech компаний в России не так уж и много, податься потом будет некуда…

Несмотря на непростое время, сейчас хорошему кандидату с должным уровнем подготовки попасть в IT не труднее чем 5 лет назад. Главное будьте честными:)

Я предлагаю на законодательном уровне запретить баги в коде.
Глядишь, оторвемся в технологическом процессе от других стран, и отечественное ПО станет лучшем в мире!

Люблю хардкорные статьи по устройству Go под капотом.

Недавно нашел реально классную статью по аллокациям памяти в Go. А сегодня вышел ее перевод на Habr.

Пополнил свою коллекцию еще одной ссылкой😁

Protobuf & Edition

После долгих лет стабильности proto3 protobuf наконец-то сменил парадигму и перешёл на Edition — набор настраиваемых фич. Теперь новые возможности можно добавлять эволюционно, не ломая обратную совместимость. А это значит, что теперь начнут активно появляться новые фичи protobuf (я на это надеюсь).

Edition 2023 — это просто разделение фичей proto2 и proto3 с возможностью настройки их глобально или локально (для конкретного сообщения/поля).

А вот Edition 2024 уже приносит несколько важных изменений:

- field_presence — настраиваемая модель поведения, позволяет контролировать, было ли поле действительно задано или нет (теперь optional не нужны получается); (с 2023 уже работает)

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

- default_symbol_visibility — задаёт видимость сообщений/перечислений, позволяя точнее контролировать, что именно экспортируется наружу, а что остаётся внутренней деталью схемы; Капец какая нужная фича в больших API!

- Opaque API в Go — сгенерированные protobuf-сообщения перестают быть «раскрытыми» структурами с публичными полями и превращаются в более закрытый API. Opaque API отвязывает код пользователя от внутреннего устройства сгенерированного кода. А это значит, что protobuf runtime и protogen могут дальше развиваться, оптимизировать все подряд, не ломая при этом пользовательский код (и они уже это сделали).

Звучит все здорово, но для внедрения в production меня останавливают две вещи:

1. Руками править сотни proto файлов — занятие неблагодарное. Парни из Google обещали сделать утилиту для миграции на edition — prototiller, но её так и нет :) AI в целом с нормальным промтом справляется, но хотелось бы официальной утилиты.
2. Для работы с proto в production я использую Buf, который все еще не поддерживает edition 2024. Парни там обещают скоро добавить поддержку, но официальной даты релиза нет…

Локально я с этим поигрался, жду впервую очередь поддержку в Buf. Уже сейчас можно мигрировать на edition 2023, сохранив обратную совместимость (добиться того же поведения, что и в proto2/proto3 и подготовится к переходу на 2024).

Мой первый удачный опыт вайбкодинга Agent Driven Development

Пока возился с активацией аккаунта Claude, вспомнил, что у меня есть подписка ChatGPT, и решил пока потестировать Codex на реальной задаче.

Взял go-ycsb: нужно было разделить адаптеры для Scylla и Cassandra и обновить драйверы до последних версий (точнее перейти на новые, но не суть). Эту задачу я уже делал сам — потратил около часа, включая погружение в проект. Потом стало интересно: а как с этим справится Codex?

Решил не мелочиться и начать с режима планирования. Сначала попросил его собрать Architecture.md, чтобы модель поняла структуру проекта. Потом, скорее для учебных целей, добавил ещё SKILL brainstorming. И тут был первый приятный сюрприз: нейронка начала задавать очень хорошие уточняющие вопросы, о которых я сам на старте даже не подумал.

Да, для такой простой задачи это уже был overengineering. Но как первый опыт — очень ценный.

Что понравилось больше всего: Codex не ограничился только кодом. Он поправил документацию, сохранил совместимость API, ничего не сломал, прогнал всё в Docker и ещё написал тесты. И вот тут стало особенно интересно, потому что мой собственный вариант был слабее: я не сохранил обратную совместимость и не обновил документацию с интеграционными тестами.

В итоге на всё ушло около полутора часов в спокойном режиме. Если честно сравнивать результаты, то я справился примерно 60-80%, а Codex на все 100% по полноте выполнения задачи.

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

Кстати, у нас в команде мы уже договорились прогонять ревью через AI и сейчас тестируем разные open-source модели. Нейронки правда бывают более дотошными и внимательными, чем человек, особенно в рутинных проверках. Нас они уже несколько раз выручали.

На следующей неделе буду тестировать Claude (все-таки у нее больше комьюнити и прикольных фич).

Кто уже гуру вайбкодинга, поделитесь своими успешными (и не очень) кейсами.