Thesis: you should not be interviewed if you have not attended at least three interviews as an applicant in the past six months .

Moreover, you yourself know this perfectly well, consciously or subconsciously, but corporate ethics makes it difficult to state your doubts directly.

To attract attention, we show the picture and continue.

Often at the interview, people look at the process of the interview rather one-sidedly. However, most experienced applicants conducted interviews at least once or were interested in them quite recently (in order to make life easier for them). However, on the other side of the table sits a person (not always, but very often) who came to the meeting in the middle of the working day, the project is still spinning in his head. From here we get that the same questions and answers, the applicant and the employer look differently .

As I said above, you should not be interviewed, if you did not go to at least three interviews as an applicant for the past six months , otherwise you will simply be interviewed extremely ineffectively, you will fall for standard traps and manipulations. And in the end, hiring is not the one who you need. However, corporate ethics still make you report that "everything is done correctly, the team has become more, now we will definitely have time for everything."

I found at least three standard themes that prevent us from hiring a competent person. All of them are united by one thing - if you follow the advice from the thesis, you yourself will clearly understand why they are only knocking you down when talking with a future member of your team. However, it is important to remember that the thesis has a downside: if you know that you are having a bad interview, but you absolutely don’t want to improve anything, you don’t want to hire competent people, you will find hundreds of reasons why you shouldn’t waste your time on interviews .

All topics are a compilation of interviews for the post of a programmer (including their own and the stories of both parties).

Stupid topic # 1 - talk about philosophy

So, you came to hire a company. You are a good plowman in your field, you have experience. You are not a super genius, not a Nobel laureate. You are an ordinary highly qualified specialist .

On the other hand, the team leader is sitting (or the project manager, or the middle manager, who may even have once programmed). His project is on fire, he doesn’t know at all who came here to talk to him. The only thing he remembers is “well, like a programmer, well, sort of worked with .Net Core”. And then the question is asked: "And tell us about the principles of SOLID ?".

The question of this topic seems very beautiful. He should emphasize the applicant's experience; he should show the difference between the green recruit and the experienced warrior. There is only one thing - the answer to this question shows absolutely nothing . If a person deciphers all five letters at once, it only means that he recently read an article about it. And recently - it is within a couple of weeks. Moreover, if a person does not remember at all what the letters mean, it still means nothing. After all, you hire an engineer, not a philosopher, not a scientist, but an engineer . He will write code, correct your same bugs, and not talk about high. He will understand why Oracle has made the interface so strange, and not why the program is "not canonical, because it does not comply with the formal 200 rules."

However, if you have heard a similar question at the interview , then there are several options, who are in front of us. The most likely - or middle manager, who sometimes looks code. Or a practicing engineer who simply decided to start a dialogue with at least some question. Therefore, the applicant’s correct answer will also contain his own question: “Since we are talking about the principles of SOLID, how would you make the authorization service completely according to these principles? We all know that the service should be responsible for a lot of important things, but let’s will only do three things: check login / password, issue a token, and at the same time check this very token. "

The question above is good because you will quickly (and most likely) understand who you are dealing with.

• A technician will quickly give back to the transfer and admits that all this is a philosophy, it is necessary to start a conversation, but all this does not matter. And you continue to communicate.
• The middle manager will answer the philosophical question of something in the style of "it is necessary to use a non-blocking queue and an IoC container using its Class Loader " (I deliberately exaggerated the answer so that the essence was clear). This sounds to non-programmers very cleverly, which means it even looks like a sloppy such answer, from which anyone will understand the further decision. However, we are talking about the role of the software developer, because you will immediately guess that at the other end of the table is not a technical specialist, and therefore you will be able to choose the answers so that he likes it .

A small remark - how to conduct a dialogue with a non-specialist, who believes that he is a specialist

Most often, such a person grows out of a programmer , but the last time he did something serious about five years ago. However, our partner still believes that he is in trend, and therefore proudly talks about the technical details. This will put pressure.

If you tell the database developer that Oracle / MS SQl are smart, and therefore they do not need separate tuning, the specialist will immediately send you home. But at the same time he will get angry, he will bring a bunch of arguments and examples from life when this is not so. However, when we speak with the manager, we can easily produce a phrase like "in database development there is the most important rule - all queries should be simple. Any tuning and speeding up queries (that is, adding hint-s ) will spend the team’s work time, complicate decisions and the exhaust will be minimal. " Such a phrase would be like a balm for the soul to a person who is not familiar with the databases in practice, but knows the theory and philosophy . He was also given an explanation by his colleagues, why the task could not be done quickly, in the way that he intended in his promises to his superiors.

