Мне приходилось разрабатывать тесты для поступающих. Правда не только Java
но и по прочим технологиям на производстве.
Это аццки сложная работа. Типичные сложности с которыми столкнулся
лично я и коллеги которые делали review по моей просьбе.

1) Субъективность . Пишуший тесты обычно 1 чел. В редких случаях это команда.

2) Отсутствие критики со стороны . Безконтрольность. Пишущий считает что никто не вправе оспаривать
истинность формулировки теста.

3) Языковые сложности и метафоры . Ссылка/Объект. java.lang.Classs/Object/reference/C++-reference/java.lang.reference
это разные вещи но пишущий обычно их путает, смешивает.

4) Трудности английского перевода . Application - приложение или применение?
Projection/проектирование - проецирование? Вот далеко не полный список.

5) Ложные ответы и ответы-обманки . Можно трактовать как тест повышенной сложности
либо целенаправленный тест-ловушка в котором с нужной долей вероятности даже гуру
даст неверный кейс ответа.

6) Сокращения. Аббревиатуры. Жаргон . OOM- Out Of Memory? Object oriented modelling?

7) Неверная формула расчёта конечного балла . У меня формула приводила к тому
что даже не знающий протаскивал порядка 60% верных ответов.

8) Видимая очевидность ответа . Армейский анекдот про ток который измеряется в Амперах.
Как ни странно - анекдот это реальность.

9) Софизмы. Диалектика. Спорные вопросы которые нельзя выностить в тестирование
но пишущий их тем не менее выносит. В Java таким софизмом обычно являются
вопросы на тему Garbage Collector и тонкостей его работы.

10) Несоответствие задачам. Пишущий может быть весьма далёк от реальных
вопросов которые будет делать соискатель.

yapadega, собеседование должно быть второй фазой.
Уже после написания теста. Вот как раз на нём
и допускается давать вопросы в более вольной форме.
Соискатель может задавать уточняющий вопрос и это
будет норм. В противоположность письменный тест - это как
правило молчаливая форма вопроса.