Павел Сорокин | Java

Собрал в один пост то, что ты гуглишь перед каждым собесом 🗒 Это подборка полезных постов на задачки с собесов, теоретическую базу и алгосы 1. Что такое идемпотентность и как реализовать её на практике 2. Как устроены транзакции в целом + задачка на них с собеса 3. Twelve-Factor App - 12 практик, которые делают облачные приложения переносимыми предсказуемыми и масштабируемыми 4. API Gateway - как он устроен и зачем он нужен 5. Чем HTTP/2 отличается от привычного HTTP/1.x 6. Почему виртуальные потоки, корутины и горутины - это гениальное инженерное решение? 7. Три задачки с собесов в 2026 году 8. Задача на многопоточность с собеса в ФинТех 9. База: чем отличается конкурентность от параллелизма 10. Шардирование - зачем оно надо и как его реализовать на практике 11. Многопоточка - она везде Приятного изучения:) А чтобы быстро возвращаться к нужным вопросом и не копаться в канале, я сделал хештэг #хардовая_польза - буду все хардовые посты им помечать

Лишился подкаственной девственности 🤨 Моим первым стал Макс Аверин - основатель @interview_hustlers У нас на двоих опыт помощи 400+ студентам со вкатом/ростом по грейду в IT, поэтому темы для разговора нашлись быстро: • Как бы мы заходили в IT в 2026 без коммерческого опыта (и почему скиллкоробка делает свою работу... хорошо?) • Влияние AI на рынок трудоустройства и что сейчас реально надо знать (алгосы 🍷) • За какой срок сейчас реально вкатиться? (меньше, чем тебе кажется и больше, чем обещает рынок) • Как эффективно обучаться в эпоху AI (и причём тут Жигули) • Рабочие фишки-советы-лайфхаки по трудоустройству здесь и сейчас • Качай софты или сдохни Суммарно вышло почти на 1.5 часа - это реально ёмкая must watch выжимка для тех, кому сейчас актуальна тема трудоустройства 🖤 Приятного просмотра - youtube.com/watch?v=9w07TKhSu6o

Transactional Outbox Pattern: как не потерять событие между БД и Kafka Есть классическая backend-задача. Cоздаем заказ, сохраняем его в БД и хотим отправить событие в Kafka: Наивно это выглядит так:

@Transactional
public void createOrder(CreateOrderRequest request) {
    Order order = orderRepository.save(new Order(request));

    kafkaTemplate.send("order-created", new OrderCreatedEvent(order.getId()));
}

И тут есть ряд проблем База данных и Kafka - это две разные системы. Транзакция в PostgreSQL не управляет Kafka Kafka не знает, что происходит в транзакции PostgreSQL. А значит, “сохранить заказ” и “отправить событие” не являются одной атомарной операцией 🙃 А еще транзакции должны быть короткими. Пока транзакция открыта, она держит connection к БД, что может стать боттлнеком. Если внутри транзакции делать сетевой вызов в Kafka или внешний сервис, и он подвиснет, у тебя подвиснет вся транзакция. А потом connection pool забьется и новые запросы будут висеть, ждать свободный коннекшн В общем, это плохой паттерн в транзакции делать какую-то долгую операцию, особенно внешние вызовы И тут начинаются варианты, как это можно пофиксить: 1️⃣ Можно сначала отправить событие в Kafka, а потом сохранить в БД в транзакици А что если потом транзакция в БД откатится? В итоге в Kafka улетело OrderCreated, но самого заказа в базе нет. Другие сервисы начали реагировать на событие о заказе, которого не существует. 2️⃣ Сначала сохранить заказ в БД, а событие отправить после коммита Но если приложение упадёт между коммитом и отправкой в Kafka? Заказ в базе будет, а события не будет. Другие сервисы не узнают, что заказ создался

❗️Именно эту проблему решает Transactional Outbox Pattern

Идея простая: в одной транзакции с бизнес-данными мы сохраняем не только заказ, но и событие в отдельную таблицу - outbox_events То есть внутри одной БД-транзакции происходит сразу две записи:

@Transactional
public void createOrder(CreateOrderRequest request) {
    Order order = orderRepository.save(new Order(request));

    outboxRepository.save(new OutboxEvent(
            OrdersEvents.ORDER_CREATED,
            order.getId(),
            toJson(new OrderCreatedEvent(order))
    ));
}

