Engineers at Form3 build highly available distributed systems in a microservices environment. Our take home test is designed to evaluate real world activities that are involved with this role. We recognise that this may not be as mentally challenging and may take longer to implement than some algorithmic tests that are often seen in interview exercises. Our approach however helps ensure that you will be working with a team of engineers with the necessary practical skills for the role (as well as a diverse range of technical wizardry).
The goal of this exercise is to write a client library in Go to access our fake account API, which is provided as a Docker
container in the file docker-compose.yaml
of this repository. Please refer to the
Form3 documentation for information on how to interact with the API. Please note that the fake account API does not require any authorisation or authentication.
A mapping of account attributes can be found in models.go. Can be used as a starting point, usage of the file is not required.
If you encounter any problems running the fake account API we would encourage you to do some debugging first, before reaching out for help.
The finished solution should:
- Be written in Go.
- Use the
docker-compose.yaml
of this repository. - Be a client library suitable for use in another software project.
- Implement the
Create
,Fetch
, andDelete
operations on theaccounts
resource. - Be well tested to the level you would expect in a commercial environment. Note that tests are expected to run against the provided fake account API.
- Run the tests when
docker-compose up
is run - our reviewers will rundocker-compose up
and expect to see the test results in the output. - Be simple and concise.
The finished solution should not:
- Use a code generator to write the client library.
- Use (copy or otherwise) code from any third party without attribution to complete the exercise, as this will result in the test being rejected.
- We will fail tests that plagiarise others' work. This includes (but is not limited to) other past submissions or open-source libraries.
- Use a library for your client (e.g: go-resty). Anything from the standard library (such as
net/http
) is allowed. Libraries to support testing or types like UUID are also fine. - Implement client-side validation.
- Implement an authentication scheme.
- Implement support for the fields
data.attributes.private_identification
,data.attributes.organisation_identification
anddata.relationships
or any other fields that are not included in the providedmodels.go
, as they are omitted from the provided fake account API implementation. - Have advanced features, however discussion of anything extra you'd expect a production client to contain would be useful in the documentation.
- Be a command line client or other type of program - the requirement is to write a client library.
- Implement the
List
operation.
We give no credit for including any of the above in a submitted test, so please only focus on the "Shoulds" above.
- Include your name in the README. If you are new to Go, please also mention this in the README so that we can consider this when reviewing your exercise
- Create a private GitHub repository, by copying all files you deem necessary for your submission
- Invite @form3tech-interviewer-1 to your private repo
- Let us know you've completed the exercise using the link provided at the bottom of the email from our recruitment team
Copyright 2019-2023 Form3 Financial Cloud
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.