Interview Technique ā€œMoStā€

It is not customary to talk about this out loud, but many candidates embellish their skills, and sometimes openly lie at interviews to get a job. For the employer, this is by no means a comforting fact, because an unscrupulous employee will not make itself felt right away - it will take a lot of effort, time and money of the company before it becomes clear that the return does not correspond to the resources invested. And by decision to say goodbye to a man, you still have to look for a new one ...

An error in selecting an employee is a long-playing phenomenon, therefore it is important to immediately investigate as much as possible a person who has come to show himself. The MoSt technique can help us with this. The interview, according to her testament, takes about an hour and provides for a structured interview of the candidate in two parts: technical and personal. You can conduct an interview both live and by phone / video.

The technique is designed to teach you to get more meaningful information about the candidate, but it will not increase the number of candidates and improve their skills. MoSt, however, will increase your chances of success when deciding whether to hire a person.

25 questions


So, we are going to have an interview. For the first, technical, part, we are preparing 25 questions, divided into 5 groups, with a total duration of 30-40 minutes:

Interest
(the group is important when working with a young candidate, as experienced programmers often have a high level of responsibility due to the presence of a family, obligations, reluctance to change jobs; also highly relevant for posts with a large flow of new requirements: outsourcing, experimental products that have not yet been tested by users and can change dramatically)

Often, candidates try to demonstrate interest in what your company is doing, or in the profession in general, and already here we must take the first step. Itā€™s easy to say ā€œIā€™m interestedā€, itā€™s impossible to imitate interest, so we will select a few questions that show how much a person is really interested in what he is doing. Attendance at conferences, blogging, forums, personal projects, participation in Open Source developments, knowledge of programming world news and IT history, scientific ideas, such as cyclomatic code complexity and formal verification of algorithms, the principles of KISS, DRY, SOLID and all that you mean they themselves could not help but hear at work - these are sure signs of interest. Questions can take the form of a free conversation, but the essence should already be clear to you. An interested person is always valuable,because interest generates a genuine desire to understand, develop and succeed.

Interest is everything, without interest we are just people.

Programming language
(most relevant for young programmers (<5 years of experience); is also of high importance if the candidate has worked for a long time in one company or as a freelancer)

Actually, the core of the interview. The candidate must know the built-in language tools, data structures, standards for writing code and its organization. This group of questions should maximize the candidateā€™s technical base, so choose carefully! Among other things, it helps to understand how thoroughly a person approaches the matter. People who aspire to just get a well-paid job, as a rule, demonstrate a high knowledge of specific (demanded in the market) frameworks, but a low awareness of the built-in language features, without which it is quite difficult to successfully solve new (for a programmer) tasks. The programmer, "for love," usually starts with the basics, the very essence, and, as a result, having a good base, is much better at coping with the new one.

Toolkit and self-optimization
(the significance of the answers increases with the candidateā€™s experience of less than 5 years due to the high probability of ignorance of tools and more than 15 years due to the widespread refusal of further development; it is especially significant for candidates for small highly loaded teams)

This group is designed to determine which development tools the candidate uses and whether he seeks to simplify his work. This, as you might guess, includes questions on version control systems, application deployment and delivery, IDEs, OS capabilities, code planning and monitoring tools (measuring program complexity, test coverage, memory consumption, index maintability ...). This group of questions should help to evaluate the candidate's efficiency, scientific nature and scrupulousness of his approach.

Architectural skills
(the significance of the answers is extremely high when selecting a leading specialist, because he will make decisions that affect the work of the whole team)

The third group should reveal the candidateā€™s ability to write convenient, flexible, easily maintained code. In most cases, questions rest on knowledge of the main language paradigm: OOP, component programming, interfaces ... We also add here documentation, arranging a Git repository, application deployment, auto and unit testing ... That is, it is not so much about knowing specific things, but about the ability to properly build the product, make it understandable, easy to use and support, sustainable, easily tested and assembled.

