Hiring Programming Staff (Part 2)

Note: this article is split into two parts due to its length. The two segments are related, but each can be taken as a stand-alone article. Part 1 deals with phone interviews, part 2 focuses on testing.

The Programming Test

The ability to hire good programmers isn’t a skill generally associated with a project manager, but if a project manager isn’t sourcing coders, who is? It’s likely that it will be senior management or HR. Senior management should definitely be involved in the selection process, but hiring new programmers is best done in conjunction with someone coming from a technical background.

So what is the key to finding that great programmer? Testing. Giving a candidate a written programming test is the only true measure of their capabilities. The main things to look for are competence in the languages you develop in, be it .NET, PHP, Java or whatever. In addition, logical and deduction skills are a must.

If I was asked to give my opinion on what the single most important attribute of a good programmer is, I wouldn’t be able to answer. That is because its a minimum of two qualities. They are; ‘is smart’ and ‘gets things done’ (see The Guerrilla Guide to Interviewing by Joel Spolsky). Of course, there are many other favorable qualities to look for when adding to your technical team, traits such as: attitude, communication skills, how well they fit into your office culture, etc. But if you don’t have both ‘smart’ and ‘gets things done’, all bets are off.

What does ‘smart’ and ‘gets things done’ mean? I will try and explain what these traits mean by presenting two fictitious examples:

Tony is a university graduate who loves to talk technology. He spends a couple of hours each day chatting with the other programmers about how AJAX is going to bridge the gap between traditional desktop applications and the limitations of the web. There is no doubt Tony is a smart guy, but if he’s spending so much time theorizing about technology rather then doing it, not much is going to get done (i.e. he is smart but does not get things done).

Sarah is a dedicated programmer who appears to be a model team member. But after a number of project postmortems, it becomes apparent that approximately 50% of all bugs are attributable to her (this is out of a team of 5 programmers). This taken together with other anecdotal evidence points to a pattern; Sarah is lacking the fundamental skills required by a programmer. She is ‘getting things done’, but the quality of her output is very low.

Now onto the test. It shouldn’t be too long, about 5-6 pages at most. It shouldn’t take a candidate more then an hour to complete. The questions are divided into a number of categories: logic, programming, SQL, JavaScript, XHTML/CSS, and people skills.



Logic questions - these questions set out to test a candidate’s reasoning and logical deduction faculties. Some would say that these are the most important questions in the test because they are a strong reflection of a person’s capability to think in an abstract manner (and therefore tackle any kind of programming or technology problem thrown at them). I even know someone who immediately terminates the interview if the candidate fails these questions. An example question would be: “if I asked you to build me a house, how would you go about doing this?”. A correct answer for this would be along these lines: “I would begin by ascertaining who the house is for, what sort of budget is available, if their are any time or material constraints. Once that is done, I would organize the contracted labor to undertake the work, ensure proper planning permits are obtained, ...”. What you are trying to gauge is if a person is thinking the problem through in a systematic sequential manner. Other questions could be: “How many petrol stations does the city of Melbourne require?” or “How much does the Golden Gate bridge weigh?” With these questions, there isn’t really a correct figure, the point is how did the person derive the figure, and what logical process did they use to get there?

Programming questions - these questions will be specific to the development environment you use, but an example would be; “Using .NET/C#, write a function to find out how many words are in a sentence”. The coding questions shouldn’t be overly hard as many programmers are reliant on reference material. A candidate’s response to such a question will make it clear whether they have used that language or not. Another good question is to present a slab of code which has a bunch of bugs in it, then ask the candidate to locate the bugs. These questions are where you will spot the above average programmers; where one programmer writes 10 lines of code to do something, another writes a one line regular expression or uses recursion (obviously the better choice). You would also be on the look out for error-checking and optimization.

SQL – I don’t believe you need to ask a super complex SQL question involving inner joins or embedded SELECT statements (especially since many IDEs generate SQL these days). The point is to determine whether they understand the basics of SQL. A question like this would suffice: “write a SQL query to return the surnames of all the people under the age of 30 shown in the above table. Ensure the results are ordered alphabetically.”

JavaScript - you want to check for a basic understanding of JavaScript. A simple question such as this will be fine: “Write JavaScript code to check that a user has entered a value for the Username and Password fields. If not, present an error message to the user”. Again, it will be very obvious if the candidate has never used JavaScript before.

HTML/CSS - you need to determine that a person has a fair understanding of HTML and CSS. I would do this by presenting a few short snippets of unrelated HTML/CSS code. I would ask the candidate to say what each snippet does and also to correct or improve each one if needed. For instance; a basic image tag with no alt attribute (nb. the alt tag is required).

People skills - the question I generally go for is this: “You’re the only one in the office when a client you’ve never dealt with rings. They say in an aggressive tone; ‘my website is down, I was told all the problems with it were fixed, what the hell is wrong with you people?’ Considering you know nothing about their project, what would you say to them?” A good answer would include these key statements: allow the client to vent, apologize for the inconvenience, empathize, tell them you will look into it immediately and call them back in a half hour, etc. Having a candidate answer well on this question is really just a bonus. Personally, I would still take a candidate with superior programming skills over someone who has good ‘soft skills’ (after all, coding is what you need done). But this may be a distinguishing factor if you have evenly matched candidates. You never know when you may have to send a programmer out on site or have them gather requirements from a client.

