Как искать решения для незнакомой задачи

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

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

Как отвечать

Опишите процесс и сразу подкрепите его своим примером:

• сузить задачу: разбить на части и понять, какая действительно новая. Часто незнакомой оказывается одна деталь, например фоновая загрузка через URLSession с background-конфигурацией, а остальное вы уже делали;
• первоисточники: документация Apple, сессии WWDC, sample code, Swift Forums, исходники Swift и открытых библиотек, issues на GitHub. Stack Overflow и ответы нейросетей полезны как подсказка, но проверяете их вы: там много устаревшего и выдуманных методов;
• прототип: маленький отдельный проект или Playground, где идея проверяется за час, а не внутри боевого модуля;
• критерии выбора: минимальная версия iOS и @available, требования App Store Review Guidelines, запрет приватного API, лицензия и поддержка сторонней библиотеки, замеры в Instruments;
• таймбокс: заранее решить, сколько копаете сами, прежде чем спросить коллегу, и прийти к нему уже с тем, что попробовали.

Пример должен быть вашим: что за задача, сколько заняло, что выбрали и почему отказались от альтернатив. Цифры берите реальные, «ускорили на 20%» без замера звучит как заготовка. Если яркого случая нет, возьмите недавнее изучение нового API или фреймворка и честно скажите, что задача была учебной.

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

Отвечают «загуглю и найду». Интервьюер слышит копирование чужого кода без понимания, особенно если найденный ответ написан под Objective-C или давно устаревший API.

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

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