Как Проверка Тестовых Заданий Перезагрузила Мое Видение

Знаете, иногда рутина может незаметно подкрасться. Взялся недавно проверять тестовые задания кандидатов в стажёры. Казалось бы, что тут такого? Смотришь код, пишешь плюсы и минусы каждого кандидата и оцениваешь его вконце, нажимая зовем/не зовем на интервью. Но этот простой процесс начал меня... выматывать. Каждый день количество кандидатов увеличивалось. Эйчар мне посылает каждый день по 2-3 анкеты с заданием. Я начал хватать выгорание.

Почему? А потому что на работе мне нравится энергия цикла разработки. Мне нравится разбираться с архитектурой. Писать код. Я люблю копаться в отладчике, смотреть как течет код, и видеть все новые и новые нестыковки и повороты потока выполнения программы в новых задачах. Мне нравится писать тесты. Нравится видеть, как все спроектировано, возвращаясь к первому шагу цикла разработки. Это драйв, азарт, адреналин и удовлетворение! А тут десятки чужих однотипных работ, которые нужно прочесть и посмотреть и проверить по чек-листу, запустить. Я начал чувствовать, как подкрадывается это самое выгорание: ощущение, что ты один в поле воин, а результат твоего труда - это капля в море.
НО! И вот это но перевернуло ситуацию. Погрузившись в работы кандидатов, когда счетчик работ зашкалил за десятки, я увидел искру. Уведел реальную страсть и старание:

🔄 Паттерны применены у 5 процентов! Сколько же грамотного применения Consumer-Producer! Фабрики там, где они действительно нужны. Это не просто код, это уже применение опыта из книжек и советов stackoverflow.

🧪 Тесты? Обязательно! Многие (20 %) использовали gtest. Видеть юнит-тесты в тестовом задании – это уровень. Приятно видеть, как тестовый код запускает пользотельский. Это говорит о понимании качества.

✨ GitHub-портфолио: Около 40% работ были оформлены на GitHub не просто как код, а как презентация себя и своих четких достижений. Чистые репозитории, внятные README, project-tree в середине, шаги к тому как запустить код и тесты. Это показатель ответственности и желания добить задачу до конца.

❓ Те самые 3%: И – особый увжение людям! – те единицы, кто спросил. Уточнили у рекрутера, задали осмысленные вопросы. Знаете, для меня это ключевой индикатор. Я всегда готов с огромной прилежностью уделить внимание задающему вопрос.

Конечно, был разброс: кто-то показал навыки уверенного мидла, а кто-то... даже не дочитал задание до конца или проигнорировал требования (надо было сделать под Линукс 😉).

Но главное открытие пришло неожиданно:

Мое выгорание было иллюзией. Иллюзией "одиночества моих стараний". Когда ты видишь десятки работ, видишь искренние старания, видишь интерес в глазах (пусть даже через код), видишь, как люди применяют те же паттерны, пишут те же тесты, сталкиваются с похожими задачами... Ты понимаешь:

Мы все – часть одного большого Дела. 🔥 Мы все проектируем, создаем, отлаживаем, тестируем. Каждый на своем месте, но ВМЕСТЕ.

И это – ТРИУМФ! Триумф не над кем-то, а над усталостью и сомнениями. Триумф понимания, что поток талантов и энтузиазма – реальность.

Поэтому о выборе:

Я не буду искать просто "самых лучших" по формальным критериям. Я не буду искать просто "самых прилежных".
Я буду искать самых ИНТЕРЕСУЮЩИХСЯ. Тех, кто спрашивает. Тех, у кого горят глаза. Тех, для кого этот код – не просто тест, а шаг в профессию, которой они искренне хотят учиться.

Потому что именно интерес – тот самый двигатель, который превращает стажёра в крутого специалиста. И именно с такими людьми хочется строить будущее. Проверка тестовых – это не рутина. Это вдохновение. Это напоминание, ради чего мы все здесь. Это видение будущего нашей индустрии, и оно – яркое! 💪

Напишите в комментариях: что для вас самое главное в программировании, конкретно, то, ради чего садитесь за код? Что самое главное в будущих стажерах?

Скоро: чек-лист 5 признаков сильного стажера в C++

