Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю):
Design and implement a RESTful API (including data model and the backing implementation)
for money transfers between accounts.
Explicit requirements:
1. You can use Java, Scala or Kotlin.
2. Keep it simple and to the point (e.g. no need to implement any authentication).
3. Assume the API is invoked by multiple systems and services on behalf of end users.
4. You can use frameworks/libraries if you like (except Spring), but don't forget about
requirement #2 – keep it simple and avoid heavy frameworks.
5. The datastore should run in-memory for the sake of this test.
6. The final result should be executable as a standalone program (should not require
a pre-installed container/server).
7. Demonstrate with tests that the API works as expected.
Implicit requirements:
1. The code produced by you is expected to be of high quality.
2. There are no detailed requirements, use common sense.
Ну я подумал что от меня за 6 часов не хотят увидеть prod-ready решения, всякие хинты вроде in-memory datastore и отсутствие реальных требований и common sense как-бы наводят на мысль, что нужно просто продемонстрировать что могу написать адекватный hello world.
Я написал и им не понравилось. Не оч понимаю, чего они хотели и где я налажал?
Понятно что в реальном мире многое было бы иначе. Отдельные проекты для model/core etc., другая модель, другой data pipeline etc.
Думал, что от меня хотят чтобы я выбирал решения к месту, не занимался overdesign и overengineering etc., показал базовые вещи вроде разделения контракта и реализации, di, testability, стиль кода, который подходит к Kotlin ну и так далее.
Здравствуйте, arth, Вы писали:
A>ну zip для вас. для них был github, но там мое реальное имя, а я не палюсь ))
Сделай другой аккаунт. Мало кто захочет скачивать архив.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, arth, Вы писали:
A>>ну zip для вас. для них был github, но там мое реальное имя, а я не палюсь )) S>Сделай другой аккаунт. Мало кто захочет скачивать архив.
..
S>приведение здравого смысла к чётким требованиям — легко занимает больше одного дня, если серьёзно подходить к делу.
можно было делать неделю, но по их словам в среднем они ожидают что чистого времени — 6-12 часов.
S>Соответственно, никто (кроме задающего задание) не скажет тебе, что именно ты там не так придумал.
Здравствуйте, Sharowarsheg, Вы писали:
S>Одно вот это
A>>2. There are no detailed requirements, use common sense.
S>приведение здравого смысла к чётким требованиям — легко занимает больше одного дня, если серьёзно подходить к делу.
так как данный курсовой проект все равно никто читать не будет, делаем сердечник трансформатора из дерева
Т.к. это тестовое задание, то наверняка приветствуется некая пояснительная записка, где будут оговариваться принятые ограничения и которая содержит комментарии к решению.
2ТС: Была записка? В коде ничего подобного не нашел.
S>Соответственно, никто (кроме задающего задание) не скажет тебе, что именно ты там не так придумал.
Оговаривать с задающим до начала выполнения тестового задания не только не запрещается, но даже поощряется.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, arth, Вы писали:
A>Понятно что в реальном мире многое было бы иначе. Отдельные проекты для model/core etc., другая модель, другой data pipeline etc.
А ты у них спрашивал?
Здравствуйте, arth, Вы писали:
A>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю): A>Design and implement a RESTful API (including data model and the backing implementation) A>for money transfers between accounts.
A>код — https://github.com/arthells/mtest
Как минимум самая важная операция по ТЗ — transfer, не является атомарной. Думаю, это сильно уменьшило баллов.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, Sharowarsheg, Вы писали:
S>>Одно вот это
A>>>2. There are no detailed requirements, use common sense.
S>>приведение здравого смысла к чётким требованиям — легко занимает больше одного дня, если серьёзно подходить к делу.
SVZ>
SVZ>так как данный курсовой проект все равно никто читать не будет, делаем сердечник трансформатора из дерева
SVZ>Т.к. это тестовое задание, то наверняка приветствуется некая пояснительная записка, где будут оговариваться принятые ограничения и которая содержит комментарии к решению. SVZ>2ТС: Была записка? В коде ничего подобного не нашел.
нет, в стартовом посте все что есть. было сказано что обычно на такое задание тратят 6-12 часов, что стало для меня референсом
S>>Соответственно, никто (кроме задающего задание) не скажет тебе, что именно ты там не так придумал.
SVZ>Оговаривать с задающим до начала выполнения тестового задания не только не запрещается, но даже поощряется.
там ясно сказано что no explicit requirements, use common sense
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, arth, Вы писали:
A>>Понятно что в реальном мире многое было бы иначе. Отдельные проекты для model/core etc., другая модель, другой data pipeline etc. K>А ты у них спрашивал?
Здравствуйте, techgl, Вы писали:
T>Здравствуйте, arth, Вы писали:
A>>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю): A>>Design and implement a RESTful API (including data model and the backing implementation) A>>for money transfers between accounts.
A>>код — https://github.com/arthells/mtest T>Как минимум самая важная операция по ТЗ — transfer, не является атомарной. Думаю, это сильно уменьшило баллов.
1/ в ТЗ не сказано, что она должна быть атомарной
2/ в реальном мире она нигде не атомарна и не может быть таковой
Здравствуйте, arth, Вы писали:
A>Попросили сделать тестовое задание часов за 6-12 (всего на задание давали примерно неделю): A>Design and implement a RESTful API (including data model and the backing implementation) A>for money transfers between accounts.
A>спасибо
Ну, не знаю. Самое просто, а почему для money у вас BigDecimal?
Здравствуйте, arth, Вы писали:
SVZ>>Т.к. это тестовое задание, то наверняка приветствуется некая пояснительная записка, где будут оговариваться принятые ограничения и которая содержит комментарии к решению. SVZ>>2ТС: Была записка? В коде ничего подобного не нашел.
A>нет, в стартовом посте все что есть. было сказано что обычно на такое задание тратят 6-12 часов, что стало для меня референсом
A>там ясно сказано что no explicit requirements, use common sense
Ну т.е. ты предложил второй стороне разбираться самим, какие соглашения ты выбрал и угадывать, почему именно так?
Я бы такое не оценил.
"common sense" он у всех свой Вот они и оценили соответственно.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, arth, Вы писали:
A>Думал, что от меня хотят чтобы я выбирал решения к месту, не занимался overdesign и overengineering etc., показал базовые вещи вроде разделения контракта и реализации, di, testability, стиль кода, который подходит к Kotlin ну и так далее.
Просмотрел сильно мельком и также мельком читал само задание. Но из того, что увидел — ничего особо криминального не заметил. Достаточно просто, при необходимости далее расширяется, рефакторится и далее можно добавлять навороты. Придраться конечно вполне нашел бы к чему, но ради тестового задания я бы не стал там сам сильно заморачиваться. Лично меня код бы вполне удовлетворил, для тестового задания все более чем нормально, и если не налажал на других вопросах далее бы все решалось исключительно твоими требованиями по зарплате. Подобный код сам периодически отправлял, вроде удовлетворялись вполне, правда оффера не было, так как я много просил, плюс сам говорил что я работу не ищу, а просто хожу чтоб навыки прохождения собеседований не терять. Раз в год обязательно собеседуюсь, но сейчас с тестовыми заданиями посылаю, если что — смотрите на гитхабе код предыдущих . Хотя, для прикола б на хаскеле я б может и сделал какое тестовое. На котлине бы уже не стал делать, уже игрался, причем с большими наворотами, чем я был бы готов делать для тестового задания .
Так что если кого подобный код на тестовых заданиях не удовлетворит — это их проблемы, зажрались . В проде конечно другой разговор, но для тестового проблем как то не вижу.