Подготовка к вопросам о проекте и компании

Ключевые тезисы

Конспект посвящён подготовке к ответам на вопросы о проекте (внутренняя CRM-система для школы английского языка) и компании.
Основная цель — научиться структурированно рассказывать о своём опыте, используя реалистичный контекст.
Ответы должны быть правдоподобными, но не требовать глубоких специфических знаний. Важно уметь обосновать сказанное.
Ключевая стратегия: показывать себя как часть команды, где многие решения (архитектурные, технологические) принимались до вас или коллегами.

Контекст проекта: CRM-система для EdTech

Что такое CRM?
CRM (Customer Relationship Management) — это система управления взаимоотношениями с клиентами. В контексте школы английского языка она используется для управления учениками и преподавателями: учёт, звонки, назначение скидок, отслеживание посещаемости, автоматизация коммуникаций.

Как устроена компания (EdTech-школа)?

Основная услуга: обучение английскому языку (на собственной платформе, в Skype и т.д.).
Участники: тысячи преподавателей (фрилансеры) и ученики (клиенты).
Подразделения: отделы маркетинга (привлечение), продаж (конверсия), заботы о клиентах (поддержка), подбора преподавателей, разработки.
Технический ландшафт: множество разрозненных сервисов (сайт, личный кабинет, портал для учителей, лендинги). CRM выступает «сердцем», которое объединяет эти сервисы и автоматизирует сквозные бизнес-процессы (от заявки до подбора учителя).

Пример бизнес-процесса в CRM:

Маркетинг размещает лендинг → потенциальный клиент оставляет заявку.
В CRM создаётся событие → с клиентом связывается менеджер по продажам.
Проводится пробный урок → данные фиксируются в CRM.
Запускаются автоматические процессы: подбор преподавателя, отправка предложений, напоминаний.

Вопросы о компании и культуре

Миссия и продукты

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

Структура и развитие

Команда разработки CRM: 2 фронтенд-разработчика, 2–3 бэкенд-разработчика, 1 QA, продакт-менеджер/тимлид. Отдельно — архитекторы компании.
Развитие сотрудников: внутренние митапы (например, гильдия фронтендеров), обсуждение кода и технологий, бюджет на обучение (которым часто не пользовались).
Корпоративные ценности: Ориентированность на результат, постоянное развитие, работа в команде, поощрение инициативы.
Мотивация и оценка: Годовые бонусы, опросы 360°, обещание повышения. Успехи оценивались по выполнению спринтов, качеству код-ревью и активности.

Технологии и процессы

Технологический стек (фронтенд): React (или Next.js для BFF), TypeScript, React Router, Zustand/React Query. Бэкенд — Node.js/Express или PHP.
Инфраструктура: Docker, GitHub (версионирование), GitHub Actions (CI/CD).
Управление временем: Двухнедельные спринты, планирование с командой, ежедневные стендапы.

Вопросы о процессах и интеграциях

Разработка и качество

Код-ревью: Обязательно для каждой задачи. Требовалось 1–2 апрува. Обсуждали сложные задачи всей командой.
CI/CD: Настроены через GitHub Actions. Деплой на прод выполнял тимлид после демо и одобрения.
Тестирование: На фронтенде — преимущественно ручное тестирование QA по тест-кейсам. Автотесты были на бэкенде или в планах.
Безопасность и совместимость: Код хранился в приватном репозитории. Кроссбраузерность не была приоритетом (внутренний продукт), поддерживались последние версии браузеров.

Взаимодействие в команде

С бэкендом: Договаривались об API-контрактах перед разработкой, использовали моки (Mock Service Worker), затем переходили на реальные эндпоинты.
С дизайнерами: Получали макеты в Figma. Использовали корпоративный UI-кит (например, Material-UI) или собственную библиотеку компонентов.
С менеджерами: Продакт-менеджер собирал требования от других отделов (продажи, поддержка). Задачи приходили в виде эпиков в Jira, которые команда декомпозировала и оценивала в стори-поинтах (числа Фибоначчи).
Распределение задач: Сложные задачи брал более опытный разработчик (сеньор), простые — менее опытный. Помощь и консультации были всегда доступны.
Решение конфликтов: Технические споры решали на митапах команды (фронтенд/бэкенд), основываясь на опыте и аргументах.

