Расскажи о последнем сложном техническом решении.
Что проверяют
Масштаб задач, которые вам доверяют, и ход мысли: умеете ли вы видеть варианты, называть trade-off и признавать компромиссы. «Идеальная» история без минусов звучит неправдоподобно — цифры и честность ценятся выше.
Структура: STAR
- S (Situation) — контекст: продукт, команда, ограничения.
- T (Task) — ваша задача и почему она была сложной.
- A (Action) — варианты, которые рассматривали, trade-off каждого, что выбрали и почему, что сделали лично вы.
- R (Result) — измеримый результат и что сделали бы иначе.
Пример ответа
S: Приложение доставки, 4 iOS-разработчика. Экран корзины тормозил на старых iPhone, а продукт планировал добавить туда рекомендации.
T: Нужно было решить, переписывать ли экран на SwiftUI или оптимизировать существующий UIKit, за три недели до релиза.
A: Рассмотрел три варианта: точечная оптимизация UIKit (быстро, но долг остаётся), полный переход на SwiftUI (чисто, но риск по срокам и минимальная iOS 15), гибрид — SwiftUI для нового блока рекомендаций внутри UIHostingConfiguration. Замерил в Instruments: 70% времени уходило на пересчёт layout ячеек. Выбрал гибрид: убрал пересчёт через кеш высот, новый блок написал на SwiftUI, чтобы не наращивать UIKit-код.
R: Время отрисовки упало с 48 до 11 мс, релиз вышел вовремя. Минус — две технологии на одном экране; через два релиза мы перевели его на SwiftUI целиком. Сейчас сделал бы замеры до обсуждения вариантов, а не после.