Работали ли вы с дженериками в Java?

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

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

Как отвечать

Сначала честно про опыт: писали ли вы на Java в андроид-части общего проекта или встречали её только в чужом коде. Дальше покажите, что механику понимаете, и сразу переводите на свою территорию:

func maxItem<T: Comparable>(_ items: [T]) -> T? { items.max() }

Ключевых отличий три, и они звучат сильнее, чем пересказ учебника по Java:

• стирание против специализации: в Java параметр типа существует только при компиляции, поэтому new T() и проверка типа в рантайме невозможны. В Swift тип доступен, компилятор либо специализирует функцию, либо работает через таблицу свидетелей;
• подстановочные типы против some и any: вместо ? extends Number в Swift ограничения на параметре и where, а для стирания типа существует явный экзистенциальный any Protocol;
• примитивы: в Java обобщается только ссылочный тип, поэтому Box<int> невозможен и числа упаковываются. В Swift Array<Int> хранит значения без упаковки.

Хорошо добавить, где вы сами применяете дженерики: сетевой слой с обобщённым разбором ответа, контейнеры с associatedtype, обобщённые ячейки списка.

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

Переносят привычки Swift на Java: обещают создать экземпляр параметра типа или проверить его на исполнении. В Java это не работает именно из-за стирания, и вопрос обычно идёт следом.

Отвечают заученным чужим текстом и не связывают его со своей платформой. Интервьюер переспрашивает про some и any или про ассоциированные типы протоколов, и разговор обрывается.

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