Костя 8Бит | Fullstack AI

3 ошибки на собеседовании, из-за которых не дают оффер

⏰ 1. Время собеседования
Идеальное время для собеса это 13-15. Обязательно после обеда.
С утра все сонные и злые, под вечер уставшие.
После обеда собеседующие более довольные после еды и также кровь от головы оттекает к желудку и мучать будут не так сильно.

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

🤔Всегда задавай интересующие вопросы. О проекте, о команде, о процессах. Это показывают вашу заинтересованность и проактивность.

👨‍💼Представьте себя на роли нанимающего. Пришел разработчик и ничего не спрашивает ничем не интересуется. Получается и в реальной работе также будет молчать.

🤫 3. Молчание во время решения задач

👩‍💻Во время решения задачи(лайфкодинг или систем дизайн) обязательно размышляй вслух
Если ты молча думаешь — интервьюер не понимает:
- как ты рассуждаешь
- почему принимаешь решения
- где именно ты застрял

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

Эти три вещи уже сильно выделяют кандидата среди остальных.


Какие моменты интересно разобрать вам с собеседований?

Ускорил разработку в 2 раза с помощью ИИ

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

🧠 Мой реальный опыт по ускорению и автоматизации написания кода:

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

⚙️ Боилерплейт
Типовые компоненты, обвязка под API, схемы, интерфейсы -> тут нейронки работают отлично. То, что раньше писал механически и монотонно, теперь появляется за минуты.

Было (писал сам):
type User = {
  id: string
  name: string
  email: string
}

export const fetchUser = async (id: string): Promise<User> => {
  const res = await API.call(API_URLS.user(id))
  if (!res.ok) {
    throw new Error('Failed to fetch user')
  }
  return res.json()
}

Стало:

Опиши функцию получения user с сервера с типизацией

🧹Рефакторинг.
Теперь разложить файл, упростить логику, привести код к одному стилю максимально быстро. ИИ делает все нас.

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

Было

export const validateUser = (data: any) => {
  if (!data) {
    return { valid: false, error: 'No data' }
  }

  if (typeof data.email !== 'string') {
    return { valid: false, error: 'Email is required' }
  }

  if (!data.email.includes('@')) {
    return { valid: false, error: 'Email is invalid' }
  }

  return { valid: true }
}

Стало

type UserInput = {
  name: unknown
  email: unknown
}

const isString = (v: unknown): v is string =>
  typeof v === 'string'

const validateName = (name: unknown): string | null => {
  if (!isString(name)) return 'Name is required'
  if (name.length < 2) return 'Name is too short'
  return null
}

const validateEmail = (email: unknown): string | null => {
  if (!isString(email)) return 'Email is required'
  if (!email.includes('@')) return 'Email is invalid'
  return null
}

🐌 Но вот когда реально ИИ начинает тормозить:

❌ если не декомпозировать задачу
❌ не формализовать требования
❌ не проверять результат

Я просто скормил промт

Сделай такую задачу(краткие бизнес требования), напиши фронтенд часть, напиши бекенд часть. Используй стандартный стек.

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

🧑‍💻 По ощущениям, ИИ как джун, который пишет код очень быстро.
Но если правильно не направлять и не проверять, будет больно.


Итог простой:
ИИ реально даёт x2 по скорости,
но только тем, кто умеет думать, формулировать и проверять.

Как выбрать стек приложения? Фронтенд часть

1️⃣Выявление требований
Самый важный пункт. Нужно не выбираем между React/Vue/Svetle, а сначала узнаем что за продукт от нас нужен.

Ответьте на базовые вопросы:

Это лендинг, админка или сложный SaaS?
Нужен ли SEO?
Будет ли мобильная версия / PWA?
Ожидаемая нагрузка и масштаб?

🔠Антипаттерн: брать сложный фреймворк на лендинг или маленькое приложение.


2️⃣ Потребности бизнеса и возможности команды
Если в компании устоявшийся стек и проект нужно сделать, выбирайте его.
Никаких

"а давайте поиграемся с Effector, я читал на хабре что он крутой"

Времени на обучение уйдет уйма.
📱 Переход на новый фреймворк/модуль ради тренда часто замедлит разработку.

Реальный пример из работы:
Много лет назад на моей работе тимлид сказал что вместо redux и redux-saga будем использовать graphql и apollo-client. Никто на нем не умел писать. Целый месяц мы только писали одну страницу и потратили десятки часов на понимание этого модуля и подхода. В итоге тимлид сказал что отказываемся от apollo-client и все перепишем обратно на redux, т.к. так быстрее.

3️⃣ Фреймворк
В данном момент 2026 кроме React или Vue я считаю выбирать нечего. Svetle, Solid, Quick не подходят для продакшен кода большого/среднего приложения. Angular вообще умер 15 лет назад.
Небольшой/средний проект? Vue
Потенциально большой проект? React

4️⃣ Ресерч модулей под требования
После выявления требований можно начать выбирать или ресерчить модули.

