At one point in my career, I used to do all final interviews for developers in an organization (Tally Solutions Private Limited if you are curious). Everybody was astonished by the dramatic improvement in the quality of programmers joining. I will let you in on the secret.

When I was a kid I used to love Asterix. I enjoyed those comics, so much, I read and re-read them often enough to have memorized them. (Of course this was before the days of TV, computers, and the Internet so entertainment was fairly limited 🙂 )

Goscinny the Author and Uderzo the Illustrator; I loved them. It was a while before I realized that the original was in French and it was translated by Anthea Bell and Dereck Hockridge. I think Anthea Bell deserves a lot of credit for the worldwide success of the Asterix. Her translation is brilliant.  They say a good translation is an art. Let us look at some things necessary for a good translation.

  1. You should understand the source language very well. Well enough to understand subtle nuances like puns, meaning based on the cultural context and so on.
  2. You should write fluently in the destination language. Well enough to make puns, jokes which make sense in the different cultural context and so on.
  3. The art of understanding the source text and choosing the appropriate words to make an attractive, readable text which conveys the same “mood” as the original text. You can’t translate relying on a dictionary

What does this have to do with recruiting developers? Developers translate “requirements” to “code”.

  1. They should understand the requirements easily.
  2. They should code fluently and have a good understanding of the impact of the decisions they take about data structures and algorithms on the code they write.
  3. Write “good” code which gets the “mood” of the requirements.

In my final interview I used to ask an open-ended question, maybe “Let’s design a word processor or a hospital administration system” I didn’t put the whole question in the beginning, I would frequently in the middle of their answer, say “Oh I forgot something, you also need to take care of xyz”. I would notice how well and easily they understood the requirements. If they asked questions which I would probably have told them a little later in the interview they got extra points.

When they had a working answer, I would make comments about the code which would only make sense if they had understood what they done and more importantly why they had done it?

To get selected they should have understood the requirements well and the nuances of the choices they had made.

Will this insight help you get “good” programmers into your team?