Mike Slinn

Connoisseur of Technology

Assessing Sample Code from Job Applicants

2011-05-24 / All Blog posts

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 don’t 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:

  1. Is it difficult or expensive to maintain?
  2. Was the code written with the next programmer on this project in mind?
  3. Is logic used instead of data structures?
  4. 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.
  5. Is the code testable? Were unit tests and/or integration tests provided?
  6. Does the code contain magic values instead of declared constants?
  7. Is the code inefficient (are there lots of conversions between string and int, for example)?
  8. Does the programmer use idioms specific to the language that it is written in?
  9. Are there appropriate comments, especially Javadoc / asdoc style comments?
  10. Are default actions or values recoded? Defaults are tacitly understood by competent programmers. Code and documentation should be written with the assumption that readers will be technically competent.
  11. Is encapsulation violated because most methods are public?
  12. Are there syntax errors?

For Adobe Flex programmers I also look for:

  1. Is there proper usage of the Flex component life cycle?
  2. Is there a heavy dependence on binding?
  3. Are events used properly?
  4. Are heavyweight Halo containers used, when Spark Groups would suffice?
  5. Is all logic in a controller, or is it shoved into views (or worse, item renderers)?
  6. 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 of the 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?


Contact Mike Slinn

Unless you are a recruiter, in which case you should not try to make contact!

  • Email
  • Direct: 514-418-0156
  • Mobile: 650-678-2285

Disclaimer

The content on this web site is provided for general information purposes only and does not constitute legal or other professional advice or an opinion of any kind. Users of this web site are advised to seek specific legal advice by contacting their own legal counsel regarding any specific legal issues. Michael Slinn does not warrant or guarantee the quality, accuracy or completeness of any information on this web site. The articles published on this web site are current as of their original date of publication, but should not be relied upon as accurate, timely or fit for any particular purpose.

Accessing or using this web site does not create a client relationship. Although your use of the web site may facilitate access to or communications with Michael Slinn via e-mail or otherwise via the web site, receipt of any such communications or transmissions does not create a client relationship. Michael Slinn does not guarantee the security or confidentiality of any communications made by e-mail or otherwise through this web site.

This web site may contain links to third party web sites. Monitoring the vast information disseminated and accessible through those links is beyond Michael Slinn's resources and he does not attempt to do so. Links are provided for convenience only and Michael Slinn does not endorse the information contained in linked web sites nor guarantee its accuracy, timeliness or fitness for a particular purpose.


comments powered by Disqus

© 1976-2020, Michael Slinn. All rights reserved.