An item with a review of the candidateā€™s personal projects (if any) fits perfectly into this group, because it is in them that the ownerā€™s familiarity with the order and architectural preferences are revealed.


Specificity and thinking
(relevance increases with the complexity of the position for which the candidate is considered - for example, general-purpose desktop programming is simpler than programming games, financial or mathematical programs, Big Data)

This group includes issues directly related to the direction for which the candidate is being considered. Very often (I have seen this myself more than once) specific questions do not sound at all. This is a big sin: a Python programmer may be a good programmer or CLI developer, but have absolutely no experience in Web development, and even not know its basics. A frontend developer / designer is likely to become a weak backend developer and maintainer of the database. Game development is a very special patrimony. There are many examples - one thing is clear: one cannot do without job-specific questions! In modern programming, there are too many directions and not all of them have similarities with each other, so experience in one does not guarantee success in the other.

Also, this group should include a couple of questions on algorithmic and low-level thinking. They do not have to be complicated, but the candidate must have an idea of ā€‹ā€‹what his program does at a low level, in what order, how much time these or other teams take relative to each other, what bottlenecks they have, how to save computing resources and solve the problem in less actions.

What's next?


Actually, we have 25 questions - what now? Now we need to ask these questions and, based on the candidateā€™s answers, answer five questions about the interviewee ourselves:

1. Interested in : will he try, develop at will, will not hate his work as such?
2. Has a technical base : is he familiar with the fundamental means of the language, knows how to use them, and will be able to solve problems "not from a textbook"?
3. Organized and economical : he appreciates his time, efforts, pays attention to the selection of tools and will try to simplify the life of himself and the whole team?
4. Architect : he can be entrusted with architectural solutions, he organizes the code understandably, extensibly, easily verifiable, so that the team can work with him?
5 Suitable for position.: Does he understand the job-specific issues and has a fundamental understanding of what is going on in her?

Based on the answers, we can understand what awaits us and our team with this candidate professionally.

Personal qualities


An important factor is determining the psychological profile of the candidate: he is a workaholic or lazy, prefers to do his job or will (possibly with envy or discontent) look at other employees, will decompose the discipline or, conversely, will support it with his actions - the second part is devoted to clarifying all this interviews (20-30 min.). The questions for determining personal qualities ask themselves: what did not like in the previous team, at the last workplace, which work conflicts were remembered, how often do you process and for what reasons ... - the story about all this can reveal a lot about the candidate.

Cunning, betrayal, falsity


The sad truth is that many candidates lie at interviews (about 70%, according to various sources). Can this be counteracted? I will formulate my own approach:

1. Determine the candidateā€™s skills that are not personally suitable for you . Something that, according to the candidate, he knows how, but you do not have to, because the position does not oblige. Suppose you didnā€™t require SQL in a job, but the candidate claims to be an SQL master.

2. Make the candidate speak. Ask a lengthy question regarding a skill such that the interviewee has the impression that you are not versed. As a rule, in such a situation, liars go on the attack, because itā€™s very easy to hang noodles on the ears of someone who does not understand, and show yourself as a ā€œconfident PC userā€. Moreover, the technical interview is already over, and ā€œaccording to the sandwich rule, in the end itā€™s necessary to make it clear that itā€™s nothing, that Iā€™ve got a little sleep on technical issues, Iā€™ve taken apart everything in the past work, I became an expert in everything, and they donā€™t remember what was in the middle. ā€

An example from personal practice:

I in the company of an employee interviewed a Go-programmer who claimed that he had worked with Firestore for several years, as well as PostgreSQL. Neither one nor the other was mentioned in the vacancy, so the following situation develops: the interviewee claims that he is practically a master in what we ourselves are not the last people. However, he does not know this - he does not know that we have experience in both Firestore and PostgreSQL. He only knows that we are Go-programmers, and by the answers to Go-oriented questions he is clearly not a winner.

