Go to file
2023-09-08 10:54:04 +04:00
callback test project 2023-09-08 10:54:04 +04:00
mysite test project 2023-09-08 10:54:04 +04:00
docker-compose.yaml test project 2023-09-08 10:54:04 +04:00
Dockerfile test project 2023-09-08 10:54:04 +04:00
manage.py test project 2023-09-08 10:54:04 +04:00
nginx.conf test project 2023-09-08 10:54:04 +04:00
README.md test project 2023-09-08 10:54:04 +04:00
requirements.txt test project 2023-09-08 10:54:04 +04:00

Тестовый проект для Python-разработчика

Привет! Круто, что ты решил присоединиться к нашей команде. Меня зовут Артем, я собираю команду крутых разработчиков(или тех, кто ими хочет стать). Вместе мы решаем сложные и комплексные задачи. Мы стараемся не брать в работу совсем простые проекты(в духе - сделать сайт с админкой), каждый проект для нас - это вызов в первую очередь к самим себе. Конечно, у нас порой попадаются рутинные задачки, куда без них. Но едва ли проекты, которые мы делаем, можно назвать тривиальными. Наши приоритеты - свобода и профессионализм.

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

Процесс разработки

Коммуникацию с тобой будет держать проект-менеджер. Это твой бро и он любит тебя! ПМ обычно ставит задачи в таск-трекере. В целом процесс состоит из простых этапов:

  • Постановка задачи (ПМ описывает задачу и ставит вас исполнителем)
  • Примерная оценка (ожидаем от тебя уточнения по задаче - ты должен четко понимать что нужно будет сделать и как это сделать, и примерную оцену - это нужно для утверждения эстимейтов и бюджета с заказчиком и планирования загруза)
  • Утверждение (ПМ утверждает затраты по задачам и подтверждает задачу в план или просит уточнения)
  • Планирование (ПМ ставит задачу в план, можно приступать к её реализации)
  • Решение задачи (тут ожидаем от тебя красивого решения задачи. Если нужна помощь или возник вопрос/переоценка/что-угодно другое - сообщи ПМ. Мы за открытость, а поскольку команда удаленная нам важна коммуникация в первую очередь)
  • Задача решена (ты выгружаешь решение на тестовое окружение, меняешь статус по задаче, задача переходит в тестирование в первую очередь к ПМ и/или на code-review к ответственным лицам)
  • Подтверждение ответственными лицами (ПМ или тим-лид подтверждает решение и дает добро на выгрузку в продакшен. Некоторые проекты мы не можем выгружать в определенное время(высокая нагрузка/зависимость от других задач), поэтому ПМ может согласовать выгрузку в определенную дату. Обычно выгрузка - это merge ветки задачи/тестового окружение в продакшен)

Про окружение и CI/CD

На всех проектах мы имеем тестовое окружение, где другие участники процесса могут проверить результаты работы команды. Мы также следуем концепции CI/CD, делая всё, чтобы ребята могли выгружать код используя только гит. Если что-то будет необходимо сделать с сервером до/после выгрузки - сообщи об этом ПМ, он решит этот вопрос или любой другой.

Про эстимейты и декомпозицию

Стуктурирование очень важно при работе со сложными/комплексными задачами. Поэтому мы просим раскладывать все задачи на отрезки длиной от 15 минут до 2 часов. Если задача занимает 2+ часов, то она должна быть декомпозирована на более мелкие. Задачи длиной меньше 15 минут в нашей вселенной быть не может :)

Про коммуникации

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

Кроме того у нас есть некоторые ежедневные процессы, которых просим придерживаться:

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

Поскольку у нас удаленка и свобода в приоритете, то мы ожидаем, что ты будешь на связи с 9-00 до 18-00 по МСК. Когда ты будешь решать задачи - выбираешь ты. Мы просим:

  • постараться попадать в свои же оценки
  • быть доступным для коммуникаций в рабочее время(либо предупреждать ПМа если куда-то нужно отойти, всякое бывает)
  • быть честным, открытым, активным и позитивным ;)

