On the internet, there are a lot articles containing tips how to pass job interview: how to make a good first impression, which words should be avoided, what a candidate must wear etc. What about people who leads that interview? Should they also prepare for that? Yes, and this is our quick turn to talk about it. I invite you to read 🙂
We do not have an easy task
Verifying technical skills is very hard task and process. Why? It is very easy to make a mistake. A lot of practices used in not-IT sector is unforgivable mistakes, for example:
Trying to prove candidate that he has lack of skills
A lot of interviewers thinks that thinks that we decrease candidate’s expected salary. Unfortunately, usually IT companies need software engineer that he/she needs company. Usually IT companies almost beg software engineer for a just coming job interview, so in my opinion we should not discourage candidates. Let’s use approach: “Join us, you can learn a lot in our projects”. I will tell more about this topic later.
Assuming that the amount of experience in years is straightforward proportional to the skills
This is my favorite. Before we created Quick Turn Studio, many times when I talked with the recruiter, before any technical conversation I got the answer that my financial expectations are inadequate to my experience and it is unacceptable that I what earn a lot more than programmers who have three years more experience than me. Yes, they were high, but that’s what another company gave me after verifying my knowledge well, raising the offer above my original expectations. From another perspective, I was leading many technical interviews in few companies and I experienced a lot of situations when verified technical candidates who had twice as much experience as I and sometimes failed on simple issues.
Let’s help the candidate!
Remember that the purpose of the conversation is not only to test his skills, but to encourage him/her to work with you and the company. Do not be an obstacle for him in getting a job, but a challenge. Remember that this candidate can get a job, you will have to collaborate with him/her or later he/she can be promoted. And then what? So:
Hide your ambitions and complexes
Many technical interviewers are smart alecks. They know the nuances of some technologies and trivia. Often at work at lunch breaks, afternoon coffee breaks, when we are in a group, I invent a task or ask a puzzle, which I create based on a trivia that I found in a book, on the Internet or when I encountered a problem when writing something after hours. However, these are trivia. Knowledge of them has little impact on everyday work. They will be useful once a month for one of the twenty programmers. Therefore, do not ask questions that are supposed to be a concrete lifebuoy. Moreover, remember: you can always meet someone smarter than you.
Let’s say we a a proposition of question/task for a job interview. How to decide if it is worth ask the candidate about this? Just answer on this questions:
- When was the last time when answer for that question helped your me or my colleagues?
- How many times in a week I deal with that kind of problem?
- Do I use it at regular work and this is a common good practice?
Answer them honestly and be prepared for sitiation when a confident candidate asks you these questions. Once, when I asked such questions as a candidate during the job interview, I got an evasive answer: “Yyyy … well … We ask about this because we test your knowledge.” Pathetic.
Ask open and descriptive questions
The closed question has a predefined answer. When a candidate does not know the answer, he start to wonder and stress. Clock is ticking and we still do not know his/her knowledge. Maybe he knows something about to this topic, but he just don’t know the specific term? Help him in telling what he knows. Remember, we want to find out what the candidate knows, what is his/her experience. Let’s don’t make a school exam with a predetermined answer and scoring key.
Let me talk about the issue, put in questions
Sometimes, when we ask you to tell a story about an issue, the candidate may start answering the questions you have prepared, but you haven’t asked yet. Very good! Then you only need to control the direction of what the candidate says. Do this by asking questions that relate to his previous answers. Example:
We: Could you tell us about possible problems that we can meet during developing multithreading application?
Candidate: The biggest problem is synchronization between threads.
We have critical sections, deadlock and livelock threats. Section
critical is a place where two threads can have simultaneous access …We: What is the problem that two threads access to …
Candidate: Because then we have a gambling called race condition …
We: What is this problem about?
Let’s not ask immediately what is deadlock, mutex. Let’s not ask two questions at once, such as “What is gambling, how to protect yourself against it.” Let’s get through this smoothly. If the candidate understands the topic (multi-threading in this case), he will tell us about it (securing critical sections with mutexes in this case).
What is also important? If we ask about a mutex and the candidate does not know what it is used for, we can accidentally suggest it by asking another question. Whenever I conduct such a conversation, I let candidate to talk. If the candidate does not mention anything, then I only ask at the end what a mutex is, but it is rather to help the candidate at the end of discussing a given issue, because I can’t imagine explaining the issue critical section not mentioning about mutexes.
The difficulty of this technique is knowing how to interrupt a candidate’s explanations do not follow the direction that we want. We want him to talk, tell, explain and do not want to indecorously interrupt him. On the other hand, we don’t want to waste time talking about secondary issues. Unfortunately, there is no universal recipe. Each candidate tells a different story. With next conversations you will gain practice. Keep an eye on the direction of the explanations and the time.
Don’t be afraid to admit you don’t know something
Sometimes, in a given area, a less experienced developer can know much more than we do. Very good. Admit it and if you think that it can be useful in a project that the candidate has a chance to join, ask him/her for telling more about this topic. Thanks to this:
- we can learn something about that topic,
- we can check candidate’s skills of telling and explaining a topic unknown to someone,
- we show ourselves as a positive organization, with open people and we establish a positive relationship.
Of course, let’s not go to extremes, do not ask questions for which we do not know the right answers. I know a company practicing asking questions during the interviews about solving problems, which programmers couldn’t handle in a project. Are they looking for free consultations or a programmer?
Do the candidate has a skill or just only know?
In theory, there is no difference between theory and practice. In practice it is.
Don’t ask difficult questions right away
To check the candidate’s knowledge of a given topic, first ask an easy question (or very easy if we know that the candidate is begginer in IT), then move on to the more difficult ones.
Asking difficult questions at the very beginning deprives us of information about the level of knowledge when the candidate answers “I don’t know”. After that kind of answer we need to ask easier question. If the candidate will answer properly, then we need to ask more difficult question. It will look like jumping in both directions: easy, hard, not easy, not hard etc. In this way, we will not be able to have a conversation in the style of loose experts conversation, a story I wrote about earlier.
Therefore, start with easy questions, increase the difficulty of questions until the candidate loses his confidence or completely does not know. When this happens, ask one more question, just as difficult or even more difficult. Why? Sometimes, the candidate knows a good answer to this even more difficult question. If not, it means that we know its maximum in a given topic. We can complement it ourselves with a small, quick curiosity “have you heard about X?” Of course, let’s use a tone that will let the candidate know that this is a loose question, not a concrete lifebuoy. If we have time, we can give the answer ourselves and quickly tell about this nuance.
Ask to write a trivial piece of code
Unfortunately, nowadays even the most reputable universities release engineers and masters who are completely unable to write code. From the theory they will say something there, but they do not know the basic patterns. And I’m not talking here about design patterns, but about simple issues, such as providing the sum of elements from an array. One of the better tasks of this type is the so-called “FizzBuzz”:
Write a program that displays numbers from 0 to N. The numbers are to be displayed normally, using digits, except for the numbers divisible by 3 and 5. If the number is divisible by 3, display the word “Fizz”, if is divisible by 5, display “Buzz”. If the number is divisible by 3 and 5 simultaneously, the equivalent number will be “FizzBuzz”.
You won’t believe how many candidates are not able to solve it properly. What is more, these are sometimes programmers with over four years of experience in programming. Let’s face it, it’s a trivial program that can be written in several different ways. Observe the approach to the problem, the solution and the time spent by the candidate. How to assess whether the candidate “went well”? Give such a job colleagues whose skills you know. Based on this research, you’ll be able to tell the developer that he’s at level A because he wrote it in X minutes and used the Y solution at time Z, taking into account that he may have been stressed.
Pay attention to learned problem definitions
Unfortunately, many questions are repeated in conversations. The question “what is a mutex” the candidate has probably heard several times and probably read and learned definition from Wikipedia. Our task is to check whether the candidate used it and understand the idea. That is why I always ask additional questions, eg “what is the difference between mutex and semaphore”, “what types of mutex do we have”.
We have to do this when we have the impression that the candidate is not quite sure what he is saying. I see it most often when I ask a candidate from TDD and testing issues. Usually the problem is answering questions about mocks. The candidate will explain what it seems to understand. However, to be sure, I don’t ask how to use it. I ask “what is a stub” or right away “what is the difference between a mock and a stub”. This is where it gets a little wild.
Using this approach, we solve two problems that may occur:
- the candidate can start telling something he does not know about, and we will quickly catch it,
- some candidates have a problem with quickly defining it, even though they know the issue very well. Asking a question about the difference between two solutions and thus not directly about the purpose can then help both parties.
Isn’t it better to immediately ask the differences between X and Y instead of asking about X first? It all depends on the situation: whether the candidate is strong, do we have a lot of time, etc. I choose this longer path whenever you get a smartie guy who is “so cool”. I had interviewed several candidates who made a bad impression on me because they did not show any respect during the interview, e.g. by the tone of their speech they meant “it’s banal”. If we are experts on a given issue, then we can afford to gain this respect by asking “what is X” and then what is “Y” (where is the subtle difference between X and Y). In this way we try to make the candidate aware that we want him to formulate the answers precisely, not to do it airily. It is important not to assume “he does not show respect, neither will I.” We do not stoop to his level of culture, we try to fix his/her behaviour. Of course, if the candidate does not show any respect at all, we can raise the question, after which he will feel pulped. Is it worth? I will describe it in another blog post, stay tune!