There is another scheme of pressure on the philosopher-manager (who tries to seem technically literate, this is very important). Often they live by the technology of their stormy youth of a developer, and therefore it will be useful to say that you are opposed to implementing the most recent, time-tested solutions . Put yourself in the manager's position - he is used to C-like syntax, and people are going to code on Kotlin / Swift / Scala. And here comes a man who is completely ready (and with all his hands for) to use old, understandable to the manager, technologies where our beloved manager can always tell. Well, how can you resist?

Disclaimer

The tips above are only useful for manipulating the manager, who is not good at managing, and therefore often climbs with technical tips (and not with help). Such recommendations will not help (and harm) when talking to:

• Competent managers. They just skip the technical phrases. It is important for them that they work stably and predictably, so that the solution has a lot of useful and convenient functionality. They are good and smart, they will immediately feel the manipulation.
• Project managers who themselves do not forget to program (and not just sometimes look at the code). These people will quickly bring you to clean water.

Conclusion on philosophical reasoning

Do not ask questions about philosophy. You just substitute yourself, and at the same time make the applicant once again worry and make mistakes. In reality, you absolutely do not care how employees theorize about programs.

However, the following topics are not related to conversations about philosophy:

• The ideas of how and why basic structures are structured in one way or another. These are just questions about discrete mathematics, almost every experienced employee saw the wrong use of structures (although rarely).
• How can improve class XXX. This is quite a practical question, and you yourself often answer it by looking at the code.

Stupid topic # 2 is non-work talk

Cliche - about commitment

A very important note: in order to become toxic, all these questions should by no means concern at least half of the employees. Or in a different way: the employees themselves can answer them “incorrectly”, and this will be considered absolutely normal.

The cliché is old, however it is used: by whom do you see yourself in our company in five years? Moreover, most often such a question is asked either by those who have been in the company for only a couple of years, or those who have been sitting in the same place in the company for 15 years.

However, the questions above mutated. For example, one of the trends in 2018: If you have a year of free time, you are paid a salary, and so on. Question: what will you do? I, unfortunately, do not know the answer to this question, which would satisfy at least 80% of employers. This question only harms the interview because:

• The applicant immediately sees before him an idiot who has run out of questions on the case, but he does not want to go back to work. An employer may have a completely different mind, but this is how he looks from the outside — an idiot.
• This question will never give a truthful and sincere answer . Just because everyone wants to appear in the eyes of other people as a person who will not leave in trouble, Mother Teresa of modernity. It is not customary to do this, but I really want to appear. And because the applicant is likely to exaggerate almost everything that is possible.
• There is already an absolutely sincere, verifiable and well-known answer to this question. A 40-year-old programmer had about 20 years of work in his life, that is, about 20 months of vacation, 2,000 days off. Plus, there are a lot of evenings, holidays, etc. We obtain an important consequence - everything that a person could have done in a theoretical year, he had already done in his life. Moreover - in the summary and so described the most delicious details, all Open Source projects, all the achievements. Everything is already there.
• And the most important reason that the question is harmful: we do not like the truth about the employee, we ask him to lie and dream, to convince ourselves that he is needed.

Talk about the usefulness of free time

Another example of how to confuse yourself in an interview. These are questions in style: "how do you spend your free time?" And again, this phrase seems well, very clever, although it is harmful in fact.

What is the minus of this question? After all, we ask a person to tell more about how smart and good he is , how easily he will master new knowledge (everything that is in italics - deception and deceit). However, in fact:

