You’ve been asked to build a new application and service that allows a solicitor to create legal job postings, and allows a client to pay for a job that has been undertaken.
The challenge has been designed to get progressively more difficult in order to gauge decision making and how a candidate deals with changing requirements and complexity.
You may take as much time as you wish to complete the challenge if you wish to complete all tasks, but we recommend time-boxing your work to 3-4 hours.
This is to avoid taking too much of your time, and the amount of time spent on the challenge will be applied contextually. In a shorter timeframe, we do not expect all candidates to complete all tasks.
Once you've deemed the challenge ended, please write some notes on the approach you would take to complete the other stories, if you had further time to complete them.
Also make notes on the trade-offs or weaknesess of your implementation.
Commit the notes you've made in the README.md
After the challenge, we will schedule a follow-up call to talk through your experience, challenges faced, decisions made and your notes.
We're looking for how you think about building products and systems. What this means specifically will depend on your level of experience and will be taken contextually.
In practice, this includes:
- Architecture/tool/library decisions
- Code structure and cleanliness
- Domain modelling decisions and abstraction choices
- Use of best-practices and principles
- Usage of git and development tools
- Your descriptions and thought processes in the follow-up conversation
- UI choices and UX considerations
- Showcasing your code opinions and creativity
It does not include:
- Visual design skills or how "pretty" it is
- 100% test coverage
Please don't fork or submit pull-requests to this repository.
Submissions should be a public repository on GitHub, sent via email to the assessor.
Submissions should be received before the deadline specified in your instructions email.
Feel free to use the code you create in any way you fancy - you can show it to other potential employers as a demonstration of your abilities.
Should you need help or any clarification, feel free to email us.
-
All application code should be TypeScript
-
The completed project should have a frontend UI, a backend API and a data persistance layer.
/app: Web UI using React, built in Create-React-App and optional MaterialUI.
Details:
- There's no requirement for SSR / static generation
- Design is a nice-to-have but not required, vanilla CSS/a component library/etc. are all fine.
/api: A NodeJS API with NestJS
Details:
- JSON should be the content type of all interactions
Scaffolded in docker-compose.yml: A MongoDB database
Embedded in api: Mongoose
Details:
- If desired, you can switch to a DB you are more familiar with, and if necessary any ORM
This challenge only contains two places where tests are required (story 3/4).
Implemented in app: yarn test
Implemented in api: yarn test:unit or yarn test:e2e
Details:
- Tests can be at any level you see fit (unit, integration, e2e)
You’ve been asked to build a new application and service that allows a solicitor to create legal job postings, and allows a client to pay for a job that has been undertaken.
This requires delivering a UI and API which satisfies the user stories outlined below.
Each user story is progressively more difficult and introduces complexities which may require changes to the design.
Ideally, the git history should identify the stories each commit relates to.
For this challenge, you don't need to worry about authentication or permissions. You can assume there will only be a single user of the application.
As a solicitor, I need to create a legal job posting so that my clients can see them.
As a client, I need to be able to see a list of legal job postings.
A legal job posting contains:
- A
title(string) - A
description(long string)
When a solicitor creates a legal job, it is in a started state.
This should be implemented as a single page app which both user personas use.
Solicitors can use a form on the app to create a new job posting, clients use the same interface to view a list of submitted postings.
We receive new requirements that each job posting needs a new field to store a fee structure in the system.
There are two types of fee structure: No-Win-No-Fee, or Fixed-Fee.
No-Win-No-Feejobs require the parameter:Fee PercentageFixed-Feejobs require the parameterFee Amount
As a solicitor, I need to be able to specify the fee structure of a job posting when it is created.
As a client, I need to be able to view the fee structure of every job posting in the list.
Modify the form and the list to represent this new functionality.
Consider how the UI and data model needs to change to accomodate selecting the different fee structures and their assoiated parameters.
We receive new requirements that a client using the application needs to show that they have paid for a legal job posting.
Note: "Paying for" legal work doesn’t need to actually trigger any financial transfer / APIs - it just stores in the system that a job has been paid, and the amount that was paid.
As a client or solicitor, I need to be able to mark a payment as paid.
As a client or solicitor, I need to be able to see that a job has been paid.
As a client or solicitor, I need to be able to see how much was paid to the solicitor.
How a payment works depends on the type of job posting:
No inputs are required to complete the payment.
The amount paid upon payment is the fee amount.
An input is required to complete the payment: Settlement Amount
This settlement amount is used to work out how much should be paid to a solicitor using the fee percentage property of the no win no fee structure.
The amount paid upon payment is settlement amount * fee percentage
There should be tests covering how the amount paid is calculated.
Once a payment is completed, the job enters a state of paid.
Paying for a case should happen by entering details / pressing a button on the relevant job list item. You don't need to use additional screens.
The status of paid and the amount paid should be displayed in the UI.
We get reports of clients putting in settlement amounts for no-win-no-fee jobs that are wildly lower than what is expected.
We want to introduce a way for solicitors to constrain what settlement amounts are valid when paying for a job.
We do this by constraining settlement amounts around an expected settlement amount that the solicitor inputs when creating a job posting.
As a solicitor, I need to be able to enter an expected settlement amount for no-win-no-fee jobs.
As a client, I need to be shown an error if I enter a settlement amount which differs from the expected settlement amount by more than 10%.
Change the payment command to include logic for: If the Settlement Amount entered is not within 10% of the Expected Settlement Amount, the payment should fail and show an error to the user.
There should be tests validating the calculation that if the settlement amount is outside of 10% of the expected settlement amount, the operation would fail.
Alternatively, it should test for valid settlement amounts within 10%.
The error should display in the UI alongside the payment form/button.
Solicitors have grown tired of creating descriptions for their job postings, as they find that there are news articles online which describe their job perfectly, and so they shouldn't need to write it themselves.
Solicitors would like to submit the URL of a news article, and use that as the new basis of the job description.
As a solicitor, I would like to submit a URL of a news article instead of typing a description in my job postings.
As a client, I would like to see a relevant summary of the news article in a job description.
Some examples sources of legal job postings are the following articles:
These news articles contain a description of a legal issue that is relevant to a job posting a solicitor wants to make.
For user experience and searchability reasons (a future requirement), the relevant content from the news articles should be persisted within the system, rather than linked to.
Change the UI to no longer require a description, and instead require a URL.
Display the contents of the news article alongside the job posting in the list.
-
Initial codebase setup (hello world)
-
Story 1
-
Story 2
-
Story 3
-
Story 4
-
Story 5
-
Written notes on incomplete stories
-
Written notes on weaknesses, tradeoffs and improvements