You got this task from that company you want to work for! You are hyped and you immediately start to work on that task. After a long night of coding, you are done and you think you implemented the best thing ever!

So you send the task back to the company. After some time you get an email from that company. You are confident that you aced it and they are sending you a draft of the contract!

Then you read the E-Mail and you can't believe what you are seeing. It's just a thank you E-Mail and that they decided to go with someone else.

What went wrong and how could you improve? Let's dig into it!

Mistake 1: You did not read the task good enough

Sometimes just one word can change the meaning of the task completely or you did not catch the word responsive on the first time or you just think that you got it but you don't get what the task is really about.

So read the task 3, 4 or more times to really understand it.

Mistake 2: You started implementing the task without fully understanding the task

So you have fixed mistake 1 but you're still having questions?
Ask the person you are in contact with. It's nothing bad to ask! It's the opposite it shows the company that you care for a good product and that you don't want to waste there time.

If they react negatively, then I would stay far away from that company because this is the first sign of a toxic environment where nobody can ask anything.

Mistake 3: you are not using Git(or any other version control system)

Please! Please! Don't send a 60 Mb ZIP file via E-Mail with the complete node_modules Folder. OSX does not like to unzip node_modules, so the person who will review your code will not even get a chance to look at your code.

Use Git instead. If you don't know Git then this is the best chance to learn it because a lot of companies use Git. Sooner or later you will have to learn it.

Mistake 4: Write good commit messages

You are now using Git, good. Don't do everything in one commit. Companies will look at your git log to read the commit messages. You have to remember you will work in a team and in a team good commit messages matter for the other team members and for you in 2 weeks when you have to find a commit or understand what happened in that part of the application. So commit often and write good short messages.

Mistake 5: You forgot the .gitignore file

This comes back to mistake number 3. If you don't have a .gitignore file everything in that directory will be added to Git. So again you will send the complete insides of your node_moudes. Nobody wants your node_modules.

Here is a good collection of gitignore files: https://github.com/github/gitignore

Mistake 5: You are sending a Zip file via E-Mail

I mean as a developer you have to know GitHub, right? So use it! Put your code on GitHub and send the GitHub link to your contact person. Your contact person will be very thankful for that.

A) No corporate spam filter will remove the zip file.
B) Yes even in 2019 E-Mail's have a file size limit and you may be just hit that limit
C) It is easier to have a first look at the code without downloading a zip file, to have a first look at the code.
D) It is easier to share with other developers in the company. Usually, more than one developer will look at your code.

Mistake 6: You don't have a README.md file or it is not good

Github will render the README.md file and it will be shown on the main page of your repo. Write some meaningful content in it. For example, the task name or explain what this task does, maybe add the dependencies and this brings me to my next point

Mistake 7: Write an instruction on how to start your task

Yes, I can go the package.json file and have a look at your scripts and if they are meaningful I can figure out which of them is the right one todo or maybe not. So please write down in the README.md how to set up and start your task so I can run it.

Mistake 8: You did not include a working link to your task

"But why should I do that when you just told me that I should write instruction on how to run it?" is what you are asking yourself right now. To make the review of your task for the reviewer as frictionless as it can be so the reviewer is not annoyed that he/she had to figure out for one hour how to see if your code is actually doing what was mentioned in the task. Put a working version anywhere on the internet where you can give the reviewer a link. Heroku, GitHub pages, aws or Azure are just a few which also have free services for doing that.

Mistake 9: Remove old/unneeded Files from the task

Don't be that guy that has an _old folder somewhere in the git repository. As a reviewer of your code. What should I do with this folder? Should I look into it or maybe don't? Why is it there? I don't even know what to say. So please remove all unneeded and old files from your code.

Mistake 10: Write a nice E-Mail with the link to your GitHub repo

Don't just send an empty E-Mail with a link. This can be viewed as very rude. I mean on the other side is also sitting someone human. Write at least: Hello XXXX, how are you? I hope everything is fine. Here is the link to my finished task [THE LINK]. Have a nice day. Best wishes, Michael

This is just a few examples I have seen. Do you have more? comment down below!

In Part 1 I was more focused on things around the code and implementation. In Part 2 I will give some examples of things that are hurting your chances to get the job in your actual code.

Maybe you want me to review your code? or give you some tips on how to help you? Just contact me on any of my social media accounts and I can try to help you. Of course, I can not do the task for you but I can help with everything else!

Thanks for reading!

10 Mistakes you probably also made in your coding task for a new job Part 1