who, where, how and why (and to what!). Part 2
The second part of a large-scale article about interviews. The first one is here. Last time we talked about the ideal candidate in a vacuum, as well as the presentation part of the interview. Here we will talk about the technical part and about the direction in which we would like to develop the topic of interviews.
At the end I added a section with bonus sections – tips and observations for those who conduct interviews or come to them as a candidate =)
9 (okay, 7) technical interview rounds: how I test applicants
So, candidates will definitely encounter some things during an interview with me, and some they definitely won’t. Let's start, perhaps, with an analysis of the first ones.
Testing your curiosity in life
In support of the previous stage, here too I like to ask strange questions: “And if you worked with technology A, you know that there is a technology B similar to it, why do you think they came up with B?” Moreover, I do not delve into narrow areas of knowledge: supporting the example about the DBMS from the first part of the article, I can ask: “There are relational databases, but why did they start inventing non-relational ones?” I'm not expecting an academically accurate answer, I'm interested in how much the candidate thinks about the world around him.
Checking your understanding of spoken words
In technical questions, I pay attention not so much to the ideality and technical refinement of the answer, but to the understanding of what exactly the candidate is saying and his ability to think.
Let me explain with an example. Let’s say in a conversation a candidate utters the phrase “microservices are more fault-tolerant than a monolith.” Here I will be sure to clarify what exactly the candidate means by fault tolerance and why he makes this conclusion. To test your ability to think, I can ask you to consider whether some popular statement is always true. I often also use questions with antonyms: for example, if the candidate confidently talked about data normalization, that it is wonderful and should always be used, I can ask the question: “Do you think denormalization is ever useful?” If the candidate himself does not voice any of the fairly common statements, I can say something like: “A popular statement is that microservices are more fault-tolerant than a monolith. Do you agree with this statement and why?” (and yes, I don’t mind answering the question “What do you mean by fault tolerance” =) ).
Testing task perception
If I give a candidate a practical task, I monitor whether he has thought of any introductory notes in the background. The specificity of analytical work is such that thinking for the problem designer is a way to shoot yourself in the foot, at best. Therefore, I expect from a good analyst that he will interview the interlocutor on the questions and blind spots that have arisen. I often notice that candidates come up with their own task, altering the original one from the prism of their own experience. When initially perceiving a task, it is useful not to allow this to happen, otherwise there is a risk of solving not the customer’s problem, but your own.
Checking exactly how the candidate works as an analyst
As I wrote in the first part, an analyst is a bridge between business and programmers. Therefore, one of my favorite tasks is to indicate that a business needs the functionality of, say, a new banner in a personal account for a certain group of users. I also inform the candidate that he can ask questions about development and business – in our interview I play the role of both. The goal is to collect a list of development requirements. The task is quite difficult for the interviewer himself, because… it has fairly open input, plus you need to follow the candidate’s thoughts, record his questions and not forget the answers to them, so that the process of working on the task does not unexpectedly end or incompatible initial data does not intersect. During the decision process, I also use a little provocation: for example, I inform that the business wants additional functionality that will cost the developers a lot.
A conversation like this is worth having. Different grades are very well separated from each other: juniors immediately go into “micro-design”, while more senior guys think about whether similar functionality already exists in the system, and try to find out the details of its implementation. Here you can also track whether the candidate is ready to think critically, because the source data does not contain a description of the problem that this banner is trying to solve. A fairly small number of candidates first start talking about the real problem – for which they receive a significant plus in karma =) I note that the final result is quite unique each time, and a couple of times it was most unexpected for me.
I also try to make all the other tasks that I give as close to reality as possible. I ask what you will indicate to the development, if you need to design this and that, where you will start if such and such a request arrives, and the like.
Why am I not particularly interested in knowledge of theory? Because we all have a computer and the Internet at our workplace. We do not take into account the cases of closed enterprises – if I had interviewed there, the policy would have been different. If you have a computer and the Internet, you can find and study any theory. And in the same way, a couple of hours before the interview, you could invest everything in the RAM. But how ready are you to apply what is already in your head – this question occupies me much more.
What is difficult to see during an interview with me?
Lengthening the interview for the sake of protocol
Among the interviewers in our company, there is a certain list of questions that +- everyone asks. But I’m disgusting and don’t follow this protocol too meticulously. I can even check with the candidate whether he is confident in his knowledge on a certain topic, or whether it is better to omit this section. If I see that the interview is not going at all (but this happened only once at the time of writing), I can finish it quickly enough. What can I do? It’s more interesting for me to test the ability to think and apply knowledge from those areas in which the candidate is confident than to check all the hard boxes. Yes, I test curiosity, but I don’t push it. Is it good or bad? Well, it seems that project managers haven’t thrown tomatoes at me yet for the guys they selected :'D
Once upon a time, a person who interviewed me at STM Labs said that he could already understand what and how just by the appearance of a candidate coming in. It sounded very self-confident to me at the time, but now I understand it. Whether this is a distortion of perception or not, it seems to me that by looking at the eyes you can understand 70% of how much a person is accustomed to mental work. However, I use this criterion only to accumulate personal statistics =)
Communication in areas that analysts do not encounter very often (and it is not a fact that they will encounter them here)
Although I love passionate and curious people, everything has its limits. There are blocks that rarely concern analysts directly: for me, this is, for example, the device of the OSI model, issues of automation by writing scripts, issues of working on Linux. If you have to deal with this in a project, it’s not a problem. But just like that, for the general portrait of the candidate… I don’t know. It’s good to know the differences between HTTP and HTTPS, it’s great to be able to write automation scripts, etc., but, for example, the last time I was personally affected by the issues of IP networks was during the era of working in technical support. And we must also try, by including such questions in the standard protocol, to find in the company the required number of interviewees who are competent on all topics. But if the candidate comes across as savvy enough, you can end up in a puddle, squandering the company’s image. It’s much more important for me to find a smart person who, within an acceptable time frame, will pick up a topic that is unfamiliar to him and begin to apply his knowledge. And this again is not about hard drives, but about software.
Same questions for all grades
A lot has been said here without me saying that “you need to know as a junior” and “you need to know as a middle”. I myself add a little more questions on hard games, depending on how senior the candidate considers himself. But, as is obvious by now, I’m a fan of software 😀 I even change tasks more often: for the senior, I’ll try to come up with something more vague for design, I’ll give less specific input and more freedom. For June I’ll give you something not on the global scale.
Where: is it possible to make interviews even more effective?
Another joke just a minute. So a couple of my real thoughts:
Adding more relevant task forms
What do we do now when solving almost any problem? We are looking for information on the Internet. I would like to come up with questions for which the candidate's initial skills will probably not be enough, and he will have to turn to Google. And let him search. There is a risk, of course, that he will feed the entire task to one well-known language model, but such a risk is possible with any question.
I even have a candidate problem, but it is quite senior and requires a little more understanding of the code structure than analysts, even systems analysts, are used to. No, you don’t need to know the specifics of a particular language, but it is important not to get confused by the type of functions and understand what importing libraries is. I’m embarrassed to give it out yet, I’m testing it on friends. Programmers, I must admit, cope more successfully (well, what did I expect :D) – read, always successfully and super-fast =)
Adding more project focus
I would like to delve more into who the manager of a particular project is looking for, and what this project is about. Yes, yes, software decides, but customer focus is also useful. Why am I not customer-focused enough now? I just don't have time for it, to be honest :'D
So far I see a couple of such growth points. If anyone shares their ideas in the comments, I will be very grateful =)
Bonus section 0: so what
In the comments to the first half of the article, I was caught by the fact that the “so what” section (i.e., why all these ritual dances) is missing.
Everything is simple here – so that the company has strong specialists who are ready for a variety of challenges, who value their work and develop.
Bonus section 1: harmonious coexistence in a couple
As I wrote above, sometimes it happens that there is more than one analyst conducting the technical part. We usually have no more than two. For this case, I also have my own code of honor/approach to interviews.
Don't forget about your neighbor
If there is a second interviewee, and I find myself in the role of the main presenter, then I try not to forget about my colleague. She asked what she wanted and passed the baton to him or her. Once I found myself in a situation where it was as if I didn’t exist for the second interviewer. It’s extremely unpleasant, don’t do it like that.
Finding the right strategy
To ensure that all interviewers are equally helpful, it is important to assess what is happening correctly. I have come across the following approaches to separation of duties:
It is effective, for example, in the following situations: the second interviewer is just learning to be an interviewer, the second interviewer is tired and wants to relax.
We each have our own unique experiences and areas of expertise. It's great to consider each other's strengths. I had such synergy with one analyst, it was a pleasure to go to interviews =)
Bonus section 2: especially for candidates – we lift the curtain on the world of interviewers
Here I want to tell all candidates that the interviewer is also a person. He may also be tired, he may not understand your idea, he may be thinking in the background about whether he turned off the iron at home. We may also be scared, for example, that you will be so great that we won’t be able to conduct an interview =) Often we worry that it’s not your knowledge that is insufficient, but that we don’t ask questions well.
If you feel like the interviewer didn't understand you, or you're so worried that everything has slipped your mind, don't be afraid to say so. We are all human and understand everything, and a successful interview is an interaction on both sides.
Bonus section 3: how do you behave as a candidate?
Something like this, to be honest:
I told you about my interviewing habits, and I’ll also share what kind of candidate I am.
Being honest about my weaknesses/areas where I don't want to develop right now
For me, this is, at a minimum, designing user-friendly interfaces. Well, that’s not interesting to me, no way. And Frontend design is also not going well, I need to understand the specifics of frameworks, but I’m more interested in diving into OOP in Python, or deploying an unknown DBMS, well, what can I do. Unexpectedly, admitting weaknesses is beneficial – I am increasingly finding myself on projects that require skills that I like to develop.
Honestly, I need to google somewhere and expand my knowledge
I was once told about a programmer candidate who, during an interview, said: “I remember how to do this, but I can’t tell you the exact syntax, I can Google it.” Excellent answer, I think 😀
I dig into problems, trying to understand what problem they are intended to solve.
Often tasks then fall off abruptly. I was once asked the following situation: “You need to add a new column to the report, in which you need to display the average value for the row. What will you do?”. I say: I will ask what this average will decide for the one who uses the report. Why did they live without him before, but now they can’t? Either this was the expected answer, or the interviewer did not know how to continue. In the end, everyone liked me 😀
I don't prepare for interviews
This is my personal problem, based on the fact that you can put sooo much information into short-term memory, memorizing everything a couple of hours before the interview, but after it, when the period of relaxation comes, 90% of the information (or even more) will safely disappear from your head. It turns out that I am deceiving the company for which I am interviewing, demonstrating to the interviewers knowledge that I do not have. I don’t like both the fact of deception and the potentially high expectations of me at a potential place of work. This will add nothing but extra pressure.
But in general I'm quite stuffy =)
I don't know how to answer standard questions for most people. Recently they asked: “What artifacts do you leave behind after the work has been done?” Probably, they expected something along the lines of: “I use notations A, B, C, I know GOST 2029-100500 and I keep track of the results of each meeting.” The interviewer received not this, but the question: “What is the structure of the team, and where does the analyst’s area of responsibility end? If there is an architect, it’s one story, and it even depends on how much this architect is about technology…” – and so on.
Because the analyst is a way of thinking. And how I will display it in artifacts is a multi-parameter task =)
