Tips for technical interviews

By Carlos Blé Jurado

Among the many services we offer to our customers, we help them improve the way they conduct technical interviews in their search for developers. Everybody is looking for developers, for senior developers to be precise. We do conduct interviews too, all the people working at Lean Mind went through our process at some point. There are at least two interviews, one that is non-technical with the aim to get to know the candidates, their values, dreams and aspirations, as well as communication skills. The technical interview happens one or two days later.

Candidates will always be nervous during the interview no matter how kind and welcoming the interviewers are. Those nerves introduce noise in the process, interfering with the communication. The first thing I say to the candidate when I notice he or she is nervous, is that every single candidate is nervous, and that I’ve been the interviewee myself too, and so I know the feeling. I explicitly say that we may take breaks whenever we want, there is no rush, and we assume people are under pressure and expect them to make mistakes and underperform. This acknowledgment usually makes people feel a bit less pressure. As the conductor of the interview, one of my goals throughout the session is to watch for the level of stress of the candidate, because when adrenaline goes up people can’t think properly as they would do at work in a regular day. All I want to infer from our short time together is whether we will work well as colleagues on a daily basis. My aim is to guess if the person has the skills we need on the team, and we find that the best way to do so is to spend time working together on actual, concrete problems, with code.

We don’t ask abstract questions based on theoretical scenarios, we work with actual code all the time. We know that many companies ask questions based on simulated scenarios, aiming to assess the knowledge and expertise of the candidate on software architecture, patterns, methodologies or technologies. Questions along the lines of “how would you connect two heterogeneous systems that run on separated processes?", “how would you optimize for a SQL query?", “how could users sign on different systems at once?"… the problem with these questions is that there is no context and thus there could be many possible answers to them. Perhaps the interviewers have a clear expectation of what the answer should be, as they probably have some implicit context on their heads, but for the person being asked, abstract questions with multiple possible answers are confusing. This leads to awkward feelings, making the candidate feel more nervous. People wonder whether the possible answers coming to their heads are too naive, too simple, or perhaps too complex. It’s a psychic game where the candidate is not only balancing technical answers but also guessing what should be the expected answer. Things get even worse when interviewers make disappointed facing gestures or express frustration. What the interviewers really want to know is how the person thinks, what is the flow of ideas coming to their brain, but unfortunately this is not what happens. The reality is that the candidate will pause and try to hide doubts or emotions, trying to look self-confident and wise or at least to match up the expectations. This game does not help to know how the candidate would work on a daily basis, because in the real world there are concrete problems, there is code, diagrams and white board discussions. If you want to know how people think, is better to be very explicit about it and tell them. My advice is to be very concrete and use code to make sure questions are very clear. For instance, if I want to know whether the candidate knows about reactive programming and observables, I open up the IDE and navigate through code using them to ask “do you know what this code is doing and how?", “could you explain it to me?, “how could we change the code over here to make it return X property or value”- we work on actual code, solving concrete problems.

My favorite way of conducting code interviews is practicing pair programming, specially working on the candidate’s machine. I ask people to bring in their laptops or to set up their machines at home if the interview is remote. Just getting to see the setup of the candidate gives me tones of information on how she or he likes and knows the tools, such us the IDE. I get to see plugins, shortcuts, templates… The candidate will feel more comfortable, as the environment is familiar to her, and the stress will not stop her from using shortcuts, running the tests or indenting the code. If she usually works like that, she will do that automatically during the interview, even being nervous. I am the one who makes an effort trying to adapt to her tools, asking questions out curiosity as things show up on the screen. This way I can even feel her empathy (or the lack of it) when I loose track. I love when I learn new things in the interview and also when the candidate wants to learn too. It’s very cool when she asks for a shortcut I just used or when she techs me one. This experience is much closer to what it could be on a daily basis. This is what we want to simulate in the technical interviews. We don’t want to make people feel awkward, inappropriate, ignorant, or unskilled, even if they are.

Of course you might be thinking this is too expensive but, isn’t it more expensive to discard talent mistakingly? or to hire the wrong candidate? In my experience it doesn’t take more than one hour to discover that a candidate’s skills don’t match what we need for a certain position at a given time. Sometimes I get the impression that they will improve a lot over time and encourage them to come back in the future for another interview. In some cases though, the technical interview could take two or three hours, and when it goes well, we often run another session with the current members of the team so that they get to know the candidate too. All of us treat people the way we would like to be treated. We don’t expect candidates to behave or to have skills we don’t have ourselves, so the interview must be conducted in a way that we could succeed ourselves if we were the candidates. Sometimes interviewers are so hard and unrealistic that they wouldn’t even pass the interview themselves if roles were to switch. We don’t want to go there.

For further information, if you understand Spanish, I encourage you to listen to this podcast on how we run the technical interviews.