#разработка #стажировка #программирование #карьера #мотивация #it #github #тестирование #gtest #паттерны #выгорание #триумф #команда #интерес #вопросы #учиться #будущееIT

Делюсь своим чек-листом чек-лист 5 признаков сильного стажера в C++

❄️ Холодный пот: Когда за словами — пустота. ❄️

Сегодня было собеседование. Студент. Сделал задание хорошо. Говорит уверенно:

О, враппер? Класс-обертка для расширения поведения!

Фух, знает - мелькает надежда...
Уточняю: Зачем подставлять реализацию в него? Можно же скопировать код, или изменить изначальный класс?

Тишина. Глаза бегают. Уверенность тает на глазах.
Ну... для гибкости? — неуверенный шепот.

Холодок по коже. Иду глубже:
Допустим, враппер должен уведомить нас о завершении долгой операции. Как?

Эээ... Колбэк? — ловит спасательный круг-термин.

А ЗАЧЕМ? Что происходит, когда ВЫЗЫВАЕТСЯ этот колбэк? Как управление возвращается?

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

Чувствую ледяную тревогу.
Не за него — выучит.
За НАС. За индустрию, за университет.

Когда базовые паттерны (Wrapper/Adapter) и принципы (инверсия управления) — просто слова без понимания сути...
Что мы строим? На каком фундаменте? На каком образовании?

Как вам кажется? Это только у меня так? 🤯 Обсудим в комментариях?
#cpp #тимлид #собеседование #паттерны #тревога

Когда "Нет" стало стартом: история собеса, где мы дали шанс вместо отказа
Второе интервью 👋 Хочу поделиться необычным кейсом. Эмоции после — легкая ирония, но главное: уверенность, что потраченные 30 минут стоили того.

Сценарий:
🧑 Кандидат: вежливый, резюме — "3 года учебного С++", тестовое — идеально (спасибо его "другу" 👀).
💣 На техсобесе: тишина. Базовые вопросы — "простите, не знаю". Три тимлида — ноль ответов.

Вместо "до свидания":
Мы осознанно устроили мини-обзор работы! Каждый за 5 минут дал практический срез своей реальности:
✔️ "Какие задачи решает трейни у нас?"
✔️ "С какими вызовами столкнешься?"
Его вопрос: "Какую задачу дадут в первый день?" (респект за смелость!)

Почему закончили интервью?
👉 Честность: Он не врал — "Не знаю" звучало чаще любого паттерна.
👉 Готовность учиться: Впитывал как губка.
👉 Ностальгия: Узнал себя студентом.

Мой вклад:
Рассказал фундамент, который выручит всегда:
🌐 HTTP: как клиент/сервер "разговаривают"
🔧 Парсеры: зачем они и что парсят (html, xml, json)
🚀 Чеклист: сети (TCP/IP), алгоритмы, паттерны → учить системно.

Выводы для команды (без стыда!):
Эта ситуация — отправная точка для калибровки процессов:

1️⃣ HR + Tech: синхронизируем чеклисты
• Какие конкретные базовые вопросы задавать на скрининге под "3 года опыта"?
• Как проверять понимание, а не умение гуглить?
• Тестовое + разбор решения с кандидатом (чтобы "друг" не делал всю работу).

2️⃣ Техлидам: рефлексия вместо допросов
• Где в собесе точки остановки? Говорить "нет"?
• Что реально должен знать trainee в 2025?
• Избегать сценария "допрос vs бесплатная лекция"?

P.S. Ваша смелость + честное "не знаю" + готовность впитывать — вызывают уважение. Учитесь — и возвращайтесь!

#HR_процессы #Собеседования #Trainee #Менторинг #Рефлексия
#Человечность #JuniorDev #КарьерныйРост

Почему мой блог о C++ не будет выходить каждый день

Меня последнее время преследует одно чувство. Хочешь вести свой блог, писать о том, что волнует. Но идеи, развернутые в пост не приходят. Возможно и сил писать ежедневно просто нет. Вести свой блог - это не должно стать тем самым состоянием, которого все боятся. Думаю, я не буду писать все о метапрограммировании, скорее напишу, как использовал сам constexpr. Постараюсь не писать книгу про многопоточность, как Райнер Гримм. Напишу про разницу между conditional variable и применение мьютексов. Мои первые 20-30 постов будут сырыми как raw pointers . Хочу создать свой уникальный путь, а не очередной учебник. Может быть в итоге собрать вокруг себя единомышленников, как хотел когда-то мой приятель в школе. Напишу пару новостных постов, например о том, что вышел ремастер MGS3, или про то, как устроено PS3. Или о том, что андроид хочет запретить установку через apk-файлы, и как подобраться к сборке AOSP, или Kiwi Browser. Посты будут выходить раз в две недели, по пятницам. Без суеты.

