Нужно ли использовать готовые классы из библиотеки для нод или реализовать свой класс

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

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

Как отвечать

Для узла дерева или списка внутри алгоритма пишется свой класс. Он маленький, точно типизирован под данные задачи, ничего не тянет в сборку и читается без документации.

record Node<T>(T value, List<Node<T>> children) {}

static final class ListNode {
    int value;
    ListNode next;
}

Готовый тип берут, когда он часть контракта, с которым вы и так работаете: узел дерева разбора JSON у библиотеки сериализации, узел DOM при работе с XML. Тащить узел дерева из графической библиотеки в серверный код смысла нет, а писать свой разбор JSON ради собственного узла тем более.

Критерии выбора стоит назвать вслух: покрывает ли библиотека нужную семантику (обход, неизменяемость, сериализация), сколько она тянет транзитивных зависимостей, кто обновит её при уязвимости, и не окажется ли чужой тип в сигнатурах ваших публичных методов. Последнее важнее всего: как только чужой класс попал в публичный API, его обновление становится ломающим изменением для всех потребителей.

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

Берут универсальный контейнер, хранящий Object, и теряют типизацию. Ошибка вылезает не на компиляции, а в рантайме, и обычно на данных, которых не было в тестах.

Пишут свой узел и определяют equals и hashCode рекурсивно по всему поддереву. На глубокой структуре это переполнение стека, на структуре со ссылками назад зацикливание, а в хеш-множестве ещё и пересчёт по тысячам потомков.

Отвечают в жанре «зависит от ситуации» и не называют ни одного критерия. Интервьюер ждёт как раз критерии: срок, поддержка, размер зависимости, нужная семантика.