Какие вопросы я задаю на собеседовании java разработчикам⁠⁠1

90% от тех 50%, которые остаются после совещаний, да). На проекте могут быть сотрудники разных уровней, тогда типовые задачи разумно делегировать начальным позициям.

Не могу сказать точно, субъективно - с начала года конкуренция среди джунов выросла

https://stackoverflow.com/a/528336

Суть проблемы - при переводе денег с одного счета на другой, нужно запретить изменять содержимое обоих счетов всем потокам, кроме одного, который произведет списание и зачисление. Для этого нужно использовать примитив синхронизации "монитор", если один поток захватил монитор то все остальные потоки, желающие захватить монитор, будут ждать пока монитор освободится. Так как в операции участвует два счета, то поток должен захватить два монитора (освобождение мониторов всегда происходит в обратном порядке).

Допустим, решим при каждой операции захватывать сначала монитор счета списания, а потом счета получения. Пусть поток1 выполняет перевод между счетами A -> B, успел захватить монитор А, но еще не успел захватить монитор В. В это время поток2 выполняет перевод между счетами B -> A, успел захватить монитор B. Получается, дальше эти потоки будут бесконечно ждать, так как ни один не может захватить второй монитор.

Для исключения этой ситуации нужно задать порядок между счетами (например, присвоить каждому счету уникальный числовой id), и первым захватывать монитор, который соответствует счету с меньшим id. То есть требуется захватывать ресурсы последовательно.

Миддл должен иметь представление о примитивах синхронизации и о проблемах которые они решают (видимость, атомарность). Меня несколько раз просили реализовать блокирующую очередь на wait/notify, из java.util.concurrent любят посправшивать про read/write lock. В чем отличие Collections.synchronized(new HashMap) от ConcurrentHashMap. Что такое оптимистичная и пессимистичная блокировки. Для подготовки к теоретической части рекомендую ознакомиться со статьей https://shipilev.net/blog/2014/jmm-pragmatics/

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

Object mon = new Object()

synchronized(mon) { .. }

Стандартизация технологий позволяет пилить проекты силами разработчиков начального уровня. К сожалению, без понимания работы под капотом легко накосячить в нефункциональных требованиях - забыть индекс, создать запрос с кучей join, в многопоточном приложении небезопасно использовать переменную.

Очевидно что на собеседовании нет смысла ограничиваться вопросом - какие аннотации вы использовали. Хардкор тоже ни к чему. Я постарался привести примеры из середины этого интервала

Можно приписать себе опыта, но тогда ждите завалов на собеседовании

Нанять рекрутера для помощи в написании резюме

Писать в личку лидам в LinkedIn и узнать не нужны ли стажёры

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

На самом деле обсуждение идёт как диалог, с наводящими вопросами. Можно предложить вспомнить про HashMap/TreeMap, подсказать пример вроде "получить записи за день"

К сожалению, на собеседовании нет времени вникнуть в проект. Можно только по-быстрому посмотреть используемые компоненты и выявить явные ошибки.

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

Да, это показывает умение на практике использовать структуры данных. В рабочем проекте видел такую конструкцию:

if (new HashSet(list).contains(x))

Разработчик знает что поиск в мапе быстрее чем в списке, но не думает что не даст прироста при однократном поиске

Примитивность определяется в рамках используемой модели - так же как материальная точка в физике. Детали реализации мониторов скрыты от java разработчика спецификацией. Не поленился почитать в jls - понятие монитора вводится в пункте 17.1, а понятие мьютекса отсутствует. По такой же аналогии, при работе с мьюетксами разработчики не думают что под капотом лежат транзисторы.

HashMap используется в коде постоянно как дефолтная реализация Map. Поэтому важно понимать стоящий за ней алгоритм, но вопрос я формулирую в контексте индексов БД а не java коллекций.

Если придут со сложной задачей - будем разбираться)

ООП это довольно холиварная тема, но в проектах где я работаю в основном довольно простая организация кода. Мы используем анемичные модели: сервисы-синглетоны без состояния и сущности без поведения. У интерфейсов обычно единственная реализация, а вместо наследования используется композиция и делегирование. Достаточно понимать структурное программирование чтобы включиться в проект. Поэтому я не уделяю этому времени.

Архитектура это тоже размытое понятие. Вопрос по кафке я считаю архитектурным, другие нет