backend_interviewer | Неотсортированное

Telegram-канал backend_interviewer - Backend Interviewer

1273

Как успешно пройти backend собеседование и получить лучший оффер

Подписаться на канал

Backend Interviewer

Как я учился говорить "нет" менеджерам и не чувствовать себя мудаком

Менеджер пишет:

Там мелкая доработка, надо просто поле добавить. Сможешь сегодня?


И я говорю "да".

Через полчаса:

Срочно надо пофиксить расчёт формулы, иначе отчёты не сходятся


Я снова говорю "да", потому что умею в многозадачность.

Но вечером я понимаю, что:

– не сделал свою задачу из спринта
– злюсь на всех
– и сам виноват, потому что никому не сказал "нет"

Почему говорить "нет" сложно

– Хочешь быть надёжным
– Боишься показаться не командным
– Боишься, что скажут: «он токсичный»
– Или просто не хочешь конфликта

Но в итоге ты теряешь фокус, скорость, мотивацию.

И постепенно превращаешься в человека, на которого всё скидывают на всякий случай.

Что я начал делать

1. Спрашивать про приоритеты

Я не говорил "нет". Я говорил: «У меня сейчас задача Х. Это важнее?»

Обычно это ставит менеджера в режим выбора, а не давления.

Он либо говорит «ладно, потом», либо помогает снять что-то из текущего.

2. Выводить цену вопроса

«Ок, но это займёт полдня. Мы сдвигаем релиз фичи?»
«Ок, но тогда не будет покрытия тестами – норм?»

Менеджер начинает думать. А не просто кидать хотелки.

3. Заранее обозначать зону ответственности

«Я не буду поддерживать это в проде – давайте назначим владельца»
«Я могу помочь, но не беру это на себя полностью»

Ты просто честно обозначаешь, что можешь, а что нет.

Что поменялось

– Я стал спокойнее
– Мой день стал предсказуемым
– Я наконец начал делать то, что запланировал
– И, что неожиданно: менеджеры стали уважать это, потому что у них тоже есть задачи, сроки и нервы

Вывод

Говорить "да" – легко.
Говорить "нет" – трудно.

Но трудное "нет" сегодня – спасает тебя от сгоревшего "я увольняюсь" завтра.

Это не про конфликты. И не про борьбу с бизнесом.

Это про выгорание, здравый смысл и то, что никто, кроме тебя, не поставит границы.

Читать полностью…

Backend Interviewer

Что происходит, когда мы пишем new в Java: от байткода до оптимизаций

Кажется, мы просто создаём объект:

var user = new User();


Но под этой строчкой скрыт целый каскад операций внутри JVM: от байткода и выделения памяти до вызова конструктора, настройки объекта и запуска JIT-оптимизаций.

Разберём весь процесс пошагово.

Шаг 1. Компиляция в байткод

Чтобы JVM могла исполнять код, он сначала компилируется в байткод.

Строка var user = new User() превращается во что-то вроде:

0: new #2
3: dup
4: invokespecial #1
7: astore_1


new – резервирует место в heap, но не вызывает конструктор.

dup – после new ссылка на объект оказывается на вершине стека. dup нужен, чтобы использовать её дважды: и для вызова конструктора, и для присваивания переменной.

invokespecial – вызывает <init>-метод (конструктор).

astore_1 – сохраняет ссылку в переменную user.

Шаг 2. Выделение памяти в heap

Когда JVM встречает команду new, она просит менеджер памяти выделить место под объект. Обычно объект попадает в Eden (часть Young Generation).

Есть два пути.

Быстро: через TLAB (Thread Local Allocation Buffer)

Если у потока есть TLAB (специальный буфер в Eden для быстрой аллокации), объект создаётся без синхронизации.

Просто смещается указатель: nextFree += objectSize.

Почти так же, как malloc в C, только безопаснее.

Медленно: с синхронизацией

Если буфер заполнен, происходит более дорогая аллокация: с блокировками и участием GC (если мало места). Возможно, произойдёт Minor GC.

Шаг 3. Инициализация объекта: header и zeroing

Перед тем как конструктор выполнится, JVM инициализирует внутренние структуры объекта.

Mark Word – служебная информация: hashCode, флаг GC, состояние блокировки.

Class Pointer – ссылка на метаданные класса (Class<?>).

Zeroing – все поля объекта инициализируются значениями по умолчанию (0, null, false).

В этот момент объект уже существует, но он ещё "пустой". Конструктор не выполнялся.

Шаг 4. Вызов конструктора (<init>)

Теперь JVM вызывает конструктор через invokespecial.

Конструкторы родительских классов вызываются первыми.

Порядок важен: сначала родитель, потом поля, потом логика конструктора.

Шаг 5. Присваивание переменной

После вызова конструктора ссылка на объект остаётся на вершине стека.

Её можно:

– сохранить в переменную (var user = ...)
– передать в метод (someMethod(new User()))
– или не использовать вовсе (будет кандидатом на GC)

Шаг 6. Оптимизации от JIT

На этом этапе JVM может вмешаться и оптимизировать создание объекта, особенно если мы много раз создаём один и тот же тип объектов в горячем методе.

Escape Analysis

JVM анализирует: уходит ли объект за пределы метода?

Если нет – можно не выделять память в heap и положить объект в стек (stack allocation).

Если JVM докажет, что объект локален – он даже не будет существовать в памяти как полноценный объект.

Scalar Replacement

Если объект используется как набор примитивов, JVM может вообще разложить его на переменные и не создавать объект вовсе.

Inlining конструктора

JVM может встроить код конструктора прямо в место вызова. Это снижает накладные расходы вызова и помогает следующим оптимизациям (например, loop unrolling, constant folding).

Почему всё это важно

Мы можем думать, что просто вызываем new, но на деле:

– JVM аллоцирует память
– происходит инициализация внутренних структур
– вызывается цепочка конструкторов
– активируются JIT-оптимизации
– включается GC и мониторинг

Мы не должны бояться заглядывать под капот – мы обязаны это делать. Потому что именно там находятся ответы на вопросы "почему прод тормозит" или "откуда утечка памяти".

Читать полностью…

Backend Interviewer

Как учиться, когда у тебя работа, семья, дела и вообще ни на что не хватает времени

Учиться легко, когда тебе 18, ты живешь в общаге, ешь пельмени и всё свободное время твое.

Но если тебе за 25-30, ты работаешь full-time, у тебя семья, дети, ипотека, собака, кошка, больная спина и прод упал – то любая мысль о том, чтобы ещё учиться, вызывает злость, вину и выгорание.

Я устал.
У меня нет времени.
У меня нет сил.
Но я хочу лучшую работу.


Это самый частый конфликт у взрослых разработчиков.

Ты знаешь, что тебе нужно расти.

Ты понимаешь, что хочешь уйти с текущей работы.

Ты листаешь вакансии и мечтаешь: вот бы в нормальный проект, на нормальную зарплату, с нормальным стеком.

Но когда доходит до действий – тебя просто не хватает.

И ты начинаешь себя грызть:

Я слабак. У других же получается.
Наверное, не так уж и хочу.
Надо просто собраться и начать.


Спойлер: не получится.

Потому что ты всё ещё мыслишь по старому: думаешь, что нужно "выделить время", "настроиться", "войти в режим".

Это невозможно, если ты живёшь взрослой жизнью с обязанностями, семьёй и реальными делами.

Тебя всегда будет что-то или кто-то отвлекать.

Что же делать?

Главное, не нужно вгонять себя в жесткие рамки.

Это вызывает только стресс.

Никакого "по 2 часа каждый вечер".

Никакого "дойду до конца курса".

Возьми ответственность только за одно маленькое действие каждый день.

Открой один вопрос.
Подумай, как бы ты ответил.
Посмотри разбор.
Всё. На сегодня достаточно.

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

Не нужно "поднять уровень".
Нужно разобраться, чем отличается твой ответ от сеньора и понять разницу.

Далее, встраивай обучение в повседневную жизнь.

Пока едешь в машине – слушаешь аудио разбор собеса.

Ждешь ребёнка с кружка – повторяешь карточки.

Сидишь в очереди к врачу – читаешь полезные тг-каналы на тему.

5 минут, 10 минут. Это не мало. Это небольшой шаг в развитии тебя.

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

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

Именно такую среду я и создаю в групповом практикуме по подготовке к java собеседованиям.

Встречи в команде единомышленников. Максимум практики. Растёшь быстрее, чем при самостоятельной подготовке.

Ты не должен всё успевать.

Ты просто можешь делать один шаг в день.

В правильной среде. С правильной целью. С поддержкой.

Читать полностью…

Backend Interviewer

Практикум по Java собеседованиям

Весной я решил попробовать новый для себя формат подготовки разработчиков к собеседованиям.

Вместо индивидуального менторства – встречи в небольшой группе.

Я опасался, что это будет не так эффективно, как личная работа 1 на 1.

Но по завершении группового практикума, я могу с уверенность сказать, что это не так.

Нас было 7 человек, включая меня.

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

Трое уже нашли новую работу с повышением должности и дохода. Двое получили контр-офферы на текущей работе и приняли их. Один в процессе прохождения собесов. Я уверен и у него все получится.

Главный плюс, который я вижу в групповой работе – это комьюнити, которое тебя подталкивает.

Пример.

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

Когда ты один – трудно заставить себя тратить на это время.

Ментор тебя тоже не заставит. Он же не будет бить тебя палкой.

А когда ты в группе – возникает азарт.

Петя решил 30 задач, Ваня решил 40 задач, а я решил всего лишь одну – непорядок, я что ленивее других?

Более того, все разбились на пары, самостоятельно встречались и вместе решали задачки. В том числе и по системному дизайну.

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

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

Кроме того, она намного выгоднее по деньгам.

Менторство предполагает пред-оплату 10/20/30 тысяч и пост-оплату в процентах от полученного оффера – 50/100/150% в зависимости от уровня человека.

В группу же можно залететь за несколько тысяч рублей в месяц при использовании рассрочки.

Суммы отличаются в разы.

Что в итоге?

Я решил продолжить развивать формат групповой подготовки к собеседованиям:

– Переработал программу
– Увеличил количество групповых встреч до 10
– Включил проверку домашнего задания
– Добавил одну личную встречу в конце практикума для большей уверенности, что человек усвоил весь материал и готов выйти на рынок

Какие темы изучаем?

– Java (от core до virtual threads)
– Spring (от бинов до hibernate)
– SQL/NoSQL (от индексов до explain)
– Kafka (от устройства до гарантий доставки)
– Docker, Kubernetes
– Задачи на код-ревью и алгоритмы
– Паттерны проектирования
– Системный дизайн
– Soft skills (от оформления резюме до рассказа о себе)

Короче, суть в том, чтобы ты:

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

Если тебе интересен такой формат подготовки, пиши мне в личку @principal_swe

Созвонимся, обсудим все вопросы и решим подойдет ли это для тебя.

Стартуем в начале августа.

Так как это небольшая группа, то, конечно, количество мест ограничено.

Поэтому выбор – действовать сейчас или отложить – только за тобой.

Я уверен это отличный буст для любого разработчика.

Читать полностью…

Backend Interviewer

Я шёл на собеседование, а попал на допрос

Вот какую цель ставит перед собой любой адекватный интервьюер, проводя собеседование?

Правильно. Найти человека к себе в команду.

Должен ли этот человек знать 100500 фреймворков? Нет. Любой технологии можно обучить.

Должен ли этот человек молниеносно и оптимизировано решать алгоритмические задачи? Нет. Любой алгоритм требует неспешных размышлений.

Должен ли этот человек вызубрить методы класса Object? Нет. Он не энциклопедия.

Что же должен этот человек?

Да ничего никому он не должен.

Как говорят психологи, долженствование – это когнитивное искажение.

Кстати, почитайте про когнитивные искажения. Очень познавательно.

Так вот. Если тебе комфортно общаться с этим человеком, если ты видишь его рост, если ты видишь его стремления, то этого достаточно, чтобы работать с ним.

Соответственно и вопросы интервьюера должны быть направлены на это.

На опыт человека, на то как он принимает решения, как подходит к компромиссам, к решению проблем, какую ответственность он готов брать.

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

Он не спрашивает, он соревнуется.

Он не слушает, он выискивает момент, когда ты ошибешься.

Он не хочет понять, он хочет почувствовать себя крутым.

Отсюда и вопросы «А если я сделаю вот такую дичь, где будет NPE?».

Это не собеседование.

Это допрос с элементами показательного унижения.

А после – его ехидная улыбка.

Каждый день мы разгребаем дерьмо:

– запутанное легаси
– ошибки прома
– тонны фич без полной аналитики
– отсутствие архитектуры и нормального техдолга
– бесконечные митинги

И ты ещё приходишь на собеседование, чтобы расти, менять проект, доход – а тебе: «Что делает GC, если у тебя в finalize вылетело исключение?».

Серьёзно? Это то, по чему ты судишь про мой опыт?

Если ты когда-нибудь выходил с собеса с мыслью: «Я вроде сеньор… но чувствую себя идиотом» – это не ты глупый. Это интервьюер сделал глупость – не смог раскрыть тебя. А иногда – и не хотел.

В предыдущем посте вы ставили 🔥 чтобы узнать как застать интервьюера врасплох на вопросах про прокси.

Адекватного интервьюера вам и не захочется заставать врасплох. Он не даст причин.

А на неадекватного – не тратьте свои силы, время и нервы. Он того не стоит. Поблагодарите судьбу за то, что работать вы с ним не будете.

❤️ если согласен

Читать полностью…

Backend Interviewer

Что будет с твоим кодом через 250 лет?

На выходных с девушкой посетил Екатерининский дворец в Царском Селе.

Во-первых, это безумно красиво!

Благодаря колоннам и пальмам складывается ощущение будто ты в Древней Греции.

Во-вторых, это архитектурная медитация.

Ты смотришь на детали: колонны, золото, лепнину, геометрию.

Каждый зал – как модуль.

Каждая анфилада – как правильно выстроенный маршрут пользователя.

И в какой-то момент ловишь себя на мысли:

Чёрт, так ведь и с системным дизайном то же самое!


Архитектура – это не просто «как расставить сервисы»

Это про видение. Про цель, ради которой всё построено.

Про гармонию между удобством, безопасностью и масштабом.

В Екатерининском дворце:

– каждая деталь подчинена композиции
– всё выдержано в стиле и логике
– даже "излишество" не выходит за рамки структуры

И это очень похоже на хорошую продакшн-систему:

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

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

Этот дворец стоит более 250 лет.

Наш код – часто не доживает и до 3 лет.

Но...

Кто сказал, что код не может быть "дворцом"?

Просто мы часто лепим фичу на бегу, строим архитектуру на авось, а потом удивляемся, почему всё трясёт от лёгкого рефакторинга.

Как мы можем улучшить ситуацию

Давайте относиться к проектированию кода, как к проектированию дворца!

Будем уважать долговечность. Писать код, как будто его будут поддерживать через 10 лет. Даже если это не так.

Будем прививать чувство масштаба. Архитектура – это не только про "сейчас работает", а про "как это будет жить в будущем".

Будем разбавлять инженерное мышление художественным. Красота в коде – это не про "а давай красиво назовём метод", а про то, чтобы всё складывалось в ясную, логичную структуру.

Архитектура – это про ответственность


Про уважение к тем, кто придёт после тебя.

Про готовность мыслить системно и стратегически.

Даже если ты сейчас просто пишешь код и застрял в развитии, постарайся начать думать шире. Это станет отправной точкой твоего профессионального роста.

Читать полностью…

Backend Interviewer

Карточки про гарантии доставки Apache Kafka

При работе с сообщениями могут возникать различные проблемы как на стороне producer, так и на стороне consumer.

Часть проблем решается настройками на уровне Kafka, а часть - использованием определенных паттернов проектирования.

Рассмотрим:

– At most once
– At least once
– Exactly once
– Transactional Outbox
– Идемпотентный Consumer

Читать полностью…

Backend Interviewer

Почему вы хотите сменить работу?

Этот вопрос звучит на 99% собеседований.

И вот тут самая частая ошибка: кандидат начинает жаловаться.

Ну, у нас руководство странное…

Проект заморожен…

Я там вообще не расту, всё токсично…


Да, ты можешь быть прав.

Но негатив сразу снижает твою ценность.

HR думает: «Если ты ноешь тут, ты будешь ныть и у нас».

Так что давай разберём:

– почему это вопрос-ловушка
– как не испортить впечатление
– как отвечать умно, уверенно и позитивно, даже если у тебя в компании полный бардак

Зачем HR задаёт этот вопрос?

Понять, что для тебя важно.

Проверить, как ты говоришь о сложностях.

Оценить твой уровень зрелости.

Послушать, умеешь ли ты конструктивно уходить.

Что говорить нельзя (даже если это правда)

У нас ужасный менеджмент

Все уволились, и я тоже

Меня не ценят

Полный бардак, всё рушится

Я просто устал


Почему это плохо:

– ты выглядишь обиженным
– ты снимаешь с себя ответственность
– ты демонстрируешь позицию жертвы, а не взрослого профессионала

Как надо: конструктив + рост

Хороший ответ строится по формуле:

1. Что тебе дала текущая компания
2. Что ты понял о себе
3. Куда хочешь двигаться дальше
4. Почему ищешь это в новой компании

Примеры сильных ответов

Для мидла, застрявшего в рутине:

Я благодарен текущей компании – за 3 года я вырос из джуна в мидла, дебажил прод, участвовал в релизах. Сейчас я понимаю, что достиг потолка: проект стабильный, зона ответственности не меняется, стек устоявшийся. Мне хочется новых технических вызовов, больше влияния на архитектуру и возможность общаться с бизнесом. Именно поэтому я рассматриваю компании, где смогу использовать накопленный опыт и продолжать развиваться.


Для человека после сокращения:

Компания сократила команду в рамках реструктуризации. Это не связано с моей производительностью – скорее с пересмотром приоритетов. Я воспринял это как возможность выйти на рынок, переосмыслить свою траекторию и найти команду, где смогу быть полезным и продолжать рост.


