React Technical Test
Over the next week, we're going to be completing our first ever 'mock' technical test! As a junior developer, it is extremely likely that at some point in a recruitment process, you will be asked to complete a technical test for your prospective employer.
For this track, we'll try to recreate as many real-world tech test conditions as possible to help us prepare effectively for the real thing. As a general guide, you will usually be given around 5 working days to complete the task but seeing as this is our first attempt it will most likely take us longer.
Things to be mindful of before embarking on a technical test:
##1. Is it reasonable?
"We want you to build a whole website from the ground up in one week, back-end and front-end" - Unreasonable
"We want you to build a form that returns results from an API endpoint when a user submits" - Reasonable
Do not feel the pressure to complete a technical test if after agreeing to do it you receive something that is unreasonable. Make your feelings known and move on to the next potential job offer. If the employer does not respect your time and has unrealistic expectations for people they're trying to recruit, what must the actual working conditions be like?
##2. Does it need to look great?
Decide which conversation you would prefer to have:
###Scenario 1 Boss: I had a look over that project you worked on and nothing seems to work properly?
Me: Yeah... but it looks great right?
Boss: Well, yeah, but it doesn't work...
Me: Art doesn't need a purpose, it just is.
Boss: Get out...
###Scenario 2
Boss: I had a look over that project you did and all the functionality we wanted is there.
Me: Yeah it should be working as intended, I just need to spend a bit more time styling.
Boss: Don't worry about it, I can present this as a work in progress to the client. Good job!
When you're short on time, don't spend days trying to get some pixels on a screen to arrange themselves in an aesthetically pleasing way. It's far more important to get the functionality working and tested first. Don't waste time on hours of styling unless your tech test specifically states they would like you to spend a large amount of time on it.
##3. My tech test doesn't say anything about testing. Do I need to write tests?
Yes! You do need to write tests!
Writing tests is your ticket to getting a face to face interview. Many people can code and many people can complete a technical test, but not so many understand the importance of testing or understand TDD. Demonstrating this skill will make you stand out from the rest of the crowd.
##4. So I just do the test, commit everything, and send it off before the deadline?
Yes, and no.
You should first do a rough draft of your technical test. Complete the brief, write tests, and finish it off with some styling to make it look pretty.
Once you've done that, we'll work on our actual tech test that will be submitted.
This one will have strategic commits to show we practice TDD as employers will check your commit history for the project.
You should make a commit and push your code after every couple of components you've created and wrote tests for so your future employer can see a clear roadmap of how you put the task together.
For what it's worth, it's okay not to finish a technical test, as long as you submit it before the deadline. You must, however, update the README to explain and reflect the reasons why.
##5. README
Lastly, once you've completed your technical test, it's time to update the README.
Here you should include a screenshot, detail what the brief was, what tech you used to complete the project, how the tester can get the app to run on their machine, and what you would do given more time on the project.
We will look at writing good README's later in the track.
Okay, let's get started!