What would be the best way to figure out which applicant is the right one for your team who you have been looking for? Do you think it is fine to read their resume, only? Some companies ask the applicants to take a coding test, and some ask them to do a small project.
There are many services, such as Codility, HackerRank, and TopCoder, to name a few, for practicing algorithms and taking coding tests. One of the more popular services is the Codility that many companies use these days. I used to use some of them for practice and for tests, too.
My team has a culture when it comes to applications. We review applicants’ applications together as a team and, of course, none of us reveal any personal information out of the office, which is a given. It was a valuable experience for me to have an opportunity to review how applicants solved the questions in the coding test. However, I have found out there were some common mistakes that may make the reviewer not like or not prefer their application. So in this post, I am going to talk about the most common mistakes in coding tests with my experiences.
Even though I am involved in a team that reviews the resume and coding test results with all of its members, I do not have any authority to score them or hire them. Besides, these mistakes I will talk about might not be a big deal. I merely wanted to share what I felt from the reaction of my coworkers. All this post talks about does not mean they are bad!! 🧙♂️🧙♂️
One. var, let, and const
According to my statistics that I would like to say no one believes, more than 50% of applicants used more than two of them, var, let, and const. I am not saying you should use var or const only. Take a look at the code below before we talk more about this.
This screenshot above is a solution code of Breaking-Score in HackerRank. What can you see in the codes? First of all, the variables were declared with the keywords, var, and let. let is the keyword for a variable that has been included in ECMAScript 2015; on the other hand, var has existed from the first edition of ECMAScript. And second, you can see another var in for loop.
var minCount -> let minCount
var maxCount -> let maxCountfor (var i = 1; ...) -> for (let i =1; ...)
Why these mistakes could result in a low score from the reviewers is because your code seems that you are confused among different ECMAScript. If all variables were declared with var only, for example, it might be better, because the reviewers might think you are accustomed to ECMAScript 2009 or older.
- Use let and const(recommended!), or var only
- Don’t mix var + (let or const)
This screenshot is from Immer.js for creating the immutable state tree. You can see that none of the semicolons are in the codes. But I can’t say this is wrong. Their coding convention was merely not to use semicolons. If you want to know more about semicolons and whether to use them, click here to get more information.
I hope you wouldn’t write your codes like above. Some lines have a semicolon, and some do not. I recommend you use semicolons all the time.
- Either always use(recommended!) or omit semicolons
- Don’t mix (no semicolons) + semicolons
Three. Equality Operators
===) and abstract comparison(
Imagine the parameter for the function
removeZero is like below.
removeZero([0, 1, 2, '0', '1', '2']);
// 1, 2, '1', '2'
Even though the result I wanted to get was
(1, 2, ‘0’, ‘1’, ‘2’),
‘0’ is also filtered out. Why is that? Because abstract comparison operator(
false. Strict comparison operator(
===), on the other hand, does not work that way.
‘0’ is a string, which is not empty, so strict comparison operator does not consider
- Always recommend using strict comparison(
- Do not use abstract comparison(
In a function, you should not change the arguments no matter what. This concept is related to Pure Function, as well. Assigning a value to the arguments could cause a side-effect, which isn’t absolutely recommended.
- Declare a new object as the returned value.
- Don’t change the inputs no matter what. It would cause a side-effect.
Maybe there are more mistakes that I didn’t mention in this post. The reviewers who will read your codes also make human errors, don’t worry. But the point is, make sure that your coding style is consistent and use ECMAScript 2015+ methods if possible.
Thank you for reading my post. Have a nice day :)