Приходилось ли работать с TreeSet или TreeMap?

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

Понимаете ли вы, за что платите, выбирая сортированную коллекцию вместо хэшированной, и знаете ли, что TreeSet определяет дубликаты сравнением, а не через equals и hashCode. Это стандартная проверка знания контрактов коллекций, а не умения назвать структуру данных под капотом.

Как отвечать

Скажите устройство: обе построены на красно-чёрном дереве, реализуют NavigableSet и NavigableMap, основные операции стоят логарифм от размера, обход идёт в порядке ключа. Порядок задаётся либо Comparable у самого ключа, либо компаратором, переданным в конструктор.

Дальше главное: брать их стоит не ради сортировки как таковой, а ради навигации по диапазонам.

TreeMap<LocalDate, BigDecimal> rates = new TreeMap<>();
var entry = rates.floorEntry(date); // курс на дату или ближайший предыдущий

Методы floorEntry, ceilingEntry, headMap, tailMap, subMap, pollFirstEntry дают то, чего у HashMap нет вовсе. Добавьте про пустые значения: TreeMap с естественным порядком не принимает null ключом и бросает исключение, TreeSet не принимает null элементом, хотя значения в карте пустыми быть могут. И про потоки: ни одна из них не потокобезопасна, для конкурентного доступа есть ConcurrentSkipListMap.

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

Говорят, что дубликаты отсекаются по equals. Отсекаются они сравнением: если compareTo вернул ноль, элемент считается уже присутствующим, даже когда equals говорит обратное. Несогласованные compareTo и equals ломают контракт множества.

Второе: берут дерево там, где нужен просто вывод по порядку. Если диапазонных выборок нет, дешевле держать HashMap и один раз отсортировать при отображении, а для порядка вставки есть LinkedHashMap.

Третье: меняют у уже лежащего в множестве объекта поле, участвующее в сравнении. Элемент остаётся на прежнем месте дерева, поиск перестаёт его находить, и запись фактически теряется до полного обхода.