Introduction

This test is aimed at assessing your skills with JavaScript development, as well as

the understanding of SPA development. The test is not aimed at exploring just

knowledge, but also experience, general understanding, as well as resourceful-

ness. The test covers multiple roles as well as different levels of knowledge and ex-

perience.

Other skills will also be assessed with this test. Some of them that include, but

are not limited to UX, optimisation, implementation, integration and other. We’re

interested in finding out not just what, but how and why.

Limitations and requirements

There is no predefined, required or best approach to this test since one of its goals

is to evaluate your resourcefulness. Thus, as with most other projects, this test im-

poses only limits on what can be used and how it is supposed to work.

Tools used to complete this test are not part of its scope, neither we believe

that there are the best tools to complete the job. You’re free to use whichever tools

you feel most comfortable with, or whichever you consider being the most appro-

priate ones.

1
Performance and ranking
Completing the test, or a part of it, allows for the assessment and ranking to take

place. Completing all the parts of the test should not be considered as demonstra-

tion of all of the required skills. Completing just some parts of the test should not

be considered as a failure.

We will consider all demonstrated skills, even if the test is just partially com-

pleted. Upon completion of the test, your skills and aptitude will be ranked as fol-

lows:

- Successful completion of the test, or it’s parts

- Time taken to complete the test, or it’s parts

- Code quality and readability

- Performance and user experience

- Optimisation techniques

- Ease of use, Implementation-wise

2
Use-case scenario

Do note that this is just a use-case scenario, and is only provided as a de-

scriptive hypothetical situation, not the actual goals of the test.

A company has a need for a custom application which would track their leads. Ap-

plication would be accessible via Internet and work on desktop as well as mobile

devices. All of the employees would have access to the application, but just the

managers can delete the data. Data within the application is available to company’s

partners via API.

- Each lead can be a person with it’s contact information:


Given name, Family Name, Gender, Address, Mobile Phone, E-Mail

- Each lead can be a company with it’s contact information:


Name, Contact Person Name, Address, Phone, E-Mail, Website

- Each lead can be categorised in one of three distinct categories:


New, Won, Lost

Implementation and goals

Create a SPA by utilising NodeJS, React and GraphQL

As per use-case scenario described in the previous section, and according to

actual goals presented in above paragraph, you are supposed to create all, or at

least some of the following:

3
 1. Web service via NodeJS

2. API via GraphQL

3. Application UI via React

Following tools are required in the development process:

1. ESLint

2. Prettier

Although not required, we do reccomend using the following:

1. Flow

2. Jest

3. BabelJS

4. Webpack

Backing data-storage is not a scope of this test thus it can be anything you

deem adequate - Apollo/Memory Cache, JSON/Plain text file, Database etc.

Web service via NodeJS

Web service should be implemented by using Koa and its sole purpose should be

just serving the SPA.

At the minimum, web service should have a single endpoint which would serve

the SPA to the browser on a bound HTTP port.

In the best case scenario, web service should be configured to parse requests

with body and cookies, to have CORS restrictions and to utilise helmet protections.

4
API via GraphQL

API should be implemented via Apollo and its sole purpose should be data re-

trieval and manipulation.

At the minimum, API should have at least one type, one input, one query, and

at least two mutations. Resolver(s) would be available to a single endpoint on a

bound HTTP port.

In the best case scenario, API should define two types with backing inputs, two

queries and three mutations.

Application UI via React

UI should be implemented by using React and Blueprint components.

At the minimum, UI should be a single page with a list of all of the leads, a dia-

log for adding new lead and/or editing the existing one, as well as option to delete

existing lead.

In the best case scenario, UI should be broken up to a list of leads tabulated by

the starting letter, dialog for adding a new lead and a dialog for editing the exist-

ing lead. Option to delete the lead should have a confirmation.

Expected results
On the first glance the goals can look overwhelming but broken down in separate

parts, each part can be just a single source file with a distinct role. Although in a

better solution, each part would be broken up in a number of smaller source files

and tied in via bundle so the final output is again just three distinct files.

In ideal case, all parts should be completed, tested and bundled before sub-

mitting them. But there is no requirement that all of the parts need to be complet-

5
ed. We will take into consideration qualifications and work experience and weight

them against completed parts. Expectation is that a skilled developer should be

able to complete all of the parts easily. Less versed developer should be able to at

least complete the UI.

We believe that this approach - where anybody can focus on the parts that suit

them the most, should alleviate the difference in skill and work experience and

provide everybody with the same chance. Since we’re looking for multiple employ-

ees with different skill sets we do believe that anybody can prove their skills in ap-

propriate manner.

You are not required to do more than test specifies, such as taking care of

UX, minifying code, writing tests or anything else that would improve upon

your solution for this test. But it is worth noting that all additional steps you

take to improve upon minimum required goals will count towards your rank-

ing.

Time-frame constraints
Imposed time limit for this test is fourteen (14) days, but you should be able to

complete it in much, much shorter time. Limited time-frame is imposed as a real-

world scenario, but it is worth noting that this limit is stretched out to account for

the current and previous obligations you might have besides this test.

Real-world development and implementation of such functionality would in-

clude shorter time-frame, working on multiple, parallel features as well as work-

place and peer pressure.

6
Tips
This test, as well as any other development task, has a multitude of different possi-

ble approaches to solving the problem at hand. There is no best solution for this

test, but there are better and worse approaches for it.

We urge you to consider the problem at hand and to think it over before jump-

ing in. Building even the smallest part of the big solution calls for some planning

and considering the implications of your decisions.

There is no single feature that cannot be improved upon, and such is the case

with this test. There are no requirements except the stated ones, but going one

mile further shows dedication and willingness to be better than the bare minimum.

Focus on your strengths. If you prefer working on the UI and have less experi-

ence with the back-end - focus on the UI and UX and do not waste time on other

parts. On the other hand, if you shine on the back-end, UI should be an af-

terthought. In every case, this test provides the means for all parts to be completed

regardless of your strengths and weaknesses.

Tools can be your best friend or worst enemy in the development world. There

are absolutely no limitations on what tool you can use to reach the best possible so-

lution, but excess of tools used can complicate the development process for a

large-scale application.

Finally - we will be looking at implementation, performance and code itself.

Your solution will be tested out in different environments, browsers and servers.

Thought process behind the solution is something that we will inquire about.