Why I won't do coding tests
At my place of work we have a coding test that we issue to all applicants for the software engineering roles. Here are a few responses from our point of view...<p>1. We know you can probably code, you&#x27;ve already passed a phone conversation about your coding experience, but you may not have a GitHub profile (you might not be allowed to at your current place of work, or you might have experienced harassment through GitHub), so we&#x27;re not going to penalise you for that.<p>2. We want to see your solution to a problem that we know REALLY well. We know the pitfalls, the places people often trip up, we know how to tell if your solution is going to be maintainable over the long term. That&#x27;s why we want to see your solution to our problem, not just &#x27;portfolio&#x27; code, or even a &#x27;bugfix&#x27;. Not to mention the fact that the bugfix should be already done by the team, finding tasks that are low enough priority that we can give them to someone outside the team is actually difficult to do.<p>3. Our coding test is quite long (3 hours), but roughly capped, we ask candidates not to take longer than this. This is significantly less commitment for most than taking a day off work for a day of working&#x2F;pair programming&#x2F;etc. We do pair program later in the interview process, but not until we&#x27;re pretty sure that bringing the candidate on-site isn&#x27;t a waste of their time, and ours.<p>I realise that there are some devs who reject the idea of coding tests, but we have found it (in the form we do it) to provide some of the highest signal to noise ratio information in the interview process, and find it to be a really good balance of time commitments on both sides. Very few candidates drop out because of it.