Для тех, кто хочет сменить тип проекта:

В текущем проекте я много работал с внутренними сервисами, и за это время понял, что мне интереснее клиентские фичи и влияние на конечный продукт. Я ищу роль, где смогу сочетать технический опыт с пониманием бизнес-целей и влиянием на UX. Ваш проект как раз про это.


Что делать, если причина ухода токс, бардак или выгорание?

Переформулируй через "что тебе важно".

Плохо:

У нас полная анархия, всё через одно место.


Хорошо:

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


Ты не врешь. Но ты смотришь в будущее, а не жалуешься на прошлое.

Итог

Собеседование не место для жалоб.

Это место, где ты показываешь:

– чего ты хочешь
– как ты умеешь говорить о сложностях
– почему ты сильный, зрелый кандидат

Ты не "бежишь от", а "идёшь к".

Читать полностью…

Backend Interviewer

Сборка мусора: что нужно знать, а не зубрить

На собесе тебе задают вопросы:

– Какой GC вы используете на проде? Почему?
– Как вы разбирались с OutOfMemoryError?
– Что у вас в GC-логах, когда пауза 3 секунды?

И вот тут ответ «Eden → Survivor → Old Gen» уже не канает.

Потому что тебя проверяют не на термины, а на мышление и опыт.

Давай разберём, что должен уметь и понимать разработчик, чтобы не плавать на вопросах по GC.

1. GC – это не про зазубрить типы

G1, ZGC, Shenandoah, Epsilon, Parallel, CMS...

Зубрить смысла нет. Надо уметь отвечать через "зачем" и "в каких случаях".

G1 – баланс между throughput и latency, хорош для сервисов с разной нагрузкой.

ZGC – очень маленькие паузы, используется когда uptime критичен.

Shenandoah – похож на ZGC, но смещен в сторону throughput.

Сеньора отличает не знание, как называется флаг, а понимание, когда его стоит использовать.

2. Разработчик должен уметь читать GC-логи

На собесах иногда дают лог вида:

[GC pause (G1 Evacuation Pause) (young), 0.1234567 secs]
[Parallel Time: 98.7 ms, GC Workers: 4]
[Eden: 512M(512M)->0B(512M) Survivors: 32M->32M Heap: 2G(4G)->1.6G(4G)]


Тебе нужно быстро разобрать:

– Что за сборка прошла?
– Какой объём был очищен?
– Какая часть heap заполнена после сборки?
– Как часто и сколько длятся паузы?

Если ты этого не умеешь – ты не можешь анализировать прод.

3. Настройка GC – это не наугад флаги, а стратегия

Middle говорит:

Мы использовали G1, потому что это дефолт.


Сеньор говорит:

Мы использовали G1, потому что у нас SLA на паузы не выше 200ms, и через -XX:MaxGCPauseMillis добились приемлемого баланса. При этом контролировали нагрузку через метрики jvm_gc_pause_seconds в Prometheus и сигнализировали при росте p99 выше 100ms.


4. Нужно уметь разбирать утечки и OOM-ошибки

У тебя сервис с 4GB heap.

Через сутки OutOfMemoryError.

Что делать?

Плохой разработчик: увеличит heap до 8GB.

Хороший: сделает heap dump, проанализирует кто живёт слишком долго, проверит GC-логи.

5. Нужно понимать не только GC, но и его связь с кодом

– Лямбды могут удерживать ссылки?
– Внешние классы зависят от внутренних?
– Пул потоков может хранить таски вечно?
– ThreadLocal может стать причиной OOM?

Сборщик мусора не магия.

Он просто не может удалить то, на что кто-то всё ещё ссылается.

6. Advanced-моменты, которые тебе стоит изучить

– Как TLAB влияет на производительность
– Large Object Allocation
– Concurrent Phase vs Stop The World
– GC barriers
– Как GC влияет на latency в микросервисах
– Какие аллокаторы используются в off-heap библиотеках наподобие netty
– Использование -XX:+PrintReferenceGC для диагностики утечек через Soft/Phantom ссылки

7. Что говорить на собесе, если GC спрашивают глубоко

Правильная стратегия – говорить через практику:

У нас были скачки пауз до 2 секунд. Мы посмотрели GC-логи, заметили, что Full GC шёл каждые 30 минут. Оказалось – утечка через кэш без лимита. Ограничили по размеру, добавили метрики и алертинг – всё стабилизировалось.


Если ты рассказываешь реальную историю – это ценится в 10 раз выше, чем просто описание алгоритма mark&sweep.

Вывод

GC – это не "обязательная теория", а часть практики.

Ты должен уметь:

– объяснять GC архитектуру на пальцах
– понимать, как GC взаимодействует с твоим кодом
– диагностировать проблемы продакшена

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

Читать полностью…

Backend Interviewer

Почему даже плохой код лучше, чем никакой

Начнём с простого вопроса: ты когда-нибудь писал говнокод?

Не в смысле «ой, забыл валидацию».

А вот прям настоящий, липкий, позорный.

Я писал.

Ты писал.

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

Как-то мы делали интеграцию с внешней системой.

По тестам – всё огонь. Как только вывели в пром – кошмар.

Внешняя система не принимала некоторые поля. Иногда. Без причины.

Ошибки рандомные. Логи непонятные. Поддержка молчит.

Откатывать было невозможно.

Пока мои коллеги ставили брейкпоинты, бизнес терял сотни заказов в час.

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

Поэтому я написал максимально тупой цикл, в котором делал переотправку запроса, если предыдущий завершился ошибкой.

Да, это был код уровня "больно смотреть".

Но именно он спас компанию от убытков.

Никакой код = никакого результата.

Вот простая математика:

Идеальный код, не готовый вовремя – бизнес терпит убытки. Тебе нечем платить зарплату.

Грязный, но рабочий фикс – бизнес делает продажи. Ты получаешь премию.

Плохой код – не преступление. Он следствие.

Вот когда появляется плохой код?

– Когда сроки горят
– Когда бизнес не может ждать архитектурных сессий
– Когда данных мало, требований ноль, а надо "вчера"
– Когда ты впервые трогаешь чужой монолит
– Когда ночью прод лег, а CTO смотрит тебе в душу

В этих условиях ты не кодишь красиво.

Ты спасаешь ситуацию.

Но ты не должен останавливаться на этом.

Плохой код без исправления – это лень.

Плохой код с последующим рефакторингом – это техдолг.

Проблема не в плохом коде. Проблема в стыде.

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

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

Итог: действуй – потом улучшай

Сделай, чтобы работало.

Сделай, чтобы было правильно.

Сделай, чтобы было красиво.

Если ты начнешь с шага 2,
шанс, что ты вообще что-то выпустишь, будет стремиться к нулю.

Научись принимать компромиссы осознанно.

Читать полностью…

Backend Interviewer

10 вопросов, которые я задаю себе перед код-ревью

Чтобы быть не формальным ревьюером, а настоящим наставником.

Когда я только начинал делать код-ревью, я думал:

Моя задача – найти баги и указать на нарушение code style


Сейчас я знаю:

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


Именно после нескольких факапов в проде (после моего "одобрено!") я выработал для себя 10 вопросов, которые теперь задаю себе при каждом ревью.

1. Понимаю ли я, что делает этот код – сразу, без контекста?

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

Я не двигаюсь дальше, пока не понял.

Если мне – более менее опытному человеку – непонятно, как это работает, что будет с тем, кто будет это дебажить через полгода?

2. Где тут может случиться баг?

Я смотрю не на happy path, а на всё, что может пойти не так:

– Что если коллекция пустая?
– Что если null?
– Что если придёт плохой json?
– Что если база вернёт 0 строк?
– А если api даст 500?

Одна из самых ценных привычек – думать как "злой пользователь".

Ты не враг автору кода. Ты его страховой полис.

3. Что случится, если этот код вызовется 1000 раз в секунду?

Производительность важна не тогда, когда сломалось, а до этого.

Я всегда задаю вопрос:

– Насколько этот код тяжёлый?
– Не делает ли он много запросов в базу?
– Нет ли вложенных filter() или map() в цикле?
– Нет ли рекурсии без ограничений?

4. Есть ли тут неожиданные побочные эффекты?

Я смотрю, не изменяет ли этот код глобальные состояния:

– Не пишет ли он в базу там, где ожидается просто чтение?
– Не мутирует ли DTO?
– Не вызывает ли сторонние сервисы, где их никто не ждал?

Хороший код – предсказуем. Плохой – с сюрпризами.

5. Этот код вообще тестируемый?

Я задаю себе вопрос:

– А могу ли я протестировать эту бизнес-логику без запуска всего Spring Boot?
– Можно ли покрыть это юнит-тестами или только e2e?
– Нет ли зависимости от static/new/System/Clock/UUID.randomUUID()?

Если код не тестируемый – его нужно дорабатывать.

6. Этот код действительно нужен?

Один из самых полезных вопросов.

Иногда люди переусложняют,
дублируют уже существующее,
пишут utility-классы вместо того, чтобы использовать стандартные api.

Я спрашиваю: а можно ли этого вообще не писать?

Удаление ненужного – высший навык программиста.

7. Этот код вписывается в архитектуру и стиль проекта?