#тимлид #cplusplus #разработка #карьера #блогинг #менторство

Важность планирования на планшете.

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

Сейчас набирает популярность open-source сервис excalidraw.com Его применение все чаще можно встретить у блоггеров в видео на ютубе.
Простой инструмент удобный, collaborative, можно с командой в реальном времени рисовать, а потом ссылку кинуть — и всё работает без регистрации. 

В каком то смысле, это и есть тот планшет со схемами, о котором говорил Щедровицкий в #лек_5. В посте о важности схем приведены конкретные цитаты.

Например, нужно структурировать сложные, разрозненные идеи и донести их до команды/менеджера/себя самого. Стандартные инструменты (тот же Confluence) для этого слишком формальны и негибки.

А тут перед тобой открывается простой минималистичный холст, в котором можно писать текст, добавлять различные фигуры (ромб, квадрат, круг). Писать внутри них. Соединять стрелками. При последующем перемещении стрелки магнитятся к краям фигур и могут перемещаться вместе с ними. Можно вставить картинку, видео с ютуба, которое будет in place проигрываться.

Но мне могут возразить:
Рисовать схемы вручную? В 2024-том? Это же так... Долго. Я промптом в GPT-4o или Claude прошу: «нарисуй диаграмму последовательности для микросервиса аутентификации на C++ с использованием JWT и Redis для кеширования». И через 10 секунд получаю готовую, идеальную диаграмму в PlantUML или Mermaid. Я её потом только немного кастомизирую. Зачем тратить время на ручное рисование, если ИИ может сделать это за меня и, возможно, учесть нюансы, о которых я даже не подумал? Ваш Excalidraw — это крутой костыль, но будущее за prompt-based design.

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

Услышал на стриме у Декабриста

Все знают, что резюме проверяют с помощью ИИ.

при этом все знают, что резюме пишут с помощью ИИ.

Поэтому они с помощью ИИ проверяют, чтобы резюме не было написано с помощью ИИ.

Ох...

Но при этом они знают, что можно руками подредактировать резюме, которое написала ИИ, и его все равно не заметит система... Вот это да!

Внезапно Linux не грузится и показывает странную консоль initramfs> после сбоя? Не паникуйте. Это не крах — это система просит вас о помощи.

Помните: это не ошибка, а аварийный режим для вмешательства. Ваш шанс проявить себя.

ПЛАН (что делать):
1. В строке initramfs> пробуем команду fsck -y /dev/sda1 (чаще всего sda1, но может быть nvme0n1p2 и т.д., можно посмотреть ls /dev).
2. Если просит — жмём y (yes). Ждём завершения.
3. Пишем exit и пробуем загрузиться. В 90% случаев этого хватает.

Готово? Система запустилась? Вы только что вручную починили файловую систему! Теперь можно выдохнуть и разобраться в сути.

А ЧТО ЭТО БЫЛО?

Initramfs — Это мини-ОС в оперативке, чья задача — подготовить всё для загрузки основной системы. Если он не справляется и зовёт вас, причины обычно в этом:

▫️ ФС была повреждена (самое частое после сбоя питания)
▫️ Не может найти корневой диск (проблема с драйверами или конфигом)
▫️ Аппаратный сбой (отходит шлейф, умер диск)

Ваша реакция на initramfs> — это и есть то, что отличает специалиста от пользователя. Вы не переустанавливаете систему с нуля, а чините и подкручиваете её. Это ценный навык.

Для студентов: Любой сбой — это возможность глубже понять систему и прокачать скиллы. Возможность стать тем, кто расскажет о себе и про это на следующем собесе.

#linux #admin #восстановление #hardcore #timely_advice #собес

Смотрел сегодня мок-собесы и увидел совместную реализацию двух паттерное.

1. Первый - такназываемый «синглтон Мейерса»

