Interview in the hands of maniacs

Interview in the hands of maniacs

A typical interview

Good afternoon, my name is Oleksandr and I’m a toxic suffocator with twenty years of experience in IT, ready to take a bite out of you as soon as you relax. My characteristics make me a good technical interviewer, so welcome to my failed interview. Remember that you will never pass it. And do you know why?

Because I know the questions I’m asking better than you. Believe me, only God knows these questions better than me. Yes, I don’t know the other questions, but the ones I ask, I know inside and out. And since I am interviewing you, and not you interviewing me, I guarantee you that you will never be able to answer without me correcting you, at least on one point. And even if you pass all the questions, I’ll always have a Hobbit ring question up my sleeve. And believe me, you are not at all clear-sighted Gorlum to guess what beauty I have in my pocket.

Recognized? This is how interviews are conducted in 99% of non-top companies around the world. Unfortunately, this is exactly the path I took at first. To oppress, humiliate a person. To find its subtleties, to knock down the bar, to trample and bring the technical skills under the stencil I set, which, of course, will be similar, but accurate, as well as the caricature is accurate with the original. This is often a good technique. It can even be used during recruitment. Especially when there is no money, and the illusion of employment must be shown. But when such a technical interview is done as a real tool for determining the quality of a specialist, it is useless. Of course, it will encourage the guys to work on themselves, but it will not give the employee what exactly he needs to work on.

So I started analyzing interviews. I watched several interviews every day. I’ve gone through and read every list of frontend interview questions (myself included) that I could find. I went through several interviews in the open to understand one simple thing – most one-round interviews are useless. But hiring an employee without an interview, as some experts advise, in modern Russia is a waste of the employer’s money. And if the answer is not in our field, then we can look for it in the field of pedagogy. Who, who, and they have definitely learned to distinguish a slouch from a homework, from a student who knows the subject.

Bloom’s taxonomy

Yes, I am talking about Bloom’s taxonomy. Let me briefly explain what I am talking about so that those who did not study at the Pedagogical University will understand me

Benjamin Bloom, in the middle of the last century, pointed out that any knowledge within a person goes through several stages of fixation in the head. Remembering, understanding, applying, analyzing, evaluating and creating. And if you translate it to our IT, then these stages will be approximately as follows: I heard somewhere, read a couple of articles, have work experience, read the code of this abstraction, made a pull request to it and participated in the creation of this thing.

So here it is. Bloom and some similar theories suggest that this is a ladder, each step of which is supported by the fact that a person must have passed the previous step. However, in the IT (and, I think, some other craft-engineering) spiral of knowledge, this is not quite so. And even vice versa, a person who has studied the principles of work inside a framework knows much less about the framework, the patterns used to work with it and the flow, than a person who has done several projects on this framework. For example, I knew about how hooks are arranged inside react before I wrote the first application with hooks and learned how to properly prepare them. And I will say even more, making an attack on the sacred, the developer of the framework himself knows about how to use his brainchild less than the one who uses it in daily mode. Therefore, the scheme of knowledge level to mastery will look a little different

This deviation is the main problem of interviews, we practically cannot evaluate a person’s work experience in a given short period of time.

Why did I decide that? It’s all about questions. Let’s write out the formats of questions from interviews and think about which questions will give us the answer to the question – is this a person who is not trained or does he really have experience. That is, answer questions different from the degree of application.

First, let’s write those question templates that, in my opinion, should not be asked, so they answer at other levels:

  • Quiz questions.
    Options: What is. ?; How called … ?;
    Question, ala, “Your game”; This is the most wrong question imaginable. But also the most popular. He answers whether a person has the first stage – memorization (heard somewhere), but he will not tell us whether he worked with it. Although, by the way, some of the answers to this question show very well where he heard it from. For example, ask Jun’s javascript what a closure is. You will be very surprised how easy it is to recognize from which courses it came to us.

  • The issue of enumeration
    Options: List …; Which … are in …;
    Also very popular and also incorrect. It also belongs to the memorization stage. However, it has a counterexample from the application stage that relates to the desired stage, more on that later

  • Essay on the topic
    Options: Tell about [название технологии]…
    Also questions from the memorization stage, but they can be a precursor to the next question. Or a test for knowledge of a very narrow field of the question, which is practically not found in the practical field, but it is necessary to know about it, and even sometimes use it

  • How it works
    Options: How … does …; What happens when …; How is it happening…; How does it work…;
    This is a question from 2 categories at once. From the category of understanding and the category of analysis. It all depends on whether there are articles/books/videos on these issues. If not, then this is a test of the analysis stage, it allows you to determine how adequately a person thinks, and whether he can reason. It is another matter when information on these issues is freely available.

  • Talk about the paranormal
    Options: Explain …; Imagine …; Why did it happen…; (code) WTF?
    This is also a question from 2 categories, on the one hand understanding, on the other – analysis. And here you can’t be sure whether it shows that a person encountered a solution in some video or article, or that a person really found this solution in front of you.

  • Question of the level of ЖОПП (life experience gained in practice)
    Options: What are the features of the application…; What will happen if … pull on …;
    On the one hand, these are good questions, and if the interlocutor was able to answer them, then they show that he has this experience. But here is the problem – the opposite does not show that a person has no experience. Not every interviewer has the same specific expertise that you need to solve this problem