– Не нарушены ли границы (например, репозиторий, который вызывает RestTemplate или UI вдруг тянет Entity)?
– Названия, формат, структура – соответствуют ли общему стилю?

Код, выбивающийся из общей картины, становится очагом хаоса.

8. Что произойдёт, если это выкатится в прод?

Я мысленно делаю шаг вперёд:

– Нет ли потенциальных рисков?
– Все ли граничные кейсы продуманы?
– Есть ли логирование, чтобы отследить поведение?
– Алерты сработают, если что-то пойдёт не так?

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

9. Кто будет это поддерживать через год?

Я представляю ситуацию: приходит новый разработчик, открывает этот класс – и ничего не понимает.

Смотрит на метод processDataAndSaveIfValid(), в котором 80 строк, и там происходит магия.

Я задаю себе вопрос: а что будет, если на месте этого разработчика окажусь я сам?

Буду ли я ругать коллег за этот код?

Если да – я должен это сказать автору PR.

10. Этот код – повод для гордости или источник стыда?

Это финальный субъективный вопрос.

Если бы этот код написал ты – ты бы хотел, чтобы его показывали на митапе как пример хорошей практики?

Если да – апрув.

Если нет – не молчи.

Автор будет благодарен. Через время.

Вместо вывода

Плохое ревью – это «ну вроде норм», «там стиль поправь», «сделай красиво».

Хорошее ревью – это диалог, наставничество, совместное улучшение кода.

Ревью – это не поиск виноватого. Это коллективная инженерная зрелость.

Читать полностью…

Backend Interviewer

Ты не обязан быть гением, чтобы стать сильным разработчиком

Я помню тот день очень хорошо.

Конец осени. Холодно, темно.

Я сижу в офисе на старом скрипучем стуле.

На экране передо мной – стена ошибок в логе.

Я туплю в код уже четвёртый час.

Все коллеги давно ушли домой. В коридоре пусто.

И в голове крутится одна навязчивая мысль:

Может, это не моё?


В те времена я всерьёз думал, что настоящий разработчик – это нечто сверхъестественное.

Тот, кто с лёта пишет без багов.

Тот, кто понимает многопоточность, как дыхание.

Тот, кто на собеседовании цитирует "Effective Java" без запинки.

А я?

Я не мог сходу объяснить, как работает HashMap.

Я забывал закрывать ресурсы в try-catch-finally.

Я писал код, который работал, но выглядел как каша.

И мне казалось:

Если я не могу всё понять сразу, значит, я недостаточно умен для этой профессии


Но потом произошла маленькая вещь, которая изменила мой путь.

Однажды архитектор из моей команды задержался допоздна в офисе.

Увидев его за монитором, я подошел к нему и поинтересовался что случилось.

Оказалось, что он не учел некоторые небольшие, но существенные требования к системе в процессе проектирования архитектуры.

Но архитектура была уже утверждена. Девопсы начали настраивать железки, разработчики писать код.

Архитектору предстояло сказать всем этим людям, что всё что они сделали нужно выкинуть и сделать по новому.

Если такой умный, опытный, уважаемый человек тоже ошибается, то что уж говорить про мои ошибки?

Тогда я понял:

Ошибки – это не признак глупости.

Ошибки – это доказательство того, что ты учишься.

С тех пор я стал по-другому смотреть на процесс обучения.

Я понял, что сила разработчика не в том, чтобы сразу знать правильный ответ.

Сила в другом:

В умении признать, что чего-то не знаешь.

В умении копать глубже, а не бросать на полпути.

В умении превращать свои баги в ступени роста.

Сегодня, спустя годы:

Я проектировал системы с тысячами rps.

Я поднимал продакшн после падений.

Я собирал и готовил команды к переходу на новые архитектуры.

И всё это – не потому, что я когда-то был гением.

А потому что я не сдался тогда, в ту холодную осеннюю ночь, когда на меня смотрела бездушная стена стек трейсов.

Мой совет тебе, если ты сейчас сомневаешься:

Не бойся выглядеть глупо. Бояться надо только остановиться в росте.

Не сравнивай себя с другими. У каждого свой ритм, свои ошибки, свои маленькие победы.

Ты не обязан быть гением, чтобы стать сильным разработчиком.

Ты обязан быть упорным. Настойчивым. Жадным до знаний.

И самое главное:

Каждый баг – это ценный шаг твоего профессионального становления.

Читать полностью…

Backend Interviewer

Spring как алхимия

С ностальгией вспоминаю свой первый раз, когда я открыл исходники рабочего проекта на Spring.

Классы с десятками зависимостей, полей и аннотациями: @Service, @Autowired, @Qualifier, @Value, @PostConstruct...

Все это выглядело сложно, непонятно, но так завораживающе.

Тогда у меня пролетела мысль, что Spring это алхимия джавистов.

Суди сам.

1. Магические символы

Алхимики верили в силу символов.

Мы – в силу @Transactional, @Bean, @Scheduled, @ConditionalOnMissingBean.

Поставил аннотацию – и вуаля, мир изменился. Или сломался.

2. Эликсир жизни

В алхимии искали философский камень.

В Spring мы ищем способ "оживить" зависимости через IoC-контейнер.

ApplicationContext.getBean() – современный аналог древнего эликсира.

Вытаскиваешь сущность из эфира и она оживает с нужными зависимостями.

3. Тайная лаборатория

Помнишь xml-конфигурации?

Тайные книги заклинаний.

А теперь java-конфигурации: @Configuration, @Bean.

Всё как в старых манускриптах.

4. Побочные эффекты

Как и в алхимии, эксперимент может неожиданно взорваться.

Написал @Transactional – но метод private? Извините, магия не работает.

5. Оккультные знания

В каждом проекте есть один человек, который понимает, почему всё работает.

Он не пишет код. Он заклинает ApplicationContext.

И когда его нет, система перестаёт работать. Потому что никто не знает, почему этот @ComponentScan искал в другом пакете.

Как алхимия переросла в химию, так и Spring перерос из магии xml и прокси в чёткую конфигурацию и зрелую модульность.

Но дух алхимии остался. Потому что в головах все еще витает вера, что если правильно расположить бины, то случится чудо.

Читать полностью…

Backend Interviewer

Не ронял прод в пятницу вечером – не мужик

Это была обычная пятница.

Мы только что выкатили новый релиз нашего микросервиса, который отвечал за расчёт скидок в реальном времени.

Всё прошло гладко – автотесты зелёные, CI/CD прошёл без ошибок, мониторинг молчит.

Можно было спокойно закрывать ноутбук и врываться в вечер пятницы.

Но я решил "быстренько" выкатить одну маленькую правочку. Самую безобидную.

Фронт тоже выкатил новую версию и попросил сделать небольшое изменение – если скидка по акции не рассчитывается, нужно вместо null возвращать 0.

Казалось бы, мелочь.

Я открываю код, правлю один метод, пушу.

Code Review?

А зачем, это же фигня. Всё работает, я написал юнит тесты.

Вливаю PR в trunk, выкатываю на прод – и… пошёл гулять.

Спустя 40 минут мне звонит тимлид: «Ты что-то выкатывал? У нас метрики конверсии ушли в ноль»

Я захожу в Kibana – вижу шквал 500-х. Буквально шквал. Что-то точно пошло не так.

Открываю логи – NullPointerException в самом неожиданном месте.

И тут до меня доходит: моя "маленькая правочка" поменяла контракт.

Раньше discount == null обрабатывался особым образом на фронте. Теперь discount == 0 означает "нет скидки", но фронт это не понял и начал считать "скидка 0%, значит, акция есть" – и показывать баннер.

Но сам баннер вёл на несуществующий оффер.

Пользователи кликали, получали ошибку и уходили.

Подождите, но ведь фронт сам попросил сделать эту правку. Почему не работает?

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

Упущенные за вечер заказы: минус 20% к дневной выручке.

Нервный откат.

Испорченный вечер пятницы.

И моё собственное осознание: нет "маленьких" изменений в проде, особенно в пятницу.

Что я сделал после:

1. Релизы в пятницу вечером только после согласования всех участников продукта
2. Запрет вливать в trunk свои собственные PR
3. Прикрытие feature toggle даже "безопасных" правок

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

Читать полностью…

Backend Interviewer

Самые тупые ошибки, которые ломают даже сильных кандидатов

Ты можешь быть отличным разработчиком.

Ты можешь знать java, spring, kafka, kubernetes и ещё кучу технологий.

Ты можешь даже решать leetcode hard с закрытыми глазами.

Но всё равно проваливать собеседования.

Почему?

Потому что есть тупые ошибки, которые ломают даже сильных кандидатов.

Сегодня разберём, какие ошибки убивают твои шансы на оффер.

1. Говорить слишком мало или слишком много

Ошибка 1: отвечать коротко, как на допросе.

Интервьюер: «Работали ли вы с микросервисами»

Кандидат: «Да, работал»

Ну и что интервьюеру с этим делать?

Правильный ответ:

Я работал с микросервисной архитектурой последние 2 года. В одном проекте мы перевели монолит в микросервисы, и это сократило время развертывания с 30 минут до 5. Могу подробнее рассказать про реализацию.