Этот паттерн особенно подходит для управления доступом к ресурсам, таким как конфигурационные файлы, аппаратные интерфейсы, логгеры, или управление состоянием для всего приложения.

Это идиома реализации синглтона в C++, предложенная Скоттом Мейерсом. Она использует статическую локальную переменную внутри функции-геттера:

class Singleton {
public:
    static Singleton& instance() {
        static Singleton s_instance;
        return s_instance;
    }

private:
    Singleton() = default;
    ~Singleton() = default;
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;
};

Какие особенности есть у этого похода:

- Ленивая инициализация: объект создаётся при первом вызове instance().

- Автоматическая корректная деинициализация: деструктор вызывается при завершении программы.

- Потокобезопасность (в C++11 и выше): стандарт гарантирует, что инициализация статической локальной переменной атомарна и потокобезопасна.

Доступность: к открытым методам такого класса можно получить доступ из любой точки мира, при условии, что вы включили заголовочный файл в другие файлы проекта с помощью #include.

2. CRTP (Curiously Recurring Template Pattern)

CRTP — это идиома, где базовый класс принимает в шаблоне тип производного класса:

template <typename Derived>
class SingletonBase {
public:
    static Derived& instance() {
        static Derived s_instance;
        return s_instance;
    }

protected:
    SingletonBase() = default;
    ~SingletonBase() = default;
};

class MySingleton : public SingletonBase<MySingleton> {
    friend class SingletonBase<MySingleton>; // чтобы конструктор был доступен
private:
    MySingleton() = default;
};

Преимущества данного похода

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

#singleton #design_patterns #crtp

Точечные оценки — красивая ложь

Проект займёт 14 недель

— слышали такое?
Я слышу это постоянно. И каждый раз внутри меня что-то сжимается 😅
Эта цифра создаёт иллюзию точности. Как будто кто-то заглянул в будущее и увидел дату релиза. Реальность: это одна из тысяч возможностей.

Помню, как в одном проекте менеджер с уверенным видом объявил:

12 недель, не больше

Спойлер: проект занял 22 недели.

И знаете, что самое интересное? Никто даже не удивился. Все молча кивнули и продолжили работать, как будто так и было задумано.

Точечная оценка без вероятности бессмысленна.

Она подразумевает 100% гарантию, хотя в разработке нет ничего гарантированного.

Три понятия, которые путают:
Оценка — вероятностный прогноз
Цель — желаемый результат
Обязательство — договорённость с учётом рисков

Когда менеджер говорит «14 недель», спросите: «Какова вероятность этого числа? 50%? 30%? 10%?»

Я начал задавать этот вопрос на каждой встрече. Сначала на меня смотрели как на человека, который усложняет простые вещи. Потом начали понимать. А потом — сами стали говорить в диапазонах и вероятностях.

Без ответа цифра остаётся пустым звуком.
Или, как я люблю говорить — красивой ложью, которая всех устраивает. До момента, когда дедлайн пролетает мимо, а релиза всё нет 🙃

А как у вас в команде с оценками? Говорите диапазонами или всё ещё верите в магию точных цифр?

Асимметрия реальности

Многие представляют сроки проекта как колоколообразную кривую - симметричное распределение вокруг среднего (как нормальное распределение Гаусса).
Это неправда.

Знаете, что меня всегда удивляло? Как упорно люди верят в эту красивую симметрию. Я сам когда-то так думал, пока не словил пару болезненных уроков в моем проекте 😅
Существует предел того, насколько быстро команда может работать. Левая сторона графика обрезана - нельзя писать код быстрее физических возможностей.

Помню, как менеджер спросил меня: «А если мы добавим ещё разработчиков?» Я ответил: «Девять женщин не родят ребёнка за месяц». Он не оценил мою метафору, но суть понял 🙃

А вот количество проблем ничем не ограничено:

Критические баги в продакшене
Уход ключевого разработчика
Изменение требований на 80% готового проекта
Проблемы с инфраструктурой
Интеграция, которая «должна была работать из коробки»

