Interview on the position of the developer, as it is

Good day. Currently, I am Senior / Team Lead IOS Developer. It so happened that over the past year I had a chance to attend a huge number of interviews, so to speak, on both sides of the barricades. Therefore, I would like to share my experience and talk about how, in my opinion, it is necessary to conduct an interview, because in the general turmoil you can miss a number of important points, which, subsequently, may negatively affect the quality of the interview.


This article will be useful to people who, by the will of fate, are forced to conduct interviews, but at the same time do not have the necessary experience and plan, as I once did. All that is described below are conclusions from a large number of interviews. But, as they say, any coincidence of names or events with real ones is an accident.

The commandments

Commandment number once

Your task is to determine what a person knows, and not to show that you know more.
Anyone who conducts an interview for the first time is faced with this. He perceives it as a kind of competition, where he must, like the interviewee, show the class. This is not true. There is no doubt that you, as a person asking questions, can find in the depths of the Internet and on the secret pages of manuals a question that the interviewee will not be able to answer. But your task is not that.

Commandment number two

Your task is to find out what this person can do for your company now and in three months, and not what he could do a year ago.

I have often had to interview people who have more experience than I do. The first time it led me into a stupor, it was kind of embarrassing to ask questions to a person who is older than you, and in the field of programming it works longer. But all the awkwardness disappeared as soon as he could not give a clear answer to the elementary principles of working with multithreading. Although the portfolio was impressive, real knowledge turned out to be shallow. You are hiring a person who will work with you in the future, and not who he was 2 years ago.

Commandment number three

Your task is to determine whether a person can join the team.

Regardless of the level of the interviewee, try to determine for yourself whether you can work with this person in a team, even if you know that you do not have to do this. Once, a companion came for an interview, who, within the first 5 minutes, managed to trick the HR manager and throughout the interview was far from business-like, although he had some knowledge. After the interview, his candidacy was no longer considered, since no one wanted to work with him on the same team. In turn, you, no matter how you like the person, should be restrained and welcoming, since you represent the whole company, and he only himself.

What you need to pay attention to

I work for a small company, and I don’t have a crowd of HR managers who organize everything at the highest level, so I will describe some points that need to be monitored.

  1. The interview should be held in the meeting room (hereinafter referred to as the meeting room). If the conversation is busy, postpone the interview. By and large, this room with you is the face of the company for the interviewee. And if you really need an employee, make sure that the “face” looks appropriate. In no case do you have an interview in the lobby of the office center or near your workplace with colleagues scurrying around. All this will not create a calm atmosphere and will not help to form a person a pleasant opinion about the company. Unfortunately, I had to go to a similar situation.
  2. On the table must be a glass of water for the "guest". Tea and coffee are options, but water must be required. First, talking over time is pretty hard. Secondly, you will save a person from having to ask you for something during the interview. And finally, in the case of a temporary hitch, he will not sit and nervously twist his fingers into the Gordian knot, but simply take a glass of water.
  3. Conduct an interview without a leaf or a laptop, otherwise you may get the impression that you yourself are not sure what you are asking. Clearly formulate the question, having previously worked it out on colleagues. The interviewee must understand what you want from him.
  4. At the interview, one person should ask questions. At the same time, several may be present in the room, so that there would be someone to discuss the results with. Three in my opinion is optimal. Often because of insecurity, we strive to bring along a colleague who will insure us in difficult times. Because of this, the interview turns into a cross-examination with two bad cops. This should not be (see commandment 1).
    If you need to talk about several areas at the interview, for example, programming and project management. Then break the interview into 2 parts, so that the interviewee would first communicate with the 1st specialist, and then with the 2nd. Avoid cross-examination.
    (this item is corrected after the comment of the User: xoposhiy)
  5. After the interview, do not be too lazy to mark information about the applicant directly on the resume. All that you consider necessary: ​​right or wrong answers, an emotional impression of communication with a person, etc.
    After a couple of weeks and 6-7 interviews, you will say thank you for this visionary decision when it will be necessary to invite a person to work. Plus, you have a good database accumulating.
  6. Time limit. At one time, I had to face the demand from the HR manager to reduce the time for an interview to half an hour, saying that people get very tired after long interviews and they have a bad impression about the company.
    Feel free to send such proposals to hell. Firstly, since you are interviewing, then only on your shoulders lies the whole burden of responsibility for hiring this person. And, therefore, in case of a wrong choice, answer you too.
    Secondly, people are more likely to get tired of uninteresting and boring interviews than long ones.
    I remember I went out annoyed with a 40-minute interview on a list of standard questions, and it was a completely different matter after 2 hours of a hard interview with copyright questions that I had never heard before. After the second, I learned something new, but on the first I just spent time.
  7. In order to reduce time, highlight a number of key questions, in the absence of an answer to which the interview can be minimized without offending the person. Maybe in a year or two he will become a highly skilled specialist.

I had to conduct interviews for various positions, and below I will try to state the main points that need to be taken into account.

Interview at a junior programmer

The goal is to find out the learner’s learning ability.

First, find out where a person studied or is studying (I am a supporter of the fact that for working as a programmer you need to have an engineering education , as this will allow you to speak the same language). God is a witness, people from the music conservatory who took 2-month programming courses came to me for an interview.
Learning can be partially offset by zeal. And here the education system comes to the rescue. Find out what the average score of the applicant, he studies for a fee or for free. A square butt in programming is useful.