Отвечай структурно и содержательно. Не слишком коротко, но и не лей воду.

2. Не уточнять вопросы

Ошибка 2: пытаться сразу отвечать, даже если не понял вопрос.

Интервьюер: «Как бы вы организовали кеширование?»

Кандидат: «Ну, можно Redis поставить»

А если это мобильное приложение?

А если это распределённая система с двумя дата-центрами?

Что делать?

Спрашивать!

Уточняй детали, не бойся задавать вопросы.

3. Бояться сказать «я не знаю»

Ошибка 3: пытаться выдумать ответ, если не знаешь.

Интервьюер: «Как работает Raft-консенсус?»

Кандидат: «Эээ… ну… это что-то про репликацию данных…»

Если ты начал нести ерунду, интервьюер сразу это поймёт.

Что делать?

Честно говоря, я не углублялся в эту тему. Но если это важно, могу быстро разобраться.


Лучше честно сказать «не знаю», чем пытаться выкрутиться и выглядеть глупо.

4. Провалить самый простой вопрос — «расскажите о себе»

Ошибка 4: рассказывать скучно и без структуры.

Кандидат: «Я работал с java, spring, делал микросервисы, писал api…»

Так рассказывают все.

Что делать?

Говорить через ценность.

Я backend-разработчик с 4 годами опыта, специализируюсь на масштабируемых сервисах. В последнем проекте я ускорил работу api в 3 раза и помог внедрить Kubernetes, что снизило расходы на инфраструктуру на 20%.


Продавай себя через достижения, а не через перечисление технологий.

5. Не готовиться к вопросам про бизнес

Ошибка 5: думать, что собеседование — это только про код.

Интервьюер: «Как бы вы оценили эффективность вашей команды?»

Кандидат: «Ну… мы писали код и закрывали задачи…»

Что делать?

Мы измеряли эффективность через lead time и количество деплоев. Когда я пришёл в команду, у нас было 1 релиз в месяц, а потом мы оптимизировали процессы и сократили цикл до 1 релиза в день.


Понимай не только технологии, но и то как они влияют на бизнес.

6. Никак не готовиться к вопросам «Почему вы уходите?»

Ошибка 6: начинать ныть про бывшую компанию.

Кандидат: «Там были плохие процессы, токсичный менеджмент…»

Правильный ответ:

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


Фокусируйся на будущем, а не на жалобах.

7. Согласиться на первый же оффер без переговоров

Ошибка 7: думать, что предложенная зарплата — это предел.

Рекрутер: «Ваш оффер – 200 тыс.»

Кандидат: «Окей, беру!»

А если бы ты попросил 250 тыс.?

Что делать?

Спасибо за предложение! На основе рынка и моего опыта я рассчитывал на 230–250 тыс. Есть ли возможность пересмотреть?


Всегда торгуйся, даже если оффер хороший.

Итог: как не слить оффер на ровном месте

1. Отвечай чётко и по делу, не молчи и не лей воду
2. Уточняй вопросы, если не понял — это нормально
3. Не бойся сказать «я не знаю», но показывай, что готов разобраться
4. Готовь хорошую самопрезентацию — «расскажите о себе» решает больше, чем ты думаешь
5. Понимай бизнес, а не только код
6. Говори про будущее, а не жалуйся на старую компанию
7. Всегда обсуждай оффер, даже если он кажется хорошим

Читать полностью…

Backend Interviewer

Как говорить про проект на собеседовании: 3 удачные схемы

Что делает большинство?

Ну… это был корпоративный портал. Мы там использовали Spring. И делали интеграцию с 1С. Я там пилил фичи.


Скучно, без фокуса, без смысла.

Даже если человек реально писал сложные вещи – этого не видно.

Я предлагаю использовать одну из трёх схем, которые превращают рассказ в сильную демонстрацию своего уровня.

Схема 1: Боль – Роль – Архитектура

Боль: С чем пришел бизнес? В чем была проблема, вызов, ограничения?
Роль: Что делал лично ты? Какие решения принимал?
Архитектура: Как ты это реализовал технически?

Бизнес хотел ускорить расчёт скидок в корзине: было слишком медленно, 3+ секунды. Я переписал калькулятор на чистом Java, оптимизировал SQL-запросы и закешировал правила. Это был отдельный сервис на Spring Boot с Redis и асинхронной обработкой. Время ответа – 300 мс.


Звучит как реальная польза + инженерная работа + понимание архитектуры.

Схема 2: Цель – Механика – Технологии

Цель: Зачем делался проект? Какая была бизнес-задача?
Механика: Как это работало? Что происходило под капотом?
Технологии. Какие библиотеки, паттерны, фреймворки использовались?

Делали сервис нотификаций для внутренних систем. При получении события генерировались уведомления по шаблону и отправлялись через Kafka -> Email/Push. Использовали Spring Cloud Stream, FreeMarker, RetryTemplate, Prometheus, Zipkin для трейсинга.


Отлично показывает масштаб и понимание потоков данных.

Схема 3: Что было – Что стало – Как дошли

Что было: Начальное состояние, проблемы, ограничения.
Что стало: Чего добились? Метрики, улучшения, профит.
Как дошли: Какие действия, подходы, решения применялись?

Была монолитная система, которую тяжело было масштабировать. После перехода на микросервисы – катим фичи независимо, проще локализовать баги, уменьшили время отклика на 30%. Внедрили Spring Cloud, API Gateway, Eureka, и распилили 3 ключевых модуля: аутентификацию, биллинг и отчёты.


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

Главное не просто что ты делал, а зачем, как и с каким эффектом

Каждый проект – это шанс показать свой уровень, если правильно его подать.

На практикуме по собеседованиям мы тренируем это постоянно: ты рассказываешь – я помогаю упаковать это в выигрышную схему. Так, чтобы было видно: ты зрелый инженер, а не просто код писал. Старт через 2 недели. 70% мест уже занято.

Читать полностью…

Backend Interviewer

Пет-проекты не нужны

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

И вот первая мысль:

А может, мне сделать пет-проект? Ну, типа… TODO-лист или трекер задач.


Но есть один нюанс.

Зачастую пет-проект только ворует твоё время и даёт ложное ощущение продуктивности.

Сколько в мире пет-проектов вида Spring Boot + CRUD + PostgreSQL + Swagger? Один контроллер, одна табличка, один сервис.

Миллионы.

Это ничего не говорит о твоём уровне.

HR и разработчики не будут вникать, если там нет уникальности, сложности, нестандартных решений.

Даже если пет-проект классный, но без README, без деплоя, без документации, без тестов, с коммитами вида "Update", "Fix", "Final version final final v2", он не вызывает доверия. Он выглядит как очередная незаконченная подделка.

Ещё хуже, если ты делаешь пет-проект, чтобы не готовиться к собеседованиям.

Это частая ловушка.

Человек боится собеседований. Чувствует себя неуверенно. И такой:
«Сначала сделаю пет-проект, потом пойду на собес»
«Сначала закончу регистрацию, потом добавлю фронт, потом… потом…»

В итоге ты 3 месяца сидишь в вечном проекте, а реального роста ноль. Ни навыков общения, ни тренировки ответов, ни практики по вопросам.

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

Например, SaaS или open-source библиотека.

То, что требует длительных, вдумчивых и компромиссных решений.

Это уже не игрушка. Это портфолио твоего инженерного подхода.

Но сколько времени ты потратишь на такой проект? Несколько месяцев? Год?

А какая была изначальная цель?

Найти работу, повысить доход.

Это не терпит целый год.

Может быть, вместо пет-проекта, тебе просто нужна структурная подготовка к собеседованиям?

Чтобы понимать, что реально спрашивают.

Как отвечать на сложные вопросы и понимать как работает под капотом.

Как показывать свой опыт и продавать себя как сеньор.

Это то, что мы тренируем на практикуме по собеседованиям.

Прокачиваем хард и софт скиллы за 6 недель. Треть мест уже занята.

Ну а вместо бессмысленного пет-проекта, делай полезный проект для людей.

Читать полностью…

Backend Interviewer

Карточки про синхронизаторы Java

Синхронизаторы позволяют управлять потоками более гибко, мощно и безопасно, чем низкоуровневые и примитивные synchronized, wait, notify и join.

Примеры использования:

– Ограничить количество одновременных действий
– Дождаться завершения нескольких потоков
– Запустить все потоки одновременно
– Обменяться данными между потоками

Виды:

– Semaphore
– CountDownLatch
– CyclicBarrier
– Phaser
– Exchanger

Читать полностью…

Backend Interviewer

Вечный Junior

С Антоном мы пересеклись на одном митапе, когда он работал джуном в аутстаффе уже 3 года.

Джуном 3 года, Карл!

Никакого роста и архитектурных задач. Ревью – формальность. Сеньоры заняты, а тимлид кидает таску и исчезает. Джуниорская вилочка и бесконечное "ещё не время".

Он чувствовал себя застрявшим.

И он был прав.

Но он боялся.

Боялся собеседований, общения с hr, рассказов о своем опыте.

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


Правда в том, что это нормальное состояние.

Так чувствуют себя многие, кто остался без настоящей обратной связи и без возможности развиваться.

