Interview - Tests Tasks

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

Warning

Задания представлены беспорядочно, т.е. они следуют не в порядке повышения уровня сложности, а рандомно.

Warning

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

1. Java Core

1.1. Тестовое задание 4

Для решения этого задания требуется от 12 до 48 рабочих часов. Это не значит, что вы решите ее за 12-48 часов. Можно потратить столько часов, сколько вы считаете нужным.

Мы предлагаем вам потратить хотя бы несколько часов на чтение задачи и моделирование решения. Мы протестировали эту задачу на наших инженерах: несколько младших разработчиков в среднем тратили 10 часов на чтение и размышления и примерно 2 часа на программирование.

Прикладная теория музыки

В теории музыки интервал — это расстояние между двумя нотами. Это расстояние указывается с помощью буквы и числа. Например, допустимые названия интервалов - M3, P5 или m7. Буква и цифра в названии интервала означают определенные вещи.

Как и в математике, если мы говорим, что расстояние на сантиметровой линейке между 3 и 5 равно 2 сантиметрам, в музыке мы говорим, что расстояние между C и E (или do и mi) равно M3.

Для этой задачи мы используем следующие имена нот: C D E F G A B

Весь список интервалов, которые мы используем в этой задаче: m2, M2, m3, M3, P4, P5, m6, M6, m7, M7, P8

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

Номер интервала — это количество названий букв или позиций нотного стана (строк и пробелов), которые он содержит, включая позиции обеих нот, образующих интервал. Например, интервал C – G является пятым (обозначается P5), потому что ноты от C до G над ним содержат пять буквенных имен (C, D, E, F, G) и занимают пять последовательных позиций нотного стана, включая позиции of C и G. Интервал от A до A содержит 8 нот (A B C D E F G A) и называется P8. Мы будем называть это число диатонической степенью (обратите внимание: термин «степень», который мы здесь используем, может не соответствовать фактическому термину в музыке).

Единица расстояния между нотами называется полутоном.

Названия букв могут быть изменены случайно. Диез поднимает ноту на полтона, а бемоль b** опускает его на полтона. К ноте можно добавить не более и двух b.

В следующей таблице показаны 12 нот хроматической гаммы, построенной на C. Расстояние между каждой нотой в таблице составляет полутон. Обратите внимание, что одну и ту же ноту можно описать разными буквами. Например, если мы поднимем C на полутон, мы получим C#. А если понизить D на полутон, мы получим Db.

C C#/Db D D#/Eb E F F#/Gb G G#/Ab A A#/Bb B

Например, расстояние в 4 полутона между C и E, расстояние в 5 полутонов между D и G и расстояние в 1 полутон между Bb и B.

Знаки альтерации:

sharp/диез #

flat/бемоль b

natural/бекар ♮

Если мы добавим какие-либо знаки альтерации к нотам, образующим интервал, по определению ноты не меняют своей степени. Как следствие, любой интервал имеет тот же номер интервала, что и соответствующий естественный интервал (означает интервал, образованный теми же нотами, без знаки альтерации). Например, интервалы C – G# (охватывающие 8 полутонов) и C# – G (охватывающие 6 полутонов) являются P5, как соответствующий естественный интервал C – G (7 полутонов).

Обратите внимание, что числа интервалов представляют собой количество содержащихся степеней или имен нот, включая их, но не разницу между конечными точками. Другими словами, вы считаете первую ноту за 1, а не за 0. По этой логике интервал C – D является вторым (M2), но D находится только на одну степень выше C. Аналогично, C – E является третьим (M3), но E всего на две степени выше C, и так далее.

Мы будем использовать только интервалы до октавы (P8, 12 полутонов).

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

Затем вам нужно отсчитать количество полутонов от начальной ноты. В последовательности C D E F G A B есть один полутон между E и F и B и C. Между другими нотами есть два полутона.

Здесь один дефис означает один полутон:

C—D—E-F—G—A—B-C

1.1.1. Как подсчитать количество полутонов?

Давайте посчитаем количество полутонов между C и G: от C до D - 2 полутона, от D до E - 2 полутона, от E до F - 1 полутон, от F до G - 2 полутона. 2 + 2 + 1 + 2 = 7 полутонов.
Давайте найдем количество полутонов между A и C: от A до B - 2 полутона, от B до C - 1 полутон. 2 + 1 = 3 полутона.

1.1.2. Как подсчитать количество интервалов?

Давайте найдем наш первый интервал - P5 (perfect fifth) от Ab. P5 означает: найти расстояние в 5 степеней и 7 полутонов.
- Сначала найдите 5-ю степень от A, игнорируя b: (A B C D E) - E - это нота 5-й степени от A.
- Теперь посчитайте полутоны: от Ab до B - 3 полутона (от Ab до A - 1 полутон, от A до B - 2 полутона), от B до C - 1 полутон, от C до D - 2 полутона, от D до E - 2 полутона. 3 + 1 + 2 + 2 = 8 полутонов. Это слишком много, нам нужно всего 7 полутонов, но нам нужно оставаться на E. Для этого понизьте E на один полутон, используя знак альтерации b.
- На расстоянии P5 от Ab находится нота Eb.
- Примечание: вы не можете написать D# в качестве ответа, потому что даже если D# составляет 7 полутонов от Ab, он имеет другую степень (он находится всего на 4 степени от A до D).

1.1.3. Пример

Чтобы показать вам, как работать со знаками альтерации, давайте найдем P5 (5-я ступень, 7 полутонов) из A#:
- Как и в предыдущем примере, найдите 5-ю ступень из A, игнорируя : (A B C D E) - E - пятая нота из A (и из A).
- Теперь посчитаем полутоны: от A# до B- 1 полутон, от B до C - 1 полутон, от C до D - 2`полутона, от `D до E - 2 полутона. 1 + 1 + 2 + 2 = 6 полутонов. Нам нужно добавить всего один полутон, добавив : E
- На расстоянии P5 от A# находится нота E#.

1.1.4. Пример

Давайте найдем m2 (2-я степень, 1 полутон) от Fb:
- Найти вторую ступень легко: (F G) - G - вторая нота от F.
- Теперь посчитаем полутоны: от Fb до G - 3 полутона. Это слишком много, нам нужен только один. Итак, мы должны понизить G на 2 полутона. Для этого добавьте к ноте G два b: Gbb.
- На расстоянии m2 от Fb находится нота Gbb.

