Что было самой интересной задачей за последнее время

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

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

Как отвечать

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

• поиск причин фризов главного потока через Instruments, разделы Time Profiler и Hangs, и вынос тяжёлой работы с него;
• утечка из-за цикла сильных ссылок в замыкании или делегате, разбор через Memory Graph и переход на weak;
• перевод слоя данных на async/await и структурированную конкурентность, разбор предупреждений об изоляции акторов;
• тормозящая прокрутка списка, диффируемый источник данных, предзагрузка и отказ от пересчёта высоты ячеек на лету;
• стык SwiftUI и UIKit через контроллеры-обёртки, когда переносили экран по частям.

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

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

Рассказывают про интересный проект, а не про задачу. Интервьюер слышит описание продукта и не понимает, что делали лично вы, а уточнять будет уже въедливо.

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

Третье: подставляют в рассказ красивые бизнес-цифры про рост конверсии или выручки, взятые с потолка. Мобильный разработчик обычно не владеет этими метриками, и вопрос «как считали, был ли A/B» закрывает тему. Лучше честная техническая метрика: время запуска, доля зависаний, размер приложения.