Теперь заказ и событие точно сохраняются атомарно. Либо сохранилось и то, и другое. Либо не сохранилось ничего 🤔 Окей, а дальше как? А уже потом отдельный процесс или задача по расписанию (poller) читает outbox_events и публикует события в Kafka

Service → orders + outbox_events → Poller → Kafka

Это может быть обычный poller, который раз в секунду берёт новые события из таблицы, отправляет их в Kafka и помечает как опубликованные. Либо можно использовать CDC-подход, например Debezium: он читает изменения из журнала WAL SQL базы и отправляет их дальше в Kafka

PostgreSQL WAL → Debezium → Kafka

Но у Outbox есть важный нюанс: обычно он даёт at-least-once delivery. То есть событие может быть доставлено больше одного раза Например, poller отправил событие в Kafka, но упал до того, как пометил его как опубликованное. После рестарта он отправит это же событие ещё раз Поэтому consumer’ы должны быть идемпотентными: уметь спокойно обработать одно и то же событие повторно. Обычно для этого используют eventId и таблицу уже обработанных событий. Писал про идемптоентность тут ❓ На собеседованиях по этой теме часто спрашивают • зачем нужен Outbox Pattern? • почему нельзя просто отправить событие в Kafka внутри @Transactional? • что будет, если БД закоммитилась, а Kafka-send упал? • что такое outbox-таблица? • почему consumer должен быть идемпотентными и что будет если НЕ?

💡 Outbox Pattern нужен, когда изменение в БД и публикация события должны быть логически связаны, но физически происходят в разных системах. Мы сохраняем событие рядом с бизнес-данными в рамках одной транзакции и потом доставляем его во внешнюю систему

Накидай огня, если пост зашел 🔥 А в комментах расскажи, какие моменты по Кафке тебе еще не понятны, выберу одну из тем и напишу пост 😎 #хардовая_польза

Теперь зовите меня вайб дизайнер ⌨️ Вот эти все шаблоны слайдов клод собрал сам, я просто сидел смотрел Всё, уже можно продавать курс "Как зарабатывать на нейросетях" или пока рано?)))

Круто дизайнить через Claude, не круто дизайнить через Claude Design Итак, проблема номер один - мне сейчас надо делать кучу презентаций: для видосов на ютуб и новый продукт мне надо +- 500 слайдов Проблема номер два - я вот совсем не дизайнер:))) Поэтому когда клод выкатили claude design, я подумал что вот оно спасение ща всё нарисуем 🍷 Нууу... я часов 5 закидывал презы и прочее туда для создания проекта, на выходе получив реально красивые слайды в моей стилистике Вот только вместе с ними шли кривые диаграммы, поехавший текст и абсолютная невозможность это редачить - промтами жрет кучу токенов, вручную нормально тоже толком это не сделать Пошел ресерчить че с этим делать дальше, понял что можно связать просто десктопный клод и фигму, чтобы он сам там собирал слайды ⌨️ Снова сидел кормил ему презентации, примеры диаграмм, собирал брендбук и тп И вот это уже оказалась максимально рабочая штука - сами слайды чуть менее красивые, зато всё легко редачится, диаграммы не поехавшие ну и так далее. Скоро всё увидите Так что вывод у поста простой - не стоить выдрачивать всё до идеала, когда можно сделать просто рабочую штуку Поэтому для себя я перефразирую фразу "Лучше сделать херово, чем никак" в "Лучше сделать хорошо, чем идеально" P.S. "а деньги что делать" пхавхпхвапвахпхвапхв

Транзакции: почему твои деньги не исчезают в воздухе ❗Warning - пост для новичков, сеньорам просьба отойти от экранов Начнем с основ, что такое транзакция

Это когда мы берем несколько запросов к БД и упаковываем их в одну атомарную пачку

То есть работает принцип: либо выполнилось всё, либо не выполнилось ничего Например, переводим деньги с одной карты на другую:

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

В теории просто: с одного счета списали, на другой зачислили НО если первый запрос прошел, а второй упал? Интернет отвалился и база сказала «not today» или кто-то криво передал id счета И теперь деньги списались, но никуда не пришли, пум-пум 🙃 Вот чтобы таких приколов не было, операции объединяют в транзакцию. Если всё прошло ок - делаем commit. Если что-то пошло не так - rollback, и база возвращается в состояние «как было до всей этой движухи» Транзакция защищает нас от промежуточного кривого состояния: никаких “почти перевели деньги”, “почти создали заказ” или “почти обновили пользователя” Либо операция завершилась нормально, либо откатилась полностью С базой мы работаем через connection - это условный канал, по которой летят запросы Приложение берет соединение из connection pool, выполняет внутри него запросы, закрывает транзакцию и возвращает соединение обратно в пул

