Писал ли сам прокси

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

Сначала уточните, о чём речь: в Java-собеседовании «прокси» почти всегда означает объект-заместитель и динамические прокси, а не сетевой прокси-сервер. По ответу смотрят, понимаете ли вы, как устроен Spring изнутри, и трогали ли вы рефлексию руками.

Как отвечать

Скажите, какое прочтение берёте, и разберите основное. Динамический прокси это объект, который подставляется вместо настоящего и перехватывает вызовы. В стандартной библиотеке это Proxy.newProxyInstance с InvocationHandler, он работает только через интерфейсы. Если интерфейса нет, в дело идут генераторы байт-кода, они наследуют класс, а значит бессильны с final классами и final, private, static методами.

Service s = (Service) Proxy.newProxyInstance(loader, new Class<?>[]{Service.class},
    (proxy, m, args) -> {
        long t = System.nanoTime();
        try { return m.invoke(target, args); } finally { metrics.record(m, t); }
    });

Дальше назовите, где это встречается каждый день: @Transactional, @Cacheable, @Async, повторы вызовов, метрики, ленивые сущности в Hibernate. Если опыт был именно с прокси-сервером, расскажите про него честно: разбор заголовков, таймауты, пул соединений, передача тела потоком без буферизации целиком.

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

Не знают про самовызов. Обращение к аннотированному методу изнутри того же объекта идёт мимо прокси, и транзакция или кеш просто не применяются. Лечится вынесением метода в отдельный бин, а не добавлением новых аннотаций.

Второе: забывают, что m.invoke заворачивает исключение цели в InvocationTargetException. Если его не развернуть, вызывающий код ловит не ту ошибку, а стектрейс становится нечитаемым.

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