There's a great article on about coding challenges in interviews that is helping prepare Developers for the minefield that is the technical interview.

Undoubtedly, it's crucial to assess technical competence, but how you do it is everything. I've heard plenty of horror and success stories from Engineers about these.

From experience, the Engineers I've spoken to that enjoyed coding tests the most said;

1) They were given a chance to meet with the hiring manager or company first to understand if they like the opportunity. Why should they have to commit hours and hours of time when it might not be right for them anyway? And that small bit of engagement early on can mean the difference between an engineer giving their best in a test, or it falling into the “do it later” pile.

2) The test was relevant and challenging in a real-world context. Coding a solution for a problem they'll never face, with tools they'll never use, under circumstances that never exist is a huge waste of time and doesn't give them the chance to express what they can do. 

3) They were given detailed and specific feedback as to why they were successful/unsuccessful. This is probably the biggest gripe I hear. If an engineer has committed time to a test, the very least they expect is feedback on how they did. This should be true of any interview, not just Engineers.

The competition for Software Engineering talent is fiercer than ever, and it's vital to have an interview process that lets you asses if they're right for the role and also gives Engineers a positive interview experience.

I’d welcome feedback from the Developer and Talent community on their experience with coding challenges and interviews.

Credit to for the original article: