Вернуться в видеотекуЛАМПОВОЕ СОБЕСЕДОВАНИЕ и общение с ТЕХЛИДОМ | FRONTEND | JAVASCRIPT
Неформальное frontend-собеседование с техлидом о Vue и React, моделях состояния, реализации deepClone и Deferred. Во второй части обсуждают инженерный процесс, CI и стратегию тестирования.
- Направление
- Frontend
- Формат
- Техническое собеседование
- Компания
Яндекс- Длительность
- 1 ч 54 мин
Коротко о видео
Это неформальное фронтенд-собеседование с Василием, который рассказывает о работе техлидом: ответственности за несколько команд, переходе от Vue к React и нехватке времени на техническое развитие. Собеседники сравнивают Vue и React, мутабельный и иммутабельный подходы к состоянию, затем совместно разбирают задачи на deepClone и упрощённый Deferred/Promise. В финале они обсуждают прагматичную организацию разработки, CI, unit, интеграционные, e2e и snapshot-тесты, после чего дают друг другу обратную связь.
Затронутые темы
Что взять на заметку
- По словам Василия, при росте нескольких команд техлиду важно не брать необязательные управленческие обязанности, если они вытесняют техническую работу и развитие людей.
- Кандидат считает переход с Vue на React возможным поэтапно, например в пределах квартала, если модули относительно независимы, а бизнес-логика отделена от интерфейса; это его оценка, а не универсальное правило.
- В обсуждении deepClone выделяют обработку примитивов, массивов, обычных объектов, Map, Set, Date, прототипов и циклических ссылок; функции предлагают не клонировать, а передавать по ссылке с учётом контекста использования.
- Для задач общего назначения участники упоминают structuredClone как предпочтительный готовый вариант при подходящей поддержке среды или наличии полифила.
- При реализации упрощённого Deferred основная сложность возникает в цепочках then, когда обработчик возвращает другое Deferred/Promise: следующий объект должен дождаться его результата.
- Василий выступает за короткий релизный цикл и быстрое попадание изменений близко к production, но набор и строгость проверок предлагает выбирать по риску и стадии конкретного продукта.
- Критичную бизнес-логику стоит покрывать unit-тестами; e2e и smoke-тесты полезны для пользовательских сценариев, но тяжёлый и нестабильный CI, по мнению участников, снижает ценность проверок.
- Snapshot-тесты собеседники считают оправданными прежде всего для изолированных презентационных компонентов и дизайн-систем, но не как замену содержательных тестов бизнес-логики.