Почему использовали дефолтный Navigator 2.0 и что бы использовали вместо него в ретроспективе
Что проверяют
Это вопрос не про API, а про то, умеете ли вы объяснить архитектурное решение и честно оценить его задним числом. Интервьюер смотрит, был ли выбор осознанным и что вы вынесли из его последствий.
Как отвечать
Сначала коротко, о чём речь: Navigator 2.0 это декларативный подход к навигации, где стек экранов не меняется вызовами push и pop, а собирается из состояния приложения. Отсюда его сильные стороны: глубокие ссылки и восстановление после перезапуска получаются почти даром, потому что адрес и стек это одно и то же состояние; условие вида «не авторизован, показать вход» выражается одной веткой, а не набором императивных вызовов, раскиданных по экранам; навигация становится обычными данными, которые видно в тестах.
Дальше причина выбора: брали то, что идёт из коробки, потому что это ноль лишних зависимостей и полный контроль над разбором адреса и вложенными стеками.
Ретроспектива это та часть, ради которой вопрос и задан. Честный ответ звучит так: низкоуровневый API оказался многословным, написанные вручную делегат маршрутизации и разбор адреса разрослись, и каждый новый экран стоил непропорционально много кода. Сейчас взяли бы обёртку над тем же механизмом с декларативным описанием маршрутов и типизированными параметрами, оставив ручную реализацию для мест, где нужен нестандартный стек.
Где спотыкаются
Отвечают «использовали, потому что так было в проекте до меня». Интервьюер ждёт причину, поэтому «унаследовали» надо продолжить тем, что вы в этом решении проверили и почему оставили.
Второе: критикуют выбор, не называя цену. «Слишком сложно» звучит как жалоба; убедительно выглядит измеримое: объём кода на добавление экрана, время на разбор новичком, число багов с кнопкой возврата.
Третье: в ретроспективе предлагают переписать всё. Сильный ответ ограничивает изменение: новые экраны на обёртку, старые оставить как есть, потому что переписывание навигации целиком ломает глубокие ссылки и историю переходов.