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!
Say Hallo! Instagram | Twitter | LinkedIn | Medium | Twitch | YouTube
Top comments (44)
I can absolutely agree.
I had the pleasure of designing and evaluating these tests for the last few years and I can confirm that Mistake 1 and Mistake 2 are the most common reasons for failing these tests. Failing here is an instant fail.
But I would also be very careful with Mistake 3! Not every company wants a solution to their tests publicly available. So if git is in clear violation of 1 or 2, then do not use git at all!
Luckily there are now free private repos on github so I suggest to always make it private and invite the reviewer – or ask when in doubt.
I also agree that it is absolutely OK to have questions about the test. This can actually be part of the test! Never hesitate to ask questions! This is also true for the following technical interview of course.
To Mistake 7 I would add that next to the instructions you should also note your motivation on why you solved it the way you did. Explain why a certain technology was chosen and why some alternatives where not.
I have evaluated over a hundred technical tests in the last 2.5 years and it helps a lot if we get a short – and I mean short – summary of your thoughts during development.
Thanks for the great comment!
I did test for several companies on both sides of the game.
I never had the case that companies forbid to open source their tasks.
Do you know the reason why they would do that?
The only point I can see so that people don't copy that solution but yeah in the question round after you would invite the candidate it would be pretty easy to see that this is not his or her code ;)
Yes. It is mainly to prevent copying solutions but also to prevent other companies from copying the test.
We explicitly asked for zip files and not a (public) git repo.
Interesting. We change the test depending on the level of the candidate.
Do you only interview one per level/position?
A test can be quite long lived. Assume you are looking for 10 software engineers (of same position, but different levels). Then you probably have to interview 100 candidates over the course of several months.
Even if I would design a test for each level (working-student, junior, intermediate, senior, principal ... Too much!) copying is still a possibility, e.g. choise of technology.
An openly constructed test that tests for skills, mindset and approach is much better suited in these situations. You learn much more too and you have an intro into the technical interview as well, as you will start asking about the test a lot – hopefully leading into a meaningful conversation.
This also allows you to actually judge the level of the candidate instead of hoping he applied for the right level.
A good test does not require a specific solution nor a specific level of knowledge but probes and challenges a candidate on all levels. It is also only the foreplay to the technical interview.
Valid points but our tests don't say anything about how to implement it.
I would never say in a test using this lib and this framework.
Usually, the candidate has their freedom. So if someone would come with the exact solution it would be very obvious.
Like for a full stack dev using exactly the stack would be amazing because you have so many stacks, libs, frameworks out there.
Yes its most of the time never about the actual implementation. It about will the candidate fit into the company/team and what is his mindset.
A big point for me is also will he/she function in a team.
We all know the rockstars that write "the best" code but nobody except them understands what is happening because he or she refuses to play well with the team. Also, other things that are more about soft skills than the actual coding skills.
I see the point that for some companies it can be a problem that the solution for the task is somewhere on GitHub.
If you are sending the task and require it to be private you could initialize a private repo on your company Github for them.
Yes, this is also a valid solution I have seen. Not every company has github or uses git though. There are other valid alternatives.
Of course, use whatever version control system you want.
I mean this are general advises and companies will have there own requirements and you can replace git with svn and github with bitbucket.
I would like to point out that if you are going to use a repository SaaS as github or similar, either create a new account for the task or make sure that your account is either filled with all your "perfect OSS projects" or at the least is cleaned up so that you don't show off code that would make other developers cry.
If you send a github repository link, the reviewer WILL look at your other repositories to see what else you do and how you do it, if they don't they are making a big mistake.
So when you work on your own private projects, it's quite important to pretend that someone else will read or use your code!
Here I can just speak for me:
A) it is more important to write readable code then perfect code.
B) I really don't care about old reports. Why should I care about have the time to look through 2-year-old reports.
C) the fact that you are putting out code at all it's more important than the code quality.
D) even if I look at other reports I will try to see some kind of progress.
E) I lake the context of why this repo exists. So how can I judge it?
Maybe there are companies where this is important but it sounds more to me that this kind of companies wants solo rock stars then a band of good developers.
The "perfect" project thing was a joke. What I mean is, if you have a heap of really messy projects in your repository that you show off to someone who is considering to hire you, they will see them and they will judge you on it.
If a repository is old and not maintained, it's a lot less important in this sense, but if you have a project that you are actively working on in which every commit message looks like "fixxxxx", or "f**k it!" or similar, I wouldn't recommend showing it of.
I like to look at peoples repository history when I intend to work with them, that way you can get a quite good idea on how they work and where they are strong and weak in their knowledge.
Okay I never write comments or commits with f@#k. In them but yeah point taken.
Honestly an empty account is a much bigger red flag to me than an account with some messy side projects.
If those projects are personal it really doesn't matter what they look like IMO. At least you're doing something and exercising your muscles 😉
Messy account would make me less inclined to hire someone than a newly created empty account.
If someone writes terrible code when in solo projects, they will likely write messy code in my proprietary code too ;)
But I guess it might be a personal preference!
Hi @lampewebdev , I had a similar situation but probably worse. I recently applied for a company which owner was the main developer/team leader. We exchanged a few emails and he sent me a quiz, did almost everything perfect, data structures, algorithms, web technologies, etc... sent my proposal hosted on fiddle and never got a response back, that was so embarrassing I'm not willing to mention names but it's very disappointing.
Anyway thank you this was a great post
Hey,
That's not very polite of him. Even you he thinks you did not a good job, some kind of thank you email would be nice.
If you want you can DM me the link on Twitter or Instagram and I can have a look at the code.
Thanks mate I wrote you on Instagram, thank you so much for taking a look BTW I followed you on Twitter didn't find a way to message you directly anywhere 😁
Thanks I followed back !
I generally use a jsfiddle or something. No coding test is going to be so complex that you need to set up your own server environment for it (please god no), it might be the jobs I apply for but they all just need a simple and quick code example, jsfiddle gives you all that, with options to include the major frameworks. Plus you can see if they viewed it or not ;)
It really depends.
What we don't do anymore is like 10 mini-tasks.
Like 1 liner or 2 liner solutions. For us, the code task is not about how fast can you google the solution and then copy and paste from stack overflow. It's more about how you work and can you work in a team. This kind of task does not add any value for us. Culture for us is more important than how do you do fizzbuzz. I, in general, would avoid companies that let you code fizzbuzz.
If you want to be a full stack developer setting up a database and connecting it to a frontend should not be hard. You can use tools like meteorjs.
If you are a junior frontend dev then, of course, you don't have to do this.
In general, all these points are things that will make you better than the average developer.
Using a service like Heroku can be done by people who are coding for a week. I had classes where we used Heroku on the 3 days of class and everybody was happy that he or she could show their website to others.
I was reviewing candidate's tests for some time and I agree in most of the things. About GitHub, some companies may require to have a zip file sent instead.
For me, as a reviewer, the most important thing before starting to look at the code, is to have a deliverable that I can compile myself. After that, I focus more on clean and readable code.
One time we had one person who sent us the test solution in a PDF!!!!
Yes, your right, not every company wants that but if they don't want that they should specify it and as a bonus, GitHub now has private free repos!
In a PDF? What? Why? How? What was he/she thinking?
For sure sending the test as a link to a git repo gives extra points!
And that was also our reaction when we saw the PDF! Like seriously, how do you expect your code to be reviewed?
And that makes me think that being a good software engineer is definitely not only about coding. So a candidate's test deliverable should go in the same direction. I much prefer a clean and well structured project with some flaws or minor bugs than a perfect solution where only the dev who wrote it understand how it works.
Yeah, our process is more about to see if the candidate fits our team and how he thinks.
It's not about the perfect code because there is no such thing as perfect code.
Coding itself is just one thing a good software engineer has to be good in there are so much more. People really tend to forget soft skills a lot but they are as important as good code.
Great article, I would also add unit testing to the list especially if the job spec asks for it. People won't just take your word that you unit test so make sure you put them in the task!
Yes depends on the level of the developer. It's not a must for me especially when it is a junior dev ;)
But I will add it in the second part!
Thanks for your comment.
Deploying to a free Heroku instance is a great idea, I should have done that. Don't forget to put your work in a separate branch from the application start as well.
" Don't forget to put your work in a separate branch from the application start as well."
Sorry, I don't understand what you mean with that?
Excellent article. I have to admit that I have been guilty of #2 due to ambiguity - lesson learned on that front. Reassuring to know that I had already formed habits for all the other tips which will others will find super useful.
That's good that you have these habits and good to know that I could at least help a little bit! 😄👍
Great article! I pin it, it should be useful in the coming months
Thank you! If you have any question just write me a dm!
I learned a lot from this grate article, just want to say THANK YOU ❤️
I really appreciate it and I'm very happy that you learned something!
Have a nice day,
Some comments may only be visible to logged-in visitors. Sign in to view all comments.