One thing to look for is how well a candidate has followed instructions, have they read the question properly? Have they answered it exactly or did they get off track? Obviously a person’s ability to read and follow written instructions accurately would be a tremendous asset at any organization.

I have come across a few other ideas for improving your chances of nabbing a great programmer. Personally, I have not tried all of these approaches, but they do seem like sound pieces of advice. One suggestion is to look for programmers who do coding on open source software.

A person’s involvement in the open source community is a reflection of their commitment to the computing industry (i.e. they don’t just code for the money). Obviously, you would want to investigate what their contribution is; for instance, if you were especially looking for a UI designer, then UI design is what they should be doing on the open-source project.



Another approach is a trial period, where you bring a programmer on-board to do a small segment of coding on a project, for perhaps 24-48 hours. I doubt they would make much of a contribution to the overall progress of the project in such a short space of time, and in fact would probably reduce productivity because of the hand-holding required, but what it will reveal is how they interact with other team members.

Project Status Reports Everyone Can Understand

Creating basic highlight reports which clients and management can comprehend.

Letting people know how a project is coming along is obviously a key responsibility of any project manager. With so many methodologies to choose from these days, it becomes hard to determine which key pieces of information will be useful to those involved in the project. These methodologies often come with a tangled mass of cryptic terminology, often only recognizable to practitioners of the system (e.g. burn down chart, sprint backlog, concession, story points, etc).

Let’s say for instance your client is in the food transport business and is getting your company to build them an ERP application. Chances are they wont understand concepts from Agile or PRINCE2, and why should they, they are in a totally different industry.

The issue then becomes; what information do you present when creating a status report that will be useful to the broadest audience (e.g. client, senior management, non-technical user advocates, etc). The project information maintained internally for planning and day-to-day management is one thing, but what gets shown to non-technical stake-holders is something entirely different. Of course, the details going into progress reports will most likely be derived from the project tracking documentation (e.g. number of bugs held in the issue log, tasks remaining as shown by the project schedule, etc).

So what kind of information will a non-technical audience understand? The simple answer is percentages and bullet points in plain English (with no methodology specific jargon).

Here is an example of a Project Status Report (or Highlight Report as its known in PRINCE2). I send these to clients and senior management via email on a weekly basis (generally on Friday afternoon):

Hi Tom,

I wanted to provide you with a brief summary on how your project is progressing:

• Your project is currently 65% complete.
• 100% of all tasks in the design phase have been completed.
• 70% of the tasks in the coding phase are finished.
• The project management phase is 45% complete.
• The quality control phase is 10% complete so far.
• 35% of auxiliary tasks have been completed

Our bug log is currently tracking 3 unresolved bugs (1 of which is marked as high priority). The bug log also holds 3 feature additions pending approval.