Эти пункты - не теория. Это список из моего последнего квартала. Причём все пять случились в ОДНОМ проекте. Одновременно. Я до сих пор не понимаю, как мы выжили 😁
Результат: график вероятностей имеет короткий левый хвост и длинный правый.
Медиана (точка 50/50) показывает: половина проектов завершится раньше, половина - позже. И эта «половина позже» может растянуться ОЧЕНЬ далеко.
Самый долгий проект в моей практике должен был занять 3 месяца. Закончили через 11. И нет, это не провал - это просто реальность, в которой работают разработчики.


А у вас был такой проект-долгострой? Сколько в итоге длился и что пошло не так?

Иллюзия 90% уверенности

Эксперимент: людям дали тест из 10 вопросов. Нужно указать диапазон ответа с «90% уверенностью».
Результаты:

Средний балл: 2.8 из 10
Только 2% получили 8+ правильных ответов
Никто не ответил верно на все 10

Когда я впервые прочитал про этот эксперимент, подумал:

Ну это же они, обычные люди. Мы-то в IT поумнее

Провёл похожий тест в своей команде. Угадайте результат? Правильно, точно такой же провал 😅

Вывод: интуитивное ощущение «90% уверенности» на деле соответствует примерно «30% уверенности».

То же самое в проектах. Команды регулярно представляют графики с «90% уверенностью» и регулярно их превышают — в 50-60% случаев, а не в 10%.

Был у меня один тимлид, золотой человек. На каждой планёрке: «Я на 90% уверен, что закончим к пятнице». Знаете, сколько раз из десяти он укладывался? Три. ТРИ, Карл! Это вообще 30%, а не 90%.
Я его спросил:

Слушай, а ты понимаешь, что значит 90%?

Он посмотрел на меня и честно ответил:

Ну... я просто так чувствую

Вот она, вся наша «уверенность» 🙃

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

Сейчас, когда кто-то в команде говорит «я на 90% уверен», я достаю блокнот и говорю:

Отлично! Давай запишем. Будем проверять калибровку твоей уверенности

.Обычно после этого люди начинают говорить более честно: «Ну... наверное, половина на половину» 😁

А вы когда-нибудь ловили себя на таком? Говорили «я уверен на 90%», а потом оказывалось совсем не так?

Конус неопределённости

Точность оценок меняется предсказуемо на разных этапах проекта.

Погрешность по этапам:

Первоначальная концепция: ±300% (диапазон 0.25x - 4x)
=> Оценка «100 дней» = реально 25-400 дней

Утверждённое определение: ±100% (0.5x - 2x)
=> «100 дней» = 50-200 дней

Завершённые требования: ±50% (0.67x - 1.5x)
=> «100 дней» = 67-150 дней

Детальное проектирование: ±10% (0.9x - 1.1x)
=> «100 дней» = 90-110 дней

Помню встречу с инвесторами на самом старте проекта. Они спросили: «Сколько времени займёт разработка?» Я честно ответил: «От трёх месяцев до года». Знаете, что они сказали? «Нам нужна точная цифра».
Я нарисовал им этот конус на доске. Объяснил про ±300%. Они посмотрели друг на друга и снова: «Ну хорошо, но примерно?»
В итоге я сказал «полгода», они записали это как обязательство, и через восемь месяцев были очень удивлены 😅

Эталонная точность ±10% достигается только на финальной стадии проектирования.

То есть когда проект практически готов. Парадокс, да? Когда тебе больше всего нужна точность - в самом начале - её меньше всего. А когда она наконец появляется - уже всем всё равно, потому что релиз через неделю.

Критично: Конус представляет ЛУЧШУЮ возможную точность для квалифицированных оценщиков. Хуже — легко. Точнее - только случайно.

Это моё любимое. Видел я команды, которые на стадии «у нас есть идея» давали оценку с точностью до дня. Спрашиваю: «Ребят, а как вы так точно посчитали?» Ответ: «Ну, мы подумали».

Подумали. На стадии ±300% погрешности. И самое грустное - иногда они попадают в цель. И потом годами рассказывают, какие они крутые оценщики, не понимая, что им просто повезло 🙃
Сейчас я всегда показываю этот конус заказчикам в самом начале. Да, некоторые уходят искать того, кто «оценит точнее». Но те, кто остаётся, понимают игру и работать с ними - одно удовольствие.

А вы встречали людей, которые требуют точных оценок на стадии концепции? Как с ними разговариваете?

Привет!
Кажется нашел нормальное чтиво по работе.