Ответ к вопросу про инкремент под гонкой:
Рассуждения аналогичные как и тут:
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

Ответ к вопросу про реализации unionLists:
Ниже представлены реализации метода

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

, и комментарии, почему они могут быть неверными:

public List<String> unionLists(List<String> l1, List<String> l2) {
    l1.addAll(l2);
    return l1;
}

Incorrect Reason: Эта реализация изменяет исходный список l1, что может быть неприемлемо, если l1 immutable. Будет exception .

public List<String> unionLists(List<String> l1, List<String> l2) {
    l2.addAll(l1);
    return l2;
}

Incorrect Reason: Аналогично l2 может быть immutable.

public List<String> unionLists(List<String> l1, List<String> l2) {
    List<String> l3 = new ArrayList<>();
    l3.addAll(l1);
    l3.addAll(l2);
    return l3;
}

Тут проблемы с immutable l1 и l2 нет.