We have just uploaded the latest work to our staging server for you to review (this can be viewed by following this link: http://www...).

The next thing we are planning to work on is the photo gallery component, we are aiming to have this completed by late next week (12/Dec).

We are still waiting to receive media release articles from your PR person. Without these, your site will launch and this section will be blank (or have to be hidden initially).

Let me know if you have any questions, I will be happy to answer them as best I can.

- LM

The email subject would be something like ‘RE: Blue Widgets, Project Status Report’.

The structure of the report is as follows:

Bullet points - the first bullet point is always a percentage saying how much of the overall project has been completed. The remaining bullet points give a percentage completion on the various phases of the project (you may have different naming conventions, but that’s OK). Will the client really analyze these figures closely and go “yeah, yeah, auxiliary tasks, 35% complete, awesome”? Probably not. So what’s the point of listing all these stats then? It’s more about the effect it will have, it will give people the feeling that you have your finger on the pulse of the project, that you know exactly where it’s at. This translates into confidence that the project is being managed in a predictable fashion.

Bug summary - a very brief run-down of where you are at with logged issues. You may want to include some information on how many bugs were closed this week, or how many feature additions are waiting approval. This demonstrates that you are dealing with the inevitable issues that will arise on the project in a systematic fashion. I should make a point regarding the discussion of bugs with clients; there are different levels of disclosure senior managers find acceptable. Personally, I like to be very open with this information, but I suggest you ask management about how much ‘bad stuff’ you are allowed to reveal to the clients.

What we’ve just done - a description of any major movement made on the project since the last update. This could be the addition of a new module, completion of a documented milestone, anything which says “we are really getting places now”.

What we are planning on doing next - this is pretty straight-forward, but is helpful because it gives the client (and management) a heads-up on what you are about to start working on. The client may suddenly say “we thought you were doing the billing module next?” or “we need to change that around, we prefer you work on... next”.

Any problems that occurred or may occur in the immediate future - this doesn’t necessarily have to be a gripe or panic zone, who knows, maybe your project is running 100% smoothly (unlikely, but you may be the first). This area can be used to give the client a polite nudge (e.g. “we need ... from you, or else this will happen”). Again, caution should be exercised about what ‘bad stuff’ senior management allows you to disclose to the client.

Also notice that the statements in the report are very brief, to the point, no longer then two sentences. This just comes down to being respectful of peoples time. Everyone in corporate life is very busy, no one wants to read long emails.



The format of the status report I have presented here is very basic. I wouldn’t suggest that Gnatt or Burn-down charts aren’t useful, just that the information contained within these or any other management tool needs to be converted to plain English before being given to clients.

Outsourcing Coding vs Building an In-house Team

Perspectives on using outsourced programmers in a web development environment

A few years ago I was in Bali for a fitness bootcamp. Whilst watching TV late one night, I came across a documentary on the construction of an underground railway system in Amsterdam. I vividly recall one of the engineers being interviewed saying “it’s impossible, but we’re going to do it anyway”. When I think of some aspects of outsourcing, I remember this statement because there definitely are some tough challenges in getting outsourcing to work, but I believe it can be done.

I should begin by saying that by no means am I an authority on working with outsourced programmers, in fact, I’ve only done it for a few months total. My brief experience with outsourcing revealed both good and bad aspects of the approach, but more importantly, it opened my mind to the possibilities. I have noticed that some people seem to be against outsourcing for personal reasons, and that is surely their prerogative.

In some ways this article is a retort to a piece on outsourcing I recently read. The article in question is by Michael Bean and is titled The Pitfalls of Outsourcing Programmers. It is one of the selected works gathered together in the book The Best Software Writing I – Selected & Introduced by Joel Spolsky.



Am I attacking what the author had to say in the article? No way, it’s very well written and full of insightful information. Some knowledge of what the article is about is required in order to understand my perspective on the matter. I don’t want to re-write the article, so I will just cover the main points very quickly.

Michael Bean discusses the following ideas:

There has been a rush in recent years for US companies to send development tasks to India, China, and Eastern Europe.

Software development is design not manufacturing. Therefore, by virtue of its creative nature, it’s not something which should be sent off-shore.

People pay for ‘value added’ services or products. If all aspects of a company’s offering (from production to customer service) are outsourced, they cannot give customers what they truly desire.

Outsourcing customer service is equivalent to saying you aren’t interested in hearing what you’re clientele have to say.

The motivation behind setting up a massive IT work force overseas goes like this; “if Nike can do it with shoes, we can do it with code”.

The “but you are taking away jobs from Americans” argument is spurious at best, people in India or where-ever have just as much right to work as anyone else. We are living in a global economy after all.

When a business outsources innovation related task, they give away their competitive advantage. Over time, a company will lose their capacity to innovate.

Innovation suffers when people are spread across different countries since they can’t communicate effectively.

Outsourced programmers aren’t around for the long term. They tend to disappear after the project is over, taking with them any specialist knowledge they have acquired.

Completely outsourcing all of your development is a bad idea (i.e. both design and coding of the software).

The difference between United States and Indian time zones means there is no overlap between their working hours. This makes communication even more difficult.

Creating software is more about design then assembly. The ability to design is also considered an uncommon skill.

This is basically the crux of Michael Bean’s article. I’ve done my best to retain his core ideas, but obviously there is the risk of misinterpretation.



I have to agree that it is undesirable to outsource everything (i.e. both design and coding). In Michael Bean’s article, he doesn’t really go into what he means by design. To me, design means the functional specification (i.e. how the software will work from the user’s point of view).

Would I trust an outsourcer to write a functional specification? No. This is not meant as an attack on the skill of overseas programmers, it’s just unreasonable to think you could get a remotely accurate spec without meeting a client face-to-face. Would I trust outsourced programmers to create software based on one of my specs? Yes, definitely.

The other problematic aspect of Michael Bean’s article is that it doesn’t explicitly mention a division between shrink-wrapped software development and custom software projects. This is a major consideration. If you are trying to minimize production costs, then outsourced programmers are very well suited to custom development (and yes, maintenance is a big issue, but it’s a big issue with normal companies anyway). Reducing operational costs may be a very real concern if your business has investors or venture capital.

There are strategies for having outsourced programmers work on shrink-wrapped software, for instance; some Indian companies offer dedicated teams that only work on your software, they even come complete with their own dedicated project manager.

It’s true, you’re communication will take a hit, that is unavoidable. But you don’t get something for nothing. If you want to produce software for 50% of the normal cost, then be prepared to put up with some discomfort.

Luckily, in Australia we don’t suffer from the same time zone issues our American friends have to endure. In my experience with Indian programmers, I found they began to stir at about 12 noon, that’s just fine as far as I’m concerned.

Communication and project management tools are very important for successfully working with outsourced programmers. MSN or other instant messaging software is the key. I remember having three different IM softwares running on my computer at one point in order to keep in touch with everyone on my projects. A project management tool like Basecamp is also very helpful. A bug tracking system is another great idea, and an online schedule that can be viewed by everyone will make life a lot easier.

Perhaps this is a little simplistic, but it seems to boil down to this: outsourcing results in cheaper software development, but in-house teams produce better quality software.