И это не их вина.

Это можно исправить.

Но нужен план, поддержка и кто-то, кто скажет: «Ты не тупой, просто ты слишком долго был один в этом болоте».

Я понимал, что могу помочь Антону, направить его в правильное русло.

Но раньше я никогда не менторил разработчиков не из своей команды.

Как и для Антона, так и для меня это был вызов.

И мы оба решили действовать.

С первого же созвона я понял – у Антона есть потенциал. Просто его никто не видел. А он сам – не знал, как его раскрыть.

Что мы сделали?

– Выявили пробелы в знания
– Прокачали многопоточку и алгоритмы
– Написали пет-проект с популярными технологиями
– Переписали резюме
– Провели мок-собеседование
– Разобрали реальные собеседования
– Обсудили его страхи

И вот спустя два месяца:

– Несколько офферов
– Один из бигтех
– Уровень мидл
– Доход x2

Главное – он обрел уверенность и понятный план развития до сеньора.

И знаешь, что самое интересное?

Ты можешь так же.

Ты можешь оставаться в болоте – или пойти по пути роста.

Ты можешь бояться – или готовиться и пробовать.

Ты можешь ждать, пока настанут времена получше – или взять и вытащить себя на новый уровень уже сейчас.

Выбор только за тобой.

Читать полностью…

Backend Interviewer

Как выделиться среди других кандидатов, когда спрашивают про Transactional в Spring

Рассказать про механизмы создания прокси: JDK Dynamic Proxy, CGLIB, Byte Buddy.

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

Поэтому разберём отличия.

JDK Dynamic Proxy

Используется, если класс реализует интерфейс.

Встроен в JDK (java.lang.reflect.Proxy), лёгкий, быстрый, прост в отладке.

Работает только с интерфейсами.

CGLIB

Используется, если класс не реализует интерфейс.

Основан на наследовании – создаёт подкласс твоего класса с переопределёнными методами.

Не требует интерфейсов.

Не работает с final классами и методами, менее прозрачен в отладке.

Byte Buddy

Используется в более гибких и низкоуровневых сценариях (Spring Actuator, Spring DevTools, Mockito, APM-агенты).

Генерирует или модифицирует байткод в рантайм, без ограничения интерфейсами или наследованием.

Безумно гибкий, работает даже с final классами и методами (если использовать javaagent).

Какой прокси используется в Transactional

В AOP используется JDK Dynamic Proxy или CGLIB.

Если есть интерфейс – JDK Dynamic Proxy.
Если нет – CGLIB.

Есть возможность всегда использовать CGLIB, указав proxyTargetClass=true.

Можно легко понять, какой механизм используется, посмотрев в дебаг:
– JDK Dynamic Proxy: com.sun.proxy.$Proxy32
– CGLIB Proxy: MyService$$EnhancerBySpringCGLIB$$abc123

Если
хочешь узнать как застать интервьюера врасплох на вопросах про прокси, ставь 🔥 и разберем в следующем посте.

Читать полностью…

Backend Interviewer

Извините, но мы не готовы сделать вам предложение

Я получал это сообщение десятки раз.

Оно всегда приходит холодным текстом. Без эмоций. Без объяснений.

И каждый раз – будто удар в поддых.

Ты читаешь и замираешь.

Ощущение, как будто тебе сказали:

Ты недостаточно хорош. Мы посмотрели на тебя – и решили, что ты не подходишь.


Но это ложь. Это не правда. Правда – другая.

Отказы – это не оценка тебя как личности или специалиста

Собеседование – это не объективный замер твоей ценности.

Это игра с кучей переменных:

– кто попался в интервьюерах
– в каком ты был состоянии
– как сформулировали вопросы
– сколько было кандидатов на ту же роль
– какой у них был "идеальный профиль" в голове

Это лотерея.

Можно готовиться. Улучшать шансы. Но 100% гарантии нет ни у кого.

У меня было 10 отказов подряд

И это были не какие-то фейковые отклики – я реально доходил до финальных этапов.

Иногда даже в компаниях, где хотел работать всем сердцем.

Где-то я сливался на кодинге.
Где-то тупил от стресса.
Где-то просто не попадал в культуру.

После 10 отказа я стал сомневаться в себе:

Может, я переоценил свой уровень?

А вдруг я уже не дотягиваю до рынка?

Может, мне стоит бросить java и уйти во что-то полегче?


Синдром самозванца лез из всех щелей.

Что помогло мне не сломаться

Я начал вести журнал собеседований.

Что спросили, что ответил, где слил, какие эмоции были.

Начал разбирать вопросы с ментором. Чтобы понимать суть.

Перестал гнаться за "оффером любой ценой". Стал искать проект и команду, подходящую именно мне.

И однажды – получил то самое "да", которое стоило всех отказов.

Что я понял после всего этого

Отказ – это не "ты плохой". Это просто "не то место".

Ты не обязан подходить всем. Это нормально.

Каждое собеседование – это опыт.

Чем больше собесов – тем лучше ты говоришь, держишься, аргументируешь.

Ты прокачиваешь не только знания, но и эмоциональный интеллект.

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

У тебя уже есть мужество – потому что ты продолжаешь идти.

Большинство вообще не пробует.

И вот что я скажу тебе, если ты сейчас на грани

Ты не один.
Ты не сломан.
Ты просто в середине пути.

Каждый отказ – это шаг. И ни один из них не был зря.

Ты накапливаешь скиллы.

А это, поверь, и есть путь к сильному разработчику.

Читать полностью…

Backend Interviewer

Как один Scheduled превратился в DDoS на наш собственный сервис

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

Обычный @Scheduled(fixedRate = 1_000)

Работал год – вообще без проблем.

Вычитывал из бд задачи, проверял статусы и обновлял другие таблицы.

А потом мы немного добавили логики:

– запросы к бд стали тяжелее
– появились внешние вызовы
– и, внимание, время выполнения стало больше секунды

Что это значит?

Scheduler с fixedRate не ждёт окончания предыдущей задачи.

Он просто запускает новую копию метода каждую секунду.

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

И вот у нас уже 5 потоков, 10, 15…

Потребление cpu взлетает.

Внешние системы начинают отваливаться, потому circuit breaker мы не добавили, подумав «ну что тут может случиться».

По факту мы устроили себе локальный DDoS.

Благо обнаружили мы это очень быстро, потому что у нас есть алерты на замедления.

В итоге мы поменяли fixedRate на fixedDelay и проблема ушла.

Поэтому не доверяй слепо аннотациям – понимай, как они работают внутри.

Читать полностью…

Backend Interviewer

Роадмап подготовки к Java собеседованиям

Цель роадмапа – предоставить список тем и источников для быстрой подготовки к собеседованиям.

Темы:

– Java (архитектура jvm, gc, многопоточность)
– Spring (aop, transaction, cloud)
– SQL/NoSQL (acid, base, уровни изоляций, explain)
– Kafka/Docker/Kubernetes
– Паттерны проектирования, ООП, SOLID
– Алгоритмы и структуры данных
– Системный дизайн

📋 Полную версию роадмапа со всеми темами и источниками забирай по кнопке ниже 👇

Читать полностью…

Backend Interviewer

Почему нельзя слишком долго сидеть в комфортной компании

У меня хорошая команда.
Меня никто не трогает.
Зарплата – ну, нормально.
Проект – обычный, но вроде стабильный.
Можно потерпеть ещё годик-другой.


Знакомо?

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

И знаешь, что самое опасное?

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

Давай по пунктам.

1. Комфорт – враг прогресса

Когда тебе спокойно, когда задачи рутинные, когда никто не требует роста – мозг говорит: «О, класс! Зачем напрягаться?»

Но в мире технологий, где всё постоянно меняется, не развиваться – значит откатываться назад.

И вот ты через 2 года вроде как "опытный", но в реальности:

– не писал ничего нового
– не пробовал другие архитектуры
– не выходил за пределы своей зоны ответственности

В итоге – стек устарел, ценность на рынке упала.

2. Зарплата растёт быстрее при смене компаний

Рынок жесткий: чаще всего, значительный рост дохода происходит не внутри компании, а при переходе.

10-15% – максимум, что ты выбьешь внутри.

А вот при смене места – +30%, +50%, иногда и x2.

Хочешь зарабатывать как мидл на уровне сеньора?

Надо уметь правильно упаковывать опыт и выходить на рынок, а не ждать волшебного повышения.

3. Ты не знаешь, на что реально способен

В зоне комфорта ты выполняешь знакомые задачи, в знакомом контексте.

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

Это как качаться в спортзале: если ты всегда поднимаешь одну и ту же штангу – ты не станешь сильнее.

Рост начинается, когда становится трудно и страшно.

4. Стабильность – иллюзия

Сегодня комфортно – завтра компанию продали, проект закрыли, рынок рухнул.

Ты оказался на улице, а последнее собеседование было 3 года назад.

Паника. Самооценка в ноль. Резюме пустое.

Хочешь настоящей стабильности?

Будь всегда готов к собеседованиям.

Держи себя в форме.

Стань тем, кому не страшно выйти на рынок.

5. Никто, кроме тебя, не заботится о твоей карьере

