| Home > The Craft of Computer Programming > 3: Managing Software Developers | Site Map | Last updated: 10th March 2010 |
A team is a group of people working co-operatively toward a common goal. This may be a project, a department, a company or, in the case of defining standards for example, the entire IT industry. Unfortunately, it is often the case that only the smallest groups - projects - work as teams to even a limited degree. Mankind’s instinct to band together in tribes tends to lead to feelings of “them and us” when it comes to inter-project, inter-department and inter-company relationships. Project A workers feel that their project is superior to Project B, members of the engineering department feel that they contribute more than the sales department who do not produce anything, etc. Similar feelings can be observed amongst national, religious and even football tribes. In addition, managers often view themselves as further up the organizational hierarchy and, therefore, intellectually superior beings, in a team entirely separate from the developer staff. This leads too many organizations to regard programmers as production line workers - simply units of resource in a software factory - rather than full members of the enterprise team with a valuable contribution to make to the future of that enterprise. When this happens, we progress to the mentality where programmers are viewed solely as coders and any time spent not writing code is time wasted. Organizations don’t bother with reviews or relegate them to a rubber-stamping exercise. They spend a minimal amount of time on design because “the sooner we get coding the sooner we’ll finish the project”. This is potentially terminal short-termism.
Another problem is that many IT workers are not natural team players. A significant proportion of IT workers are attracted to IT because of their poor people skills. Human relationships are a balance of give and take and some people are better at managing this exchange than others; those who are more inclined to take than to give are attracted to computers because the computer requires no reciprocation. Programmers, in particular, enjoy a very one-sided relationship with computers because the computer will do anything they want, no matter how ridiculous, without ever questioning their judgement. Being team-orientated means putting aside your own goals and working in pursuit of those of the team, but many programmers have great difficulty in doing this. While I do not claim, by any means, that all software developers are self-centred egotists, the fact is that too many are, and in organisations where many managers and marketeers are also ex-programmers this inhibits the development of a team-orientated culture.
Because very few IT enterprises succeed in the long term. Although computer technology has not fundamentally changed for several decades, the exponential rise in processor speed and storage capacity mean that software becomes out-of-date very quickly. All IT organizations must adapt or die. Working together allows people to perform better since they can benefit from each other’s knowledge and experience. Organizations must also be able to capture and utilise all good ideas generated within them, whatever their origin. They cannot do this if they foster a “them and us” culture between sections of their staff - it is important for everyone to recognise that they are all on the same team and looking to achieve the same goal, i.e. the success of their enterprise. The more skilled an organization’s staff the quicker it can react to technological development and new customer demands. For example, code reviews are a valuable way to improve the skill of less capable staff and to reduce the amount of time wasted debugging software, but most organizations think that they cannot afford the time for them. I say that, in the long term, you cannot afford to do without them - every organization needs skilled staff. And the design phase should be as detailed as possible because an issue identified and eliminated at design time saves much more effort at test time - truly a stitch in time saving nine. So any individualistic culture that discourages developers from engaging in these activities is contributing to its own demise.
One way to start to achieve this is to get people talking to each other. Create a forum that can act as a suggestions box to capture ideas from anyone in the organization. Subject all ideas to equal rigour by allowing anyone to critique anyone else’s ideas and thereby remove the usual correlation between the value of an idea and the organizational status of its originator. Recognising that no-one has a monopoly on good ideas and creating a level playing field fosters a culture of everyone feeling that they are equal members of the enterprise team. Some people will be reluctant to stick their head over the parapet so institute regular one-to-one meetings between team managers and members for the discussion of their future work to ensure the widest possible involvement. It may be necessary to have the forum moderated to prevent it being hijacked by a vocal minority. The moderator should ensure that good practice is observed when proposing ideas by only accepting submissions which are balanced and objective. This means that the proposer should have demonstrated that they have identified alternatives to their suggestion and given a reasoned evaluation of the pros and cons of each option before selecting their preferred solution. Submissions that do not fulfil these criteria should be returned for reworking until they conform to good practice. Managers must be willing to see beyond vested interest and consider all the ideas thrown up by the forum, whatever their source. Many people favour their own ideas no matter what which is why it is important to have an open discussion with as wide an involvement as possible since this will identify all the arguments for and against. When considering which ideas to adopt I would recommend noting the following:
Bad reasons for dismissing good ideas:
Good reasons for dismissing bad ideas:
Another way to encourage the right sort of culture is to make the effort to measure what people contribute to their organization rather than just what they cost. It is said that most companies are run by accountants and that an accountant is someone who knows the cost of everything and the value of nothing. Sadly, I have found that, by and large, this tends to be the case and it leads to staff being regarded as a liability to be minimized when it would be a lot more constructive to regard them as an asset to be maximized. People feel a lot more valued if their employer regards them as an asset and are much more motivated to increase their worth than to reduce their cost. At an individual level, measuring value is easy for salespeople for example (you can measure how much product they have sold each month), but harder for programmers. You cannot simply measure how many lines of code that they write because a skilled programmer will implement the same functionality in half the number as an unskilled one. In my experience, one useful measure is the difference between the number of errors (incorrectly known as bugs) that they fix and the number that they create. This is a measure of problems solved minus problems created and the more positive the difference the better. And helping someone else fix a problem that they are having should count as a point to the helper. It is also worth mentioning at this point, one traditional measure which generally turns out to be a rather poor yardstick. In practice there seems to be very little correlation between the actual value of someone’s contribution and the lateness of the hour to which they are willing to stay in the office of an evening. Writing accurate, reliable software requires considerable concentration and I have never met anyone who could keep up the required level regularly for more than the contractual six or seven hours a day. When people try, they invariably make so many extra mistakes that the exercise is rendered counter-productive, so any programmer who regularly stays late in the evening probably isn’t doing very much with their time during the day.
At a departmental level, measuring contribution can also help in creating more positive relationships. The classic example of this is where organizations claim that they run their engineering and sales departments as profit centres, but expect the engineering department to hand over the products which they produce for nothing. This creates a very negative environment as it effectively says that what they are doing is of no value. If the sales department were distributing third party products they would have to pay for them; their relationship with their in-house supplier should be exactly the same. Similarly, the engineering department should be free to sell its wares through third-party distributors. Otherwise you get the situation where engineering can never be profitable; sales are viewed as generating all the revenue and engineering just spending it all. If this were true however, it would make sense to make all the engineering department redundant, but this would obviously kill the business as it would have no products to sell. So the solution to this problem is to adopt an accounting model which fairly reflects the contribution of each department. This also helps to focus minds when it comes to “specials” - if sales have to pay for any special features which they want for a particular customer, they are more inclined to consider whether the extra work can be justified by the potential extra product sales.
Measuring people’s contribution can also help create a more positive culture at the strategic level. I have been through many cost-cutting drives, but never through an asset-maximization drive ! Doing more at the same cost is, if anything, more constructive then doing the same at less cost. An example of this would be in utility companies customer service. In the utility companies I have worked for and been a customer of, the customer service IT systems have been very fragmented with many separate small teams each dealing with only one aspect of the customer relationship. On many occasions I have been passed from one team to another, talking to perhaps three or four different people before finding the person who can deal with my query. Why not reduce the time wasted in making customers repeat their queries to four different people and train all customer service staff to deal with all customer queries ? This makes their job less monotonous and empowers them to take responsibility for customer problems from start to finish thereby reducing errors and subsequent complaints. This would improve the quality and efficiency of the organization’s customer service and, thereby, save money.
A team-orientated culture is something that has to be created in an organisation from the top down. Team objectives, at all levels, must be clear and well-publicised as it should be these which drive the efforts of the team members. It is also important for all members of staff to feel involved in their enterprise - if you want people to put aside their own goals for the benefit of the teams to which they belong, you must make them feel a valued member of those teams. The leaders of an organization must lay down public guidelines defining all roles within their organization and ensure that these are followed. As well as defining everyone’s responsibilities, these guidelines need to define how teams interact. This should include how people should be involved in decision making and training. Obviously, consultation on these guidelines should be as wide as possible ! The guidelines for managers need to make it clear that management is an active role; it is not good enough just to preserve the status quo or run a happy ship - making no decision at all should be considered more serious than making the wrong decision. The training guidelines should not only include measures for things like allocating time to developer peer review, but also, for example, regular marketing presentations to keep developers up-to-date with customer issues.
One further issue which can affect the corporate culture is the bonus scheme, common in product companies. Usually it is fairly insignificant in value for software developers, but if it made a more significant proportion of developers’ remuneration it could help to keep them more customer focussed, particularly if it were proportional to company sales. It also helps to remind them that everyone is dependant on the success of the company and thereby encourages the view that everyone is a member of the enterprise team. This helps to counter the commonly found “them and us” attitude between engineering and sales departments: I have always found resistance to having a sales based engineering bonus on the grounds that “we don’t want our bonus dependant on incompetent salespeople”. It is only fair, however, since the salespeople’s commission is highly dependant on the quality of the products they are given to sell by the engineering department.
The role of the developer is to fulfil their team’s goals, so primarily, they need to accept that their job is to create saleable product. Obviously, in order to do this they need to be able to write software, but, more than that, it needs to be concise, accurate and reliable software. In the same way that it requires more than fluency in English to make someone a successful novelist, the software developer must be able to do more than just write syntactically correct statements in a computer language. They need to be able to analyse tasks and express ideas rationally and concisely - both language-independent skills - and so these should be evident in their native language as well as C++ (or whatever the language du jour happens to be). Thus they will also be able to document the systems which they write in a way which minimizes the learning curve for other developers starting work on them. Developers, like everyone else, should always be open to improving their skill level, including in-house from peer review. And by skill I do not mean the recruitment consultant’s interpretation of the word, i.e. knowledge of a particular product, but the ability to apply that knowledge.
Further to this, however, we should remember that developers are not just members of their immediate project team, but of teams at many levels throughout their enterprise. This means that they should have goals set at many levels as well, so, at the very least, developers should be required to remain aware of the possibilities that the technological advances in computer speed and storage capacity bring. They should be able to generate ideas for new functionality in the systems which they create. And, in order for these ideas to be useful, the software developer needs to remain commercially aware and understand the customer problems that their organization is trying to solve.
The role of managers is two-fold. They are responsible for making the decisions which get the team to its goal, but also for ensuring that the people charged with implementing those decisions have the resources they need to do so. To do their job properly, developers need an open and rational decision making process in a genuinely team-orientated culture. For the decision making process to be rational requires that managers consult as widely as possible and not be afraid to impose decisions once they have listened to the arguments for and against the options given to them. Sadly, human frailties tend to obstruct both of these things. Many managers are afraid of making decisions for fear of the consequences if they get them wrong. They do not like options because this gives them more chances of failure, so they often consult as narrowly as possible. When they do consult more widely, they will try to obtain a consensus view, which invariably eliminates any chance of radical change, snuffing out all dynamism in the organisation, as well as yielding the intended result of limiting the options. There is nothing wrong with imposing a decision that not everyone agrees with, provided there has been a rational evaluation of all the options first.
Having made your decision, it is then important that the people assigned with implementing it have clear objectives given to them, so I recommend that you observe the SMART rule. This means ensuring that the tasks assigned are:
Specific - avoid vague tasks like “improve component X”, which makes presumptions about the quality of component X, and instead make the task more detailed such as “review component X with a view to identifying and correcting any deficiencies”.
Measurable - specify in advance the criteria which will be used to determine successful or unsuccessful completion of the task.
Achievable - make sure the task can actually be completed ! It is a good idea to break down any large, long-term tasks into smaller steps so that progress can be measured more easily.
Relevant - avoid making up tasks just to fill up someone’s task list. If they do not have any real tasks, reassign them to another project; don’t make work for its own sake.
Time-related - always specify a timescale for a task; if you cannot see how to do so for a particular task then it needs to be re-specified in such a way that you can.
These rules may seem like common sense, but it is surprising how much thought needs to go into task specification in order to satisfy them all.
Principally the personalities of the people involved. As discussed already, many people in IT are not natural team players. Some of the general problems I have noticed during my career are as follows:
One True Way Syndrome (OTWS) - sufferers get carried away with the first idea which comes into their head and refuse to consider any alternatives. They see a way of processing typical case input which looks elegant to them and regard all less frequently occurring input cases as minor detail which can be dealt with later. Unfortunately this is not the case and their “elegant” solution falls down when they try to incorporate those “details” leading to repeated reworking of the solution which can cause lengthy delays to a project. Sadly, many managers love OTWS sufferers as the lack of options presented to them gives them no decision to make and cuts down on the time “wasted” in consultation. They regard them as “bringing solutions not problems“.
The Spade Analysis - if you show a group of programmers a spade, only about 20% will see a spade. 60% will see a shovel and the other 20% will see a “manual excavation implement”. A vocal minority like to see everything as new and different whereas, in reality, most concepts in IT are simply variations on a traditional theme. There is a strong tendency amongst programmers to see the differences between systems rather than the similarities which leads to over-complicated solutions. Often managers like what they hear from this minority as they give the impression that they are offering more than they really are.
The Cake Analogy - to bake a cake successfully, you need to follow the cooking instructions. You can cook a cake at double the temperature for half the time on the grounds that you are applying the same amount of heat resource, but you won’t get the desired result. IT projects are similar; doubling the number of workers will not usually get the job done in half the time. The difference is that IT projects are never repeated - they are all different and so there are no pre-established cooking instructions because you are always working to a new recipe. It is therefore up to the IT “baker” to use his skill and experience to judge the optimum resource level for each project. However, this does not stop clients or managers from trying to get the job done quicker than the optimum resource level will allow. When this happens, it is rare for any significant amount of time to be knocked off the project delivery - it simply increases costs and reduces the quality of the end product.
Management Supremacy - in many IT organisations, the management are mostly ex-programmers and regard their higher position in the organisational hierarchy as proof that they are better programmers than their staff. This is rarely the case, though, as developers who are good at their job usually desire to remain doing what they are good at and don’t seek to climb the greasy pole; it is those who find programming difficult who seek to move out of the development arena. In order to avoid the situation where IT managers regard themselves as having a monopoly on good ideas and don’t consult their developers, it is necessary to create an alternate, technical, career path for developers to follow with senior developers, rather than junior managers, being given technical authority on projects.
OTWS can be dealt with fairly effectively by ensuring rigorous consultation - OTWS sufferers inevitably produce incomplete solutions and this should be flagged when the proposal is reviewed. However, this presumes that the proposal is in writing and the reviewers are given a reasonable length of time to examine it. You must avoid the situation which frequently occurs where proposals are presented verbally at the meeting called to decide between them. The “manual excavation implement” problem requires the leaders of an organization to encourage a culture which institutes the “KISS” rule - keep it simple stupid ! Then this problem will also be picked up at review. Identifying optimum resource levels is much more difficult. Everyone on the project will have their own view and there is no way of knowing what would have happened had you done things differently so it is not possible to tell who was right. All you can do is conduct a thorough review of each project on completion in order to identify problems so that you can avoid repeating any mistakes.
In addition to these general problems I have observed that most programmers fall into one of the following personality categories:
The Religious Fundamentalist - mercifully rare, this type of programmer is the extreme case of OTW syndrome. He has opinions on everything and spends far too much of his time trying to convert his colleagues to his view. He has no commercial awareness due to his inability to see anyone else’s point of view and is completely impervious to reasoned argument. He is convinced that he is the world’s best programmer, but actually produces highly verbose and unreliable code. He demoralizes his colleagues with his attempts to monopolize meetings with his irrational pontifications and the amount of effort required from other people to fix his work. The religious fundamentalist is beyond redemption and should be removed from the organization at the earliest available opportunity.
The Demolition Expert - also mercifully rare, the demolition expert is a more intelligent and less extreme form of the religious fundamentalist. He is basically a control freak who uses his quick mind to pick holes in other people’s ideas in order to get his own way on all technical issues without ever having to put forward any positive arguments in support of his own ideas. In other words he uses the “last man standing” approach to getting his own way which works if he is allowed to get away with it, i.e. if other people are not given the time they need to subject his ideas to the same scrutiny as he subjects theirs. Whereas the true religious fundamentalist is incapable of moderating his views no matter who he is dealing with, the demolition expert knows he has to keep the boss sweet in order to get his ideas adopted and will happily suck up to him by heaping praise on his ideas whether he agrees with them or not. Although he can be good at fixing errors, the demolition expert’s own work is not usually of very high quality. The demolition expert needs strong management in order to force him to use his mind more constructively and avoid demoralizing his colleagues with his constant sniping at their work.
The Artist - has encyclopaedic product knowledge of his own areas being intimately familiar with every detail of the technology which he uses, but usually has little commercial awareness. He is more interested in writing the most concise, “beautiful” code without consideration of customer requirements. The artist is a very useful resource when it comes to reviewing code and giving technical training to others, but not much use when it comes to analysing customer requirements or designing products.
The Serf - has no interest in sticking his head over the parapet and just gets on with his work without making a fuss. Gets the job done efficiently without being noticed and is, consequently, a much undervalued member of the team. Needs recognition and encouragement from management to make full use of his skills for the benefit of the organization.
The Craftsman - is a genuinely skilled technician able to fix any problem, including those which defeat others, and, while perfectly willing to seek help when he needs it, does not expect other people to fix his mistakes. The craftsman is someone for whom getting a computer to do what they want does not present a major challenge and who understands that their job is to make end-users’ tasks easier. He understands people as well as technology and can express ideas concisely and accurately. He has an eye for detail and does not ignore awkward input cases when analysing tasks which allows him to produce reliable and complete solutions quickly. The craftsman’s methodical approach means that he cannot give instant answers and so must be allowed time by management to do a thorough job when it comes to proposing new ideas or reviewing other people’s.
The Journeyman - one of the more common types of programmer, the journeyman knows he is not particularly skilled at his job, but, with help from more skilled colleagues, gets it done in a reasonable time. He does not usually have any strong opinions to express or vested interests to pursue and is often happy to leave having ideas to other people. The journeyman often views his job as a stepping stone on the way into team leadership. He needs encouragement from management to develop his skill level through training.
The Hobbyist - another common type of programmer, the hobbyist feels that he should be allowed to indulge his desire to have a constant stream of new “toys” to play with, unencumbered by the commercial reality that his employer has to make money. Frequently a sufferer of OTW syndrome and prone to seeing manual excavation implements, he can only be bothered with “interesting” new work and finds it very difficult to knuckle down to the detail of finishing off what he starts. He relies on more skilled colleagues to fix the difficult errors in his work. He regards things like documentation and testing as “boring” and, consequently, is not very conscientious about them. Left to his own devices the hobbyist can become very arrogant and unproductive, believing that the details of finishing the job are beneath him. He needs guidance from management to keep him focussed on the job at hand and to remind him of what he is paid for.
Obviously, in addition to the above, there are some programmers who simply do not have the aptitude for the job and will never be able to deliver quality end product no matter how much help they are given. These people are the ones who would be weeded out by a mandatory professional qualification and they need to be encouraged to look for another career.
Meetings can be used to involve people in the decision-making process. However, this is only the case when they are used sensibly: a meeting must have a well-defined purpose and be called sufficiently in advance to allow appropriate preparation. It is a common mistake to call a meeting “to discuss ...” when what is really required is to make a decision. Discussion is a means to an end rather than an end in itself and does not therefore constitute a purpose to the meeting. In fact, the discussion is part of the preparation for the meeting; it is how you evaluate the options to be decided upon. It is, therefore, the results of that discussion that should be presented at the meeting in order to allow the responsible party to make the decision. When someone calls a meeting “to discuss ...” it is because they are expecting too much from it; they are expecting to identify and evaluate the options as well as make the decision between them, all in one go. It is simply not possible to do this and such meetings usually end up with everyone in disagreement and nothing resolved. Another common scenario is the rubber stamp meeting. This is where only one person has been advised of the true purpose of the meeting and so only one option gets presented. This is just another way for the decision-maker to avoid having to make a decision: honour is satisfied in that a meeting has taken place, but in practice no-one was in a position to challenge the decision-maker’s preferred option. Good decision-making takes time and preparation: the question to be decided needs to be advertised to the relevant parties well in advance so that they can propose possible answers (the options) well before the meeting is held. These proposals should be in writing and be circulated amongst all meeting attendees for evaluation. Only then are you in a position to make the decision, but, as discussed previously, it is highly unlikely that the solution will simply emerge via a consensus (though you may achieve a majority view), so you need to recognise that there will still be a decision to make. Thus, the calling of a meeting should generally be accompanied by a timetable for the associated preparatory activities and the meeting then, is only the last stage of the decision-making process - most of the work needs to be done prior to it. You may even have to call a meeting to decide what the question is, since defining the problem is a large part of solving it.
IT practitioners like to think of themselves as professionals, but IT does not compare favourably with other genuine professions such as medicine or the law. Both of these fields require their practitioners to pass a mandatory degree-level qualification and serve several years post-graduate training, whereas anyone can call themselves a software developer. As previously discussed, software development is a skilled activity requiring much more than simply the ability to write syntactically correct statements in a computer programming language. Consequently I submit that there should be a mandatory qualification involving business process analysis, systems analysis and software architecture and design, as well as programming techniques. The problem is that many organizations are run by people who do not understand the level of skill involved in developing software. At the beginning of my career I was interviewed by a number of people who clearly regarded my computing degree with considerable suspicion because they could not see how it took three years just to learn a computer language. I was even told by one human resources representative from a leading software house that her company trained graduates with no previous IT experience to degree standard in two weeks. Only when the industry learns that there is a need for its staff to be properly qualified in all aspects of software development will IT become a true profession and start to avoid the huge number of failed projects which we see so regularly. Although I cannot see this happening in the near future, we can, however, offer the post-graduate part of the training to IT practitioners straight away.
I propose that all software development organizations offer a grading scheme for their staff leading to a consultant grade whose members would be responsible for supervising all those at a more junior level. This supervision would take the form of reviewing work (i.e. product proposals, designs, code, test plans) with a view to correcting errors, identifying omissions and suggesting simplifications and improvements. As on-screen reviews tend to quickly degenerate into a rubber-stamping exercise, reviews should be in writing. This gives the reviewer the chance to consider the work thoroughly and allows the results to be kept on file to help evaluate the reviewee’s performance at appraisal time. These activities should be expected to take around twenty percent of the consultant’s time. In order to qualify as a consultant I suggest that the practitioner’s own work must be of such a quality that it cannot be significantly improved by their own consultant and that they must be able to fix any error presented to them. In terms of how many errors they produce, the number should be very small and their standard of testing high enough that the number of errors in their released code should amount to an average of no more than one per year. This is the level at which the best programmers in the industry operate. Some people will take many years to reach this standard and a significant proportion will never achieve it, but it is important that those who are training others be skilled enough to do so. It is important that mangers recognise that programming needs to be undertaken by skilled specialists and that progression to consultant level should be a genuine alternative to the traditional route of moving into team-leadership and thence management, conferring equivalent status and rewards. This is directly analogous to the relationship between hospital consultants and managers.
When it comes to appraisal time and the possibility of career progression, as well as looking at the review records to assess a programmer’s performance, I suggest that the appraiser seeks feedback from the programmer’s colleagues. This should be mandatory and confidential, and in writing in order to encourage a considered opinion. If it is not mandatory many people will opt out so as to avoid “getting involved” and you will not get a balanced view. The purpose of this is to help assess how much help the programmer gives to his colleagues, how much help he receives from his colleagues and to identify how he could improve his performance. Technical career progression needs to be meritocratic if it is to be of value to the organization so constructive criticism is to be encouraged. While offering praise for successes, do not be afraid of the f-word (failure) as it is important that everyone in an organization recognizes that they have failings and the need to work to overcome them in the future. It is essential for the long-term health of any organization that its members learn from their mistakes and they cannot do this if they are encouraged to believe that they have succeeded when they have not.
Before answering this question let us review what skill actually is. In order to do this I offer the following definitions:
So skill is the ability to apply knowledge, not just the possession of that knowledge. It does not matter how much knowledge or experience someone has if they do not know how to use it to create saleable product. This sort of skill generally comes from an ability to see others’ (i.e. client’s and computer’s) points of view, allowing the developer to avoid omissions and erroneous assumptions. Skill is more difficult to test for than product knowledge, but it is possible to do so by looking for an ability to analyse tasks objectively and rationally. The recruiter should set a series of exam type questions which candidates should be required to answer in writing before they are interviewed. Something along the lines of: “Error handling by exceptions is fundamentally flawed in principle as, in a deterministic system, there is no such thing as an exceptional event. Discuss” would give the opportunity to assess a candidates ability to reason objectively, rationally and concisely. I would suggest that you should be looking to set questions which can be answered completely in about one side of paper. If candidates take significantly more than this, look carefully at how concise their arguments are, and, if they take significantly less, be sure that they have covered the whole problem. Remember that the purpose of this exercise is not necessarily to find someone who agrees with you, but more to find someone who can see all sides of the problem and who is capable of making a sound argument. If you use recruitment agents, I would recommend not telling them what you are looking for in response to these questions so that they are not in a position to skew the results by coaching the candidates. When advertising for programmers, make sure that you emphasise that you offer meritocratic progression along a genuinely technical career path.
Once you have selected your candidates, a good test for them at interview is the building block test. This is where they have to describe an object made out of building blocks to another person in such a way that the other person can replicate the object without ever having seen it. This allows you to assess the candidate’s analysis and communication abilities, though, obviously, you do have to make sure that the people charged with building the object are reasonably skilled in these areas as well, otherwise it is not a fair test. All this may seem like a lot more effort than most companies can usually be bothered with, but, as with most things, the more effort you put into your recruitment process the better the results will be. If you just rely on recruitment agencies to supply candidates with experience of the software products which you are using, the chances are you will be sent a load of CV’s of candidates most of whom don’t meet your criteria and you will be pushed into settling for one of the few that do irrespective of whether they are any good at their job.
Genuinely skilled developers generally have no difficulty in learning new languages and programming environments as they need them, because they are aware that most languages and environments are essentially very similar, differing mostly superficially. Consequently it is more important to recruit skilled programmers rather than those with specific knowledge. There are commercially available aptitude tests which can be used to assess a candidate’s programming ability in a language independent way. These are very useful and I recommend that you use them ! It is also worth examining a candidate’s attitude to programming; the most skilled programmers regard programming as a relatively straightforward process, so if your candidate is making a big song and dance about his past efforts he probably isn’t that skilled. If you still wish to examine a candidate’s ability in a particular language try not to get bogged down in the syntax of infrequently used features - it should be enough that the candidate has an awareness of their existence and to what use they can be put, as they can always look up the syntax in the manual. It is quite amazing how daft some interviewers can be when asking technical questions. On one occasion I was expected to come up with a particular trick in assembly language from scratch in two minutes even though my interviewers freely admitted that they had been trying to optimise a certain section of their code for two weeks before it had occurred to them !
When it comes to team-working ability do not be too obsessed with the classic teamwork question: “What do you do when you have a problem ?”. (The correct answer is that “I consult my colleagues.”). Anyone who is genuinely team-orientated will be discussing their work with their colleagues regularly whether they have a problem or not and so may not consider an issue a problem until after they have established that none of their colleagues can help. The fact that the questioner regards such consultation as an exceptional event says far more about their team-working ability than the interviewee’s. A better determination of teamwork to look for is how willing the candidate is to spend time offering help to their colleagues.
| Copyright © 2007-2010 Andrew Edgington | Go back to Home page | Send me some Feedback ! |