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 codin...
For further actions, you may consider blocking this person and/or reporting abuse
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,
Great article. Will come back for this soon in the future.
Thank you! Part 2 is coming soon!
Mistake #4
Mistake #5
Mistake #5
Mistake #6
Number #5 came twice, deliberately done? :)
Maybe... Maybe... 😂😂😂
No It is a mistake.
But I kind of like it now so I will keep it :)
This is much helpful. Thank you for sharing.
Your welcome. Hope you could find some good information in the post.
Mistake 11: not reviewing your code before posting... I hate to be that guy, but we're supposed to be the ones OCD about any misplaced characters. Loved the post, but proofread for goodness sake.
Please complain to Grammarly xD
I even have a premium subscription ;)
But yeah I'm trying to improve!