One hiring manager’s lament…
Code exercises. They’re nearly inescapable today. Hiring managers insist on ‘seeing’ what you can do before scheduling an interview. And there’s good reason, too. In my experience, approximately 80% of all engineering candidates fail their initial code exercise, therefore who wants to schedule an hour out of their day for a candidate who can’t pass a simple code exercise? To be perfectly candid, the high fail rate is due to laziness and sloppiness on the part of the candidate. It is for these reasons I have outlined a path to a successful code exercise submittal. If you do exactly what is written below, you stand a very high chance of passing.
1. Hiring Managers. What are they looking for? They will look at your exercise and extrapolate from it the kind of quality they can expect from you on a much larger project. That’s it in a nutshell. So how do you show them you ‘really’ know what you’re doing?
2. Read the code exercise question carefully. Know what they are asking of you.Sounds pretty obvious, right? Apparently not obvious enough to the vast majority of developers. This is one of the major hallmark failures: not understanding the task at hand. I’ve had hundreds of misinterpreted code exercises cross my desk from all levels of talent.
3. Best practices. An alarming rate of developers do not follow best practices. For instance, separation of concerns, modularization, error handling, documenting, and testing to name a few. (Everything that SHOULD be in your code exercise). Candidates slap together a solution in five minutes, send it off without checking it and assume that since they’re a ‘Senior’ developer, they’ll get a pass. Not so.
- Many, many times candidates write elaborate, lengthy solutions that could have been streamlined by using a built-in function. (If I had a penny for every time I’ve seen this). This is a showstopper. It tells hiring managers that you don’t know the language you develop in. Odds are extremely high that the functions you need exist, so look them up before hamming out 30 additional lines of unnecessary code.
- If your exercise requires input, don’t hardcode it into the solution. Big FAIL. Design your code to take input (e.g. read from a file).
- Consider the possibilities for errors. Why? Because the hiring manager will try to break your solution. For instance, if it requires a number for input, check to see that it catches letters, special characters or unnecessary spaces. I know this sounds agonizingly obvious, but this trips up Jr. to Architect level developers at a staggering rate. They simply don’t consider the possibilities. Invest some time in a well-known testing tool (e.g., JUnit if you’re a Java dev.).
- Run your solution to make absolutely certain it works. About 30% of the engineers I have worked with didn’t bother to run their code because they just ‘knew’ it worked. Well, I’ve got news for you. It didn’t.
- Make sure you’re using the best solution for the problem. For instance, should it be a HashMap, TreeMap, or HashTable…and why? Furthermore, explain why you’ve gone down your chosen route (e.g., pros and cons). The hiring manager wants to know that ‘you’ know the differences.
I am very confident that if you follow the above advice you’ll do very well with your next code exercise.
This post originated on, www.dorigan.com.
