Assessments will differ per company and the role you’re applying for, but in general they should take you between 4 to 8 hours to complete. Sometimes you get the assignment and can decide when to build it, sometimes you will not have access to it until you start on it and there is a timer on it. If you get the assignment beforehand, read it and let it sink in for a bit. Try taking different ideas for a spin in your head first and plan when you are going to build this. If you want this to be a success, plan it properly, don’t start at 10 at night when you’re already tired. Make sure you are well rested and have blocked out your calendar and keep distractions to a minimum. If this means cleaning your desk from shiny objects, or telling your roommate/partner to leave you be for a few hours, do it.

After you read the assignment, think about how much time you want to spend on certain parts of it. Write out a small plan of action if that helps, with what your main focus is going to be and which parts are not mandatory for the final project, but are nice if you have some extra time at the end. If the assignment is strictly timed, make sure you set a timer up for yourself, so that when you have the basics finished, you still have time to write a readme file or accompanying documentation. I usually plan out two thirds of the time for building the project, and then one third for testing it, fixing bugs, writing documentation and making sure that what I deliver is the quality I want. I’d rather have one less feature and everything nicely checked and tested, than a sloppy extra feature that sometimes works and is not reliable.

In my experience, these assignments are used over and over again for candidates. Unless it is a super specific role, you are probably able to use languages and tech of your own choice. Use this to your advantage! Use tech you know and understand, because you have limited time to build this, it needs to work, and you need to be able to explain why you made certain decisions. Using technology that you already are familiar with will save you a lot of precious time. If you work with a technology you are unfamiliar with, you might get stuck on errors and losing precious time in the process of fixing those. Working with what you know best will show the company your skills in the best way. If the assignment does not allow you to do so, you can always ask the company if you can do it in the language of your preference. It can’t hurt to ask, and it could make a huge difference in the outcome.

The projects I built for assessments all had a clear goal in the assignment briefing, but there were also some less important extra goals, and a couple of things to choose from what seemed important to me. It is important to keep your eye on the main goal of the assessment and deliver it well. Then you could add extra functionalities to it if time allowed, and improve it with features that were nice-to-haves instead of must haves. Work on this like you would work on it if this was your job. See them as a customer that is paying you to build this, and take it seriously.

The assignment will most likely have more requests and possible features than you are able to build in the given time. That is ok, don’t panic, it is ok if you don’t have time to build it all. This happens in real life too, customers will want a lot of things and you can only spend so much time on their project. You will have to make some choices. Remember why you made certain choices, if they ask you to come back for another interview and talk about your assignment, they might ask about your motivation behind certain choices.

While working on this assessment, you are super focused and all into it and know every line of code and what it does. And then a week later you’ve been on another interview, worked on a personal project, possibly even made another assessment and then you get invited to talk about this assessment. Suddenly you have to think hard to remember exactly why that code is there and what its purpose was. It is not a bad thing to write some comments in your code about the more complicated parts of it. This helps you to remember why you wrote it that way, and will also help the people who are checking your code to understand what is going on and why you wrote it the way you did.

I will say it again: documentation. It is very important to have a Readme file with instructions on how to install your project. Once you’ve submitted it, someone or multiple someones are going to check your work and discuss it. You don’t want to get an email back with the question on how to open it, or how to run it. Make sure you add clear instructions, and test them out before you submit. Make sure what you’re sending works on its own and is complete. Do a fresh install from the (zip)folder you created to submit, follow the instructions and see if those get you where you need to be on setting up the project.

While it is the most important that your project works when it is finished, there are a couple of details that will really give it a polished feel and have the company invite you back over.

1. More documentation, add in writing some more info about what you built. Are there known bugs? This might feel like something you want to hide, but it is much better to be honest about it and recognize it if you have any. They will find the bug and ask you about it, it’s better to tackle this beforehand and let them know you’re aware of it. This explanation could also include a possible cause for the bug if you have an idea about this, or even a possible solution for it and reason that you ran out of time to fix it.
2. Personality; are you passionate about Search Engine Optimization (SEO), or animations with CSS, or accessibility for screen readers? Add a small feature to the project on something you love about coding, and write about it, either in your documentation or in the accompanying email when submitting your assignment. This will highlight your skills and a little extra you would be bringing to the team. 
3. Check the console for any errors on any pages you built. This is easily done and should all/mostly be fixed before you submit.
4. Test it thoroughly. Resize your screen, reload it, try to break your own assignment. Why? Because the company will try this too. Here you can either still fix it, or be aware of it and be prepared for the interview.
5. Use Git. This will help you if things crash, it shows you can work with Git, you and the company can read back and commits you made and changes you made.

With these tips I’m convinced you can make an excellent tech assessment that will have you invited back for another interview soon. Don’t forget to have fun with the assignment! Yes it is for a job interview, yes it needs to work, but it’s also your first taste of how the company works and what it might be like to work there. Can you see yourself working at that nice desk yet? Enjoy and good luck!