Проблема, с которой мы сталкиваемся, связана с тем, как компилятор Java обрабатывает varargs внутри условных выражений, особенно когда ветви условия производят разные типы. Вот подробное объяснение и пошаговое решение:
когда мы используем условное выражение, компилятор не может обернуть только одну из ветвей. Он воспринимает условное выражение как целое. Поскольку тип ветви then — String, а тип ветви else — Object[], тип всего условного выражения является общим суперклассом для String и Object[], то есть просто Object. Это не массив, поэтому компилятор добавляет автоматическое оборачивание, что означает, что массив params будет обернут ещё раз.

Вы можете исправить это, если не будете полагаться на компилятор и обернете строку вручную: params.length == 0 ? new Object[]{"default"} : params. Однако, вероятно, будет менее запутанно вообще избегать условных выражений внутри вызова метода с varargs.

Что может напечатать метод print?

Ответ к вопросу про инкремент под гонкой:
Рассуждения аналогичные как и тут:
https://t.me/java_interview_tasks/96
Для примера, посмотрим, как может получится 2 - это самый интересный случай (см. картинку к посту)
Остальные варианты (больше 2) возможно получить аналогичными рассуждениями.

Выводы: этот простой пример показывает, что не синхронизированный счётчик может терять много данных.
Если вам нужно использовать счётчик под гонкой, то надо синхронизировать инкремент или использовать уже синхронизированные счётчики, например, AtomicInteger

Логическая задача с собеседования:
Два друга, Андрей и Иван, решили приготовить пирог. Андрей внес вклад, добавив в тесто 300 грамм муки, а Иван добавил 200 грамм сахара. Когда пирог был испечен, к ним заглянул сосед и они пригласили его на чаепитие. Пирог разделили поровну на троих. После чаепития сосед оставил им 500 рублей в качестве благодарности.

Андрей предложил делить деньги так: 300 рублей ему, а 200 рублей Ивану. Однако Иван не согласился.
Как вы считаете, как они должны разделить вознаграждение, чтобы все было честно?

Что вернет метод?

Проблема в порядке операций, что может ввести в заблуждение - тернарный оператор имеет низкий приоритет
Пример кода, который однозначно будет пониматься:

Что делает метод trimAll?

Здесь автор кода по ошибке попытался обрезать все строки внутри списка, но метод forEach позволяет использовать все элементы коллекции, но не позволяет их обновлять. Он принимает функциональный интерфейс Consumer, чей абстрактный метод accept() возвращает void, поэтому результат вызова trim() игнорируется. Было бы правильнее использовать метод replaceAll() в данном случае.

Что напечатает код?

Правильный ответ: key=keyline
Как видите, содержимое начинается с ключа, что не соответствует нашим ожиданиям. Давайте внимательнее изучим:

map.computeIfAbsent("key", StringBuilder::new)
.append("line").append("\n");

Здесь мы создаем новую запись в мапе, если она еще не была создана. Мы использовали метод референс для новых записей. Но какой конструктор StringBuilder мы вызываем здесь? Если вы преобразите ссылку на метод в лямбда-выражение, вы получите следующее:

map.computeIfAbsent("key", str -> new StringBuilder(str))
.append("line").append("\n");

Теперь результат более понятен. Функция, переданная в computeIfAbsent(), имеет аргумент, который является ключом, переданным в качестве первого параметра. Легко забыть об этом, поскольку обычно вам не нужен этот аргумент, и если он вам нужен, вы можете захватить переменную key. В лямбда-выражении вы можете просто проигнорировать этот аргумент. Однако, когда используется ссылка на метод, компилятор ищет конструктор, который принимает строку. Поскольку в StringBuilder фактически есть такой конструктор, компиляция успешно завершается, но вновь созданный StringBuilder не будет пустым. Было бы правильнее использовать лямбда-выражение и конструктор по умолчанию здесь. Ссылка на метод здесь совсем не подходит.

Какая реализация метода верная? (мы не знаем какая конкретно реализация List придет в метод)

java 
public List<String> unionLists(List<String> l1, List<String> l2);

1

2

3