Расскажите про самую сложную техническую задачу, с которой сталкивались

Что проверяют

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

Как отвечать

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

Ведите рассказ по шагам расследования:

• как проявлялось и что было известно из отчётов о падениях;
• чем сужали: Instruments, Time Profiler и Allocations, Thread Sanitizer для гонок, логирование состояния до и после;
• в чём оказалась причина и почему она была неочевидной, например обращение к UIKit из фоновой очереди годами сходило с рук и сломалось на новом устройстве;
• что сделали и как убедились: воспроизводящий тест, проверка на устройстве, наблюдение за долей сессий без падений после выката.

Скажите и про отвергнутый вариант: почему не стали лечить симптом задержкой или лишним DispatchQueue.main.async.

Где спотыкаются

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

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

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