Данные в реальном времени? WebSocket/SSE/Long-polling
Много графики? Canvas -> но модулей я не знаю -> иду ресерчить
PDF? pdf.js / react-pdf / PDFObject
Нужен SSR? Подумай о Next/Nuxt

И далее по списку

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


5️⃣ Архитектура проекта
Фреймворк это только часть стека.
Нельзя забывать про:
- структуру проекта (FSD, слоистая, модульная)
- state management
- роутинг
- тестирование
- сборщики и линтеры

Хорошая архитектура важнее выбора конкретной библиотеки.

🔥 Архитектура до кода: как я сэкономил миллионы

Самая важная стадия разработки == архитектура.

Как я проектировал прилоежние сотни тысяч клиентов 🚀

1️⃣Сбор требований
Главная ошибка всех программистов сразу начать писать код ❌
Супер важно определить бизнес-цели, технические риски и будущие интеграции.

Я созвонился с 5 командами 📞, чтобы понять всю сложность. Множество деталей, которые нужно было держать в голове 🧠

Оказалось все не так просто, как описывал ПМ. Куча ограничений по безопасности, хранению данных пользователей 🔐 и непростые интеграции.

2️⃣ Проработка и визуализация

После сбора всех требований начал прорабатывать архитектуру.

Собрал клиент
👉 React + canvas + websockets + zustand

API Gateway

Обрисовал все взаимодействия с бэком и на какие сервисы будет делиться система:

User Service
Data Service
Anonymizer Service

Написал все интеграции и что нужно для взаимодействия с ними

Авторизация
Внешние LLM
Внутренние LLM
Хранение файлов S3
Email API

Определил зоны ответственности сервисов.
После этого апрув ✅.


3️⃣ Технический бэклог
После апрува архитектуры я разложил её на конкретные технические блоки:

Инфраструктура 🛠
- настройка CI/CD (линт, тесты, сборки, деплой)
- окружения (dev / stage / prod)
- управление секретами и конфигами

Безопасность и доступ
- модуль авторизации и ролей
- сервис анонимизации (чистки) данных

Frontend-архитектура
- сборка и изоляция модулей
- real-time взаимодействие (sockets)
- canvas / сложные UI-сценарии


И только после этих этапов начал писать первые строчки кода.

Новые стандарты разработки

Из всех углов слышно:

Нейронки заменят айтишников.

👻Страшно. Выключай.

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

🙎‍♂️Менеджерам тоже скоро придется напрягаться.
Без современных инструментов и базовой технической подкованности такие менеджеры скоро будут не нужны.
🦜Эпоха «менеджеров-дятлов» заканчивается.

Теперь:
— спецификация обязательна
— бизнес-контекст обязателен
— нормальное описание задач обязательно

🔽Тикеты формата «ну там кнопочку сделать» — в бан.

С программистами чуть по другому.
Больше не прокатит:

«Ну мужик, я сделал как мог, у меня вроде работает, дальше сам».

💻Теперь разработчику придётся:
— вникать в продукт, а не просто закрывать таски
— думать об архитектуре, последствиях решений и масштабировании
— пользоваться современными инструментами: AI, автотесты, линтеры, анализаторы, нормальные пайплайны

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

Миллион WebSocket соединений

Представьте что у вас огромный поток пользователей и уперлись в аппартные ограничения. Что делать? Как масштабировать?

В новом ролике поговорим про вертикальное и горизонтальное масштабирование

Микрофронты в банке: архитектура, за которую платят дорого

Это было большое банковское приложение, которое в итоге грузило 15 микрофронтов.
Несколько команд, разные домены, независимые релизы классика для MFE.

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

Первое — общие зависимости.
UI Kit должен быть единым, но обновляться безопасно.

shared: {
  react: { singleton: true },
  '@bank/ui-kit': { singleton: true }
}

Второе — общение между микрофронтами.
Прямые импорты запрещены, global state — риск.

Мы сделали отдельный пакет в Nexus npm, который выступал контрактом:

// @bank/mf-bridge
export const events = createEventBus();

events.emit('user:logout');
events.on('user:updated', handler);

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

Главное открытие — микрофронты ломаются не из-за кода,
а из-за отсутствия правил и границ ответственности.

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

Если хочешь понять, как это делают в больших продуктах:
Смотри
👉ПРОБНЫЙ УРОК

👉 Узнать детальнее в лс

ПОЛУЧИТЬ ДОСТУП

Самая дорогая фронтенд-архитектура

Есть фронтенд-навыки, которые просто закрывают задачи.
А есть те, которые повышают ценность разработчика на рынке.

💫 Микрофронты из второй категории.

их сильно ценят крупные компании — и готовы за это платить.

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

В этот момент фронтенд перестаёт быть приложением
и становится сложной системой.

В которой вопросы без простых ответов:
— какие зависимости shared?
— кто владеет роутингом?
— где границы ответственности?

shared: {
  react: { singleton: true },
  'react-dom': { singleton: true }
}

Одна строка здесь уже архитектурное решение.
Поэтому микрофронты — одна из самых сложных
и самых дорогих архитектур во фронтенде.

На этом и построен мой интенсив по микрофронтам:
архитектура, реальные кейсы и мышление сильного инженера .

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