BEGIN;

UPDATE users SET name = 'Ivan' WHERE id = 1;

COMMIT;

или если поняли, что натворили херню:

ROLLBACK;

❗️Важный момент: транзакцию надо закрывать всегда 🤢 А зачем тогда ROLLBACK, если без COMMIT ничего не сохранится? Потому что ROLLBACK - это не просто «не сохранять изменения», это команда базе:

«Заканчиваем, освобождаем ресурсы»

Пока транзакция открыта, база может держать блокировки, snapshot данных и само соединение в занятом состоянии. В PostgreSQL это состояние часто выглядит как: idle in transaction ❗️ Connection ≠ Transaction Connection - это соединение с базой. Условный канал, по которому приложение отправляет SQL-запросы Transaction - это логическая пачка операций внутри этого соединения. В одном connection можно выполнить много транзакций подряд:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
ROLLBACK;

BEGIN;
UPDATE users SET name = 'Ivan' WHERE id = 1;
COMMIT;

BEGIN;
INSERT INTO orders(user_id, status) VALUES (1, 'CREATED');
COMMIT;

То есть connection - это не одноразовая штука под одну транзакцию. Приложение берёт connection из пула (например, HikariCP), выполняет транзакцию и возвращает обратно: • взяли connection • сделали запросы • COMMIT / ROLLBACK • вернули в пул Количество соединений у нас ограниченно (например, 10), поэтому они переиспользуются. Например, у HikariCP по умолчанию maximumPoolSize = 10. То есть приложение не будет бесконечно открывать соединения к базе. Если все 10 заняты, новый поток будет ждать свободное соединение У PostgreSQL тоже есть лимит на количество одновременных подключений. По умолчанию это обычно около 100, но в реальных проектах его часто настраивают: 100, 200, 300 - зависит от сервера. Но тут важный момент: больше соединений не всегда лучше. Если ты просто выкрутишь pool size в 200, база не станет магически быстрее. Иногда она станет медленнее, потому что каждое соединение ест память, ресурсы и создаёт конкуренцию за CPU. 📝 Резюмируя: Транзакции нужны, чтобы база не оставалась в состоянии «деньги списали, заказ не создали, статус пользователя завис в воздухе» COMMIT и ROLLBACK - это нормальное завершение операции. Transaction - это пачка SQL-операций. Connection - это канал к базе, через который эти операции выполняются. Один connection может пережить много транзакций, потому что он переиспользуется через connection pool

Отлично знаешь теорию? А с ЭТИМ справишься? Вот как ты обычно решаешь алго-задачи? Смотришь на чужой код, киваешь головой под разборы и тебе этот мир становится абсолютно понятным, потому что всё просто и логично Но стоит кому-то попросить объяснить просмотренное решение - ты понимаешь, что ничего внятного сказать не можешь, итак же всё понятно Через какое-то время ты сам пытаешься написать код и внезапно ловишь себя на мысли, что вообще не уверен даже в базовых вещах А ведь это всё дома, в спокойной обстановке, с кофеечком. Но что тогда будет на собесе, когда помимо давления, ты еще и смотришь постоянно на время? Сегодня вместе с Java-разработчицей - Яной разберем несколько задач с реальных лайвкодинг собесов, где я дам подробные комментарии по ходу решения, а бонусом для всех посмотревших будет полный разбор всех задач из видео 🔥 Поэтому залетай по ссылке, смотри и попробуй решить быстрее, чем Яна даст правильный ответ 🤨 Смотреть видео на YouTube: youtube.com/watch?v=FSB7dIv6AfI

Мой осознанный демпинг зашёл слишком далеко 🙄 В общем, как я думал всё будет происходить: • курс по лайвкодингу купит человек 30 от силы • они кайфанут от материала, накидают обратки что им ещё хотелось бы узнать • я добавлю 1-2 модуля сверху, соберу отзывы и повышу прайс до рыночного уровня В итоге уже больше 60 человек присоединились за первые 3 дня после анонса... пу-пу-пу... Это, разумеется, очень приятно видеть доверие стольких человек и спрос на знания, только у этого есть и обратная сторона медали - смотрите:

