Published 2011-05-24.
Time to read: 3 minutes.
posts collection, categorized under Evaluations.
Once again I am reviewing programmer resumes for a client. This client needs to hire an entire team, including Flex and Java programmers. Because programmers write software, I always request sample code from candidates. I do not ask stupid hypothetical questions or play mind games – I just want to assess the quality of their work.
I request the code along with a resume. Code is truth. I do not interview candidates who do not provide sample code that passes inspection. The requirement for sample code is published in the job description. Surprisingly, most applicants do not provide sample code. I do not respond to those applications because clearly those people do not follow simple instructions.
This is worth repeating: If a job applicant wants to be considered as a candidate, they need to provide sample code along with their resume.
I assume that the programs that candidates show me are examples of their best work, or at least work that they are proud of. Most of my clients need programmers to develop software products or in-house applications, so efficiency and maintainability are important.
I ask for sample code in at least two languages. It is up to the candidate to decide how much to show me, and what they show me. The more sample code they show me, the more sure I can be about my assessment.
Here are some issues that I look for in submitted code:
- Is it difficult or expensive to maintain?
- Was the code written with the next programmer on this project in mind?
- Is logic used instead of data structures?
- Is the code neat, and does it follow a consistent pattern? I don’t care if particular formatting conventions are followed, I am looking for an ordered mind and a conscientious worker.
- Is the code testable? Were unit tests and/or integration tests provided?
- Does the code contain magic values instead of declared constants?
- Is the code inefficient (are there lots of conversions between string and int, for example)?
- Does the programmer use idioms specific to the language that it is written in?
- Are there appropriate comments, especially Javadoc / asdoc style comments?
- Are default actions or values present in the code? Defaults are tacitly understood by competent programmers, and providing them just adds noise. Code and documentation should be written with the assumption that readers will be technically competent.
- Is encapsulation violated because most methods are public?
- Are there syntax errors?
For Adobe Flex programmers I also look for:
- Is there proper usage of the Flex component life cycle?
- Is there a heavy dependence on binding?
- Are events used properly?
- Are heavyweight Halo containers used, when Spark Groups would suffice?
- Is all logic in a controller, or is it shoved into views (or worse, item renderers)?
- Are style sheets used, or is style information explicitly coded?
I also provide a reading and comprehension test, and ask them to critique the code I provide. Some code I provide is good, some bad.
Many enticing resumes are simply not supported by good sample code. Would you hire a chef without tasting a sample of their food first?