Документирование и требования

Техническая документация: Как таковой не было. Код — самодокументируемый. Бизнес-процессы описывались в Confluence или в самом движке BPMN.
Требования (ТЗ): Бизнес-аналитик писал описание в эпиках Jira после общения с продактом. Это и было ТЗ, детали уточнялись по ходу работы.

Управление проектами и процессы

Планирование и выполнение

Появление проектов: Запросы от других отделов → приоритизация продактом → оценка тимлидом и командой → квартальное/месячное планирование.
Спринты: Двухнедельные. На планировании оценивали и брали задачи на 15-20 стори-поинтов на фронтенд. Была практика резервирования 10% времени на технический долг.
Работа с рисками и сроками: При нехватке времени шли на сокращение функционала первой очереди (гибкость scope), а не на продление дедлайнов. О критичных рисках докладывали тимлид и продакт.

Взаимодействие с пользователями

Обратная связь: Собиралась продактом и менеджерами. Для разработчиков это были такие же задачи в Jira.
Демо-презентации: Проводились в конце спринта для продакта, который затем транслировал изменения бизнес-пользователям.
Срочные запросы и баги: Существовал канал в Slack для инцидентов. Дежурный бэкенд-разработчик разбирался и при необходимости привлекал фронтенд. Горячие фиксы выкатывал тимлид.

Технические детали и решения

Архитектура и производительность

Архитектура: Монолитное фронтенд-приложение с модульной структурой (по фичам или Atomic Design). BFF (Next.js) для общения с бэкендом.
Масштабируемость: Не была острой проблемой благодаря модульности и пагинации.
Управление состоянием: Использовался стейт-менеджер (Zustand/Redux) или React Query для server state.
Оптимизация: Использование React.memo, useCallback, виртуализация длинных списков, разбиение больших API на более мелкие, ленивая загрузка модулей.
Типичные задачи: Разработка и расширение карточки клиента (добавление полей), списков с фильтрами, лента действий оператора.

Внедрение нового

Принятие решений: Технологические решения обсуждались на митапах гильдии фронтендеров или внутри команды. Итоговое слово было за сеньором/тимлидом.
Внедрение: Новые библиотеки/подходы сначала опробовались на изолированном модуле, затем, при успехе, распространялись.
Обновления: На обновление зависимостей выделялось специальное время раз в несколько месяцев.

Организация работы и продуктивность

Рабочий день и баланс

График: Удалённая работа с гибким началом дня. Обязательные встречи: стендап в 10:00, демо и ретро раз в две недели, митапы гильдии.
Инструменты: Jira (задачи), Slack (коммуникация), Confluence (документация).
Баланс: Компания формально не поощряла работу в выходные, но иногда это происходило в срочных случаях. В целом культура поддерживала отдых.
Приоритизация: Старались не заниматься многозадачностью. В начале спринта брали самые важные задачи.
Обучение: Происходило в свободное время и на рабочих митапах. Компания предоставляла бюджет на курсы.

Выводы

Для успешного ответа на вопросы важно построить целостную и непротиворечивую легенду о проекте и своей роли в нём.
Следует делать акцент на командной работе и стандартных практиках (Agile, спринты, код-ревью), а не на уникальных или сложных решениях.
Нужно быть готовым обосновать любой названный технологический выбор (почему React, почему именно эта библиотека).
Стратегия «я пришёл на готовый проект и поддерживал/дорабатывал его» позволяет избежать сложных вопросов о первоначальных архитектурных решениях.
Ключевые моменты, которые нужно уметь описать: жизненный цикл задачи, взаимодействие с бэкендом и дизайнерами, решение проблем с производительностью, работа в Agile-цикле.