The next describes some techniques that I use when interviewing candidates for Software program Engineering positions in offshore places. I have brought these techniques collectively into five stages:
Logic plus Problem Solving Ability
Spoken and Written English Ability
Communication Skills plus Personality
1 . Logic and Problem Solving Ability
When I first started out interviewing offshore software engineering applicants in Malaysia, I wasted considerable time looking at their CVs and using those as the basis for the first stages of interviews. This resulted in the candidates doing a lot of talking about tasks they (claimed) they had done plus skills they (thought) they had before I even started measuring their particular technical ability. Some CVs appeared very impressive indeed, their authors claiming almost endless lists of skills obtained, many to “advanced” standards. Today, back in the UK, for the most part when discussing highly skilled jobs there is an unspoken rule when it comes to CVs, candidates only list skills that are really worth listing plus certainly being prepared to back up any kind of claims of “advanced” levels of proficiency in any of those claimed skills. It really is no surprise that upon receiving this kind of impressive CVs in Malaysia I actually assumed the candidates were very good quality indeed and decided that the initial hour of the interview should be information talking about their experience (to assist them relax into the interview) plus me doing a bit of a sell on the role and company. Only from then on would we dive into the specialized questions, which looked like they would a piece of cake for them. Unfortunately, the aforementioned CV “rule” that applies in the UK does not utilize in Malaysia, nor does it at any other offshore location that I have got 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 a while talking about the role and the firm, before even thinking about getting their own 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 fashioned talked to for the previous hour or so was not the person who was for the piece of paper (the CV) before me; they had exaggerated wildly and in some cases blatantly lied on their CV.
When only recruiting for one or 2 positions, wasting an hour here and there talking to a candidate who has deliberately fabricated their CV is not a big deal. Indeed, several candidates I talked to were truthful and I subsequently hired them. However , when recruiting on a larger scale offshore, the numbers not in favor of you and such an approach can be greatly inefficient. Given that I was recruiting on the larger scale, I had to find a method to determine as quickly as possible if a candidate I used to be interviewing was worth talking to additional. I therefore put aside their CVs and piles of certificates plus jumped straight into a bunch of logic and problem solving activities (which involve writing code) on the whiteboard; I had been quietly amazed with the results.
The particular questions were short and easy, often programmatic, such as:
Using the language of your choice (or even pseudocode for junior candidates), write a function to reverse a string.
Using the language of your choice (or even pseudocode for junior candidates), write a function that designs all the prime numbers from 1 to n.
At the very start of interview, before asking these queries, I would I often ask an applicant 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 types of ratings on the whiteboard, in view of the candidate, for later reference. I then inquired the candidate to complete questions just like (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 towards the problem, thus removing any prospect of them to claim they struggled with all the question due to a particular language becoming imposed on them. Furthermore, I am content for them to use pseudocode / British if they are unable to code the solution (though that in itself will tell me something about the ability of the candidate and can set alarm bells off if they happen to be applying for a more senior position). In line with the candidate’s solution to problems such as these, it will not take long to establish if they are really worth interviewing further for the role involved. We are talking minutes. For example , We still vividly remember an already very senior candidate C creator who had worked in the USA being an embedded engineer and was today back in Malaysia working on C program code related to aviation systems. He requested one of my senior software engineer jobs in Malaysia. On paper, this individual looked fantastic – good diploma, 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 have a tendency mean he got one or two statements wrong due to not remembering syntax, After all he completely could not reverse the string as per question (1) above. After far too much guidance through me, eventually we got generally there. Thinking he was nervous, I then gave him the prime numbers issue (2) as above. After some initial explanation from me in regards to what a prime number was (he did know it in the end, perhaps he or she forgot) he had no idea where to go and wrote drivel on the board, constantly wiping it out, puzzling his forehead and writing yet a lot more drivel. He looked embarrassed. I actually stopped it there and inquired him what he now believed his ranking was in C. I really could see the look of torment on his face, like he still desired to stick with his original answer. “5 or 6, perhaps? “, he or she reluctantly admitted. Based on his claimed level of experience and the level work he was applying for in Malaysia, I had no further questions. Even though I did not set a timer off, I would be surprised when the whole thing lasted 15 minutes.
I at this point never start an interview without wondering similar questions to the above in the opening 15-30 minutes, no matter what the level of software engineer I am interviewing to get. Candidates do not proceed to other stages without first getting past this stage. The level of role will simply determine how much leeway I provide for incorrect answers. For example , for a very junior position, what I will look for is not necessarily the right solution, but how the candidate thinks about the solution. At the very least, they should be able to describe in my experience how their algorithm could solve the problem. In my view, even for such a junior candidate, if somebody has been through university, done a Computer Science degree, and cannot also explain how to reverse a string or does not know what a leading number is, they probably ought not to work for me. Likewise, if somebody has been working for 10 years and are not able to reverse a string in the vocabulary of their choice, they definitely really should not working for me. Importantly, very importantly, no matter what the level of the candidate is, I ensure that they never suppose the solution to my problems and try to choose to bluff their way to an answer, talking about this as if it’s the right answer to win over me. Anybody that has worked for me personally will know that I hate guessing in software engineering. A candidate who is ready to guess and try to bluff their way through an interview is likely to do the same when they are working on a task for me personally or someone else. For example , they may, not knowing a problem thoroughly enough and hence speculating, go off and write reams associated with code that they are equally unsure of. I always tell my staff that when they are unsure of the work these are doing, to stop what they are doing plus come and see the team head or me to discuss; never guess. So , I always jump onto any kind of evidence of guessing during this stage and find out why the candidate is doing it.
One other point worth mentioning regarding the questioning techniques I describe above is that are easy to conduct along with candidates that are remote, as long as they have got a computer and Internet connection. For example , You will find interviewed candidates in completely different nations by setting up a shared whiteboard program (many Internet communications tools offer such a facility) or a shared Search engines Doc and asking them to type the solution to the problem while we all talk over the phone. Arguably, considering that we are not in the same room they could cheat by looking up solutions on the Internet, but since I do not allow much time for the questions and I was also on the phone at the time, this really is unlikely. Furthermore, I take steps to look for any solutions to the problems I request online and ensure they did not merely type out one of those. That said, even if I am suspicious that they copied a specific solution, it is trivial for me to develop upon their solution and ask them to modify it to solve an associated problem. Use of this technique has allowed me to screen many remote applicants before inviting them to travel to the place of work for an interview.
To sum up, my advice when interviewing offshore candidates is to get a quick handle on their Logic and Problem Resolving ability before deciding whether or not to advance on to talk about their experience as well as the role. Spend up to 30 minutes achieving this and give them a fair chance to answer a range of questions, not just a single issue. Make sure the questions involve actually writing code, but ensure the questions allow flexibility in the languages utilized unless the role you are recruiting for is a senior role that uses primarily mandates use of a particular language. By all means ask further Reasoning and Problem Solving questions in later stages, but the key of this stage is to provide a quick “Go” or “No Go” on a given candidate.
2 . Computing Knowledge
Although I know of a number examples of colleagues that neither studied Computer Science at degree level nor acquired any knowledge of computers who continued to become exceptional software engineers throughout their career, when I interview offshore candidates I do look for general Computing Knowledge; so many aspects of the work, at least in my opinion, that software engineers do every day depends upon a having a solid foundation in the principles of computing. Maybe more obviously to me, I believe it to be of great advantage if a candidate has a genuine interest in computers plus understands how they are work. More often than not, such candidates will have interacted along with computers regularly as they were growing up, perhaps taking them apart, producing modifications, playing games, configuring networks and suchlike. I always keep a search for these candidates and they certainly exist in offshore locations such as Malaysia.
A simple way to determine how much a candidate knows about computers is ask them to draw the diagram of a computer on a whiteboard, asking them to label the various aspects of the system. Then ask them to describe the function of these components. It’s an easy question and how well they carry out at this question will give me a concept of how much they know about processing. If they do well at the question, perhaps I’ll throw in some more challenging queries about the hardware or maybe we’ll move onto software such as talking about how a compiler works, or perhaps we’ll talk about essential algorithms. The level of questions I ask depends on the seniority of the role becoming applied for, but I nearly always begin with a question about a computer. This workout, since it is mainly on the whiteboard, also gives me a further opportunity, following the Reasoning and Problem Solving stage, to assess the candidate’s communication skills.
Once i was at Nottingham University in the UK reading for my degree in Computer Science, I was surrounded by people like me, people who loved computers and who “messed around” using them on a regular basis, just for the fun of it. Inside my view, people like this need to be appeared out for, so I nearly always ask just offshore candidates why they are pursuing a career in software engineering and try to find out how interested they are in computers.
Our advice, therefore , when looking for offshore applicants is to look for those that have a genuine interest in computers, who possess a good understanding of their inner workings and who are able to answer typical computer science kind questions with ease. Try to establish how good they are in this area before you move on to specific skills, as that stage will most likely require significantly more time and involve people other than yourself in case you are the hiring manager.
3. Specific Abilities
By this stage, following the previous two stages, which just involved me and the candidate, I will will have a pretty good “gut feel” in the candidate’s suitability for the role. After a little more talk about their experience and profile (including talk about software development processes etc), as well as some more speak from me about the role plus company, now is the time to get other people included and start assessing specific skills. I normally involve at least two associated with my software engineering subordinates in the skills assessment stage, as well as one or more other people manager. If the candidate will have any dealings with the core group (most likely), I will also include technicians and managers from the core team offices e. g. in the UK or even US. All are free to ask any kind of questions they like and their own views hold considerable weight in my decision-making process. After all, software growth is very much a team sport and it is important to me that my team buys into the idea of the candidate joining their team; they are the ones that will be working with them daily. I therefore allow to several hrs of talks with these various stakeholders, either on the same day or upon alternative days if time will not permit. Some of these talks, if along with overseas colleagues, take place via phone, Skype, or suchlike.