[] Задача от иностранной компании или как я провалил собеседование

в 7:52, , рубрики: java, задачи для собеседований, Занимательные задачки, интервью, Программирование

Решив попробовать свои силы на зарубежном рынке, я начал отправлять резюме в различные конторы. Даже не с целью найти работу, а просто для расширения кругозора. Выбор пал на вакансии «Java Developer». Промышленного опыта работы с языком у меня нет, только личный опыт, сертификаты с Oracle Certification Center, книги и.т.д. Честно признаться, на последнем месте работы за полтора года ничего кроме «форов» и «ифов» я не писал (но это совсем уже другая история) поэтому решил, почему бы собственно и нет.

Пропустив историю поиска и разговоров с работодателями, перейду к сути. Одна компания К из города Г написала, что заинтересованы в проведении собеседования со мной после того как я решу задачу.

После того как я решил и отправил им решение, К ответила, что после код ревью решили не рассматривать мою заявку более. Это был удар по моей самооценке. Я конечно понимаю, что язык новый, и вообще всякое бывает, но надеялся хотя бы на отзыв о моем решении. Плюс задача-то простая на самом деле… Надеюсь, вам будем интересна задача.

Ниже представлен оригинальный текст задачи.

RESTAURANT EXERCISE

image

RESTAURANT EXERCISE (please use JAVA 7 syntax)

Your restaurant has a set of tables of different sizes: each table can accommodate 2, 3, 4, 5 or 6 persons. Clients arrive alone or in groups, up to 6 persons. Clients within a given group must be seated together at one table, hence you can direct a group only to a table, which can accommodate them all. If there is no table with the required number of empty chairs, the group has to wait in the queue.

Once seated, the group cannot change the table, i.e. you cannot move a group from one table to another to make room for new clients.

Client groups must be served in the order of arrival with one exception: if there is enough room at a table for a smaller group arriving later, you can seat them before the larger group(s) in the queue. For example, if there is a six-person group waiting for a six-seat table and there is a two-person group queuing or arriving you can send them directly to a table with two empty chairs.

Groups may share tables, however if at the same time you have an empty table with the required number of chairs and enough empty chairs at a larger one, you must always seat your client(s) at an empty table and not any partly seated one, even if the empty table is bigger than the size of the group.

Of course the system assumes that any bigger group may get bored of seeing smaller groups arrive and get their tables ahead of them, and then decide to leave, which would mean that they abandon the queue without being served.

Please fill RestManager class with appropriate data structures and implement its constructor and three public methods. You are encouraged modify other classes too (to help us test them) and add new methods at your will.

public class Table
{
   public final int size; // number of chairs
}

public class ClientsGroup
{
   public final int size; // number of clients
}

public class RestManager
{
   public RestManager (List<Table> tables)
   {
      // TODO
   }

   // new client(s) show up
   public void onArrive (ClientsGroup group)
   {
      // TODO
   }

   // client(s) leave, either served or simply abandoning the queue
   public void onLeave (ClientsGroup group)
   {
      // TODO
   }

   // return table where a given client group is seated, 
   // or null if it is still queuing or has already left
   public Table lookup (ClientsGroup group)
   {
      // TODO
   }
}

Разбор задачи

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

  1. «Of course the system assumes that any bigger group may get bored of seeing smaller groups arrive and get their tables ahead of them, and then decide to leave, which would mean that they abandon the queue without being served.»
  2. Структура класса RestManager

По поводу первого пункта, дело в том, что наша система распределения мест работает по выше указанным правилам, поэтому ситуацию описанную в пункте 1, никак нельзя избежать. Единственное, что я и написал в ответном письме, можно добавить задержку перед выдачей свободного стола. Скажем группа из 3 человек приходит в ресторан. На данный момент есть единственный стол на 6-ых. По условию мы обязаны им предоставить стол (you must always seat your client(s) at an empty table… even if the empty table is bigger than the size of the group). Но если сделать это не сразу, а через минут 5. За это время есть вероятность, хоть и небольшая, что освободиться место или стол с размерностью меньше. Но выглядит это несерьезно конечно.
По второму пункту как минимум имхо метод public Table lookup не в своем классе. Мы можем получить стол геттером у клиента, который по идеи должен хранить ссылку на стол.

В общем, я выделил два основных момента:

  1. Необходимо сортировать столы в нужном порядке. Логику нахождения нужного стола перенести просто в сортировку. Первый стол который сможет вместить группу клиентов и будет необходимым.
  2. Только два события вызывают необходимость поиска стола для клиента или клиента для стола. Это прибытие нового клиента и после того как группа вышла из-за стола соответственно.

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

Оставляю ссылку на git с решением: RestaurantTask

Автор: PetrShchukin

Источник

* - обязательные к заполнению поля