Названия интервалов, качество и количество

		полутон	степень
`m2`	Minor Second	1	2
`M2`	Major Second	2	2
`m3`	Minor Third	3	3
`M3`	Major Third	4	3
`P4`	Perfect Fourth	5	4
`P5`	Perfect Fifth	7	5
`m6`	Minor Sixth	8	6
`M6`	Major Sixth	9	6
`m7`	Minor Seventh	10	7
`M7`	Major Seventh	11	7
`P8`	Perfect Octave	12	8

Ваша задача реализовать две функции, которые будут работать с интервалами: одна будет строить интервал, а вторая определять интервал.

Требования:

intervalConstruction()

Функция intervalConstruction() должна принимать массив строк в качестве входных данных и возвращать строку.
Массив состоит из трех или двух элементов.
Первый элемент в массиве — это имя интервала, второй — начальная нота, а третий указывает, идет ли интервал по возрастанию или по убыванию.
Если в массиве нет третьего элемента, по умолчанию порядок построения возрастает.
Функция должна вернуть строку, содержащую название заметки.
В строке возврата разрешены только следующие имена заметок:

Cbb Cb C C# C Dbb Db D D# D Ebb Eb E E# E Fbb Fb F F# F Gbb Gb G G# G Abb Ab A A# A Bbb Bb B B# B##

Если во входном массиве больше или меньше элементов, должно быть выдано исключение: Illegal number of elements in input array
Соглашение: ['a', 'b'] здесь означает массив строк.

Примеры ввода и значение:

Обратите внимание: данные, которые получит ваша функция, будут выглядеть как массив строк, как определено на вашем языке. Никакого дополнительного разбора не требуется! Форма ['', ''] - это просто соглашение!

Допускаются следующие примечания:

Cb C C# Db D D# Eb E E# Fb F F# Gb G G# Ab A A# Bb B B#

Допускаются следующие интервалы ввода:

m2 M2 m3 M3 P4 P5 m6 M6 m7 M7 P8

