Home > Uncategorized > On interviewing – beyond technical competence

On interviewing – beyond technical competence

November 23rd, 2007

In the last few posts on interviewing, I discussed mostly about the technical aspects of the interviewing process and some readers had raised the concern that whether technical competence alone is sufficient for doing programming job well. Well, it’s definitely not. In this post, I will discuss on the three most important factors, besides technical skills, that people must care about when evaluating candidates for a programming job.

You want people programmers who are really passionate about their craft and take pride on what they do. Passionate people are self-motivated; you don’t have to spend your time on preaching them on why they should add value to the team in one way or another. They are also autonomous; as long as you have given clear and challenging objectives, they will know how to get things done. Passionate programmers will spend their weekend surfing over technological blogs and feeds to keep them up to date and their evenings reading books or coding something, unrelated to the project, to sharpen their knowledge and skills. Passionate programmers are also curious, they just don’t accept the fact that there is something about this software business that they can’t understand and will go any necessary length to understand stuffs under the hood. They will “javap” Java class files to see what the bytecode instructions look like; they will decompile DLLs to see how the MS developers actually write code; they will use Fiddler to see what are actually sent back and forth between their web client and the WCF web service…

Look for passion in CVs. Do the candidates code in their free time even as simple building some “toy” projects? Are they contributors of any open-source projects? Look for passion during the interview. Asking them how they learn new things – whether they are up to date about latest technologies and trends, whether they learn things on their own initiative instead of “learning on the job”. Notice if they sound really enthusiastic when talking about technologies or display a curiosity in stuffs that they don’t know. At times, you will interview very good liars, but then, passion is among the most difficult things to be faked and I can’t think of any single mistake I’ve made on this so far.

There is nothing worse than a highly competent programmer who is dishonest. Dishonest people have excuses for almost everything. They cover their mistakes with lies and blames. They will trick anyone on everything just to get to where they want to be. They will take all praises if things go well and dismiss all the responsibilities when things go wrong. They spend office time fulfilling their personal timetable and always act as though they were the most hardworking staff. And the more competent they are, which usually mean the more authority they would assume in the project, the more damaging it will be when their mistakes are uncovered. The bottom line, dishonest people, no matter how competent, ruin the people, the project, and the organization.

On the contrary, trustworthy people will tell you and everyone else in the team about their mistakes and have a plan to avoid it from happening again. They even take note of every criticism from others in order to reflect and improve themselves. They are transparent in everything they do even if that means there are more chances of them being caught of making mistakes (“So what? Everybody makes mistake, the point is to learn from it and be a better person”, these people think.) And last but not least, trustworthy people also get thing done. They are given a task and if they say they will finish it they will finish it.

It’s quite difficult to tell if people are trustworthy or not unless you have worked with them for a while. But there are a few things that can help. Check if they really know the things they list in the CV. Check for their integrity by asking questions about their past behaviors in certain circumstances – try to ask a lot of questions and identify inconsistency in things they say. And as this is no exact science, use your instinct as well. If they display any single sign of being untrustworthiness, then unless they are so competent that you really want to give them a try, you should quickly proceed with a no-hire decision.

Programmers have to work well in team. You don’t need a hero who does not listen or accept almost anything said and done by others. You don’t need a hero who refuses to participate in code review just because they think their code is perfect or because they don’t want to accept any comments from “those inferior programmers”. You don’t need a hero who disregards almost every team rules and processes. These people, often cynical, never see the good things in others but can spend the whole day criticizing the bad things. In most team meetings, these people either speak a lot, leaving no space for other (“I’m the only one in this whole team that can make sense. The others had better listen to what I say”) or they don’t speak a thing (“Are these people know what they’re talking about? I’m bored to dead here.”)

On the other hand, people who have high teamwork spirit will care about everyone else in the team. And even if their colleagues are really incompetent, these people, instead of saying “I hate working with these jerks”, they will say “I think I can assist my colleagues in this particular area”. They think independently and at the same time value diverse opinions; they can work effectively on their own and at the same time care about the things others do and are always willing to give a helping hand. They not only comply with team’s discipline but also do their best to bolster it as they know discipline creates great team, or simply because they can’t just accept the idea that others have to suffer because of their sloppiness or the idea that they are too lazy to adhere to something the whole team has agreed on. They share their knowledge to their colleagues whenever they have a chance. And if you have a team wiki’s, their names will be in the top of the contributor list.

Just like trustworthiness, it’s very hard to tell if people have teamwork spirit or not unless you have a sufficient amount of time working with them. Again, instinct counts. Does this person seem to talk only about his/her achievements without any regards to the people s/he worked with? Does this person mostly use “I” instead of “We” when describing all the significant technical decisions made in his past 50-people project? What does s/he think about other job roles like tester, business analysts? Does s/he think that discipline is very necessary?

That’s it. Passion, trustworthiness, and teamwork spirit (plus sufficient technical ability) are all that you need. You may think these things are too obvious to be discussed at length in any blog post, but then, as simple as they are many interviewers I know often forget about them and pay too much of their time questioning the technical competence alone. The more time you spend up-front to evaluate these factors during the hiring, the better off your organization/project will be. And if some time in the middle project that you discover that the person you hired is dishonest, lacks of passion, or tends to go for one-man heroic effort, the best thing you can do for your team, and probably for that person as well, is to let him/her go very quickly.