• If a person is seriously working for 10-12 hours, he often studies enough at the work itself. He watches the presentations of colleagues, he reads profile articles, he analyzes much of what is directly related to his work. As a result, if a person is really professional, he will not be able to honestly and beautifully answer about free time .
• If our applicant is a delicate manipulator, then he will instantly be able to understand that he has already been practically taken, if they ask such questions. Well, perhaps the employer would not ask questions about the profession, if you have already decided not to take the interlocutor? So, a competent negotiator will respond in the spirit of : “We talked about .Net technologies on Windows. I’m at home reading articles on .Net Core on Linux (well, or on a Mac, on iOS / Android, the main thing is that the topic is related rather than coinciding . ) I think this is the future of the industry, and therefore I try to be more careful about new solutions, because we will soon work with them. " I have repeatedly heard such an answer, but each time the applicant quickly left the technical description for the theory. However, the pattern of the answer is simple and ingenious. After all, the new employee makes a passage towards the technology with which the interlocutor deals. Therefore, he cites a couple of truthful (albeit well-known) facts. And at the end he translates the topic to where it is possible to dissemble and frankly lie, since it will be difficult for the employer to check (he himself hardly studied it).
• And the most important consequence: no matter how the applicant answers, all this is not important. You yourself can check with the company that the answer about free time will not correlate with the quality of work.

Finding non-work conversations

Do not ask such questions. All companies are more or less the same, it makes no sense to ask the candidate to admit loyalty. It makes no sense to ask what is even difficult to verify - you just take a liar, and expel an honest hard worker.

Do not ask questions that even your team members answer incorrectly.

Stupid topic # 3 - talk about rare problems

Cliche - I recently learned, let's talk about it.

An example of a toxic question: "We are doing services in Java, we recently updated on Spring Boot 2 and noticed an interesting feature of XML serialization - in some cases the server cannot process the XML message. Have you encountered this?"

What the employer expects to hear: the new Jaxb2XmlDecoder class does not override the decodeToMono method, which is declared in AbstractDecoder (as you understand, Jaxb2XmlDecoder inherits AbstractDecoder). The default implementation of decodeToMono is to throw an exception, which means that neither XML can be decodeToMono nor sent.

Thesis of the article - you should not be interviewed if you did not go to at least three interviews as an applicant in the past six months. As a job seeker, you already see a hard problem in this matter. And as an interviewer - not a fact.

So, why this question is bad:

• We ask about a very private thing. The error does not manifest itself in JSON serialization, that is, if the applicant used JSON in the project, he simply could not find out about such a setup.
• We ask about a very fresh thing. After all, Spring Boot 2 was released not so long ago, and therefore the applicant could easily work in a project where they had not yet begun the update.
• Having solved this problem, we will forget about it. However, we liked the solution found so much (or the very fact of finding it) that it directly itches in the brain, and at the same time it requires consideration at the interview.
• The most important consequence: most likely in a year we ourselves will not be able to answer this question. So, asking it, with a high probability, we will simply expel a competent developer.

Cliche - even though this is not happening with us, let's talk

An example of a toxic question: "Although we do not have large amounts of data, how would you store 100 pb of data, with the ability to quickly access it?"

I heard such questions from colleagues I interviewed and potential employers . In all cases, I asked myself the question: "well, why ask it? We do not have such tasks, we are not professionals in this field. Yes, the applicant came to us with other skills. Well, why ask for something that we can’t even verify? ".

This question is very similar to the philosophical one, but it looks quite specific, realistic, and most importantly - it speaks of the scale of the company .

And he is also very, very problematic, because:

• We will not be able to verify the response of the person. It's like with the philosophy about the right software - the person will answer, but this will not give us any information about what he can really do .
• The task is set very abstract. Neither the size of the objects, nor the frequency of recording is said, there are no requirements even about the reliability of the system. Here a competent specialist can simply brush aside the answer of the form "I will take one of the efficient distributed storage systems." Or he may be afraid of his ignorance, and therefore will give a confused incomprehensible answer.
• Often, even your colleagues will not be able to give a clear and correct answer to such a question (and this is not bad, this is normal; the optometrist may simply not know what drugs are used to treat a rare form of cancer).
• We come with the same consequence: this question will only increase the error in the assessment of the candidate. This question we learn not how much a person helps our team, but how well a person solves the problem of another department (or another company)

The conclusion of the attempts to dream about rare problems

Do not talk about tasks that you do not solve. Again you will take not the one who will help you, but the one who will fantasize how to help others .

General conclusion about silly questions

As you have already seen - there are many stupid questions that only interfere with the interview. They are not even neutral - they are harmful. However, it is very difficult to understand that the question is toxic. And there is a simple and understandable solution: you should not conduct interviews if you have not gone to at least three interviews as an applicant in the past six months .

After all, this is a simple, understandable and verifiable rule that will save us:

• From stupid and unnecessary questions to the candidate
• From the huge ego, the rage of genius and its own overpricing

And at the same time you will communicate with smart people, plus you will find questions that you should ask.