['M3','A','asc'] - построить возрастающий интервал M3, начиная с A ['m7, 'Fb', 'dsc'] - построить убывающий интервал m7, начиная с Fb ['P5', 'C'] - построить восходящий интервал P5, начиная с C ['P4', 'E#] - построить восходящий интервал P4, начиная с E #

intervalIdentification()

Функция intervalIdentification() должна принимать в качестве входных данных массив строк и возвращать строку.
Массив состоит из трех или двух элементов.
Первый элемент - это первая нота в интервале, второй элемент - это последняя нота в интервале, третий указывает, идет ли интервал по возрастанию или по убыванию.
Если в массиве нет третьего элемента, по умолчанию интервал считается возрастающим.
Функция должна вернуть строку - название интервала.
В строке возврата разрешены только следующие интервалы:

m2 M2 m3 M3 P4 P5 m6 M6 m7 M7 P8

Если интервал не подходит под описание, должно быть выдано исключение: Cannot identify the interval.

Соглашение: ['a', 'b'] здесь означает массив строк.

Примеры ввода и значение:

Допускаются следующие примечания:

Cbb Cb C C# C Dbb Db D D# D Ebb Eb E E# E Fbb Fb F F# F Gbb Gb G G# G Abb Ab A A# A Bbb Bb B B# B##

['C', 'D'] - найти возрастающий интервал между C и D ['C#', 'Fb'] - найти возрастающий интервал между C# и Fb ['A', 'G#', 'asc'] - найти возрастающий интервал между A и G#

Вы можете найти больше примеров здесь. Мы протестируем ваше решение на этом и подобных примерах.

1.2. Тестовое задание 5

Создать консольное приложение, удовлетворяющее следующим требованиям:

Использовать возможности ООП: классы, наследование, полиморфизм, инкапсуляция.
Каждый класс должен иметь исчерпывающее смысл название и информативный состав.
При кодировании должны быть использованы соглашения об оформлении кода java code convention.
Классы должны быть грамотно разложены по пакетам.
Для демонстрации работы приложения использовать unit тесты.

Проект: Цветочница.

Определить иерархию цветов.
Создать несколько объектов-цветов.
Собрать букет (используя аксессуары) с определением его стоимости.
Провести сортировку цветов в букете на основе уровня свежести.
Найти цветок в букете, соответствующий заданному диапазону длин стеблей.

2. Java Core + SQL

2.1. Тестовое задание 2

Программа, работающая с БД SQLite, которая организовывает работу с оборудованием на скважинах со следующими функциями:

Создание N кол-ва оборудования на скважине.
При выборе этого пункта пользователь указывает кол-во оборудования и имя скважины.
Программа создает указанное кол-во оборудования на скважине с указанным именем.
При создании оборудования каждому присваивается свой id и свое уникальное имя (генерируется программой с использованием латинских букв и цифр).
Скважина также создается программой с указанным именем, если ее еще нет в таблице.
Вывод общей информации об оборудовании на скважинах.
При выборе этого пункта пользователь указывает имена скважин, разделяя их пробелами или запятыми.
Программа подсчитывает кол-во оборудования на каждой скважине и выдает на экран таблицу вида "имя скважины - кол-во оборудования".
Экспорт всех данных в xml файл.
При выборе этого пункта пользователь указывает имя файла.
Программа выбирает все скважины из базы и записывает данные по ним и оборудованию в xml формате в виде (одна и та же скважина или оборудование не могут повторяться несколько раз):

<dbinfo>
    <well name="АААА"  id="123">
        <equipment name="EQ0033" id="12"/>
        <equipment name="EQ0034" id="13"/>
    </well>
    <well name="BBBB"  id="124">
        <equipment name="EQ0038" id="11"/>
        <equipment name="EQ0039" id="14"/>
    </well>
</dbinfo>

Дополнительная информация:

Проект оформлен для сборки при помощи maven.
Перечисленные пункты реализованы в виде параметров командной строки.
Для доступа к БД использовался sqllite-jdbc.
Файл базы данных test.db располагается в каталоге запуска программы.
Если файла еще нет, программа сама создаст БД и все необходимые таблицы в ней.

Таблицы для БД:

Well - скважина.
- id: уникальный идентификатор записи (первичный ключ), генерируется средствами БД.
- name Varchar(32) - имя скважины, уникальное, не может повторяться и быть пустым.
Equipment – оборудование на скважине.
- id: уникальный идентификатор записи (первичный ключ), генерируется средствами БД.
- name Varchar(32) - имя оборудования, уникальное, не может повторяться и быть пустым.
- Well_id: ссылка на Well.id - id скважины, на которой установлено оборудование.

3. Java Core + Frameworks

3.1. Тестовое задание 1

Дается проект сгенерирован на https://start.spring.io/ с заданной конфигурацией.

Требуется создать БД со следующими таблицами:

пользователи (id, email, пароль, дата создания);
клиенты (id, имя, дата создания);
заказы (id, id клиента, стоимость, дата создания);

Написать API, которое под /data/ выдает данные из таблицы заказов и клиентов (в формате JSON), а под /update/ обновляет данные в таблицах (например обновление имени клиента или смена id клиента, указанного в заказе). Данные операции должны допускаться только авторизованным пользователям. Пользователь считается авторизированным, если он делает HTTP запрос:

с Bearer токеном (указан на сервере)
с JWT токеном (назначается клиенту сервером на основе логина+пароля)

Способы авторизации зависят от пути: возможна как и Bearer авторизация, так JWT авторизация для запросов под /update/, /data/.

Ограничения:

Для авторизации использовать модуль spring security.
Использовать либо JDBC, либо JPA для запросов (оба содержатся в зависимостях проекта)
Выход из системы (logout) необходим
Версия 8 Джавы

Допускается:

Менять архитектуру проекта любым способом
Добавлять зависимости в проект
Создавать дополнительные поля в таблицы БД

Приветствуется:

Логирование через logback
Аргументированный подход по созданию архитектуры проекта
Дополнительные запросы и функционал
Графический интерфейс (VUE.JS, JFX)

3.2. Тестовое задание 3

CryptoCurrency watcher

Функциональность:

Просмотр списка доступных криптовалют (REST-метод)
Просмотр актуальной цены для указанной криптовалюты (REST-метод - код валюты передается пользователем)
Запасать в лог сообщение об изменении цены более чем на 1%. Для это пользователь регистрирует себя с помощью REST-метода notify и передает свое имя (username) и код криптовалюты (symbol). В момент регистрации сохраняется текущая цена указанной криптовалюты с привязкой к пользователю. Как только актуальная цена для указанной валюты поменялась более чем на 1%., в лог сервера выводится сообщение уровня WARN в котором указан: код валюты, имя пользователя и процент изменения цены с момента регистрации.

Требования

Вы можете использовать Java или Kotlin (любой версии)
Используйте Spring или Spring Boot (можно использовать https://start.spring.io/ для ускорения)
Актуальные цены храните в реляционной базе - можно использовать любую (H2, Mysql, Postgres,…)
Список доступных криптовалют предопределен и является частью конфигурации сервера
Список валют:

[
  {
    "id":"90",
    "symbol":"BTC"
  },
  {
    "id":"80",
    "symbol":"ETH"
  },
  {
    "id":"48543",
    "symbol":"SOL"
  }
]

Раз в минуту актуальные цены для доступных криптовалют запрашиваются c внешнего источника CoinLore и сохраняются в базу данных.
Что бы получить актуальные цену по коду криптовалюты используйте open API Crypto API | CoinLore Method Ticker (Specific Coin): https://api.coinlore.net/api/ticker/?id=90 (BTC)
Когда пользователь запрашивает актуальную цену для указанной криптовалюты - данные должны быть получены из базы данных

3.3. Тестовое задание 6

Создать простое веб-приложение, функционал которого включает следующее:

Начальная страница
Регистрация
Авторизация
Главная страница

Сценарий:

Пользователь попадает на начальную страницу, на которой есть два поля для ввода текста (E-mail и Пароль) и две кнопки (Войти и Регистрация).
Введя e-mail и пароль, и нажав на кнопку "Войти" отправляется запрос на сервер, где происходит проверка на наличие аккаунта пользователя в системе.
Если данные корректны, происходит переход на Главную страницу, на которой указаны e-mail и статус аккаунта (Подтвержден/Не подтвержден) и есть кнопка "Выход".
Введя e-mail и пароль, и нажав на кнопку "Регистрация" отправляется запрос на регистрацию. Если аккаунта пользователя нет в системе, то создается новый аккаунт, на указанную почту отправляется письмо, в тексте которого будет ссылка для подтверждения, а пользователь попадает на Главную страницу.

Условия:

Использовать фреймворк Play https://www.playframework.com/
Не использовать готовые решения
Обработать ошибки
Если возникают вопросы, не бояться спрашивать у других разработчиков

3.4. Тестовое задание 7

База резюме

Имеются следующие тестовые данные в виде резюме:

ФИО: Петров Петр Петрович
Дата рождения: 12.12.1986
Контакты: +375(29)123-45-67, http://github.com/petya, petrovich@gmail.com
Пол: мужчина
Технологии: Git, Spring Boot, HTML

ФИО: Иванов Иван Иванович
Дата рождения: 4.4.1997
Контакты: +375(29)87-65-43, http://github.com/vanya, skype:ivanko
Пол: мужчина
Технологии: Git, JavaEE, Java Core

ФИО: Морская Мария Васильевна
Дата рождения: 07.11.1999
Контакты: +375(29)999-99-99, https://www.linkedin.com/in/mariya/
Пол: женщина
Технологии: Maven, REST, Spring

3.4.1. Первая часть.

Необходимо спроектировать базу данных и заполнить её тестовыми данными указанными выше.
Тип базы данных - Oracle или PostgreSQL.
Результатом этой части задания должен быть текстовый файл с SQL-инструкциями для создания и заполнения базы данных (CREATE TABLE …, INSERT … вот это всё).
Выполняя это задание важно помнить про нормализацию баз данных.

3.4.2. Вторая часть.

Необходимо создать Maven-проект (.jar), в которой описать JPA-сущности (@Entity) для таблиц, созданных в первом задании. А также набор классов, который помогал бы строить простые SQL-запросы. Фактически, механизм должен давать нам возможность получать данные из БД без знания SQL. Что-то вроде собственной реализации Criteria API.

Механизм должен предоставлять возможность указать, что мы хотим получить (например объекты класса «Резюме») а так же критерии отбора (например «имя» равно «Петр» и «фамилия» равна «Петров»).

Минимальные требования к реализации:

Ваш класс должен уметь отдельно возвращать строку запроса и отдельно значения параметров запроса.
Для построения параметров запроса должен использоваться паттерн «Строитель».

Например:

exp.equal("name", "Петр").and().equal("surname", "Петров").and().equal("patronymic", "Петрович");

генерироваться должен SQL-запрос, но нужно предусмотреть возможность, чтобы когда-нибудь в будущем кто-то другой смог бы добавить реализацию, которая будет генерировать JPQL или HQL и при этом не пришлось бы переписывать ваши классы.

Также в составе проекта должно быть два теста:

Составление (при помощи механизма описанного выше) и выполнение запроса, который бы выбрал все резюме, в которых фамилия равна «Морская», имя = «Мария», отчество = «Васильевна» и как верный результат - получение третьего резюме из БД
Составление (при помощи механизма описанного выше) и выполнение запроса, который бы выбрал все резюме, в которых фамилия заканчивается на «ов» или пол – женский и получение всех трёх резюме из бд.

Глобальная задача – сделать механизм как можно более удобным для использования. С одной стороны, в условиях ограниченного времени вам важно реализовать только тот функционал, который будет проверен тестами. С другой стороны вам нужно построить механизм так, чтобы его было удобно расширить новым функционалом (например в будущем добавить in, between, больше и меньше и так далее).

Исходя из предыдущего абзаца важно отметить, что оцениваться будет не объем функционала, а его качество и удобство использования.

Важно постараться сделать механизм максимально независимым. Например, сделать так, чтобы если имя таблицы поменяется, нам не пришлось бы вносить изменения в тест. Только в Entity.

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

Все эти моменты (за исключением минимальных требований) не являются обязательными, но могут помочь вам получить преимущество.

Результатом выполнения этой части задания должен быть архив с исходными кодами проекта (каталог src и pom.xml).

3.5. Тестовое задание 8

Создайте мини веб приложение Monitor Sensors.

Приложение состоит из трех форм.

Форма логина

Форма Таблица датчиков

Форма добавление/редактирование датчиков

Приложение должно состоять из серверной и клиентской части.

Для разработки серверной части используйте: Java, Spring MVC, Spring Security

Для клиентской: Angular 2+

В системе все данные хранятся в БД (можно выбрать любую реляционную БД).

В качестве ORM предпочтительно использовать – Hibernate

Web Server – Apache Tomcat

3.5.1. Описание

В системе 2 предустановленных пользователя:

admin c ролью Administrator
user c ролью Viewer
- Для аутентификации и авторизации используются Spring Security.
- Пользователю с ролью Administrator разрешен доступ ко всем формам и разрешены все действиям в приложении.
- Пользователю с ролью Viewer разрешен только доступ к формам Логин, Таблица датчиков. На форме Таблица датчиков разрешены действия, связанные только с просмотром данных, без права добавления, удаления либо изменения записей.
- Для не авторизированных пользователей доступна только форма Логин
- После ввода логина и пароля, авторизированного пользователя система перенаправляет на форму Таблица датчиков.
- Если пользователь не прошел авторизацию, то перенаправления не происходит, а пользователю выдается сообщение об ошибке авторизации.
- Данные для таблицы берутся посредством запросов с серверной части (данные хранятся в БД).
- Пользователю с ролью Viewer и Administrator разрешено просматривать данные таблицы, использовать пейджинг (количество записей на странице 4), использовать поиск по данным.
- Поиск по данным представляет из себя поле ввода текста и кнопку поиска. Поиск происходит по частичному совпадению введенного текста в любом поле записи (включая поля, не показанные в таблице – description).
- После окончания поиска в таблице остаются только подходящие записи.
- При наведении на имя (поле Name) датчика показывается hint с полным описанием датчика (поле description).
- Пользователю с ролью Administrator разрешены дополнительно действия -
  - добавление нового датчика (переход на форму 3)
  - редактирование выделенного датчика (переход на форму 3)
  - удаление выделенного датчика.
- По кнопке logout – пользователь выходит из системы и его перенаправляет на форму логин

3.5.2. Форма 3. Добавление/редактирование датчиков

Звездочкой отмечены обязательные поля:

Name – текстовое поле. Обязательное. Валидация – не пустое поле и количество символов не превышает 30.
Model – текстовое поле. Обязательное. Валидация – не пустое поле и количество символов не превышает 15.
Range from, to – числовое поле. Диапазон значений датчика, в котором предусмотрена его работа. Валидация – при вводе двух значений, from должно быть меньше to. Целые числа.
Type – список выбора. Предустановленные данные, берутся из БД. Значения - Pressure, Voltage, Temperature, Humidity.
Unit – список выбора. Предустановленные данные, берутся из БД. Значения - bar, voltage, °С, %.
Location – местоположение сенсора. Текстовое поле. Валидация не больше 40 символов.
Description – описание датчика. Валидация не больше 200 символов.

Save – сохраняет или изменяет сенсор. Cancel отменяет ввод и закрывает форму перенаправляя на форму Таблица датчиков.

После выполнения задания нужно предоставить:

Readme файл с описанием шагов, которые нужно сделать для запуска системы.
SQL скрипты для создания начальной структуры БД. Скрипты для инициализации данных
Исходные коды, выложенные на Git.

3.6. Тестовое задание 9

Documents management system

Необходимо реализовать пример системы для работы с документами (document management system)

3.6.1. Страницы

Список документов. Необходимо наличие фильтрации по критериям, сортировки, постраничного просмотра (Pagination). Критерии: дата создания, с кем заключен контракт, кто заключал контракт, срок исполнения контракта Пагинация средствами серверной части, а не только фронта.
Детальный просмотр документа (отдельный скрин).
Для пользователя добавление/редактирование документа (отдельный скрин). Необходимо наличие валидации вводимых данных - кнопка сабмита дизейблится, а поля ввода подсвечиваются красным итд.

3.6.2. Технологии

Angular последней версии (Single Page Application) или HTML/JS/CSS
Серверная часть - Java 8, Spring MVC, Swagger, Spring Data, H2 (MySQL), Gradle, Tomcat.

Визуальную часть делать можно простой, без наворотов (можно сделать на базе bootstrap).

Архитектура - 3 уровневая с разделением по слоям - Controller, Service, Repository. Общие вещи не дублировать, а делать через наследование от базовых классов (по возможности использовать generics).

Объект "Документ" из себя представляет описание документа - можно добавить произвольных атрибутов - дата создания, статус, автор документа, файл документа (файл любого формата) и тд.

Можно добавить по своему усмотрению:

Авторизация и 2 вида пользователей: администратор и простой пользователь.
Админ видит все доки и всех пользователей

В проект добавить файл readme с краткой инструкцией по запуску приложения. Структуру БД создавать с помощью скриптов.

Проект должен запускаться из командной строки. Независимо от операционной системы компьютера (Linux, Windows)

3.7. Тестовое задание 10

Payment cards

3.7.1. Технологии

Java 11, Spring Boot, Spring Data, MySQL, Swagger UI

3.7.2. Условие

Дано:

Клиент
1. ФИО
2. Номер телефона
3. Email
4. Статус
Платежная карта
1. Номер
2. Валюта
  1. BYN
  2. EUR
  3. USD
Тип
1. Classic
2. Gold
3. Platinum

Необходимо реализовать REST сервис, который имеет:

Метод заведения клиента в системе.
Метод оформления карты и привязки к определенному клиенту (на основании выбранного типа карты, клиенту присваивается соответствующий статус: Classic – 0, Gold – 1, Platinum – 2).
Метод, который возвращает постранично список номеров телефонов в зависимости от указанных параметров (количество записей, номер страницы, тип карты, валюта).

3.7.3. Требования

Результат выполнения задания размещается на сервисе GitHub, ссылка на репозиторий отправляется рекрутеру для проверки задания.
Выполнять задание необходимо самостоятельно, без уточнения дополнительных деталей (как понимаем, так и делаем).
Нельзя использовать связи Hibernate (one to one, one to many, many to many).

3.7.4. Будет плюсом

Организовать безопасный доступ к методам с помощью Spring Security (JWT, Basic Auth).
Покрытие методов тестами.
Для всех методов сделать описание для Swagger c помощью аннотаций.

3.8. Тестовое задание 11

Personnel Management System.

3.8.1. Technologies to use

Java 8 or 11
Spring Boot
Spring Data JPA
PostgreSQL or MongoDB
Maven
Swagger and Swagger UI
Git

3.8.2. Requirements

Application must have REST API to manage departments and employees. Departments and employees data must be stored in a database. All endpoints must be visible in Swagger UI. Source code of application must be versioned using Git.

3.8.3. Department has

Name
Description
Phone number
Date of formation
One or many employees

3.8.4. Employee has

Full name
Date of Birth
Phone number
Email address
Position
Date of employment

3.8.5. Endpoints to implement

Get all departments with their users
Get one department
Create department
Delete department
Get one employee
Create employee
Delete employee
Add employee to department
Remove employee from department
Get all employees which do not belong to any department

3.9. Тестовое задание 12

Create your personal solution
Focus on breadth rather than depth when cover expected output (Expected artifacts) points.
Do you best to figure out industry best practices and utilize them properly.
You have a time limit - 7 days.
Tech challenge is your primary focus.

3.9.1. Problem statement

Implements a web crawler that traverses website following predefined link depth (8 by default) and max visited pages limit (10000 by default). The web crawler starts from a predefined URL (seed) and follows links found to dive deeper. The main purpose of this crawler to detect the presence of some terms on the page and collect statistics, e.g.

Seed:

https://en.wikipedia.org/wiki/Elon_Musk

Terms:

Tesla, Musk, Gigafactory, Elon Mask

Output:

https://en.wikipedia.org/wiki/Elon_Musk 208 641 9 0
acbd.com/page2.html 8 4 0 5 17
qwerty.com/page1.html 3 2 0 2 7
anotherseti.com/page3.html 0 1 0 1 2

Clarification:

https://en.wikipedia.org/wiki/Elon_Musk 208 641 9 0 858
    Number are
        Tesla – 208 hits
        Musk – 641 hits
        Gigafactory – 9 hits
        Elon Mask – 0 hits
        Total – 858 hits

All stat data should be serialized into CSV file (no predefined sort).
Top 10 pages by total hits must be printed to separate CSV file and console (sorted by total hits).

Expected artifacts:

Source code provided through GitHub project:
- Focus on Java 11 LTS
- Take into account project supportability
- Focus on documentation
Env setup can be easily repeated:
- Add configuration and startup script
- One button setup & configuration
- Prepare sample data if necessary
Code follows industry best practices
- Matches predefined code style – you can setup any
- Code coverage >40%
- contains tests of several levels – unit, integration, ect.
Provide a google drive link to your Demo session (up to 10m)
- record a video proof that the app works
- cover both the happy path and failure/edge-case scenario
- Take a code tour and clarify selected solutions
- Prepare it in English

3.10. Тестовое задание 13

Реализовать REST API согласно Open API Specification:

{
  "openapi" : "3.0.1",
  "info" : {
    "title" : "reposService",
    "version" : "0.0.1-SNAPSHOT"
  },
  "servers" : [ {
    "url" : "/reposService"
  } ],
  "paths" : {
    "/api/v1/repository/{id}/children" : {
      "get" : {
        "operationId" : "getChildren",
        "parameters" : [ {
          "name" : "id",
          "in" : "path",
          "required" : true,
          "schema" : {
            "type" : "integer",
            "format" : "int32"
          }
        } ],
        "responses" : {
          "default" : {
            "description" : "default response",
            "content" : {
              "application/json" : {
                "schema" : {
                  "type" : "array",
                  "items" : {
                    "$ref" : "#/components/schemas/ReposItem"
                  }
                }
              }
            }
          }
        }
      }
    },
    "/api/v1/repository/{id}" : {
      "get" : {
        "operationId" : "getItem",
        "parameters" : [ {
          "name" : "id",
          "in" : "path",
          "required" : true,
          "schema" : {
            "type" : "integer",
            "format" : "int32"
          }
        } ],
        "responses" : {
          "default" : {
            "description" : "default response",
            "content" : {
              "application/json" : {
                "schema" : {
                  "$ref" : "#/components/schemas/ReposItem"
                }
              }
            }
          }
        }
      }
    },
    "/api/v1/repository/root" : {
      "get" : {
        "operationId" : "root",
        "responses" : {
          "default" : {
            "description" : "default response",
            "content" : {
              "application/json" : {
                "schema" : {
                  "$ref" : "#/components/schemas/ReposItem"
                }
              }
            }
          }
        }
      }
    }
  },
  "components" : {
    "schemas" : {
      "ReposItem" : {
        "type" : "object",
        "properties" : {
          "id" : {
            "type" : "integer",
            "format" : "int32"
          },
          "name" : {
            "type" : "string"
          },
          "content" : {
            "type" : "string"
          },
          "folder" : {
            "type" : "boolean"
          },
          "parent" : {
            "type" : "integer",
            "format" : "int32"
          }
        }
      }
    }
  }
}

Сервис возвращает некий репозитарий, хранящий древовидную структуру из элементов. Каждый элемент – набор полей

Integer id; // идентификатор элемента
String name; // наименование элемента
String content; // содержимое
boolean folder; // признак – является ли элемент папкой (может содержать другие элементы)
Integer parent; // ссылка на родительский элемент

Приложение должно иметь следующую структуру:

Дерево репозитария
Документ
Закладки
- После запуска приложение должно отобразить дерево в зоне 1.
- При двойном клике на элементе с признаком folder==false должна появиться новая закладка, и в зоне 2 отобразится содержимое поля content и кнопку, при нажатии на которую открывается диалог с содержимым поля content. Функционал, отображающий область 2 и нажатие кнопки, должен быть реализован в виде отдельного бина.
- При переходе по закладкам должны отображаться соответствующие данные
- Интерфейс должен быть реализован на JSF с использованием библиотеки primrfaces.
- Проект должен собираться с помощью maven.
- Поле content представляет собой xml, содержащий объект o1 с полями f1 и f2 или объект o2 с полями f3 и f4. Для каждого вида объекта должна быть своя форма с соответствующими полями

3.11. Тестовое задание 14

Разработать систему управления пользователями.

Система должна представлять собой WEB-приложение, которое предоставляет интерфейс управления пользователями.

Система должна поддерживать следующую ролевую модель

Роль	Доступные действия
USER	Авторизация (Login)
Просматривать список пользователей (List)
Просматривать детали любого пользователя (View)
Выход (Logout)
ADMIN	Авторизация (Login)
Просматривать список пользователей (List)
Просматривать детали любого пользователя (View)
Создание нового пользователя (New/Edit)
Редактирование существующего пользователя (New/Edit)
Lock/Unlock пользователя (Lock/Unlock)
Выход (Logout)

Роль

Доступные действия

USER

Авторизация (Login)

Просматривать список пользователей (List)

Просматривать детали любого пользователя (View)

Выход (Logout)

ADMIN

Авторизация (Login)

Просматривать список пользователей (List)

Просматривать детали любого пользователя (View)

Создание нового пользователя (New/Edit)

Редактирование существующего пользователя (New/Edit)

Lock/Unlock пользователя (Lock/Unlock)

Выход (Logout)

Основная сущность в системе – UserAccount.

Field	Description	Length	Validation
Username	Имя пользователя для авторизации.	3-16	Только латинские символы; Должна быть уникальным
Password	Пароль пользователя	3-16	Только латинские символы и цифры. Минимум один символ; Минимум одна цифра;
First Name	Имя.	1-16	Только латинские символы
Last Name	Фамилия	1-16	Только латинские символы
Role	Роль пользователя. USER or ADMIN. На UI должно быть dropdown.
Status	Состояние пользователя. ACTIVE or INACTIVE. На UI должно быть dropdown.
Created At	Дата заведения пользователя. Проставляется автоматически при записи в БД.

Field

Description

Length

Validation

Username

Имя пользователя для авторизации.

3-16

Только латинские символы; Должна быть уникальным

Password

Пароль пользователя

3-16

Только латинские символы и цифры. Минимум один символ; Минимум одна цифра;

First Name

Имя.

1-16

Только латинские символы

Last Name

Фамилия

1-16

Только латинские символы

Role

Роль пользователя. USER or ADMIN. На UI должно быть dropdown.

Status

Состояние пользователя. ACTIVE or INACTIVE. На UI должно быть dropdown.

Created At

Дата заведения пользователя. Проставляется автоматически при записи в БД.

Пароли в БД хранить в хешированным виде с применением алгоритма bcrypt.

В системе должны быть следующие страницы:

Страница URL Описание Доступные действия (с учетом роли)

Страница	URL	Описание	Доступные действия (с учетом роли)
Login	`/login`	Авторизация в системе	Вход в систему; Если состояние пользователя INACTIVE, то вход невозможен; Если логин/пароль не верен, то вход невозможен;
List	`/user`	Список пользователей	Опционально: 1. Фильтрация списка по Username; 2. Фильтрация списка по Role; 3. Пагинация
View	`/user/{id}`	Просмотр деталей пользователя	Lock/Unlock: должно приводить к смене состояния ACTIVE/INACTIVE
New	`/user/new`	Создание нового пользователя	При наличии валидационных ошибок должно показываться соответствующее сообщение на UI.
Edit	`/user/{id}/edit`	Редактирование пользователя	При наличии валидационных ошибок должно показываться соответствующее сообщение на UI.

Login

/login

Авторизация в системе

Вход в систему; Если состояние пользователя INACTIVE, то вход невозможен; Если логин/пароль не верен, то вход невозможен;

List

/user

Список пользователей

Опционально: 1. Фильтрация списка по Username; 2. Фильтрация списка по Role; 3. Пагинация

View

/user/{id}

Просмотр деталей пользователя

Lock/Unlock: должно приводить к смене состояния ACTIVE/INACTIVE

New

/user/new

Создание нового пользователя

При наличии валидационных ошибок должно показываться соответствующее сообщение на UI.

Edit

/user/{id}/edit

Редактирование пользователя

При наличии валидационных ошибок должно показываться соответствующее сообщение на UI.

Предпочтительный стэк технологий:

Java 8+
Spring (Spring Boot, Spring MVC, Spring Data, Spring Security)
PostgreSQL
Html Template Engine - любой (Thymeleaf, Freemarker, etc.)
Gradle
Опционально: сборка docker-образов

Можно использовать сторонние библиотеки

3.12. Тестовое задание 16

3.12.1. Предметная область

В модели предметной области имеются сущности (в скобках указаны обязательные атрибуты):

Товар (Артикул, Наименование, Цена последней закупки, Цена последней продажи).
Склад (Наименование). На складе может храниться несколько товаров.

Документы:

Поступление (Номер, Склад, Список товаров). Заводится при поступлении товара. Содержит список товаров, их количество и закупочные цены. В документе указывается склад, на который поступают товары.
Продажа (Номер, Склад, Список товаров). Заводится при продаже товара. Содержит список товаров, их количество и цены продажи. В документе указывается склад, с которого списывают товары.
Перемещение (Номер, Склад1, Склад2, Список товаров). Заводится при перемещении товара между складами. Содержит список товаров и их количество. В документе указывается склад, с которого списывают товары и склад, на который они поступают.

3.12.2. Постановка задачи (backend)

Необходимо реализовать серверную часть приложения по учету товаров на складе.

Приложение должно включать API для просмотра, создания, редактирования и удаления сущностей.

На вход приложению поступают документы: API включает операции импорта (создания) и просмотра документов.

На выходе имеется возможность сформировать отчеты:

Общий список товаров (артикул, наименование, цены закупки и продажи). В качестве опционального параметра может быть передан фильтр по имени товара.
Остатки товаров на складах (артикул, наименование, остаток по всем складам). В качестве опционального параметра может быть передан фильтр по складу.

API для работы с сущностями оперирует форматом JSON.

Работу с документами также можно проводить в формате JSON, либо использовать другой человеко-читаемый формат (например CSV).

Формат выводимых отчетов на выбор: JSON, CSV, HTML (а можно и все три :) ).

Функциональные требования

Предусмотреть валидацию входных параметров. Программа не должна «упасть» на некорректных данных.
Выполнение любой операции должно возвращать результат — ОК либо сообщение/код ошибки.

3.12.3. Нефункциональные требования

Язык разработки: Java.
Фреймворк: использование Spring нежелательно, лучше обойтись без него.
Данные можно хранить в памяти (например, в виде списка), либо использовать для хранения PostgreSQL / H2 (будет плюсом).
Сборка с помощью инструмента Maven без установки или настройки каких-либо дополнительных компонент.
Выполненное задание должно быть размещено в публичном репозитории на Github / Bitbucket.
Файл README должен содержать инструкцию по сборке, настройке, конфигурированию и развертыванию приложения (если необходимо).

Дополнительные возможности

К реализованному API можно составить небольшую документацию — список возможных команд с передаваемыми в них параметрами и возможными ответами на запрос. Файл с документацией может быть в формате Markdown, либо с использованием инструментов для документирования АПИ( API Blueprint, Swagger и подобные).

Реализованный функционал желательно покрыть юнит-тестами и интеграционными тестами.

3.12.4. Постановка задачи (frontend) — опционально

Плюсом будет создание UI для серверного приложения.
Язык разработки и фреймворк: на ваш выбор.
Дизайн страницы (страниц): на ваш выбор.
Желательно наличие возможности аутентификации.

3.13. Тестовое задание 17

Задача: спроектировать и разработать API для системы опросов пользователей. Использовать технологии: Spring Framework.

3.13.1. Функционал для администратора системы

Авторизация в системе (регистрация не нужна)
Добавление/изменение/удаление опросов. Атрибуты опроса: название, дата старта, дата окончания, описание. После создания поле дата старта у опроса менять нельзя
Добавление/изменение/удаление вопросов в опросе. Атрибуты вопросов: текст вопроса, тип вопроса (ответ текстом, ответ с выбором одного варианта, ответ с выбором нескольких вариантов)

3.13.2. Функционал для пользователей системы:

Получение списка активных опросов
Прохождение опроса: опросы можно проходить анонимно, в качестве идентификатора пользователя в API передаётся числовой ID, по которому сохраняются ответы пользователя на вопросы; один пользователь может участвовать в любом количестве опросов
Получение пройденных пользователем опросов с детализацией по ответам (т.е. что выбрано), по ID уникальному пользователя

3.13.3. Результат выполнения задачи

Исходный код приложения в github (только на github, публичный репозиторий)
Инструкция по разворачиванию приложения (в docker или локально)
Документация по АРІ

3.14. Тестовое задание 20

Web-сервис перевода средств с карты на карту.

3.14.1. Функционал

Форма логина
Регистрация новых клиентов.
- Атрибуты клиента (все поля - обязательные):
  - ФИО
  - Логин
  - Пароль
Личный кабинет клиента должен обладать возможностью:
- Добавления карт и просмотра их баланса
- Пополнение баланса карты
- Перевода средств на карты других клиентов
  - Пользователь должен ввести номер карты того, кому переводятся деньги.
  - После этого система должна запросить подтверждение перевода и отобразить ФИО того, кому переводятся деньги.
  - После перевода, средства должны быть списаны с исходящей карты в счет входящей
  - Сумма перевода не может превышать текущий остаток (баланс)
- * Просмотра истории операций с возможностью фильтрации:
  - По сумме от/до
  - По счёту получателя
  - По дате от/до
- ** Отображения статистики за выбранный период (при реализации с использованием СУБД):
  - Сумма переводов в разрезе счетов получателей за период
  - Отношение поступлений к тратам
  - Операция с максимальной суммой за период
  - Средние траты в день за период

3.14.2. Пожелания к реализации

Приложение - Spring Boot
Слой доступа к данных.
- В качестве хранилища - любая СУБД (например, h2, mysql, postgresql и тд) либо текстовые файлы.
- Для доступа использовать jdbc/jooq/hibernate/java.io.* (в случае хранения в текстовых файлах)
Веб-формы с использованием любого шаблонизатора, например ThymeLeaf
Для передачи данных на веб фopмy c бeкeндa должны быть реализованы контроллеры Spring MVC с необходимыми REST-endpoints

Примеры настройки и структуры:

Предпочтительный порядок реализации:

Слой данных (хранилище)
Services и controllers
Web-интерфейс. Имеет самый низкий приоритет, т.е. основная задача состоит в реализации REST-контроллеров, реализующих все функции приложения.
Задания повышенной сложности, т.е. задания со звездочками

3.15. Тестовое задание 21

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

3.15.1. Сущности

User
Event (File file)
File
User → List<Events>

3.15.2. Технологии:

Java
MySQL
Hibernate
HTTP
Servlets
Maven
Flyway.

3.15.3. Требования

Все CRUD операции для каждой из сущностей
Придерживаться подхода MVC
Для сборки проекта использовать Maven
Для взаимодействия с БД - Hibernate
Для конфигурирования Hibernate - аннотации
- Инициализация БД должна быть реализована с помощью flyway
- Взаимодействие с пользователем необходимо реализовать с помощью Postman (https://www.getpostman.com/)
Репозиторий должен иметь бейдж сборки travis (https://travis-ci.com/)
Рабочее приложение должно быть развернуто на Heroku (heroku.com)

3.16. Тестовое задание 21

Create REST API Service.

REST - approach with HTTP (transport) + JSON (data format).

REST method:

GET - read
- all - http://localhost:8080/api/users
- one - http://localhost:8080/api/users/58094da1-940d-4cd6-8940-c9042ef6d2e4
- list by name - http://localhost:8080/api/users?name=Dmitry
- list by name - http://localhost:8080/api/users?name=Dmitry&age=23
- list by name - http://localhost:8080/api/groups/jd2-86/users?groupName=jd2-86&userName=Dmitry
- list by name - http://localhost:8080/api/groups/58094da1-940d-4cd6-8940-c9042ef6d2e4/users?name=Dmitry
- by name
POST - create
- one - http://localhost:8080/api/users + HTTP Body as JSON
PUT
- one - http://localhost:8080/api/users/58094da1-940d-4cd6-8940-c9042ef6d2e4 + HTTP Body as JSON
DELETE
- one - http://localhost:8080/api/users/58094da1-940d-4cd6-8940-c9042ef6d2e4
- many - http://localhost:8080/api/users?id=58094da1-940d-4cd6-8940-c9042ef6d2e4&id=58094da1-940d-4cd6-8940-c9042ef6d2e4

4. Java Core + Frameworks + Advance topics

4.1. Тестовое задание 15

4.1.1. Описание

Существует некоторый бизнес-процесс – пополнение счета консультанта с помощью транзакций с банковской карты в рублях.

Требуется реализовать сервисы 2 микросервиса.

Микросервис `Payment`

Должен иметь endpoint на получение {host}/pay. POST запроса с телом json в формате:

{
    "accountId": 1, // ID аккаунта консультанта
    "amount": 100.2 // Сумма пополнения в рублях
}

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

Микросервис `Backend`

Должен читать очередь Queue
Сохранять транзакции из очереди Queue в базу данных Postgres payments
Каждые 5 минут записывать в файл transaction.csv в локальной папке транзакции в формате

id;account_id;amount;datetime_transaction
1;1;100.2;2022-07-28 07:00:00

4.1.2. Задание

Спроектировать БД Postgres payments
Создать сервис Payment реализовать эндпоинт для приёма запросов
Реализовать очередь обмена сообщениями между сервисами
Наполнить БД Postgres payments транзакциями из запросов
Наполнить файл transaction.csv транзакциями из запросов

4.1.3. Технологии

Java 11+ / Kotlin 1.3+
Spring Boot 2+
Postgres 9.6+
Любой брокер очередей

4.2. Тестовое задание 18

Необходимо реализовать веб-приложение Погодный брокер (по принципу REST API).

4.2.1. Что реализовать?

Ввод названия города. Форма заполняется и отправляется из Postman (https://www.postman.com/). Отправляется запрос (rest-метод) на weather.yahoo.com (или любой другой бесплатный погодный АPI) с введенным городом в качестве параметра. Форматы запросов детально описаны на сайте weather.yahoo.com. Полученный ответ посредством Jackson парсится в Java-класс, который далее с помощью Spring JMS Template отправляется в JMS-очередь, настроенную по архитектуре Public-Subscriber.
Необходимо реализовать Spring JMS Listener, получающий сообщения из созданной JMS-очереди. После получения, содержимое сообщения конвертируется и сохраняется в базу данных посредством Hibernate. Данная операция должна быть обернута в Spring Transaction (достаточно аннотации @Transactional).
Необходимо с помощью Spring Web реализовать REST-endpoint, который по определенному запросу, с указанием в качестве параметра названия города, будет возвращать xml или json с соответствующей информацией о погоде. Информация берется из базы данных посредством Hibernate, парсится в json или xml с помощью Jackson.

4.2.2. Технические требования

Необходимо обеспечить покрытие исходного кода unit-тестами, с использованием JUnit и Mockito, или аналогов.
Проект должен собираться сборщиком maven или gradle.
Исходники нужно загрузить на gitlab. Сделать gitlab-ci.yaml, который запускает тесты и собирает проект.
Программный код должен удовлетворять Code Conventions.
JMS-брокер можно использовать любой (Rabbit MQ, Kafka, Active MQ).
В качестве СУБД рекомендуется использовать PostgreSQL или MySQL.
Архитектура приложения должна быть реализована максимально-несвязанной, с использованием принципа Inversion of Control.
СУБД, ЈМS-брокер и пр. желательно развернуть с помощью Docker Compose.

4.3. Тестовое задание 19

Написать многопользовательский чат для обмена текстовыми сообщениями.

Должна быть возможность:

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

Сообщения следует сохранять в базе данных. В качестве клиентов можно использовать простой веб интерфейс.

4.3.1. Обязательные требования по стеку технологий

Использование Java
Использование Maven
Использование event-driven архитектуры
Использование Docker

4.3.2. Результат

Загружен на Github
Имеет файл для запуска всего необходимо с помощью Docker Compose

4.3.3. Будет плюсом

Разбиение на отдельные небольшие модули
Использование RabbitMQ для обмена данными между модулями
На своё усмотрение можно добавить любую функциональность