Technical interviews.
This week has been like living a mirror of the past two, the reason is that I’ve had to exchange roles with the colleague who interviewed me.
On the one hand, it has been quite challenging since I have to find a technical test for my colleague that has certain characteristics, on the one hand, it must be challenging enough to represent an effort that can measure his capabilities as a developer, but it shouldn’t be difficult just for the sake of it, that means, it’s okay that the test represents a challenge, but it shouldn’t be something that involves a single solution or depends on precise data that few people know.
The aim of the interview is to know my colleague's abilities, I am not only talking about his ability to complete a task, but I am also interested in knowing the process that leads him to a solution or an approximation (it’s perfectly ok if the interviewee doesn’t reach the solution).
In this last topic, I learned a lot from the book “Cracking the Coding Interview” by Gayle Laakmann McDowell, which opened my perspective a lot in terms of interviews in the tech industry, I say this because before I had certain prejudices, one of them was that the technical tests were activities full of difficulties where the only thing that was sought was to make the interviewee suffer and only the most trained and virtuous interviewee were able to survive and get the long-awaited contract, all this sounds more to a test of some contest program where only elite athletes can compete and only a very small percentage of these can conclude the tests that are presented to them. Clearly, I was missing the focus of interest in the interviews with technical tests, which is to have a notion of the applicant's knowledge and how is the process that occurs when a task is delegated to them, in order to measure this it is not necessary for the candidate to arrive in a correct solution in a short time, or that it even reaches a perfect result at all, it is much more enriching to see the steps that it follows to achieve its objective, this raises several very interesting questions such as:
Do the interviewee reuse code when it’s necessary, is she/he name their variables in a proper way, do the applicant prefers to create an obvious answer and then refine it, or does she/he prefers to take more time to find the best solution, what is the “big O notation” of their algorithm, is their communication effective with others, does she/he asks for help in time, what is her/his reaction to feedback?
All these questions can only be solved organically when the interviewee is subjected to a process where they are challenged, and also they aren’t treated like a machine, because it’s also the job of the interviewer to be able to make the interviewee feel comfortable, in order to we can get the best of our applicant. Another facet of the interviewer is being able to solve the test in more than one way since only then will she/he be able to help the interviewee when she/he needs it.
As you can see, it has been a week full of learning and challenges that I had never faced before, but that is a good thing because each challenge presented represents an opportunity to improve and be better, something that is always greatly appreciated.