HR может быть милым, тимлид – понимающим, но у них нет цели развивать именно тебя.

Они решают задачи бизнеса.

Твоя задача – развивать свою ценность, свой доход и свои перспективы.

Если ты годами сидишь на месте и надеешься, что тебя заметят – увы, это наивность.

Что делать?

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

Комфорт – это хорошо. Но только когда ты сам его выбрал, а не застрял в нём из страха или лени.

Бери ответственность за своё развитие.

Читать полностью…

Backend Interviewer

Отдых – это часть работы

На этих выходных я отправился в Карелию. Без ноутбука, без интернета, без Jira.

Я отключился от рабочих задач и позволил себе просто быть.

Знаете, что самое интересное?

Впервые за долгое время я почувствовал, что отдохнул по настоящему.

Не просто "не работал", а молчал, смотрел, дышал.

Мы постоянно живем в каком-то аврале: еще одна таска, еще один фикс, еще один фреймворк.

И в какой-то момент ты замечаешь: код работает эффективно, а ты – нет.

Когда ты пашешь без отдыха, ты не становишься героем. Ты становишься медленным, неэффективным и уставшим.

Ты решаешь отдохнуть. Но ты путаешь отдых с отвлечением.

Посмотреть YouTube или поиграть в GTA это не отдых.

Настоящий отдых это смена режима. От "анализировать и держать все в голове" к "отпустить и наблюдать".

Устраивай себе один выходной в неделю без IT-контекста вообще.

Никаких курсов, pet-проектов, видео "как стать ещё лучше".

Выйди на природу (лес, вода, любое место без визуального шума).

Твой мозг нуждается в "тишине", чтобы потом создать что-то по-настоящему стоящее.

Я, как и ты, часто чувствую вину за отдых.

Но отдых это не слабость. Это стратегия.

Необходимо научиться системно встраивать отдых в рабочий процесс, чтобы не сгореть.

А теперь факты:

После 50 часов работы в неделю производительность резко падает, а количество ошибок – растёт. Исследование

Мозг в покое (когда ты, казалось бы, "ничего не делаешь") активирует Default Mode Network – зону, где рождаются идеи, креатив и долгосрочные решения. Исследование

Сон и отдых усиливают нейропластичность – способность мозга адаптироваться, обучаться, решать нестандартные задачи. Исследование

Вывод: хочешь думать лучше – перестань работать постоянно и отдыхай.

Читать полностью…

Backend Interviewer

«Чистый код» – вредная книга?

Да, если читать её как библию.

Однажды ко мне на ревью пришёл молодой и воодушевленный разработчик.

Он только что прочитал «Чистый код» Роберта Мартина – и пришёл в полном восторге.

Методы у него были максимум по 5 строк.

Всё строго по SRP.

Комментарии удалены.

Названия переменных по 12 слов, чтобы «говорили сами за себя».

А читать этот код было невозможно.

И тогда я понял:

«Чистый код» это не книга. Это оружие. И как любое оружие оно может ранить. Особенно в руках новичков.


Почему «Чистый код» может быть вреден?

1. Он отрывает принципы от контекста

Мартин пишет правильно. Его принципы работают.

Но только в определённой среде, при определённой культуре команды, определённом размере проекта.

В реальных условиях тебе:

– Нужно зафигачить фичу до конца дня
– Работать с устаревшим монолитом
– Не сломать интеграции в 10 других микросервисах
– Объяснить, что ты вообще сделал своему коллеге, у которого 3 проекта на поддержке

В этих условиях:

– Иногда комментарий важнее красивого метода
– Иногда switch-case быстрее, чем абстрактная фабрика
– Иногда "грязный" код спасает бизнес, а "чистый" тормозит релиз

2. Он провоцирует перфекционизм, а не результат

После прочтения книги многие начинают:

– Выносить каждый if в отдельный метод
– Создавать 8 интерфейсов на каждый класс
– Изгонять все дубли даже там, где это ухудшает читаемость

В итоге:

– Архитектура становится перегруженной
– Код читается хуже, а не лучше
– Количество абстракций делает поддержку невозможной

А самое главное скорость команды падает в разы.

3. Он убивает командный стиль

Один разработчик решил, что комментарии – это зло.

Другой – что методы не должны превышать трех строк.

Третий считает, что нужно всегда инвертировать условие, если так в книге.

И в результате:

– Проект превращается в песочницу философий
– Код-стайл расходится
– Ревью превращается в войны

Хотя главный принцип чистого кода чтобы его мог понять и поддержать любой член команды.

Виноват ли Мартин?

Нет.

Он пишет книгу как приглашение к размышлению, как курс молодого бойца по дисциплине мышления.

Но люди читают её как доктрину, не разбираясь в деталях, переносят всё на продакшн без критики.

А так нельзя.

Чистый код ≠ Хороший код

Чистый код – это не тот, который нравится Роберту Мартину.

Чистый код – это тот, который твоя команда может читать, поддерживать и развивать.

Он может быть не идеален.

Он может быть даже неэстетичен.

Но если он помогает бизнесу, понятен команде и устойчив в долгосроке – он лучше тысячи идеальных, но мёртвых архитектур.

Что я советую?

Читай «Чистый код». Но не слепо.

Фильтруй советы через реальность своей команды и проекта.

Не превращай принципы в мантры.

Комментарии – иногда полезны.

Большие методы – иногда читаемее.

Дублирование – иногда лучше, чем абстракция.

И самое главное – думай.

Любая практика хороша только тогда, когда ты понимаешь её цену.

Читать полностью…

Backend Interviewer

Стоит ли в 2025 году учить Spring Boot, если есть Quarkus и Micronaut?

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

1. Почему Spring всё ещё нужен

Когда ты учишь Spring, ты получаешь не просто знание одной библиотеки.

Ты получаешь:

– Понимание подходов к проектированию, которые стали стандартом в мире Java
– Навык строить интеграционные решения (Kafka, PostgreSQL, Redis, ElasticSearch) через готовые стартеры
– Умение работать с мониторингом и продакшн-инфраструктурой (Actuator, Sleuth, Zipkin, Prometheus, Cloud)
– Глубокую связь с реальным бизнесом (90% финансового сектора, банков, страховых компаний используют Spring)

Spring сегодня это фактически стандарт корпоративной разработки на Java.

Пока ты его не знаешь – вход на собеседования закрыт.

2. Почему появились Quarkus и Micronaut и в чём их реальный профит

Quarkus и Micronaut родились не на пустом месте.

Они решают конкретную проблему: производительность.

Spring Boot приложение:

– Стартует 5-10-30 секунд (особенно если много контекста)
– Жрёт память прилично
– Поднимает много всего "на авось" (через автоконфигурации)

Quarkus и Micronaut говорят:

– Мы стартуем за 100 миллисекунд
– Мы используем AOT компиляцию
– Мы готовы к GraalVM и native-образам для serverless решений

Это действительно важно, если ты:

– Пишешь микросервисы для облаков типа AWS Lambda, Azure Functions
– Оптимизируешь стоимость биллинга в облаке (меньше памяти = дешевле)
– Работаешь над системами с требованием "холодного старта" в доли секунд

Но...

Когда ты разрабатываешь огромную корпоративную систему из сотен микросервисов, 30 секунд старта роли почти не играет.

Тебя интересуют:

– Стабильность
– Тестируемость
– Наличие специалистов
– Богатая экосистема библиотек

И здесь Spring пока безальтернативен.

3. Реальные кейсы из жизни

Проект 1 (финтех):

Сервис управления кредитными историями. Java 17, Spring Boot 3.
Выбирали между Micronaut и Spring.
Выбрали Spring, потому что нужно было быстро найти команду из 5+ разработчиков, а рынок по Spring в разы больше.

Проект 2 (стартап в e-commerce):

Сервис обработки заказов в serverless-инфраструктуре AWS.
Выбрали Micronaut + AOT. Потому что cold start критичен: 50 миллисекунд против 5 секунд имеет значение в деньгах.

Проект 3 (госзаказ):

Огромная система документооборота. Строгие требования к надёжности.
Только Spring Boot. Потому что есть готовые решения для безопасности и аутентификации через OpenID и LDAP.

4. Когда стоит учить Quarkus или Micronaut

Если ты хочешь:

– Специализироваться в cloud-native решениях
– Работать с serverless архитектурами
– Любишь экспериментировать и быть на острие технологий

То да, изучение Quarkus и Micronaut даст тебе фору перед теми, кто застрял только в "традиционном" Spring.

Но без понимания принципов, которые дал тебе Spring, ты рискуешь строить неуправляемую архитектуру и натыкаться на больные углы DI, транзакций и обработки ошибок.

5. Что будет дальше?

Моё личное мнение, Spring останется ещё минимум 5-7 лет доминирующим стеком в Java-разработке.

Он меняется. Он уже поддерживает полный AOT-подход (Spring Boot 3 + Spring Native).

Он идёт к компактности, но остаётся зрелым.

Тот, кто хорошо знает Spring – освоит любой новый фреймворк за пару недель.

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

Итог

Учи Spring Boot.

Он даст тебе фундамент.

