When I first started out interviewing offshore software engineering candidates in Malaysia, I wasted a lot of time looking at their CVs and using those as web development company the basis for the first stages of interviews. This resulted in the candidates doing a lot of talking about projects they (claimed) they had done and skills they (thought) they had before I even started measuring their technical ability. Some CVs looked very impressive indeed, their authors claiming almost endless lists of skills acquired, many to “advanced” standards. Now, back in the UK, for the most part when talking about highly skilled jobs there is an unspoken rule when it comes to CVs, candidates only listing skills that are really worth listing and certainly being prepared to back up any claims of “advanced” levels of proficiency in any of those claimed skills. It is no surprise that upon receiving such Techies App Technologies Sdn Bhd impressive CVs in Malaysia I assumed the candidates were very high quality indeed and decided that the first hour of the interview should be about them talking about their experience (to help them relax into the interview) and me doing a bit of a sell on the role and company. Only after that would we dive into the technical questions, which looked like they would a breeze for them. Unfortunately, the aforementioned CV “rule” that applies in the UK does not apply in Malaysia, nor does it at any other offshore location that I have interviewed candidates from thus far. I could therefore quite easily waste the first hour of an interview talking to a candidate about their CV, and perhaps spending some time talking about the role and the company, before even thinking about getting their hands dirty with some technical questions. When the technical phase began, many candidates were turned down because it quickly became apparent that the person I had talked to for the previous hour or so was not the person who was on the piece of paper (the CV) in front of me; they had exaggerated wildly and in some cases blatantly lied on their CV.

When only recruiting for one or two positions, wasting an hour here and there talking to a candidate who has deliberately fabricated their CV is not a big deal. Indeed, many candidates I talked to were truthful and I subsequently hired them. However, when recruiting on a larger scale offshore, the numbers go against you and such an approach can be hugely inefficient. Given that I was recruiting on a larger scale, I had to find a way to determine as quickly as possible if a candidate I was interviewing was worth talking to further. I therefore put aside their CVs and piles of certificates and jumped straight into a bunch of logic and problem solving activities (which involve writing code) on the whiteboard; I was quietly amazed with the results.

The questions were short and simple, often programmatic, such as:

  1. Using the language of your choice (or even pseudocode for junior candidates), write a function to reverse a string.
  2. Using the language of your choice (or even pseudocode for junior candidates), write a function that prints all the prime numbers from 1 to n.

At the very start of the interview, before asking these questions, I would I often ask a candidate to rate themselves, 1-10 (1 being beginner, 10 being advanced), in each of the programming languages they listed on their CV, quite a few responding confidently that they were 8,9, 10’s in languages such as C and Java. I would record these ratings on the whiteboard, in view of the candidate, for later reference. I then asked the candidate to complete questions similar to (1) and (2) on the whiteboard in front of me. The key with the questions is that I emphasise to the candidates that they are to choose which language they want to use when writing the solution to the problem, thus removing any potential for them to claim they struggled with the question due to a particular language being imposed on them. Furthermore, I am happy for them to use pseudocode / English if they are unable to code the solution (though that in itself will tell me something about the ability of the candidate and will set alarm bells off if they are applying for a more senior position). Based on the candidate’s solution to problems such as these, it doesn’t take long to establish if they are worth interviewing further for the role in question. We are talking minutes. For example, I still vividly remember an already very senior candidate C developer who had worked in the USA as an embedded engineer and was now back in Malaysia working on C code related to aviation systems. He applied for one of my senior software engineer jobs in Malaysia. On paper, he looked fantastic – good degree, strong background and the right skills. To my surprise, he struggled to reverse a string in his language of choice, C, for which he had rated himself as a 9 when asked at the start of the interview (and which I wrote on the board). I don’t mean he got one or two statements wrong due to not remembering syntax, I mean he completely could not reverse a string as per question (1) above. After far too much guidance from me, eventually we got there. Thinking he was nervous, I then gave him the prime numbers question (2) as above. After some initial explanation from me as to what a prime number was (he did know it in the end, perhaps he forgot) he had no idea where to go and just wrote drivel on the board, continually wiping it out, puzzling his forehead and writing yet more drivel. He looked embarrassed. I stopped it there and asked him what he now thought his ranking was in C. I could see the look of torment on his face, like he still wanted to stick with his original answer. “5 or 6, perhaps?”, he reluctantly admitted. Based on his claimed level of experience and the level job he was applying for in Malaysia, I had no further questions. Although I did not set a timer off, I would be surprised if the whole thing lasted 15 minutes.