Categories: Uncategorized Tags:
  1. November 26th, 2007 at 04:51 | #1

    I agree with all of these but I think that passion is the most important thing. If people are passionate they are going to be passionate about coding, they are passionate about the project and passionate about making things work.

    If they want to make the project work they will happily work with those that they wouldn’t normally choose to mix with – for the project’s sake.

  2. Anders
    November 29th, 2007 at 19:09 | #2

    And even if their colleagues are really incompetent, these people, instead of saying “I hate working with these jerks”, they will say “I think I can assist my colleagues in this particular area”.

    Without commenting on the rest of the article, I have to say this is really faulty reasoning. If they DO have passion and honesty they will want to create a good product which they can be proud of. If they have really incompetent coworkers, no matter what they do this will not happen. So they shouldn’t be thinking “I think I can assist my colleagues in this particular area” because that help will be to no use. Instead they should get the hell out of there…

  3. November 29th, 2007 at 19:41 | #3

    @Ian: well, you can weight passion most highly, but then, the other things are indispensable.

    @Anders: you’re right if we’re talking about completely incompetent coworkers here. But note the phrase that I intentionally put – “in this particular area”. In other words, the teamwork guy does see both good and bad things in others, s/he knows s/he can be a star in one area but his/her colleagues in another and they are supposed to work together.

  4. December 13th, 2007 at 23:47 | #4

    Buu Nguyen wrote:

    And if some time in the middle project that you discover that the person you hired is dishonest, lacks of passion, or tends to go for one-man heroic effort, the best thing you can do for your team, and probably for that person as well, is to let him/her go very quickly.

    One thought crossed my mind: how effectively do processes hinder/feed one-man heroism?

    Some examples of processes/practices that ensure team collaboration: mandatory artifact review, testing, resource backup/workload sharing/shadowing

    What is your experience in applying (and possibly improving) these practices and how well do they relate to teamwork?

    If you have good and well-managed process in place, would it save your time and effort in the interviews so you could focus on other traits of the applicants?


  5. December 14th, 2007 at 21:43 | #5

    If you have good and well-managed process in place, would it save your time and effort in the interviews so you could focus on other traits of the applicants? Yes and no. A good process does make people collaborate better and leave the hero less room to play his game. But that assumes the hero is the exceptional case since a process can only be as good as the capability of the team who executes it.

    Having a bunch of heroes sit together in a the code review, you might end up watching people throw tomatoes at each other. (“Hungarian style is the way to go”, “No, Pascal style is”, “You nuts, my style is.”) And let’s forget about all the fights between hero coders and QA teams. (“Me? Misunderstood the requirement?”)

    Therefore, the question remained is how one would do to build up a team which can establish and execute an effective process – one that nurtures the right people and eliminates wrong people very quickly – from the first place. Process, while being absolutely necessary, should only be second thought.

    Finally, talking about traits, this post is all about the 3 most important traits that developers need to possess. Others do count, but are less important.

  6. Thanh Vu
    March 17th, 2008 at 01:31 | #6

    Hi Buu,

    I have just visited your blog and found that this post is so interesting. This is a common phenomenon for all teams, and human factor plays an important role in the success or failure of a project. Please let me tell my thoughts about “hero coder” you mentioned above.

    I think hero-coder is not worth being dismissed from the team. I have witnessed one guy in my old teams, he has good technical knowledge, maybe he has strong personality, special characteristics, so occasionally he considered his ideas the best solution. He still contributed to the team. People often say that talented persons often look like nothing and sometimes are peculiar. We have to suffer this. Dismissal is not a last and best solution in this case. A good leader should drive him and transform him into a guy having teamwork mind, a part of team. How to combine all sorts of persons in a team, receive their true respects and lead them to a common goal is one of the traits that not all project managers have. However, I don’t want to defend hero-coders disregarding the team’s disciplines. Whoever you are, the first thing to care is discipline.

    Let’s look out there to football teams (in some aspects, software development team and football team are the same). A football team without some stars in its line-up hardly reaches the top of the race. We still remember Platini and Maradona ? They are both the good players in their times, but only Maradona touched the gold trophy because beside his passion, he has strong will and special personality for the triumph. I give examples here just to mean that hero-coders or star-coders should be treated with special ways. It’s so boring if teams include all “yes” men.

    Sorry for my telling in a lengthy way here.

    Thanh vu

  7. March 17th, 2008 at 22:00 | #7

    Thanks for your comment, Thanh. You mentioned very good points and I don’t think I have any disagreement with you. In fact, the kind of “hero coder” I’m talking about is the self-acclaimed hero coder who thinks too highly of himself and little of others.

    Only the other hand, the hero acknowledged and respected by his colleagues is in a much different position. In fact, most teams would need as many such stars, those highly excel at their craft, as possible to do something really useful. Stars can be peculiar, or indeed everyone should be unique in his or her own way – that’s a good thing as long as s/he recognizes that teamwork is there to stay and s/he can help bring about much greater achievement with the support from all others. A genius and a thousand servants may work, but a genius and a thousand partners who work along well together do much better.

    I don’t know much about soccer, but if a star player is resented by his teammates then I wonder if he could single-handedly beat other teams. It’s a 11-man game, after all.

    Looking forwards to hearing more from you…

Comments are closed.