Thoughts on Recruitment and Interviewing of Technical Role

Recruitment is an extremely important (if not decisive) factor to the success of a project. This is very true for software project too and some even go to the extend to say that the success or otherwise of a project is determined on the first day the project recruits its full team. The significance could be partially attributed to the unique nature of software related work. I always believe that working with software requires the meticulousness, being analytical towards details and disciplines from the spirit of engineering, yet it also allows the freedom to create without fear of criticism and allows you to give lasting impressions to your audience (ie your user or another software). It is this nature and its implied demanding that makes the recruitment more difficult.

This suggests that a good candidate must possess both traits, analytical problem-solving skill in engineering and capacity to originate creativity and develop useful/practical design. A good candidate has a balanced ratio of mix and intuitiveness of each. Whether there is an magic ratio number is not as important but there must be minimum of each component to allow appreciation of both worlds at the same time - indeed they complement each other.

Interviewing candidates is a very complicated and dynamic process and requires more than just casual thought to make it right. Screening of technical talent for software project requires looking at both hard technical skills (fluency in tools of trade and technologies) and soft technical skills (capability to decompose problem and design). In the case if the role has to lead the project, it requires also the aptitude to communicate effectively to different kinds of people (team members, management, existing customers, prospective customers, marketing/sales forces): technical communication skills.

It is usually easier to determine the level of hard technical skill, by asking the type of black/white technical questions surrounding the topic (programming language, algorithm, technologies). Ideally we should reasonably trust what the candidate tells us on his/her resume or during the interview, but it is typical that the resume is inflated or the candidates tells they are better or more experienced than they actually are due to the incentive of selling. Questions of such could filter out those no hires. You can find better candidate if they respond faster than the average (fluency), or even better one if they can provide additional oversight or consideration of exceptional cases (experience). Again, what is important here is not the final answer, rather the chain of thought which reveals how much the knowledge or best practices has been burned and hard wired into their thinking and those have become just too intuitive to allow pause for retrieval (retrieval has long latency if they only just try to recall from the preparation before the interview). Only by gaining such fluency, the bottleneck of expressing any design ideas could be eliminated and one could concentrate on the actual design work rather than spend time in translating the ideas into physical bytes.

It is much more difficult to determine the level of soft technical skill or the actual skill of designing software. Design is partially scientific in terms of capability of composing the big picture with bits and pieces, but also is largely a reflection of personal styles and values. Design is about trade-off and people decides trade-off, consciously or unconsciously based on their personal beliefs. It could also relate to self-knowledge, how we think we appear to others, how we think others evaluate that appearance probably against some benchmark. That results in shame or pride we feel and we may inevitably align with that benchmark. That could explain why frequently the latest technology, the paper design in the patterns book, the best practices from the industry white paper become the output to align with rather than the input to the thought process of software design. Finding the perfect candidate is certainly very ideal situation and luck usually plays an important factor too. It is also true that the maturity could be developed but the potential is the key. That said, measuring the competence of designing software or the future potential has to go through some metrics.

One metric is to see how a candidate possess an intuitive capability to handle multiple levels of abstraction (from design of software/system, to design of sequence interaction, to design of class in separating of concerns, to design of eg longest common subsequence algorithm, and down to eg pointer arithmetic) at the same time. He/she should be able to switch among those different levels of details very very quickly. Any loss in chain of thought (remember, we are talking about the thought, not the answer) probably means that some people do not get it or just can't do it; any slowdown in chain of thought is an indication for lack of fluency.

Another metric is how good understanding the candidate has about "trade-off". This could be partly revealed in their attitudes towards architecture. Many people talk about architecture without truly appreciating its significance. In fact most of the time it is because there is common belief or tendency to consider architecture or software architect more prestige than the final implementation or those who implements (software engineers, programmers, coders). The exact thinking that the latter, who designs an implementation is not doing the creative design work of the same magnitude, reveals the lack of experience in designing software, not to mention the design of architecture. It is just at a different abstraction level. In my opinion, I always prefer someone who is humble, down-to-earth in talking about software architecture and has mastered the tools of trade for conveying and communicating the idea of designs. They are usually those who along the bumpy roads, learned and started to appreciate the series of "trade-off" in designing software.

The final aspect to watch is the technical communication skill. This is important for every team member but is extremely important for whoever need to lead the team or act as the interface to the outside world. The candidate must be able to explain things well and with passion. During the interview, there should be no drifting in explanations or avoidance of hard questions. If ever provoked (if you have chance for such a question), the candidate should not stand on the fence; but also on the other hand never never argue for the sake of arguing. How the candidate can provide a convincing middle ground to close the topic reveals the capacity of influencing others.

Talking about technical recruitment cannot avoid the topic of career path. Many people has disbelief in the technical career and they cannot be blamed. "Managerial career is the only option" - this is in fact quite common belief in Singapore, also in Asia. This belief is an indicator of several opinions of (possible) facts:

 - people consider managerial position more prestige than technical position

 - society tends to reward managerial position more materially than technical position eg there might be simply perceived gap in pay cheques

 - success tends to be attributed to managerial position and failure frequently attributed to technical position

 - managerial positions are cycled faster (promoted) than technical positions

 - managerial positions suffer from soft stress and technical positions suffer from hard stress

 - incompetent management could be tolerated at times; technical decisions could be sacrificed when required (remember NASA Challenger)

 - managerial positions are profit center and technical positions are cost center

 - etc etc

This belief also acts as self-fulfilling prophecy. Pay/rewards drives more supply, the abundance of supply (for manager career) and lack of consistent high standard would lead to more incompetent management - but again they could be tolerated - this only enforces the belief. Given the respective reward/risk ratio, it is not difficult to see the statistical distribution of choices. The above is the collective value of the society, it is hard to change. To attract technical talent, the employer has to do the action. There is only one way to stand out among the crowd - to build and enhance the company culture of valuing "value generation", and separate the wheat from the chaff.

Sometimes there is also misconception that management is just easy and all about watching over the shoulders, which sounds like the "reward" for completing the rat race in the junior roles. Wrong! That happens in many industries and in many fields, a reality of the life. But the motive being completing the rat race just sounds dubious for the devotion of contribution. Taking up managerial role is definitely a natural extension of responsibility: a soldier who does not want to become a general is not a good soldier but a solider who just wants to become a general so could no longer fight the war is definitely not a good soldier.

Another caveat I would like to bring up is, good candidates are hard to come by, luck plays its part too. But do not limit your hire/no hire selection only to the current batch of potential candidates you may have at hand. It's sometimes tempting to lowering the standard if other attributes of the candidate are likable (genuinely good people are many but good people does not mean they are suitable for the given role), or if there is pressing needs from the project. Give you time to search harder, if the role is important to the project and if the project is important to you.

I am advocating elitism? No. Some are lucky and born with talent, most are not and have to earn/nurture it with hard working. What I said is that I do not advocate equal outcome, I advocate equal opportunity that everyone can be or become one talent.