Well, it seems that there is no need to ask, and why we decided. And then what to ask?

My advice is to ask questions based on your area of ​​expertise. That is, those questions to which you can get specific answers based on practice. Such questions help to understand how a person actually acts, and not just what he thinks about it. In addition, they can suggest what skills and techniques can be used to improve work efficiency. Example:

  • Search for errors by eye
    Question patterns: (code) Find the error in this code; (code) What is the problem with this broken code; (code with test) The test will fail. Why?;

    For example, we often asked juniors in the very distant past how let differs from var. And then they started showing the construction with for (var and asking why it would output 10 times the number 10. Until it became commonplace, this was just a way to get around learning the let-var-const question. By the way, after a bunch of articles on this topic, the question moved from the field of experience to the field of analysis.

    Another, also slightly hackneyed example, in the filter.map.reduce code reading block, I give the construction .map(parseInt) and see how well a person knows the problem of using functions of several variables filter/map/reduce. Surprisingly, this question did not enter the sphere of analysis, but remained the sphere of experience

  • Optimization by example
    Options: What is the complexity of the algorithm and how to speed it up; What is wrong with this working code?

    Here, let’s also give an example on social media with a junior block about optimization. One of the basic questions in June’s interview is: What is React.memo? (Well, it is more old according to PureComponent). But not every June and even Middle knows how to use them in practice. For example, to the question of what is wrong with this dress code:

const Component = ({items}: Props) => {
	const viewItems = items.filter(checkViewItem).map(renderItem);
	return (
		<ul className={styles.container}>
			{viewItems}
		</ul>
	)
}

not every medium will talk about optimization and rerendering of components. By the way, a question for middlemen, is it more profitable to use React.memo or useMemo? Think before you answer.

  • Synthesis of experience
    Options: List the ways ….; Come up with N ways to use…;

    A similar example from June’s interview: List the value of the position quality. But in reality it is not at all interesting from the point of view of experience. From the point of view of experience, we want to know if June can work with absolutes. Therefore, it is more correct to ask this question in the following context: As for the positioned element with position: absolute. And if June says that about position: relative, then ask what will happen if another element with position: absolute is placed in one position: absolute. Or ask a question that can be used to extract an element from the stack context and why it is needed at all.

  • An architectural question
    Options: How to do …; What methods…; What patterns to use …;

    This type of questions, which are better to ask on vacancies from the middle. In larger companies, there are entire architectural sections where you tell how to implement some functionality. Unfortunately, in small teams, no one will let you communicate with a candidate for 5-6 hours, and candidates will simply get up and leave after two hours. Here you need to approach more sterile.

    For example, asking to tell how to implement some component, be it a table with pagination or a list of objects. The main thing is to limit the time of the story to 5-10 minutes. Or ask how you can optimize the rerendering of a component that depends on part of the values ​​of the global context.

    You can also talk about state managers, assemblers, css-in-js and take 5-6 minutes to holivar on some topic. Yes, it is very toxic, but it will show the developer’s soft skills very well. And sometimes it will even save you to take on a relatively large legacy project of a person who will insert the linting rules transferred from the previous work into the first commit in the developer.

  • Tell us about your ZHOPV
    Options: Give examples of the use of…; And how was your project implemented?

    Very good and at the same time difficult type of questions. Usually, the question is formed at the first stage of “tell me about yourself”, when the interlocutor talks about the latest project. Here you have to stay awake and notice what kind of project it is, what tasks it has set. And already at the stage of the technical interview, you can ask how you did it on the previous project, which libraries you used, how you solved the limitations of the libraries, etc. This allows you to dig deeply into technology, into the area of ​​responsibility of the interlocutor, his initiative and proactivity.

    For example, the interlocutor says that he had a calendar with a time reserve on the project. You can ask how the transfer of the reserve of the second day, week was implemented. One might ask how availability of the backup resource was checked and how exceptional situations where the backup could not be moved were handled. A person who actually did the project, and did not make it up in his head, will answer these questions quite correctly within his competence. At the same time, it will be easy for him to talk about it. The only thing holding him back is the NDA. so the answer will be enough with a long delay to know whether the NDA is violated by this “revelation” or not.

PS A knowledgeable interviewer will say that all the questions are from yesterday and should be replaced with life coding and algorithms. But what is wrong here, why it does not work well and what can be done, we will talk about it in the next article.

Related posts