Book Review: Heads You Win

Solving a programming exercise

One of the practices that we follow to select an intern (in fact, even developers) in our start-up is to administer a programming exercise.  It is a fairly simple problem, sent over email and the candidate has a week to solve it in a programming language of his/her choice.

Besides the fact that the program has to work, there are two additional criteria that are specified

  •  it should meet coding standards 
  •  it should have unit tests
These are not elaborated, allowing the candidate to figure out and do what he/she feels is appropriate.

Here are the kind of responses that we have got.

Word document: Some of the candidates sent across programs in Word format.  I believe this could be the effect of writing programs as part of their exam papers. (Write a program to illustrate the "for" loop, for example)   The exercise to copy the content from the Word format to a text format and compile and get it to work was left to us.

Netbeans project:  Another set of candidates sent across a zip file which contained a Netbeans project which solved the problem.  Perhaps the idea was to illustrate the fact that these candidates used an IDE for programming.  Yeah, these were those who tried to solve the problem in java.  That we need to download, install and then import the project in Netbeans to see if the program worked is not something that the candidates worried about.

C programs that used conio.h (and/or similar libraries):  Yes, it is good to "clrscr()"  (clear the screen), but seriously was that the problem that we wanted to solve?  Should the C program not compile on my system (which could be Windows, linux or Mac)?  Well!  We did not specify it, did we?  It (possibly) did compile on the candidates' system (using the IDE/compiler that they were developing it on).

Program with no instructions on how to compile:  How do we know if it is a C program or a C++ program - especially when the program file did not have an extension or was a Word document?  Look for the header files or syntax and use a suitable compiler - an exercise left to us.  No information on what programming language used.

Once we went past these and got the programs to work, then we came to more interesting things.

Our problem said, "the program should take 3 arguments and do some operation".

Not one program that we received contained the code to take three arguments - whether from command-line or otherwise.  But most of them had code which displayed a message, asked for a value, displayed another message, asked for another value and so on... using printf/scanf or equivalent in C++/java.  And then there was a program in php, which would only run as a web application since the parameters had to be entered through the web page!  Evidently, the programmer (by the way, we hired him), did not know (or did not care about the fact that) php could be used to do standalone programs as well!

Once we looked beyond this, we could see programs that did not work for some use cases.  When pointed out, some of the candidates were quick to send across a "bug fix".  It appeared as if it was our responsibility to identify defects.

So, what about code quality and unit testing.  Let us start with code quality - across languages
  • Class names in small cases ("roman", "convert")
  • Not so meaningful method names - convert1, convert2
  • Not so meaningful variable names - i, j, c, st
  • Exception with empty catch block
  • Lack of indentation
  • Inconsistent location of curly braces
  • Missing curly braces for single statements
I could go on...

As for unit testing, out of about 15 applicants who applied for "internship", one person attempted to write a junit class.  Two-three sent a word/excel document with test cases that they thought were relevant for the program.

The takeaway from the exercise is as follows:
  • The focus in College curriculum is just on programming language syntax - how to get output for a given problem
  • There is no emphasis on code quality - anything that works is acceptable
  • Unit testing is unheard of - perhaps a theoretical section in software engineering
  • Software design is again only theory
The sad thing is, this pretty much extends to the software industry as well, where very few companies go beyond getting a program to work, preferably in the shortest possible time.  It is another issue that double that time is spent on fixing bugs - possibly a good revenue model as maintenance contract.