Я мыслю так, что +- первые 100 покупателей - это те, кому реально нужна и/или интересна тема алгосов, и они реально будут проходить этот продукт

Но дальше это превратится в "дешёвое не ценят" - люди будут покупать и забивать на прохождение. А я в первую очередь хочу реально ценный материал давать и помогать людям - то есть я хочу, чтоб вы проходили продукты мои, а не просто покупали ⚠️Поэтому я решил ограничить сейчас продажи ровно до 100 мест и временно убрать кнопку оплаты с сайта, потом буду улучшать продукт и собирать отзывы Последний раз даю ссылку на сайт - sorokin.school/livecoding, в ближайшее время не буду его пушить в контенте P.S. Мб я конечно шизу поймал с качеством обучения, но думаю на этом всё-таки важно делать фокус на пути к позиционировании уровня "Если Java - то это к Паше Сорокину" 🧱🧱🧱

Однажды черепаха подошла к древне-китайскому мудрецу и спросила:

Мудрейший, как эффективно кэшировать данные?

Мудрец посмотрел на неё, немного помолчал и ответил:

常用 时限 失效

Черепаха вбила иероглифы в гугл переводчик и увидела 3 главных принципа кэширования: 1. Кэшируй то, что часто используют 2. Ставь время хранения 3. Инвалидируй при изменениях Так на черепаху снизошло backend-просветление А потом черепаха превратилась в Павла Сорокина и записала полный курс по REDIS - тыкай если еще не видел

Кидай в коменты любимый мем, поднимем настроение друг другу под конец недели 🔫

Это ж надо было так облажать... В общем, у меня уже глаз замылился с текущим количеством работы по курсам и видео на ютуб, и я не увидел, что дизайнер на сайте написал LIFECODING 🤩 Хотя даже так его купили уже 35 человек вообще без прогрева и прочего (и только двое написали в личку, что там ошибка на сайте!!!!) Чтож, теперь это всё-таки курс по liVecoding'у, и если вас останавливало неправильное название - теперь всё норм, можно покупать 🤝🤝 А если серьёзно, то давай подробнее расскажу что ты получишь на нём: • Перестанешь зависать на пустом экране - поймёшь как думать, с чего начинать решение • Научишься распознавать паттерн по триггерам в условии за 30 секунд • Перестанешь забывать решения через неделю, и в голове останется навык решения по паттерну, а не зубрёжка отдельно взятых задач • Узнаешь, что говорить и как себя вести на собеседовании - что проговаривать вслух, какие вопросы задать, что делать если завис И всё это за 2.990 рублей на минимальном тарифе - ну не сказка ли? Заходи на сайт, читай подробнее содержание и присоединяйся - sorokin.school/livecoding P.S. Разумеется, я понимаю, что это низкий прайс, и ценник будет повышаться минимум в 2 раза, а уроки добавляться. Повышать буду летом, поэтому как есть говорю - кому актуальна тема лучше возьмите сейчас, обновления для вас бесплатными будут

АЛ-ГО-СЫ ⌨️ Такое просто, короткое слово. И настолько важное для прохождения собеседований... Я снимал много разборов вопросов и различных задач, но со временем понял, что на деле это слабо применимо в РЕАЛЬНОЙ подготовке к собесам Задачи разрозненные, единичные, и понимание как решается какая-то определенная задача не несёт в себе какой-то большой ценности Поэтому я и решил объединить всё цельный курс по алгосам! 😎 Его главная задача - сделать так, чтобы ты: • понял базовые паттерны и умел видеть их в задачах • научился решать задачи каждого типа, а не зубрил решения • не впадал в ступор на собесе и мог объяснять своё решение интервьюеру Всё максимально понятно, простыми словами и с доступными примерами Сейчас он стоит буквально копейки, пока я обкатываю программу и собираю обратку В планах его улучшать, ну и ценник, соответственно, будет расти ↗️ Так что держи сайт и не проепропусти момент: sorokin.school/livecoding P.S. А вы знали, что спор “нужны или не нужны алгосы” обычно заканчивается ровно в тот момент, когда тебе дают задачу на собесе 🤔