Without hesitation, we asked the interviewee to tell him what he was doing on Firestore, and then on SQL, "so that people who werenā€™t in this one understand." According to him, he designed databases and tables, indexes, wrote new queries and optimized the old ones after other employees (that is, we heard confident, loud, but very general statements). What was his surprise when we started asking specific questions about the Firestore device and SQL (thereby revealing our own experience), and how little he could tell us.

However, we did not say that we did not understand, we only asked to tell in such a way that unknowing people understood. The innocuous manipulation allowed us to determine that the candidate has no idea about the Firestore device and JOINs in SQL, and, most importantly, is trying to deceive us. Yes, we donā€™t require knowledge of Firestore, and we donā€™t use SQL at all, but we found out that the candidate wasnā€™t reliable, and he was hardly a successful programmer at the previous job, because he did not understand what he was supposedly doing there.

With the help of silence, retention of information about ourselves and stupid questions, we created the impression that we were not in the tooth, gave the candidate to seize the initiative, start talking. Provocation? Hardly. We just created a situation in which a lie would be beneficial, we looked at how the candidate would behave, and then we proceeded to the third, especially important step.

3. Concrete. The interviewee must answer questions specifically! Do not let confident speeches mislead you - each statement must be evaluated for concreteness. The phrase ā€œI worked with Angular for two years, completed three projects, and in the fourth I was the leaderā€, even said in a confident, ordinary tone, still does not really mean anything. Try to find out from the candidate what exactly he did, what he knows, what difficulties he saw, how he decided them - if he really tells you something technically specificthen you can begin to believe. If the conversation continues with general phrases and attempts to evade direct answers, it is better to end it smoothly - we are looking for real evidence of experience, rather than unfounded allegations that still have to be tested in practice. A person cannot write a program, but cannot understand it at all, because in our profession, understanding precedes the result. One who understands, can express himself specifically. One who does not understand, this certainly can not.

The program does what you wrote in it, and not what you want from it.


Order


Perhaps this is not obvious at first glance, but there is a certain order in this interview technique. The first group of questions is simple and allows the candidate to get used to the situation, to relax. The second group throws in technical questions, after which there is a jump to the tools, then a return to programming issues and then to the most difficult one - low-level and specific questions. The load and topics are jumping, it is necessary to at least look a little at the candidateā€™s ability to switch between tasks. In the third and fourth groups, it is recommended, whenever possible, to exert psychological pressure, put the candidate into a dead end, create the feeling that he is not saying exactly what is expected of him. This is necessary to create tension in order, again, to at least partially evaluate its behavior and performance in a stressful situation.

After the candidate is thoroughly loaded with technical questions, a personal survey begins. In practice, this moment falls on about the fortieth minute of the interview - the time when the candidate is already quite tired, begins to lose his vigilance and honestly reveal the details of his personality.

Conclusion


Many details of the technique were omitted in order to shorten the article, however, the essence of the approach is fully disclosed. MoSt requires a half-hour preparation for an interview from the person who conducts it, attentiveness and some acting skills, but it offers the following advantages:

- You can identify those who came for the money. Such an aspiration is not always ā€œthe code is red, the code is red, we have a careerist here!ā€, However, an interested person is usually more successful than someone who seeks only profit.
- Questions are asked by specific groups. This allows you to determine the strengths and weaknesses of the candidate and, based on the context, make the right decision. For example, when searching for a Junior, architectural skills will be a plus, but they will not have increased value, and when selecting a person for a highly loaded team, it is important to understand whether he will cope with complex development tools, which no one has time to explain the device.
- With due care, you will identify liars and those who have prepared "five minutes before" - as a rule, they answer some specific questions well, but when considering the situation, they begin to stumble from different angles.

In conclusion, it is worth saying that some may find the MoSt technique provocative, but the interviewer only needs to manipulate - creating situations in which you can see the candidate in the true light, and not the image that he prepared for the interview - but not an obvious lie. Our goal (of people conducting interviews) is precisely the fight against lies and the collection of significant, reliable information.
-
Ilya,
QLogic LLC,
Python / Go developer
GitHub acc | Personal page

All Articles