А потом – осваивай Quarkus, Micronaut, Helidon и другие инструменты.

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

Читать полностью…

Backend Interviewer

Выстрел в ногу через @Transactional

Плавающий баг, который не могли поймать неделями.

Дано:

– Два микросервиса
– У каждого своя база данных
– Первый микросервис записывает в бд информацию об операции и отправляет событие в kafka
– Второй микросервис вычитывает это событие, обрабатывает его и сохраняет результат в свою бд

Классика.

Записали в бд, кинули событие.

Что может пойти не так?

Как оказалось, многое.

Через месяц после релиза аналитики заметили расхождение.

Количество записей в базах данных двух микросервисов не совпадало.

Во втором микросервисе записей было больше, чем в первом.

Начали копать.

В кибана ни error, ни warn логов нет.

Но с каждой неделей расхождение в базах данных становилось все больше.

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

Плавающий баг, с которым никто не хочет разбираться и закрывает на него глаза.

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

Но шел уже второй месяц, а проблема никуда не девалась.

Всех это уже начало раздражать и я решил найти корень проблемы.

Для начала я посмотрел, а как же первый микросервис записывал в бд и отправлял в kafka.

Делал он это примерно так:

@Transactional
public void registerOp(OpDto dto) {
opRepository.save(dto.toEntity());
kafkaTemplate.send("topic-name", dto);
}


Мы имеем дело с распределенной транзакцией.

Нам нужно гарантированно записать в бд и отправить в kafka.

С первого взгляда проблем нет.

Если произойдет ошибка на уровне бд в методе save, то до отправки в kafka дело не дойдет.

Если произойдет ошибка на уровне kafka в методе send, то транзакция на уровне бд откатится.

Звучит правдоподобно?

Да.

Работает действительно так?

Нет.

Во-первых, коммит транзакции в бд происходит после выхода из метода registerOp.

Это значит, что если произойдет ошибка на уровне бд, то сообщение в kafka уже будет отправлено.

Во-вторых, метод send асинхронный. Он возвращает Future.

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

Элементарный метод из двух строчек может вызвать множество фантомных проблем.

В нашем случае проблема была при коммите транзакции из-за одного constraint на уровне бд.

Получалось, что в бд мы не записывали, а в kafka отправляли.

Но почему не было error логов?

Человеческий фактор.

В ExceptionHandler не добавили log.error(…) для ошибок бд.

Как я исправил проблему?

Применил Transactional Outbox Pattern.

Метод registerOp вместо отправки в kafka пишет события в отдельную таблицу-очередь (outbox).

В фоне работает job, который читает закоммиченные записи и отправляет их в kafka.

Фантомные ошибки приходят, когда ты забываешь, что живёшь в распределённом мире.

Читать полностью…

Backend Interviewer

Стоит ли соглашаться на оффер, если от тебя требуют быстрый ответ?

Ты прошел собеседование, получил оффер, но вдруг…

Нам нужно ваше решение до завтра


Или

Если не ответите в течение 24 часов, мы предложим оффер другому кандидату


Тебя пушат на быстрый ответ.

Но вот в чём подвох.

Когда работодатель торопит тебя с решением, это не потому что он так тебя хочет.

Скорее всего, тут есть скрытые причины.

Разберем, что делать, когда от тебя требуют быстрый ответ, и стоит ли соглашаться.

1. Почему компании давят на быстрое решение?

Компании любят ставить кандидата в режим паники.

Тебя вынуждают думать: «А вдруг упущу шанс?»

Но чаще всего это не в твоих интересах.

Вот ключевые причины, почему тебя прессуют:

– Они боятся, что ты найдешь что-то лучше
– У них есть другой кандидат, но ты им приоритетнее. Они хотят, чтобы ты сказал «да», прежде чем дадут отказ другому
– Они не уверены в оффере. Если бы условия были сильными, тебя не пришлось бы уговаривать
– Это просто корпоративная политика. Некоторые компании стандартно дают 24-48 часов на решение

Что это значит для тебя?

Они хотят ускорить сделку в свою пользу, а не в твою.

2. Когда стоит соглашаться, даже если давят?

Иногда давление – это не красный флаг, а просто рабочий процесс компании.

Стоит сказать «да», если:

– Ты уже полностью разобрался в условиях оффера и тебя всё устраивает
– Ты заранее изучил рынок и уверен, что это достойное предложение
– Ты не ведёшь переговоры с другими компаниями и готов выйти именно сюда
– Оффер действительно уникальный

Но если у тебя есть сомнения – не торопись.

3. Как правильно отстоять время на размышление?

Если тебя давят, но ты хочешь время подумать, действуй умнее.

Спасибо за оффер! Хочу всё внимательно взвесить, чтобы принять осознанное решение. Смогу дать ответ в понедельник.


Рекрутер может сказать: «Срок – завтра, иначе отзываем оффер»

Что ответить?

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


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

На данный момент у меня есть другие офферы, поэтому мне нужно немного времени, чтобы сравнить предложения.


Если компания реально хочет тебя, они могут даже улучшить оффер.

4. Когда срочное решение – это красный флаг?

Если тебя не просто торопят, а буквально шантажируют, это уже тревожный знак.

Что это может означать?

– В компании жёсткая токсичная культура
– Они боятся, что ты увидишь недостатки оффера
– Они хотят закрыть вакансию любой ценой, не давая тебе сравнить предложения

5. Как понять, что тебя реально шантажируют?

Задай себе 3 вопроса:

– Давление исходит от всей компании или только от рекрутера?
– Тебя уговаривают или скорее угрожают?
– Ты точно понимаешь все условия?

Если хоть на один из этих вопросов у тебя нет четкого ответа – задумайся, стоит ли вообще соглашаться.

Итог: стоит ли соглашаться, если тебя пушат на быстрый ответ?

– Соглашайся, если ты уверен в оффере и у тебя нет альтернатив
– Проси время на размышление, если есть сомнения
– Не соглашайся, если давление слишком сильное – это тревожный знак

Случай из жизни

Мне сделали оффер и попросили принять решение как можно быстрее. Я взял паузу. На следующий день мне предложили welcome бонус, если я приму решение за сутки.

Читать полностью…

Backend Interviewer

Как справиться со стрессом на собеседовании?

Ты заходишь в zoom, ждёшь подключения интервьюера…

Руки потеют, сердце колотится, в голове пустота.

Что делать, чтобы не слить собеседование из-за стресса?

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

1. Почему стресс убивает твой шанс на оффер?

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

– Кровь уходит в мышцы (а не в лобные доли мозга)
– Логика и память проседают
– Ты начинаешь заикаться, путаться, тупить

И даже если ты знаешь ответ — в стрессовом состоянии ты не сможешь его нормально объяснить.

Наша цель — войти в собеседование спокойным и собранным.

Как это сделать?

2. Подготовка за 24 часа до собеседования

Уменьши неопределённость

Чем меньше неожиданностей, тем спокойнее.

Что делать?

– Узнай у рекрутера структуру собеседования
– Проверь, кто будет интервьюером
– Потестируй софт

Мозгу станет проще, когда он знает, чего ждать.

Проведи тестовое собеседование (но правильно)

Не нужно заучивать — это не помогает.

Прогоняй мысли вслух!

– Поставь камеру, запиши, как ты отвечаешь
– Слушай себя: звучит уверенно или нет?
– Попробуй объяснить задачу своему другу

Главная цель — научиться говорить спокойно и чётко.

Выспись и отдохни

Звучит банально?

Но если ты недоспишь, мозг работает на 20-30% хуже.

– Спи 7-8 часов перед собеседованием
– Не зубри ответы в ночь перед собеседованием — только закрепляй

Отдохнувший мозг лучше решает задачи.

3. За 1 час до собеседования

1.5 минуты физической активности

Доказано, что короткая нагрузка снижает уровень кортизола (гормона стресса).

– Сделай 10-15 отжиманий или приседаний
– Пройди пешком 5-10 минут
– Потянись, разомни шею и плечи

Ты сбросишь лишнее напряжение и соберёшься.

4. Настрой себя правильно

Не думай: «А вдруг я завалю?»

Думай: «Сейчас я покажу, на что способен»

– Вспомни свои сильные стороны
– Напомни себе: «Я не обязан знать всё, главное - думать вслух»
– Визуализируй процесс: представь, как ты спокойно отвечаешь

Твой настрой — 50% успеха.

5. Во время собеседования: как не терять концентрацию?

Если завис — говори вслух

Когда стресс растёт, мозг замирает. Но если ты начинаешь говорить, ты «размораживаешь» мышление.

Правильная фраза, если завис: «Хороший вопрос. Давайте разберём его по шагам…»

Так ты даёшь себе время на обдумывание.

Фокусируйся на процессе, а не на результате

«Я должен получить оффер» – лишнее давление.

«Я просто покажу, как мыслю» – расслабленность и концентрация.

Сконцентрируйся на задаче, а не на страхе.

Итог: как войти на собеседование спокойным и уверенным?

1. За день: уменьши неопределённость, протестируй оборудование, выспись
2. За час: сделай разминку, настройся
3. Во время: размышляй вслух, фокусируйся на процессе

Читать полностью…
Подписаться на канал