Dig through the archives of any long-standing software development forum and you're likely to find discussions on how to conduct interviews for the purposes of increasing the project headcount.
Usually the hirers will have a particular set of activities in mind that need to be undertaken, and an appreciation for the technologies they would like the candidates to use in fulfilling the work. From this the hirers formulate a description of the candidates they wish to hire. There then follows, provided the hirers are fortunate, a steady flow, or trickle, of candidates to interview.
Interviewing the candidates presents a small but surmountable problem of verifying their technical competence, which may be resolved by a battery of test activities. If the candidate navigates the tests and they presented themselves well, they may then find themselves on the final shortlist for potential hiring or employment.
This is the usual scene for technical recruitment. To elaborate, here's a brief job description that an agent sent to me earlier today:
"C# - Greenfield - Front Office - Contract - London - £650pd
I am looking for expert C# Developers to work on 2 Greenfield projects in a leading city based investment bank:
1) Collateral Optimization Engine (Fixed Income) - Up to £650 - City based - Expert front-to-back C# (not asp.net) - Must have Fixed Income or Futures front office experience
2) FX Options eTrading - Up to £650 - City based - Expert server-side C# (C++/Java) background - Must have investment banking/hedge fund experience." [i]
For completeness, here are some details the agent omitted:
1. The client is expecting you to work flat out for a year at least. Ideally they will want to hold onto you until the next time they have to make some sweeping budget cuts. Four years would be "solid".
2. They want you to know everything about the technology that is required and they want you to undertake any jobs they see as urgent.
3. Despite the greenfield adjective, you're well aware that in this kind of culture you don't get to spend much time tinkering with design options, or looking into space.
Now, there are different ways to read this brief description, which constitutes the first gambit of an agent to acquire a fresh batch of CVs and phone numbers for this and other, less glamorous, projects. Let's assume you've had some experience with this situation and that you qualify for the role or, rather, that you can see a way of presenting yourself such that you may be construed as qualifying. Let's also assume you're aware of what "must have investment banking experience" means. Here's the question: does this "usual scenario" seem reasonable, where surely here the case is quite a straightforward one of hours worked in a professional manner for high pay, with anything extra being a bonus?
Irrespective of whether it seems reasonable, it is, I assure you, normal. In the following sections, I present several interrelated contradictions to this model of recruitment.
The contradictions of the expertise and development
The first and basic contradiction that manifests itself here, and elsewhere (repeatedly), is development. How did you, the expert programmer, acquire the skills that are being sought by this agent? What personality traits were central to this activity? If amongst those traits you omitted curiosity, learning, elegant design, insight and creativity, you're going to fall short of being a bona fide expert. If, on the other hand, you do exhibit these, and other, traits, what kinds of impoverishing things are going to happen during those years of high pay when these traits are denied expression?
There are ways to resolve this contradiction, of course. Perhaps the best way, given the all round naivety, is to present yourself as an expert and then proceed to become the expert on the job, this way there'll be things to learn. But this doesn't seem to be what the hirers want, does it? On the other hand, perhaps you have acquired all the syntactic and empirical knowledge required for passing the technical tests, consider yourself an expert, and other than being a bit confused as to why some people go on about design, collaboration and something called concepts, you've no reason to let reflection get in the way of rolling up your sleeves and getting on with the work. Is this the expert that we want to unleash on core company architecture?
Let's go back to the original need to increase the project headcount and contrast this with the source of our basic contradiction, which is development. Ah, the Newtonian model of project management has distracted us. What we really need is "to increase the numbers on the team, such that all of the team members experience some improvement in their working environment, with increased satisfaction in doing the work that is required, whilst being presented with the kinds of challenges that meet with their daily personal conduct, such that they will be working as satisfied productive team members for several years, if not more."
Great, progress. That seems reasonable as a first effort, but we're in a hurry, so let's refine this so that an agent can recite it, and then do our interviews.
The contradictions of testing and integration
We have interviews to conduct! That means we'll need those technical tests from last time again, because without them, we might end up with someone not suitable...
Technical tests... Not suitable...
Could it be?
Is it possible?
Could it be that those technical tests mean that we end up with someone not suitable? Is that possible? Yes, it is perfectly possible. Here are some reasons why.
Firstly, there may be significant inconsistencies amongst the interviewers. It may well happen that an interviewee will score well with one technical interviewer and not with another. One conclusion to draw from this is that the interviewee knows how to solve one set of problems but not the kinds of problems presented by the second interviewer. That's one way of looking at it. But what if these two interviewers have very different models of what is required?
I recall an interview I attended for a large consultancy. Upon greeting me the interviewer, a senior consultant with the firm, turned to the whiteboard, drew four dots in a square formation on the board and said, "What's this?" I looked at him whilst considering weighing up my various answers, "four dots on a whiteboard" was probably the best compromise between accuracy and patronization. For this interviewer silence was evidently a sign of ignorance, clearly I did not know what a scope operator was.
On another occasion, with a different consultancy, I was requested to create and work through an entity relationship model for the interviewer, who was 'the client'. "When I am sitting down", the interviewer said, "I am the client." He paused, looked around casually, stood up and said, "And when I'm standing up, I am the interviewer."
Clearly these two interviewers had elaborate models and expectations. The question is whether the other interviewers agreed with them!
Note also, that these assumptions also relate to the other themes, for instance as assertions of authority and seniority. In the case of the interviewer as client, do you, as the interviewee and potentially more junior employee, agree to pretend to pretend, whilst the interviewer gets to write the script and pull the rug away when he so chooses, or do you confront him?
A second condition of unsuitable testing, is that you're testing (exploring would be a better word) the wrong thing.
Let's return to the developmental mode of consideration. The person we are looking for is going to integrate into a team and the team as a whole will hopefully work better once he or she is fully on board. How do we determine whether someone is going to integrate well?
The standard approach to interview testing is to determine what the candidate does and doesn't know. Yet this will not tell you anything about how the candidate works with others and whether he or she will integrate with the team.
Furthermore you will be fooled if you believe that the "not knowing" results from such a test equate to "can't do". "Not knowing", rather, means "can't do on their own in this situation". Now this reach, of what can be done with some assistance, is actually a variable property. Some people with a little extra assistance can do a great deal more, whilst others do not gain the same benefits - their knowledge and methods of activity are far closer to the binary model that testing implies. This means that some of the candidates who do very well at the technical tests are unlikely to integrate very well on things that they don't know how to do, and are more likely to take particular, potentially divisive, strategies regarding the kinds of 'collaboration' they are used to.[ii]
For some scientific researchers of psychology, the notion of cognitive reach has taken on a central, conceptual, basis for studying development, often called the "zone of proximal development" (Vygotsky, 1987). How far you are able to reach, in an unfamiliar setting, tells us much more than what, in this particular instance, you able to do. It tells us that you can listen carefully to others, that you can identify what is not known, and that you can build, quickly, upon relevant information that is provided.
A second interesting aspect of cognitive reach is that it has reciprocity too. If you are able to conduct assisted activities successfully far beyond your usual current independent limits, it is likely that you will also be equipped to provide the right kind of information and orientation to help others reach beyond theirs. This sounds like exactly the kinds of skills we'd like for team integration, doesn't it?
More contradictions of expertise and development
Hirers and, by proxy, interviewers are often focused on short term project needs and the competencies of the candidates, rather than on longer term development. If, as an employer, you have an urgent need for a developer, then you have something wrong with your enterprise, and it isn't the absence of developers.
There are plenty of competent developers who would like to work in, or for, a place that honoured their own development. An urgent need for developers is a clear message about the kind of culture being recruited for. For example, I have seen many job descriptions labelled urgent that also stipulate the necessity for a particular syntax or library as a "must have". If you're looking to hire someone for many years, then what is a month to gain a working memory familiarity with your particular syntax of choice amortized over this duration?
This issue leads to a third and more profound point about cognitive reach, which is that the things we are able to do with assistance foreshadow what we will be able to do independently in the future. This is worth reflecting on.
Fundamentally the mindset for this kind of mutual support in reaching is grounded in a helping mindset which is often anathema to a culture of demonstrating cleverness and claims to authority.
The basis of the helping mindset is one of process; it's about how we do things rather than what, in particular, we do. If, as a helper, you are focused on telling others what to do, you are acting as an expert (Schein, 1999). If your only mode of helping is telling others what to do, collaboration and team integration are not going to be improving noticeably, because you're not providing a framework for others' development.
In other words, to play the expert role without attending to development, is actually tantamount to denying the opportunity for others to develop. Instead, you are contributing to establishing a hierarchy of "knowledge power": a culture of silos, where experts are urgently required at high rates of pay.
The contradictions of assessment and understanding
Interviewers often employ a school model of knowledge, which arguably isn't right for schools either.
One of the things many of us learnt at school is that the exams we took and the means of passing them do not have that much to do with whether a pupil understands or appreciates the subject. The exams are incidental to genuine learning. Yet many people persist with the notion that tests demonstrate whether the critical capacities for knowledge are present. Whether they can repeat an answer, formulaically. Yet this unthinking answer is as far from a real, conceptual, answer as correctly reciting the syntax for an SQL statement is from an appreciation of normalisation. Such a situation would be laughed at were it not for the state of the whole industry and our wider culture.
More specifically on the theme of technical assessment, the interviewer may not know the important difference between empirical concepts and theoretic (or scientific) concepts (Davydov, 2008). It is quite possible that the primary interviewer for these high paying jobs does not know the difference. In such circumstances, they will be unable to discriminate between superficial technical knowledge and technical insights that pave the way towards orders of power of magnitude in improvements of software capability.
Knowledge is certainly key to the successful activity of software development. However, some of this knowledge is far more superficial and subject to change, such as knowing the particular syntax for an API for instance.
Other forms of knowledge are more efficacious: knowing when to probe around to find out how others have dealt with a particular problem, knowing how to partition a system or write a class, knowing the various constraints and affordances of particular means of writing software such as scripts or programming languages, knowing how the procedures and standards of the organisation influence the choice of means of implementation, knowing what it means to persist data or what impedance mismatch is, or having a notion of the concurrency capacity of a particular server instance. These forms of knowledge are more significant than recalling the particular syntax [iii] for a left outer join.
This insightful knowledge is theoretic and, as has been explained by noteworthy scholars such as Dewey (1967) and Piaget (1976), these ideas cannot be communicated directly. Rather they must be constructed personally to appreciate them. This means that the methods employed by a "non-technical" interviewer must be skewed. The damage would be less if we recognised this. However, many technically competent people take the interview methods of the non-technical as de facto standard practices, thereby discarding any means of attaining a high quality, nuanced evaluation.
The contradictions of investment and value
What is the programmer's attitude as he or she leaves his desk to interview a candidate, in order to give some feedback to the hirers about the technical competence of the candidate? Perhaps, if he has done some preparation, he will have a portfolio of programming tasks or puzzles to solve. If he has done less work, he may have a few sheets of code in which the object is to find the bugs. The basic point is that the test presented will be more a reflection of the tester's notion of what programming is about and in particular where they spend much of their time.
Where, psychologically, people spend much of their time is often conflated with what is valued, which is reflected in attitude. If you poll people for what they value most (such as their favourite book [iv]) many people will select the activities that take the longest. It is processes of this sort, a variant of cognitive dissonance, that lead programmers to test another programmer's debugging skills.
I do not wish to devalue the skills inherent in debugging of a real kind, which is often a highly conceptual activity, yet I have not encountered this kind of real debugging during interviews. Interview debugging is often mocked up and artificial.
Then there are the programming interviews about demonstrating cleverness which, as we've seen, is often an indirect reference to claims of authority. Yet much of all the variants of this politicized access to knowledge is merely a familiarity with protocols[v], such as knowing where to go to diagnose a particular problem in a particular system. Anyone can acquire this kind of expertise provided they stick around long enough. This certainly satisfies an older generation's notion of seniority within a company based upon length of service, but is that the kind of knowledge and respect we aspire to?
Note also, that if you have a culture of expertise along these lines there will be vested interests in not changing the way things are done or, at a push, certainly not changing them quickly. This applies even if there are clearly better ways of conducting the work. Provided the work is sufficiently muddled, in an expert culture there will be people who believe they stand to gain by keeping things that way.[vi]
The contradictions of formality and intuition
The interviewer may be looking for something to fail the candidate on, because there's something else not right. Perhaps the interviewer has intuitions which are difficult to express using their interview model. Or perhaps the interviewer has a hidden agenda: to some people, the smarter you are, the more of a threat you are. Either way, a simple way forward, for this style of interview, is to continue presenting technical tests until the interviewee makes a mistake.
The role of intuition in the workplace is pervasive. Intuition entails a non-conscious mode of directing ones awareness, rather like the experience of having a word or answer on the tip of one's tongue. If we design our processes such that intuition is disregarded, we deny a powerful source of creativity and a powerful means of overcoming frustrating circumstances. For example, the side effects of a managerial response to change efforts, by requesting a well articulated alternative may lead into quicksand. This is simply because the necessity for a well articulated description coupled with an absence of resources and conditions to formulate the articulation results in status quo.
Widening channels of communication to encourage the translation of intuitions and speculations into clear explanations can be given a boost by incorporating this awareness into the process of recruitment. Workplace awareness for intuitive processes has significant cultural ramifications for facilitating where the creative work takes place in an organisation. Is it to be found in the half-starved processes that are reduced to a few private moments between meetings, or can it be facilitated as the core activity of those collaborations, that energise the work of a whole team?
Achieving a culture of creative participation of this form is no easy endeavour. However, even small shifts in the direction of inclusiveness and mutual permission for this creative attitude can have considerable benefits. Giving credence to these processes during interviews and recruitment is an example of such a shift.
The contradictions of partitioning and sharing work
From a technical stand point, the manner of conducting interviews has tangible implications for the enterprise, including the structure of the code. This is, essentially, the point of Conway's (1968) law. A fragmented or partitioned team will, at best, produce a fragmented and partitioned software product. But this is not the kind of partitioning that good design entails. This is a partitioning where one subsystem is built without any internal relatedness to the other subsystems.
As many companies begin to explore further the potential for distributed work, these issues stemming from cutting corners and paying lip-service to technical problems, by only heeding empirical practice, will come increasingly and frequently to the fore. Typically there exists a spectrum of approaches to remediate this situation. At one end presides the acknowledgement of development along with all that it implies. The opposite end, which some might refer to as the conservative approach, entails imposing yet greater and more rigid constraints.
Conclusion
I have enumerated key contradictions inherent in the problem of recruitment, which implicate team cohesion, effectiveness and development. These and other contradictions are interrelated. They comprise a complex whole, whereby each facet cannot be treated successfully in exclusion to the others.
A central theme has been the critique of the normative methods of recruitment that lead, in a self-fulfilling manner, to a perpetual and often urgent search for technical expertise. In juxtaposition to the expertise model, I have presented an alternative, viable model of development. The developmental model presents challenges too, yet I believe the arguments in favour of it are compelling.
I hope to have provided some readers with a pause for thought regarding their practices and culture. I also hope to have provided some pointers for improving the recruitment process, particularly the implications for the developmental alternative. For an effective organisation, where team integration is genuinely sought, the architects of the organisation, which include all those involved in the process of recruitment, will need to confront these issues.
About the Author
Huw Lloyd is a software developer, tutor and researcher in educational psychology. He has developed C++ software systems in finance, defence, engineering and market research. In addition to the software collaboration and mentoring, he teaches GCSE subjects part-time. He is currently conducting research on mediation and memory, grounded in the materialist psychology of cultural-historical activity theory. He lives in London with his young family.
Thanks to Shane Hastie, Kevlin Henney and Helen Lloyd for their reviews.
References
1. Conway, M. E. (1968), How do Committees Invent?, Datamation 14 (5): 28-31
2. Davydov, V. V., (2008) Problems of Developmental Instruction, A Theoretical and Experimental Psychological Study. Nova
3. Dewey, J., (1967) Psychology, in John Dewey, The Early Works 1882 - 1898, Volume 2. Southern Illinois University Press.
4. Festinger, L. (1957) A Theory of Cognitive Dissonance. Stanford University Press
5. Piaget, J. (1976) To Understand is to Invent. Penguin.
6. Polyani, M. (1958) Personal Knowledge: Towards a Post-Critical Philosophy, p61. Routledge, Kegan & Paul.
7. Schein, E., (1999) Process Consultation Revisited: Building the Helping Relationship. Addison-Wesley Longman.
8. Vygotsky, L. S., (1987) Thinking and Speech, in The Collected Works of L. S. Vygotsky, Volume 1. Plenum Press.
[i] Permission granted, by email, for quoting the anonymous agent.
[ii] I am fully aware of the need to create circumstances and supportive environments for those people labelled with particular psychological symptoms. In a supportive environment discrimination means "to notice differences".
[iii] Caveat lector. Not all syntaxes are equally arbitrary. Some syntaxes such as the equals sign in mathematics indicate concepts. A clinical precision in their use has more profound implications.
[iv]"Lord of the Rings" came top of the BBC's "The Big Read", a poll conducted in 2003.
[v] Polanyi (1958) describes this as "absorbing elements through an operation".
[vi] This is the tip of the iceberg, the domain name for which is called "organisational development".