Тестовое задание

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

  • тесты
  • просмотр кода

О проекте

Итак, перед тобой проект, на котором подключены FastAPI и Django одновременно. Django используется только как ORM и админка, FastAPI используется для запросов. Мы не фанаты DRF, почти все проекты пишем в связке какой-то фронт(Vue/React) + API(чаще всего не REST), поэтому использование Class-based Views пригодится максимум для админки. Собственно, от Django кроме ORM и умения рулить админкой мы больше ничего и не берем. Если не сталкивался с FastAPI - не беда, наверняка ты уже пробовал Flask, они очень похожи.

Дисклеймер: не пытайся оценить структуру проекта, это всего лишь тестовое, которое должно решаться парой десятков строк кода.

Мы храним базу данных игроков и игр. В игре может быть не более 5 игроков. Игроки и игры создаются при помощи API-вызовов с применением аутентификации по методу JWT(уже внедрено, читай OpenAPI-документацию доступную по запросу на http://localhost:8000/docs).

Инфраструктура

Мы используем активно Docker и Docker-compose для поднятия инфраструктуры, используй их. docker-compose up -d поднимет всю инфраструктуру проекта и проект будет доступен по http://localhost:8000/. Правки применятся автоматически(благодаря --reload(command в docker-compose), файлы внутри контейнеров и на локальной машине синхронизированы через volumes(docker-compose). Внутрь контейнера с python можно попасть, используя команды:

docker ps #отобразит список всех контейнеров
docker exec -ti <container_id> bash #войдет в запущенный контейнер для выполнения команд, например - создания superuser

Задачи в рамках тестового задания:

Задача на понимание моделей Django, миграциями, работы с админкой и docker

ТЗ: отобразить в списке игроков: имя, email, дату и время создания игрока, дату и время изменения игрока(в нашем случае только через админку); добавить поиск по имени или email. Отобразить в списке игр название игры и имена игроков через запятую(отдельным столбцом), дату и время создания игры, дату и время изменения игры. На странице редактирования игры отобразить inline'ами всех привязанных игроков. Модели менять можно!

Что будем оценивать:

  • создана ли миграция?
  • выполнены ли все условия ТЗ?
  • как выполнен reverse lookup?
  • Задваивание игроков с одинаковым name и email

Задача на понимание FastAPI, валидации и транзакций

ТЗ: при создании игрока(/new_player) его имя и email должны быть уникальны. Имя должно содержать только цифры от 0 до 9 и только буквы от a до f. Если пользователь с таким email и name уже существует, необходимо вернуть ошибку с HTTP-кодом 400, status = "error", текстом "player with such name or email already exists". Аналогичную ошибку необходимо вернуть при ошибки валидации имени пользователя или e-mail'а с указанием соответствующего текста ошибки

Что будем оценивать:

  • возможна ли race condition?
  • выполнены ли все условия ТЗ?
  • можно ли получить 500 ошибку при отправке данных, величина которых не предусмотрена БД?
  • Реализовать логику для метода /add_player_to_game

Задача на работу с ManyToMany Django ORM, валидацией FastAPI, транзакциями

ТЗ: при запросе игрок с указанным id должен добавляться в игру с указанным id. Если игрока или игры с заданными id не существует, должна возвращаться ошибка с HTTP-кодом 400, status = "error" и соответствующим текстом. Количество игроков в одной игре не более 5.

Что будем оценивать:

  • возможна ли race condition?
  • выполнены ли все условия ТЗ?
  • можно ли получить 500 ошибку?
  • что произойдет при добавлении одного игрока два и более раз?

Как сдавать тестовое

Перешлите архив с вашими доработками нашему менеджеру, мы дадим ответ на следующий день.

Название архива должно содержать ваше имя и фамилию. ВасяПономорев.zip / VasyaPonomorev.zip

Спасибо за внимание ;)