Technical Interview: Five Ways to Scare a Candidate / Five Ways to Fuck the Interviewer

A lot of pain pours on the web pages about unsuccessful interviews. Someone didn’t like the questions of the interviewers, another was offended by ridicule, others were sued on the VKontakte page. The interviewers keep up with the applicants and swear at how badly the staff is today and what stupid answers the inexperienced programmers give to their intricate technical questions.

Unfortunately, there are no universal rules for passing and conducting interviews, because employees are selected not only by their technical skills and personal qualities, but also by coincidence with some (often implicit and very subjective) “profile”, which, according to interviewers fit into their team or company. As for the “how to properly conduct interviews” series of guides, they usually cause no less pain in the comments, because they are very subjective and will surely touch someone's pain points.
')
During my professional career, I happened to be on both sides of the barricades, although, perhaps, I had to conduct technical interviews a little more than go through them. But during this time I have accumulated a certain amount of “fad” that scare me away during a technical interview and immediately put an end to further conversation in my mind. I wanted to tell you about this - from the standpoint of the interviewer and the applicant. I want to make a reservation right away that the article reflects my personal subjective impressions and does not claim to be a “guide to interviewing”. On the other hand, this is not a minute burst of rage from a failed interview, but a long-weighted set of criteria that, although on a negative basis, allow me to weed out the options, or not to scare away a potentially suitable applicant.

And what annoys or annoys you at the interviews? Share in the comments.

Job Interview

Every time when looking for a job, the programmer has to undergo many technical interviews. He walks around the office or speaks on Skype, solves puzzles or does test tasks, answers intricate technical questions, trying to demonstrate himself from the best side. However, he himself at the same time evaluates people who will interview and check him, thinking that tomorrow he will potentially have to work with these people. And there are many ways for technical interviewers to scare an applicant of an interesting position. I will talk about what has always scared me personally, and what I try to prevent as an interviewer.

1. “What other technical interview?”

The first and most important thing that always alarmed me in a technical interview was his absence. It so happens that the entire conversation with technical experts - potentially future colleagues - is based on questions regarding professional experience: where he worked, what projects he was engaged in, what function they performed in them. By technology or knowledge - questions the level of "what color is the textbook". Know what a Message Broker is? Great, we take you!

This approach to interviewing always sharply set me up against a potential employer. I was not asked a single question to verify that I really know my business. It looks as if the people interviewing me either do not understand the topic themselves and are looking for at least one person who understands, or simply despaired and are ready to take on anyone. In any case, in the team recruited in this way, I hardly want to work.

2. "Well, what did you do there in this his ..."

It is amazing how often a scornful attitude towards job-seekers at technical interviews occurs. Yes, perhaps you are a harsh and experienced programmer with a bunch of projects behind you, you have been torn away from extremely important work for some unnecessary interviews with people, most of whom, in your opinion, are completely incompetent. But do not forget that at this moment you represent your company and your team, and the person according to your behavior will necessarily make an assessment about the climate in the team and how it will be treated in this team. Be polite and respectful of the applicant, even if you have understood from the first five minutes that you cannot be allowed close to your precious code.

3. "Something you have the name / surname / patronymic in the summary is incorrectly written!"

This is not at all technical, but, nevertheless, a common jamb even at technical interviews. I, fortunately, have a fairly simple and common name, and such problems did not happen to me. However, I know that there are surprisingly many people who are piously convinced that certain names and even patronymic names simply do not exist. They will convince you that it is not “Daniel” that is correct, but “Daniel”, or that the name “Alena” is not, but only “Elena”. Will offer to correct and write in their documents "correctly." People with rare or unusual names often have to deal with such well-wishing diplomas, and believe me, this is incredibly annoying. So, there is one simple rule: there are no such names that do not exist. Correctly write as written in the passport. Show respect for the applicant and do not consider him so stupid that he is not able to rewrite his own name from the passport in the resume. Even if you suspect a mistake, it can be clarified somehow more tactfully.

4. “How many golf balls will it take to wash all round windows on a school bus, reduced to the size of a five-cent coin, during the evacuation from San Francisco, using no more than 3 weighings?”

No article about the interview will not be complete without mentioning the sewer manhole. You can consider this as my personal fad, which is connected with the inability to solve non-standard tasks quickly and energized. But I am sure that brain teasers at the interviews are absolutely useless. Rather, it is a great way to recruit a full department of geeks with a brain olympiad, which, all day and night, instead of working, will be exchanged freshly brain teasers. A real programmer in his natural habitat, even working on very cool and non-standard tasks, still rarely gets energized, and most of the day he sits and in a relatively calm environment slowly thinks about how beautiful it is to cut the code according to the methods. "Brain muscles" to solve clever puzzles he does not use in this process even once.

