Задачи с собеседований: обработка параллельного редактирования данных

Андрей Когунь

руководитель группы Java-разработчиков ИТ-компании КРОК

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

Например, в разрабатываемом приложении надо решить задачу обеспечения непротиворечивости данных при параллельном редактировании несколькими пользователями. Допустим, в системе с веб-интерфейсом ведутся данные сотрудников. Карточку сотрудника могут редактировать несколько пользователей с соответствующими полномочиями, а данные в виде JSON отправляются в бекэнд и сохраняются в базу данных. Большинство из нас подобный код реализовывали и не раз. Задача — сделать так, чтобы тот пользователь, который первым отправил изменение, в результате увидел измененные им данные. При этом тот, кто был вторым — получил возможность внести свои изменения с учётом изменений, внесённых первым пользователем. Задачу можно решать по-разному, и она хорошо работает — показывает уровень владения заявленными технологиями в зависимости от уровня кандидата.

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

Если кандидат не готов проектировать подобное решение на собеседовании, то проверяю уровень другим способом. Почти наверняка он видел пример реализации подобного решения в одном из своих предыдущих проектов. И тут мы можем рассмотреть с ним механизмы, которые предоставляют используемые фреймворки и какова особенность реализации. Например, в ORM такие механизмы есть из коробки, и в Hibernate достаточно пометить одно поле класса сущности аннотацией @Version, чтобы реализовать механизм оптимистической блокировки. Каждый раз, когда запись будет сохранена, значение такого поля обновится, и если будет попытка сохранения записи, у которой значение этого поля не соответствует таковому в базе данных, возникнет исключение. Такое решение опишет разработчик достаточно опытный, чтобы разобраться, какой именно код был в проекте и почему, даже если он сам не писал этот код.

Для начинающего кандидата задача полезна тем, что он, скорее всего, вообще о подобном еще не задумывался.

Для него это вызов, который можно попробовать решить на уровне базовых знаний, если просто описать структуру данных в БД (их мы формулируем вместе) и в каком-то виде получить их с клиента. Здесь можно предложить вариант реализации на самом низком уровне. Это может быть SQL-запрос вида: update ... where id = <Id> and version = <version>, результатом которого будет количество измененных строк 0 или 1. И таким образом можно будет понять, принято изменение или значение version разошлось с тем, которое на текущий момент в БД.

Это лишь один из примеров наших задач. Он одинаково понятен всем кандидатам и при этом мало где в сборниках задач на собеседования разбирается таким образом, чтобы получить осознанный ответ и удовольствие для обеих сторон. Хороших вам технических интервью!