👉 ПРОБНЫЙ УРОК

❗️Узнать детальнее в личке

👉 ПОЛУЧИТЬ ДОСТУП

САМАЯ СЛОЖНАЯ АРХИТЕКТУРА

В новом ролике поговорим о подходе микрофронтов.

В чем отличие от микросервисов и почему Яндекс и Сбер используют эту архитектуру?

Микрофронтенды

Микрофронты — это подход, при котором большое фронтенд-приложение разбивается на независимые части, каждая из которых:
🚧 разрабатывается отдельно
🚀 может деплоиться независимо
👥 имеет свою команду и ответственность

По сути, это микросервисы, но для фронтенда 🧩

🤔 Зачем это делают?

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

👨‍💻 Как это выглядит в коде

SPA composition (через роутинг)

Shell-приложение решает, какое SPA показывать по URL:

// shell/App.tsx
import { BrowserRouter, Routes, Route } from "react-router-dom";

export function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/profile/*" element={<ProfileApp />} />
        <Route path="/billing/*" element={<BillingApp />} />
      </Routes>
    </BrowserRouter>
  );
}

✅ Плюсы очевидны:
- независимые релизы
- масштабирование команд
- изоляцию ошибок
- можно использовать React, Vue, Angular одновременно

❌ Минусы тоже есть:
- сложнее инфраструктура
- сложнее дебаг
- выше требования к архитектуре

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

Микрофронты оправданы, если вы работаете на большом проекте 🏗️

В моей практике я использовал микрофронты на очень больших проектах:
🏦 2 больших банка и 🛒 маркетплейс.

Есть несколько вариантов реализации: Module Federation, iframe, SPA composition

// profile/webpack.config.js
new ModuleFederationPlugin({
  name: "profile",
  exposes: {
    "./ProfileWidget": "./src/ProfileWidget",
  },
});

<iframe
  src="https://billing.example.com"
  style="width:100%; height:100%; border:0"
/>

Шпаргалка по System Design про которую говорил в видео

🚫 КАК НЕЛЬЗЯ ВНЕДРЯТЬ AI / CHATGPT

Расскажу, как на моём реальном проекте внедряются нейронки 🤖
Это не просто

«отправил данные по API с токеном и визуализировал результат»

1️⃣ Системный промпт 🧠

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

export const SYSTEM_PROMPT_V1 = `
You are an assistant helping to analyze user input.
Rules:
- Return JSON only
- If data is insufficient, return "INSUFFICIENT_DATA"
Output format:
{
  "summary": string,
  "confidence": number
}
`;

2️⃣ Анонимизация данных 🔐

Перед тем как отправить персональные данные, их обязательно нужно обезличить.
Мы сделали отдельный сервис анонимизации, который:
🧹 удаляет / маскирует персональные данные
🏷️ заменяет сущности на нейтральные имена
🛡️ гарантирует, что модель не видит реальные данные

Внутри сервиса анонимизации крутится отдельная логика замены данных.

POST /anonymize
{
  "text": "Иван Иванов работает в компании X и живет в Москве"
}

function anonymize(text: string) {
  return text
    .replace(/[А-ЯЁ][а-яё]+ [А-ЯЁ][а-яё]+/g, "USER_NAME")
    .replace(/Москва|Санкт-Петербург/g, "CITY");
}

3️⃣ Оркестратор вместо прямого вызова AI 🧩

Мы не дергаем ChatGPT напрямую ❌
Есть оркестратор, который:
🔁 управляет пайплайном
🤖 решает, какую модель использовать
🧠 оперирует контекстом, если он есть

async function aiPipeline(rawInput: UserInput) {
  const anonymized = await anonymizeService(rawInput);

  const preparedPrompt = buildPrompt({
    system: promptRegistry.v1,
    user: anonymized.text,
  });

  const aiResponse = await callLLM(preparedPrompt);

  const validated = validate(aiResponse);

  return postProcess(validated);
}

4️⃣ Пост-обработка ответа ✅
Ответ модели это не конец. После ответа LLM мы:
🧪 валидируем структуру
🚫 фильтруем некорректные данные
🎯 приводим результат к виду, пригодному для UI / API

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

При интеграции важно учесть архитектуру, безопасность, контроль и ограничения

Зимовка айтишника на Пхукете, Бали

Уже как полтора месяца назад улетел из Питера в Азию и работаю отсюда. Проехал Пхукет 🇹🇭 , Бали 🇮🇩 , Гонконг 🇭🇰 , Шеньжень 🇨🇳

➕ Плюсы

В +28 куда приятнее жить и работать , чем в -10 и без солнца 😄

Стоимость жизни: в ЮВ Азии жизнь гораздо дешевле чем в Питере или Москве.

Перезагрузка головы: новый контекст освежает и придает новые идеи 💡

➖ Сложности

Дисциплина: очень сложно работать, хочется пойти на пляж и начать смузихлебить

Таймзоны: начинаю работать в 15 а заканчиваю в 23. Когда все отдыхают вечером ты только заканчиваешь.

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