SQL, Spring, Kafka, Hibernate: что точно надо знать на джуна? На собесах больше всего боятся забыть не базу, а что-то посложнее. Например, паттерны микросервисов или отличия volatile от synchronized. И логично, что при подготовке совсем забивают на фундамент и делают упор на то, что тяжелее Сегодня в заключительной серии мок-собеседований с подписчицами вместе с Java-разработчицей Яной разбираем базу всех собесов: • SQL, join’ы, подзапросы • транзакции и уровни изоляции • Spring и аннотации • ну и Java Core: hashCode, HashMap и т.д. Это хорошая возможность проверить себя и свои скилы, если всё еще боишься ходить на реальные собесы 🙂 Смотреть видео на YouTube: youtu.be/Cx_sEm0ygIA

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

Пока пилил продукт по лайвкодингу наткнулся на классную платформу для решения кодерских задач Называется CodeRun. По сути, это онлайн-тренажер, который Яндекс создал для своих разрабов, но потом открыл для всех: решаешь задачи, качаешь скиллы и готовишься к техсобесам. Недавно там появился AI-помощник на SourceCraft: он не напишет код за тебя, но проведёт от намека к инсайту, при этом оставляя тебе право на ошибку. То есть вместо готового решения ты получаешь: • подсказки на каждом этапе; • тест-кейсы для проверки решения, включая краевые случаи; • разбор примеров из условия. Зацените сами: заходите на CodeRun и открывайте вкладку «Кодерун AI» P.S. Ребята передали, что пока что фича в бета-режиме, нужна авторизация, а лимит 20 запросов в сутки. Самое время потестить.

Шардирование: когда одна база уже не вывозит Однажды база данных становится слишком большой. Запросы тормозят, индексы пухнут, реплики для чтения уже не спасают. Да, можно вертикально отмасштабировать - накинуть сервак помощнее, памяти побольше, но в какой-то момент уже не получится растить мощности бесконечно И тут появляется шардирование - разделение данных на несколько независимых частей, которые называются шардами То есть мы не просто оптимизируем одну большую таблицу, а распределяем данные между несколькими базами или узлами Например, пользователи с одними user_id живут в одном шарде, с другими user_id - в другом

shardKey = user_id % 4

0 → shard_0
1 → shard_1
2 → shard_2
3 → shard_3

То есть по user_id мы сразу понимаем, в какой шард идти. В теории круто: было много данных в одной базе, стало меньше данных в каждой отдельной базе НО не все так просто, потому что мы получили несколько доп. сложностей. Очевидно стала более сложная инфра: была одна БДшка - стало 4. Нужны новые серваки, мониторинг за каждой, поддержка и тд Но с точки зрения работы с данными - главная боль шардирования в том, что теперь данные распределены Раньше можно было сделать обычный запрос:

SELECT * FROM orders WHERE user_id = 123;

И база сама разбиралась, где что лежит. После шардирования приложение или специальный routing layer должны сначала понять, в каком шарде лежит user_id = 123 Но и тут проблемы начинаются, когда мы заходим сделать запрос не по shard key

SELECT * FROM orders WHERE status = 'FAILED';

Если status не является ключом шардирования, то мы не знаем, в каком шарде лежат такие заказы Значит, надо идти во все шарды, выполнить запрос в каждом, собрать результаты, склеить их и отдать клиенту. А если у нас 10 шардов, то это +10 сетевых вызовов и большой риск, что какой-то из этих запросов отвалится Иногда это ОК, но если таких запросов много, то лучше пересмотреть архитектуру хранения данных Еще больно становится с JOIN’ами Классическая ситуация - надо достать user и все его связанные orders. В рамках одной БД это просто. Но если user и его orders лежат на разных шардах, то простым JOIN уже не получится. То есть ключом шардированя у order был бы не order_id, а user_id ❗️Поэтому один из самых важных вопросов при шардировании - по какому ключу шардировать Плохой shard key может убить всю производительность Во-первых плохой выбор может привести к распределенному запросу по шардам, что мы уже разобрали, и это not good Но еще при плохом выборе может быть неравномерное заполнение шардов. Один или несколько шардов будут гореть, на них будет приходить многоп данных и запросов, а остальные будут проставивать. Это называется hot shard - когда нагрузка распределяется неравномерно, и один узел становится бутылочным горлышком В реальности, конечно, это всегда компромисс, потому что всегда будет какой-то перекос. Главное предотвратить заранее проблему на этапе проектирования, а то потом будет дорого перераспределять кучу данных Окей, а где это шардирование включить? Такой вопрос может возникнуть, особенно у начинающих В PostgreSQL шардирование не появляется магически из коробки. SQL БДшки вообще по дефолту не продоставляют такую функциональность. Если мы хотим шардировать SQL БД, то у нас есть два варианта: 🟣Писать свой routing layer в приложении То есть мы обращаемся из кода также в обычный репозиторий userRepo.save(user), но под капотом он считает ключ шардирования и идет сам в нужный шард. Но эту логику надо писать самим. На моих проектах часто это была своя платформенная библиотека

