This is Part 2! If you like this, I would appreciate it that you also check out Part 1! Also if you want to see more tips and talk to me, go to my Instagram account. You can also write me a DM, I'm trying to answer them all as fast as I can!. Thank you and hopefully, this will give you some helpful advice.
In Part 1 we looked more into how to send and prepare your code for evaluation by your interviewer.
Let's get started with the second part where we will go more in detail how the actual code should look like and other mistakes you are probably making.
Mistake 1: Don't say something is easy
"Javascript is easy and not hard". I don't know why people say this but it is a common thing. You can replace Javascript with anything you want. Everything is easy and also hard at the same time. Driving a car is easy but driving a Formula 1 car is hard. Also, it shows the interviewer that there is some kind of elitism in your mind. What do I mean by that? It's the same thing when people who are new to programming are asking: "What is the best way to do XYZ?". There is neither the best way or one way. There is not such a thing as the best programming language to use or to learn. So if you think that only because you learned C++ you now look down on Javascript developers that show that you feel like you are in some elite squad. It just means that you learned one tool from your toolbelt. You now can use the Claw Hammer but not the Sledgehammer. Yes, it will be easier to now learn the Sledgehammer but both hammers have there own pros and cons. So please don't say that things are easy. Most probably they are easy because you don't fully understand them.
Mistake 2: Write tests if the job specs say you have to know to test
It's always a plus to show that you can write tests. They don't have to be perfect. You don't have to have 100% code coverage. Just write some simple tests that are testing your core functionality and you probably have a big plus point.
Mistake 3: Not splitting your code into smaller files
If you send one big file with 2000 lines of code it is hard to review that.
As someone who has to check your code, it is hard to see what is happening in this file and how the code flow is. Probably you also have to scroll from top to bottom. Better try to split your code into smaller files. This will also be important later for work. Nobody wants code that only you understand but none of your team members. Please split it up. It's so much easier to review.
Mistake 4: You don't have code comments or just writing what the next line does
This one I see people do even after some years of working as a developer. Comments like: // Loops through an array and the next line is Array.forEach(). Yeah hello, Captain Obvious. It would be better if you would describe what this loop does in a more abstract way. // preparing data for sending it via AJAX or something in this direction. So people know what the intent of the code is.
Mistake 5: Your code is all over the place
const array = [ 1, 2];
array.forEach((a ) =>{
a = a+ 1;
console.log(a) ;
}
);
This is really hard to read and also shows that you working very carelessly. Today we have tools like eslint and prettier. Every bigger editor and IDE has this build in or you just need to install a plugin/extension. So please use it.
Mistake 6: You are not naming your variables properly
const b = true;
const a = [];
This is not easy to read and not helpful to understand what b is.
Way better naming could be:
const isReady = true;
const listOfPersons = [];
Again these are just examples and every team will have its own way of naming things. Of course, you can not guess that style but just do what you feel is a meaningful name and stick to one style.
Mistake 7: You are just commenting out old code
I have seen this often and I still don't understand why people are doing this. You have a file with 100 lines of code and 70 lines are just old code which is commented out and 30 lines of actual implementation. Should I read the old code? Should this show me that you did it the first time wrong and then reimplemented it? Nobody is perfect and writes the first time the perfect code. So please delete this code. If I want to see if you refactored the code I should see it in the git commits with git commit messages where I can understand what you did.
Mistake 8: You did not check if your code is still running
This happens all the time. You get one E-Mail from an interviewee on Sunday evening. You go to work on Monday and start to check the code and suddenly you get a second E-Mail with some updates in the code. You also get a promise that this time it really works. So please, Before you send your code. Stop the program, clean the cache, install the dependencies and start it again. If it then still works then you can say that you're ready.
Mistake 9: You changed something and did not check if it is still running
For our full-stack developers, we have a task where they need to save variables in a database. They can choose the database, the schema and how to save the variables. We just say this has to be saved. This is where people change the code and don't check if after the changes it still really saves to the database. For example, they change the schema or they just try it with a small file, etc. Again before you send your task back, check if all functions are still working as they should and try to break stuff. Nobody is saying that you need to catch every edge case but at least the most common things a user can do.
Mistake 10: You did not prepare for the coding interview
Some time has passed between sending the task and the actual interview, maybe a week or more. Do you really still remember what you have done in that task? Like why did you solve this task in that way and what was your thinking when you implemented your task. One of the goals of this entire process is not to see how good you are as a programmer but will you fit the team and are you a team player. It's more about your soft skills then your coding skills. Please read your own code before you go to the interview part.
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!
Top comments (13)
Nice post. I would like to add that comments should usually be avoided, especially when few people work on the same codebase.
There are multiple reasons, but the most obvious maybe:
This could lead to misunderstanding in the future.
Having this in mind, I agree with "Mistake 4", but it would be even better to put the code in a separate function with a descriptive name. For example "prepareDataForSending()"
I totally agree here.
This can be a problem especially if you are using JSDoc and suddenly your function changes but people forget to update the JSDoc.
If you have a function that is like 200 lines of code you should exactly do what you are proposing. you should split it up into smaller functions. I would even go that far that if your function is longer then 30 lines you can split it up.
Thanks for the comment and its a really good point!
I have seen too much code whose purpose is never explained, and been told too many times to "read the code", as if by some process of clairvoyancy that will tell me what was in the mind of the coder.
If a method is called "setMessage()" and you change its functionality so it appends instead of replacing, you don't leave the name unchanged, do you? So why are comments any different?
It's the responsibility of all programmers to ensure their code remains readable and its purpose is clear. As with method names, without appropriate comments the purpose is often far from clear. Don't duck the responsibility.
It's true that all programmers need to ensure that their code remains readable, and again, this could also be the one more reason to use descriptive function names instead of comments.
These are some reasons why I think that descriptive names are better than comments:
Comments inside a function used to describe what some block of code does can lower readability.
If we need a comment to describe a block of code, then this block of code can be moved to a separate function.
A function should do only the one main thing which should be easily described by its name.
A large number of comments also lower the readability.
There is more chance to see that some function has a bad name than that comment is bad.
Functions are recognized by modern tools and IDEs, while comments are not. This can help us to recognize that name is bad even outside of a file the function belongs.
Additionally, functions should be short enough that comments are not needed.
However, sometimes comments could be our friends:
public functions should be commented (documented) especially in public libraries/packages - this could help us to understand what those are doing without the need of looking at source code.
todo's - but please, do not push it to the repository or rely on someone else to fix it or to see it (I used to see some todo's more than 2 years old). It is better to create a new ticket/task/issue.
It's not easy to make fixed rules about these things, but I do believe that too little documentation is the enemy of maintainable code. In the end we have to rely on the professionalism and common sense of the programmer. If (s)he doesn't have any we're doomed anyway.
I think I'm generally in agreement with what you say. I advocate the implementation of 'user stories' as high-level code, if only as a set of single-use functions, to match (where possible) the project brief supplied by the client. Then it's quite clear what the intention of the program is without the need for excessive documentation. That tends to answer the "why?" question that the code itself rarely reveals.
Definitely agree about comments. Just occasionally they are required, but if you have to describe something using comments then that's probably a smell since it should be easy enough to follow the intent of the code. Code should always follow DAMP principles, which ties in with one of the other points about not using single letter variable names. There's no excuse for that.
I see the SOLID force in you.
Clean code FTW
That's it. Good guess :) and I totally agree with him.
Very informative post, thanks a lot and Captain Obvious!!! Ahahaha good one....
Your welcome. How you could get some useful internation.
If tests are specified and you have written them (some people don't and that's an instant fail), then for the love of all that is good, make sure they actually run. I have reviewed code tests in which there are failing tests and that test was instantly rejected as a result.
Also, don't write tests for the sake of it: Your tests should be usefully exercising your code, and test cases should be things such as boundaries and edge cases not just the same test run a few hundred times with slightly differing values that would never cause a different outcome.
I've seen this kind of thing in code tests submitted for mid-senior positions.
Great points!
Always comment your intent; don't just restate the code.
Yes true!