Сообщение из чата 8 потока ❤️‍🔥

Уроки, созвоны, практика в обучении — это база. Но важно еще и комьюнити.

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

И у нас были случаи, когда ученики по рефералке трудоустраивали друг друга к себе в компании🤝

ВОПРОС С СОБЕСА НА 240К💰

❓ Что такое обратная совместимость API?

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

🤦‍♂️ Плохой ответ:

Ну, это когда всё работает и ничего не ломается… типа API совместим со всеми. Если что-то не работает, то этим занимаются разрабы 🤷‍♂️

🤝 А хороший звучит так:

1. Обратная совместимость — это когда изменения в API не ломают работу старых клиентов.
2. Пример: добавил новое поле email, но сделал его опциональным. Старые клиенты, которые не ожидают его, просто его игнорируют — и всё работает.
3. Breaking change — это любое изменение, которое ломает старые клиенты.
4. Как поддерживать совместимость:
• Добавляю новые поля, но не удаляю старые
• Использую новые версии API (/v2/user)
• Делаю параметры опциональными
• Чётко документирую изменения

🧐 Что чаще всего ломает обратную совместимость?

• Удалили поле из ответа API — старые клиенты начинают падать.
• Поменяли тип данных (id был строкой, стал числом) — половина запросов с ошибками.
• Переименовали поле — старый код ничего не понимает.
• Изменили формат ошибки или код ответа (200 на 201) — клиенты зависают в ожидании.
• Сделали обязательным новый параметр — старые клиенты его не передают — ошибка.

Если на собесе скажешь хотя бы 2–3 таких примера — это будет уверенный middle-уровень, потому что интервьюер сразу понимает: ага, чел реально сталкивался с боевыми интеграциями.

Еще небольшой лайфхак:
Упомяни компромисс: «Иногда проще завести новую версию API, чем тянуть старые костыли».

+ Можно блеснуть примером из практики: «Мы добавили новые поля в ответ, но не трогали старые, поэтому старые интеграции не упали».

Если коротко 😑

Обратная совместимость = изменения в API не ломают старых клиентов.
Breaking change = ты поломал, и теперь у клиентов горит 🔥

Арендовал катер за 16 тысяч 💸

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

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

P.S. Я радовался как ребенок, кричал другим катерам, что сейчас возьмем их на абордаж…

Снимаю большой ролик про историю своего пути в IT 📹

Понял, что опыта накопилось достаточно, будет интересно и новичкам, и ребятам с опытом. Решил всё это собрать в одно видео: с чего начинал учебу в айти, как попал в ВТБ, из-за чего увольнялся из Самоката и что сейчас делаю в Wildberries.

В процессе начал вспоминать, каким было менторство в самом начале, и мягко говоря, охерел от того, насколько всё изменилось 👇

Лето 2024

• Начинаю собирать групповые потоки, записываются 6-13 человек 🙂

• Сам веду лекции, времени уходит очень много, структурности в школе не хватает. Понимаю, что нужно расширять базу знаний.

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

Осень 2025

• Становимся полноценной школой IT Garden, в которой 200+ человек: ученики, команда и подрядчики.

• Большая база знаний: уроки, роадмапы, гайды по БА, СА и трудоустройству. Это уже не просто менторство, а целая экосистема с пошаговым доведением до оффера.

• Полностью оцифровали процесс трудоустройства: резюме, собесы, готовые стратегии, все разложено по шагам 🗺

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

Но это не значит, что пора остановиться. Я четко вижу, что ещё можно улучшить и докрутить. Так что большие рекорды только впереди 🥊

🛒Собес в WB на middle СА: разложи процесс заказов без факапов

Клиент отправляет данные через фронт -> сервис проверяет наличие товара на складе -> если товар есть — формирует заказ -> отправляет уведомление клиенту.

Вопрос: Как организовать процесс, чтобы он работал стабильно и без ошибок?

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

Поэтому, как я бы разложил это на собесе:

1️⃣ Фронт

Клиент жмёт «Купить», фронт шлёт запрос с ID товара, количеством, данными клиента, способом оплаты/доставки.
Уточняю: формат запроса? поддерживаем повторные клики/повторы запроса? Показываем интервьюеру, что следим за деталями.

2️⃣ Проверка наличия

Сервис обращается к БД: доступно ли нужное количество.
Сразу встречный вопрос: «Как обрабатывается ситуация, если товара нет?». Варианты, если нет остатков: вернуть ошибку, предложить уменьшить количество, показать альтернативы.

3️⃣ Формирование заказа

Создаём запись заказа: id заказа, клиент, позиции, суммы, статус, способ оплаты/доставки, время.
Обязательно проверить, хватает ли средств/валидна ли карта.

4️⃣ Уведомление клиента

Отправляем e-mail/push/sms асинхронно (чтобы не тормозить основной поток) после успешного сохранения заказа/резерва. Если уведомление не ушло —журнал ошибок, сам заказ не откатываем.

5️⃣ Подводные камни / детали

• Некорректные данные от фронта — чёткие коды/сообщения об ошибках
• Одновременные заказы на один товар — резерв/блокировки на уровне склада
• Логирование действий для поддержки
• Кэширование остатков для ускорения проверки
• Асинхронные уведомления для масштабируемости

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

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

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

Набираем 150 мешков и продолжу разбирать вопросы из бигтеха💰