int shardId = userId % shardCount;
DataSource dataSource = shardRouter.getDataSource(shardId);

🟣Есть расширения вроде Citus, которые можно накатывать на Postgres За счет него БДшка «сама» будет роутить данные, мы просто обращаемся к узлу-координатору, а он дальше распределяет данные. Но это не бесплатно и в этом надо разобраться, а не просто включить галочкой. В общем, свои трудности Ставь 🔥 , если заходят такие посты P.S зацени, схему к посту)

Что спрашивают по многопоточности на Java-собесах 🤔 Есть старая байка из мира бэкенда: однажды разработчик решил «чуууууть-чууть оптимизировать» код и добавил многопоточку в сервис, который спокойно работал годами… Ну, что было дальше, наверное, и так можно догадаться 😐 Чтобы ты не был таким челом, сегодня собрал ТОП вопросов по многопоточке, которые валят даже опытных кандидатов на собесах. Раскрывать все карты не буду, скажу одно: помимо теории разберем вопросы еще и на практике Тебя ждут 3 лайвкодинг-задачи с реальных собеседований и задача из Яндекса в конце 😎 Смотреть на YouTube: youtube.com/watch?v=6K9kaxp3JN4

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

«Ща, выучу всё за короткий срок, просто буду учиться постоянно, в любое свободное время»

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

Быстрый прогресс - это миф, который нам втирают каждый день в соцсетях

Если ежедневно ты будешь улучшать свои навыки хотя бы на 1%, то через месяц станешь лучше на 35%, а через год вообще в 37 РАЗ Но тут суть идеи не в цифрах, а в регулярности. Если каждый день выкладывать по 🧱, через какое-то время сможешь построить для себя лестницу в светлое будущее...получилось очень пафосно, ахвах, но так и есть Пора бы уже понять, что ошибки - это нормально и даже отлично, потому что совершаешь ошибку → ищешь решение → исправляешь и получаешь новый опыт 🤷‍♂️🤷‍♂️🤷‍♂️

Если ты делаешь ошибки, значит, ты растешь и это заебись

Долгосрочные результаты ВСЕГДА, ну вот абсолютно всегда требуют времени Даже если кажется по началу, что ты топчешься на месте. Главное - не бросать и продолжать двигаться в том же направлении, пусть и как черепаха Даже если никто не замечает твоего прогресса и, возможно, говорят, что пора бросать эту затею, закладывая фундамент будущего успеха и накопив достаточно опыта, в один момент ты сделаешь огромный скачок, который будет сложно не заметить И я тут говорю не только про программирование, а вообще любую область, где ты хочешь добиться успеха Ставь 🧱, если согласен, а в комментах предлагаю интерактив: напиши, чего ты хочешь добиться за следующий месяц и что ты будешь для этого делать. А через 30 дней я вернусь к этому посту, и посмотрим, кто насколько продвинулся

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

- фраза, которая одновременно вызывает облегчение и тревогу у каждого джуна Потому что смотреть разборы и проговаривать в слух это одно, а писать под давлением в стрессе - воообще другое Этот этап дает понять работодателю твой реальный уровень подготовки. Лайвкодинг тот навык, который надо качать через боль, опыт и слезы регулярную практику, ошибки и работу над ними Сегодня решаем 2 задачи: • алгоритмическую на массивы • небольшое code review куска кода Как обычно по ходу разбираю: • моменты, где можно ошибиться • как вообще думать над такими задачами • на что смотрит интервьюер И почему даже простые задачи иногда валят людей сильнее, чем хардовая теория 😉 Чтобы получить максимальную пользу от видоса, можешь решать с нами в параллель Смотреть на YouTube: youtu.be/0i_0D23aNGU