When a software developer participates in a recruitment process as a candidate, they will probably have to provide proof of their knowledge. That proof will probably involve a home task, a live coding session, or an automated online tool. In this article, I’ll help you prepare for some of those challenges.
There is no one magic recipe to nail a code challenge – that’s why even the greatest professionals may fail to deliver good results. Some of the reasons we see when testing applicants to Nord Security include excitement, haste, the feeling that what is being asked is above the candidate’s knowledge, the fear that the delivered content will be insufficient, etc.
As a member of the team that issues and evaluates code challenges at Nord Security, I’ve come to understand many of the strategies that help applicants succeed. I’d like to share some great tips to improve your chances of scoring higher and to leave a great impression when faced with a home task code challenge.
Usually, a coding challenge consists of a brief description of a problem or a list of tasks to perform (sometimes both). The expectation is that the candidate is able to read, understand, and prepare a solution for the problem by writing code and/or arranging tools. Avoid the temptation to start to set up environments and code right away: instead, try to make a detailed plan by understanding the requirements and distributing the required steps in your available time.
It is normal to have doubts at first or even misunderstand the requirements, as it may be a different subject than you are used to dealing with. If this is the case – now is the time to ask your recruiter for clarifications. Don’t be afraid – it is better to ask now than to waste time on an incorrect implementation.
Pay attention to specific requirements. They may ask you to use a specific language, tool, framework, or technique that you don’t know. There is nothing wrong with taking some time to do some research on these new topics, but don’t dive too deep, or you may lose too much time.
Make sure to prioritize your list of requirements and draw a roadmap for your work. Consider the time you’ll need to review your code, to rest (you may be good, but still not a robot), and to write a presentation or a read-me file (if needed). Last but not least, make it work first and leave the improvements and fancy stuff for later.
When planning your time, try to deliver your work before the specified deadline to account for unexpected events or technical hiccups.
The code you deliver for a challenge will never reach the production environment, but that doesn’t mean that it can look like amateur work. If anything, it needs to look better than usual. After all, this is your chance to put your best foot forward.
Therefore, make sure to review your code before sending it, remove empty and draft files, get rid of those sample codes that come with the framework, fix indentations and blank lines, check if all the comments in the code are really needed (remember the Clean Code practices), and make it clean enough so the person who evaluates it doesn't waste time looking into stuff that does not reflect your skills.
Looking through other people's code is more enjoyable when it’s consistent, but that’s not all. Writing understandable and meaningful code leads to a more maintainable and error-free project, so your code will definitely be judged in part on how neat and readable it is.
Want to read more like this?
Get the latest news and tips from NordVPN.
Coding shouldn’t involve magic or crazy behaviors. That’s why developer communities have created many good practices for different languages and environments over the years. Some of these practices are implicit, and some are mandatory, and all of them will make your code easier to understand and maintain. Code evaluators will want to see you use best practices that will save you from delivering poor code.
Start by maintaining authenticity. Don’t copy code from similar projects online. It is OK to do some research on similar problems, but what counts is how you implement the solution in your own way and according to your own understanding. Be aware that other people's codes might not actually be good.
Regarding the code itself, watch out for redundant code, cyclic calls, interfaces as dependencies, error handling, and parsing input/output data. All these are mostly covered by the SOLID principles and are worth using for maintainability.
Keep in mind that your code can be viewed in a totally different editor or IDE from yours that may not have resources like auto-complete or click-to-go, so avoid tricky hidden code and always consider the language/framework standards.
Remember that the person who will evaluate your code also may not have a machine with the same environment, which can also cause all sorts of problems. Your code might not even run at all. Making use of dockerization is a good practice to avoid common environmental issues, such as the language itself and its dependencies (version, libraries, packages, etc.), desired settings, databases, and third-party services.
Running multiple conditions on a software can be frustrating, especially with conditions that need many parameters or involve different technologies. Preparing a make file is a good practice to save some time when running the most common aspects of your software.
Going through someone else's code can be a painful experience. Understanding what the code does, what it does not, and how to run or set it up can be tricky. A read-me file will help give some instructions and establish a good impression right from the start.
Tests are an important part of software development. Even if writing tests aren'tisn’t explicitly required of you, they will improve your chances because they will showcase your ability to take ownership of your work. Your successful tests prove that everything works.
Consider writing at least a few tests to cover the basics and edge cases around your code and to demonstrate the quality and consistency of your work.
Home task code challenges are a great way to show a bit of all of your skills and receive feedback from some other professionals.
Remember that the people evaluating your code want more than just to see if you are good enough with a specific framework or tool. It isn’t a marathon to see which candidate delivers the content first. The point is to see how the candidate solves a problem and if the candidate knows how to use the right tools to make something work.
Give it your best, try to make a good impression with your work, and your chances are bound to improve.