For me, the greatest difficulty was the formation of a list of questions, since many, with the exception of creating a class or array, do not know anything at all.

This is what I came to as a result of the experiments. You can walk through standard questions: OOP with examples, scope of variables, overriding and overloading methods, virtual functions. This will allow the applicant to understand that they plan to take him as a programmer , and not as a teacher of elementary grades to solve the problems of crossing a wolf and a bunny across the bridge.

  • Try to come up with several tasks for the quick-wittedness and quick-wittedness of the interviewee. For example, what is Single Responsibility. After listening to a person, you will understand how he acts when faced with an unfamiliar task : in which direction he moves or simply falls into a stupor. It is important.
  • Give a simple task, say, to add an element to an array and a leaf with a pen. This will make it possible to understand whether a person is able to write anything at all without the help of the environment.
  • Invite the applicant to describe the classes that he would create to implement, say, the VK message page. Based on this, we can judge whether a person is able to think in the format of OOP .

I am not a supporter of logical problems, since their solution does not provide any information about the candidate, except for the fact that a person can solve problems of this type. If you do not agree, you can give an IQ test instead of an interview.

Interview at a middle / senior programmer

Things are better here. Before you is a person with experience and you have something to talk about. If you have enough experience, you can use what is described below, if not, then a prepared list of interesting questions is an excellent option. After two dozen interviews, I realized that it’s difficult and boring to extract information from a person through dry interrogation. Let him tell him better.

Begin an interview from afar. Find out what the person was doing at his previous job, what role he played in the team, and if he had a chance to participate in software design. Everyone loves to talk about themselves, and even more love to be listened to, so you turn the interrogation into a conversation and relieve some tension from the interviewee.

Listen to him calmly until he mentions the technology that interests you. And here you begin to ask questions, it’s even better to say to be interested in how he, as a very serious engineer, would solve a certain problem.

Of course, you need to have in your head a list of questions that you would like to touch on in order to guide the conversation in the right direction. This type of interview will allow you to check a very important quality of a person - his honesty. There was the following case. A man came for an interview who said that he worked on the project in leading roles, and also that his project had more than 50 tables in the database, more than a dozen migrations and calls to the database are in different streams, and much more. However, when asked how the work with the base was organized from many streams, there was no clear answer (see commandment 2). I think everyone understands that this person did not get a place in our company.

After the conversation, we go on the offensive. Most of all I like tasks like “if”. Such tasks begin very simply, for example, “redefine the setter for a property”. After which the task is overgrown with various kinds of additional conditions, classes and restrictions.
For the setter, the next step may be the ability to access the property from many threads. At the same time, there will be an occasion to talk about multithreading in general, if this was not done according to the “will” of the interviewee at the very beginning.

By all means, avoid questions like “I know / don't know,” the answers to which can be given only if you read about it. An example of such a bad question is the question of the internal structure of a highly specialized class.

You must find the boundary of knowledge of the interviewee, if a gap is found, it is not worth spending 10 minutes to finish, it is better to move on. This option will be more pleasant for the interviewee and more productive for you. (see commandment 1).

If as a result of the interview all the questions were answered, the price of such an interview is worthless. You did not allow the interviewee to fully reveal their potential.

Finally, I’ll touch on the question that is debatable for many: “Is it worth explaining the correct answer to the question?” In my opinion, if a person was close to solving a problem, the answer can be announced. However, if a person did not come close to solving the problem one iota - I see no reason to explain something to him.

How to behave in an interview

  1. I deliberately do not touch on the topic of wages, since in the field of IT it is very individual. The only thing I can say is ask so much that you want to work and you do not feel cheated.
  2. Take the time to take half an hour before the interview to repeat the main points. Believe me, this time will pay off with interest. I remember there was a person at the interview who answered the question “What is OOP?”, “Well, Uh ... This is necessary for inheritance.”
  3. Do not put on a tie or suit if you do not wear it in everyday life. I am more embarrassed by a man in an unusual stranglehold than in a bike. If the company has a dress code, they will tell you about it. The main thing is to look neat.
  4. Do not lie about your merits. Lies are easily revealed.
  5. Prepare in advance for questions like: “Which project did you like the most?” - This question is needed to start a conversation.
    “Why did you leave your previous job?” - I won’t say how to answer it, but the worst answer I heard was: “I was offered more in another place.” After such an answer, many questions arise for the person.

How many times have I been in interviews, each time I recalled something that I wanted to ask after parting. These are the questions that I would like to find out for myself:

  • the actual amount that you will receive on hand (net of taxes and God knows what else);
  • format of the room in which you will work: open space / separate rooms. It is advisable to even look;
  • equipment provided: monitors, laptops;
  • ask in detail about projects, team sizes and your role on them;
  • Find out who will be your immediate superior. This may be the person who interviewed. And if this is not so, then you can ask to get to know him.


Remember: even the most well-organized interview can fail due to the complete lack of talent of the interviewee, just as the candidacy of the best applicant can be rejected due to the lack of experience of the interviewer.

All successful searches and upscale professionals.

Also popular now: