Why do so many people fail the test?
The number of companies using technical coding tests has increased in recent years. However, the success rate for developers taking the tests varies wildly, with various factors at play. This doesn’t make them bad developers; here ConSol Partners discuss whether changing the approach to the technical coding test will generate the right results.
Some candidates spend so much time perfecting a niche area of technology, that sometimes they find that they are lacking basic knowledge after spending an extended period not practising. Something as simple as linking a database can become oddly tricky if you haven’t done it in years.
Many people fall into the trap of ‘showing off’, instead of addressing the brief and producing exactly what it asks. Over-complicating your code can make it tough to follow and understand. Keep it tidy and simple.
Rushing into the test without thoroughly reading and understanding the brief can be detrimental to your results. Miss-understanding the slightest element of the brief can change the trajectory of the whole solution.
Failing to Prepare
Some candidates in the past have been guilty of letting their ego convince them they are too senior to fail the test. Usually resulting in a pretty big shock when it comes down to formulating a solution.
Our advice for facing the technical test:
Don’t rush into the test without a thorough understanding of the brief. Take extra time to re-examine the brief and sketch out a plan for the main pieces of your program and how you will tie them together. You’ll provide yourself with an overview of the program, enabling you to spot any issues that may arise and prevents you coding yourself into a dead-end.
Too many candidates use the test as an opportunity to show off their skills by producing overly complicated code without providing a Readme to accompany it. The reviewer will only spend so long attempting to run your program without any documentation, and the longer it takes to debug, the more negative your review will be. By keeping it simple and supplying proper documentation, you can provide the reviewer with a good experience and come out the other side with a solid review. A clear Readme can also offer you the opportunity to address anything within the solution you view as a flaw or something you didn’t quite get to.
Take some time in the run-up to your test to brush up on anything you haven’t practised in a while. For example, if test-driven development was mentioned in the job add, the chances are you will be expected to show some level of this in your solution. So, go back and get comfortable with it again, you will be better prepared for the test, and you will feel more confident in knowing that you are ready for any scenario.
Help on specific problems isn’t a bad thing. Showing the initiative to research any roadblocks you come up against can be a positive thing. Be wary not to copy a solution but rather understand it and apply it to your answer. Don’t be afraid to bounce ideas off other developers too. You will be expected to engage in this type of activity in your role.
Don’t make the mistake of finishing your code after days of draining concentration only to mail it off before conducting a thorough check over your work. Refactor your solution, check for any errors and then review your documentation. Mistakes in your solution show the reviewer that you either don’t understand the coding or didn’t care to check it and neither is a good look. Utilise all your given time to perfect every aspect of your code, so when you send it, you know it’s your best work.
Criticism and Experience
Regardless of the outcome, you will receive constructive criticism and experience of the process. Take the advice on board and either implement it on future applications or into your new job. The knowledge you gain from the test can only improve your capability in future coding, whether for tests or your employer.