5. “Wrong. Farther."

Of course, it’s not the job of the interviewer to train people coming in for an interview. However, if the applicant could not answer the question, but was still interested, then prompt or at least point him to the right decision before moving on to the next question is a matter of professional ethics, demonstration of what will help him in this case, will teach , do not throw alone with technical problems. Say at least a few words that google it, what to read. After all, the interest in the correct solution of the problem is in itself a positive quality of a technical specialist, and it is not worth demotivating such a person by neglecting his mistakes or inaccuracies.

Interview from an interviewer's position

Every time a new job is opened, the leading specialist or department head has to do a lot of technical interviews. People with different technical experience, level of training, and expectations come to the interviews. To conduct interviews, you need to think over a plan of conversation, make a list of questions, and then try to understand the answers to these questions, whether the person is suitable for the position or not. And sometimes job seekers say such things at the interviews that it becomes immediately clear - no, you cannot work together with this person. Here is a set of key phrases for job seekers who personally alert me.

1. "Any questions you have theoretical. I am not strong in theory, I am hardened in practice! Let's test better! ”

The word "theoretical" is usually pronounced with a scornful tone, as if it were something bad. But the trouble is not even that. Do you think this phrase was preceded by the interviewer's request to prove the Cauchy theorem? To give a precise definition of the third normal form? By no means. Such cries I heard in response to the following questions:

• How does comparing == differ from equals comparing in Java?
• Tell us how the hash map works.
• explain in your own words what REST is.
• What are transactions and why are they needed?

Yes, from a certain point of view, any programming question is theoretical, unless it requires you to write a line of code right here and now. But I am sure that a person with a sufficiently large experience in a certain area should be able to explain in his own words the most basic things, or at least not to pretend that their ignorance is normal and natural.

2. “I did not expect the Spanish Inquisition here! You just like the exam at the institute. Usually they just ask where he worked, what he did. ”

You have come for a technical interview. At a technical interview, you will be asked technical questions to test your technical skills. The method of checking and the choice of questions leave on the conscience of the interviewer - the questions may not always seem adequate to you, but the interviewer knows what kind of information he wants to receive about you, analyzing your answers. Many questions are needed not to test knowledge, but to make you speculate and look at the course of your thoughts. Remember also that not all questions require a perfectly accurate answer, and if you clearly answer at least half of what you were asked, it will make a good impression.

3. “I don’t need to know this, I specialize in higher-level tasks!”

Do not confuse the specialization and ignorance of the basics of programming. From the developers of mobile applications, I heard similar things about the TCP / IP stack protocols, from front-end programmers - in response to questions about the sorting and search algorithms. "Why do I need to know this, everything is in the standard library, I work at a higher level." In response to such statements, I have long invented a couple of small problems with a basely hidden algorithms - hoping to show that the "naive" solution, issued from ignorance of algorithms, does not stand up to criticism, and encourage at least to self-education. And these are not some artificially constructed tasks, but such things that are found in the development every day. Any code is an algorithm. Understanding the basic algorithms and data structures is important for any programmer, and the Internet protocols are the base, without the knowledge of which it is impossible to write at least something that goes beyond the limits of a single computer.

4. “And you yourself! / And show your code! / But I went to your GitHub, and there it is ... "

The last thing the interviewer wants is to hire a person, and then listen to him criticism of his code base. Yes, she is most likely imperfect. Yes, technical debt is everywhere and at all. In any code there is something to criticize. But if you really consider yourself so cool that you see obvious problems in the code of your potential employers - translate it into a constructive positive: I know how to improve, I have some groundwork on this topic, I can be of benefit to you.

5. "You are wrong!"

Anything can happen, of course, but it’s better to leave the opinion that the interviewer is not right or has doubts about his competence until the end of the interview. Then google and figure out which of you was right. A technical interview is not a place for discussion or self-affirmation, and the questions here are asked first of all to you. The interviewer will not ask about what he does not understand.

Conclusion

Do you know what the most pleasant thing I heard at the interview from the applicants? “Something I didn't really answer, right? Can you give a piece of paper? I will write down your questions and I will sort out at home, even if you don’t take me, at least I’ll know now. ” Tears of pride come to mind - you did not waste a man for an hour and a half, he himself learned something from this interview. Even if he is now rather weak for this position, perhaps this will induce him to self-education, and in a year or two he will come again, show himself from the best side and get a job - as it happened once in my own career.