Interview at a junior position. Interpersonal interviewers

Good afternoon habrayuzery! Not so long ago, I started looking for a job as a junior developer. Even thanks to my modest resume, I managed to attend not a few interviews in a relatively short period of time. From each interview I took out something new for myself, somewhere there were my punctures, but it was much more interesting to notice the fails of the people who were interviewing me. Actually, I would like to tell about such punctures.

Typical questions and answers will not be presented here, and for sure this material will be more useful to the interviewees than to those who will be interviewed. Although at the end of the article I highlighted several, in my opinion, good rules when conducting an interview. I think it will be useful to get acquainted with them all.
It is worth noting that this material does not claim to be the ultimate truth. On a habr from time to time articles on this subject appear. I decided to describe the search for work from a junior developer’s position, in search of a specific vacancy that met certain requirements (who thought about money now - you have a bad approach to recruiting :)). To summarize, company names are omitted.

I must make a reservation that I am considering interviews for a junior developer vacancy, and I agree in advance that much of what is said here may not be applicable or not so relevant to the position of middle / senior. All the positive or negative points that I remember, I decided to group and give them a name. It turned out something similar to patterns and antipatterns, and I propose to get acquainted with them.

Antipatterns interview


1) Template questions

Tell me, why should a senior programmer and especially a team leader bother inventing new insidious questions if you can go in and just drive something like “questions to the position of C # junior developer” in the search. It is so wonderful when in a second you can print out these standard questions that fully reflect the required knowledge. We can all imagine the ideal option when the interviewing programmer asks from the sheet a list of questions from the site that the candidate read 15 minutes ago. Here you can certainly hope for a complete understanding. Of course, this happens extremely rarely, because Google / Yandex / Bing does not give the same results to candidates for vacancies and people conducting interviews.
Speaking absolutely seriously, I believe that the only person who has the right to ask standard questions is HR. All technical questions can and should be changed (namely, “changed” and not “replaced”) in order to make respondents think and not pronounce the same text a hundred times.
I completely failed to say my first interview, because I did not answer a few of these questions, but the second reminded me of checking the multiplication table. Sometimes I had the feeling that the people who were interviewing me really read the same article as I did 15 minutes ago. But the saddest thing is that apart from these template questions, they have never asked me anything.

2) Why ask for vacancies?

This anti-pattern, as logic tells me, is extremely rare. But when he comes across to you, you know you got a lot of luck. When you grow up to a team lead you can tell stories in style, but for me it’s like during an interview ....
Its essence lies in the commonplace thing. You are simply not asked for a job. Generally:). All that you prepared, all that you prepared for, keep it with you. It happens when the company simply does not have specialists in your field, but there are other good specialists. Say there are no iPhone programmers in the company, but there are Android developers who are happy to ask you about the intricacies of the activity lifecycle). One can also classify here the wonderful question of the interviewee: “I do not know how this is implemented in the X language, but in the Y language it is implemented this way and that. Please compare the implementations to me. ”
Considering that you are just going to the junior position of a developer, a reasonable question arises: who will you actually learn from and by whose example will you improve your skill? Unfortunately, the antipattern does not give an answer to this question.

3) We will interview the whole company)

It’s good when at the beginning of the interview PM talks about the project and the company and simultaneously plays the role of HR (in the absence of one). It’s bad when then during a technical interview, when you should be asked by those. specialist, PM sits nearby and carefully looks at you or at those. specialist. Again, from my own experience, it seems to me that at such an interview the techie is experiencing even more than the one who is interviewed. In fact, he also conducts an interview in front of the boss). In addition, in this case, the one who is interviewed does not really know who is best to answer. If you ignore PM at all, you get something like an interrogation under. observation of glass, only without glass.
This anti-patern is more likely my personal conviction of how the interview should proceed, but still, maybe someone will find it reasonable.

4) Repetition is the mother of learning.

Have you ever had a sense of déjà vu when going through another interview? Especially when you have to answer once again what a singleton is and what it is eaten with. It probably happens. Especially if you have to answer 2 times in the same company, and even at the same interview. This happens when the PM decides that he (or she) is universal, and can also conduct those interviews. It is especially funny when such an interview goes after an interview with a real technical specialist, and in collaboration with the first antipater presented, it turns out to be a combo.
It is no secret that sometimes when you answer a question incorrectly, they immediately tell you the correct answer. In the case of this anti-pattern, a unique opportunity is given to fill up all technical issues, and then immediately correct it.

5) Never give homework. Never!

I think there is nothing to explain here. Again, why waste valuable time working people to parse someone's test task. After all, at the interview everyone already found out, and most importantly, the person agreed to work for food). Just think that it has all the variables called no longer than 5 characters (3 of which are usually the same).
And indeed, again, this test task still needs to be invented, and who should do it? And what, is Timlid most needed? He already has enough work. The candidate answered correctly all the questions at the interview (again, remember the first anti-patern). Just think, the big thing is that a person does not understand why you need to write
List values = new ArrayList(); instead. ArrayList values = ….;
Well, who doesn’t want to see the names in style ArrayList arrayList = new ArrayList();and smile. It is a pity that with the use of this anti-pattern, all of these things that cause a smile, are usually detected after about a month of work.
There is also a special case. When they offer to perform some kind of “easy” task right there. Of course, at the same time, the candidate should get used to the new layout in a second (ideally if it is also a netbook so that the candidate can show his whole solve problem skill), and if this turns out to be insufficient, you can still give a different development environment (yes for .Net there are not many options :), but there is a notebook. After all, I hope everyone knows how to compile a C # program through the console?)

6) That is not a problem at all.

“So this is not a problem at all” or “We have many options” (without specifying these very options) - such an answer can be received on a lot of questions.
Usually this anti-pattern is found in small companies, or companies recently founded. In the first case, there is simply a big friendly family and they know that they have all these problems solved very easily, in the second case, even the founders themselves do not yet know how they solve (will) solve such problems. But not in the first, and even more so in the second case, it is impossible to tell the candidate about approaches to solving problems.
Perhaps it should be said that the more bureaucracy in the company, the less often you can hear a similar answer. Since in large companies everything is usually clearly established.

BestPractices Job Interviews


It's no secret that the approach to software development changes over time. The approach to hiring employees is also changing. And if HRs are at least trying to improve their interview skills (I sincerely believe this, they still pay money for it), then from the technical side the questions “What is the difference between ArrayList and LinkedList?” Will not leave the stage for a long time. Now I would like to give a few points from which, in my opinion, a good interview should consist of.

1) Parallelization of tasks.

Immediately make a reservation that this is a rather specific point. Especially for jobs like junior. But since I was looking for a mobile developer, he came up perfectly when two experts interviewed me on the technical side. One asked standard questions about language, collections, and patterns. In short, the standard junior stuff interval. And the second specialist asked precisely on the intricacies of the mobile platform.
The minus for the company is immediately visible in the form of loss of working capacity by two employees at once, but on the other hand, subjective opinion is excluded and interviewers have more opportunities to better prepare their part.

2) About everything that you did not ask - HR should tell you.

In the description of one anti-pattern, I stipulated that the only person with a standard set of questions should be HR. And he should tell you the answers to these questions, even if you did not ask them (questions). For some reason, no one forgets to stipulate the size of the RFP, but not everyone remembers asking about the work schedule, code, the possibility of business trips, payment for processing, etc. Actually here the fault partially falls on the shoulders of the one who is looking for work. After all, the company cannot know what suits you and what doesn’t, so it’s best if you figure it out yourself in advance. I think it goes without saying that HR’s duty is also to tell about all the advantages that are present in the company.

3) All company buns at once.

I think HRs don’t need to tell how to hunt people. But the thing is that no one usually hurries to hang on a junior position. And, usually, the candidate learns about the company as much information as possible during an interview with HR (excluding, of course, large companies and all kinds of feedback portals). I once heard in an interview that the company provided a place in kindergarten and this was a good bonus for "family" programmers. If you give your MacBook and Android device for personal use, do not forget to say so. 2 monitors in the workplace are also an advantage. Believe me, it is. On habr there was one article about chairs. So there were links to chairs up to $ 1,000. Not every programmer can even afford such a home. I used to be in companies where everyone has such chairs and no one said this as a plus of the company (!!).

4) Clearly defined goals and objectives.

It is good if both parties understand what they want from the candidate / position.
A company that takes a junior programmer must clearly understand who she wants to make of it in 3-4 years. It is approximately this understanding that should tell the candidate HR or PM. It’s good if you explain to the candidate what he’s going to do on the next project, but it’s even better if they tell him what will come of him in a year and a half work in this position (again, if all you can say is “salaries will be higher than the market average” , then I would not go to your company).
It is important for the candidate to understand what he wants from this job. I understand that many people get a job as a junior in fact on their first job, gain experience in OOP, work in a team, and participate in a real project in the end. But for some reason, few people realize that this first job determines all further career development (in most cases) and your professional language in programming. Now I will explain with an example. Say you like to program in java and you know this language pretty well, but in the 3rd year you find work (we read: we are ready to take you) only the junior C # programmer. Well, what will you go or not? I would go, and for about 2 years I learned the intricacies of .Net programming. And now you are finishing this 5 year old university that is so sick and you have 2 years of .Net programming in reserve, it is quite possible that you are no longer junior at all. And you want to change work to become a junior programmer again but already a java junior? Of course not. If you are clearly sure that you want to be, say, an iPhone developer, then obviously you need to look for a job not “Android / iPhone / WinPhone developer” but clearly “iPhone developer”. I hope I managed to convey a thought.

5) Questions about vacancies, not resumes.

This paragraph directly relates to the previous paragraph from the point of view of the company. Of course, everyone is responsible for what he has written in the CV. And I understand that if I have C ++ or JavaScript specified, they can ask me for any of these languages, even if they are not my core ones.
On the other hand, the company must understand exactly who it needs. And if in the case of small companies a person can be taken as a universal developer (accordingly, the more he has everything indicated in the resume, the better), then large companies should be interested in hiring highly qualified narrow-profile specialists. We all know what a typical vacancy looks like, say, in the middle position. But I have never been to an interview at which everyone asked what is indicated in the vacancy, but I was asked more than once throughout the CV, where half of everything was not related to the desired position. Unfortunately, this happens in most cases. There are 2 options here, either the company does not understand who it needs, or absolutely everyone is suitable for it, and HR vacated the mine with paste in 10 minutes.

6) No need to wait for feedback. Never.

I thought for a long time to write on this point here, or in antipatterns.
I think it is no secret to anyone that a letter on the results of an interview in a company gives a lot of experience (especially if this letter is with a refusal, especially if the reasons for the refusal are indicated there). Especially a lot of experience gives a response letter as such). Believe me, a company that conducts competent correspondence, stands out from the rest.
A reasonable question may arise, why is this letter so important? To answer this question, it is worth moving a little away from the main topic. I allow myself to quote Jacob Fine : “The search for work consists of 4 steps. Drawing up a resume. Search for a job. Interviewing. Consideration of the proposal. ”
You will not agree to the first available option (or will you?). Therefore, you should always keep in mind it is advisable to coordinate with HR when the interview is worth waiting for feedback. Everyone who wants to find a job (not just a job with which he will leave in half a year, but really a good place) should have an idea about when he will have the bulk of the results of the interviews. In other words, if I was in two weeks at 20 interviews (let some give an answer in a week, some in 2), then I understand that at the end of the month it is already possible and necessary to choose a job offer. And to go to the interview at the end of the third week is stupid (unless of course it is Google :)), or at least you need to immediately agree on the terms of feedback, because while you wait for the result of the interview with this company,
There was a case when after two weeks I decided to take an interest in the results of my interview (I was then more interested in where exactly I had gaps and what I should tighten up for subsequent interviews). After negotiating with PM on Skype, he promised to find out why the reply letter was not sent and promised that I would receive a feedback soon. Now, after almost three months, I have not received a letter).

7) Determining the size of the RFP and the timing of its review.

Yes, I completely agree that junior should not chase salaries. But the employer company must understand the real situation. Let’s say one thing, if you offer a salary of 10-20% percent below the average market and quite another if you are offered to work for all these 10-20% of the average salary. In large companies, everything is easier. Everyone knows that there is a salary review 2 times a year. In addition, large companies, as a rule, are ready to immediately pay good money for a junior position. At least tighter than the average market RFP there can be requested without a twinge of conscience. Just because a large company can afford to invest money in advance.
A small company is usually not ready to buy a pig in a poke. Quite often you have to hear the words “we have a flexible policy of revising salaries”, “when I see the result, then the salary immediately rises”, etc. You can of course get into the position of small companies, in addition, juniors, in my opinion, should work on a set of experience, not salaries. But nevertheless, they are perceived in a completely different way, for example, such words “now your salary will be such, but after 3 months we will revise it, based on your work”. It is also good when two sums are discussed during an interview, one for a trial period and the main salary.

8) Ideal questions.

I decided to highlight in a separate paragraph the questions that I would like to hear at the interview. At least, asking them would immediately notice his company. I would like to go to such a company, simply because there are people there who can learn from, and this is still a priority task for a junior programmer, regardless of language or platform.

Code example;

For example, ask what the code outputs, explain why. Take at least one like this:
public class Main {
    String variable;
    public static void main(String[] args) {
        System.out.println("Hello World!");
        B b = new B();
    }
    public Main(){
     printVariable();
    }
    protected void printVariable(){
        variable = "variable is initialized in Main Class";
    }
}
public class B extends Main {
    String variable = null;
    public B(){
        System.out.println("variable value = " + variable);
    }
    protected void printVariable(){
        variable = "variable is initialized in B Class";
    }
}

And what will happen if instead of String variable = null; write simply String variable; ??
Such code makes you think, and it clearly shows how the one who answers is guided, in this case, in polymorphism and memory allocation in the JVM.

Articles on Habr;

And who from the interviewers asked if the candidate wrote anything on Habr. Does he even read this habr? And what is his rating on stackoverflow. Or, for example, the candidate does not pass, some online courses. Agree it can say a lot.
Bad is the soldier who does not dream of becoming a general. Correctable if there is no development experience on a real project, but if a person is carried away by programming, then this can just be identified with the help of such questions.

Is there an account on github;

Another question that I never had a chance to hear. Meanwhile, even without a lack of experience, a positive answer gives the idea that the candidate knows what a version control system is. This also includes questions of the category of whether the candidate participated in open source projects. As far as I know, in less serious projects, there are very strict requirements for code formatting, and if a person participated in something like that, this could not but have a positive effect on the quality of the code.

Last technical book read;

Of course, when answering this question, the answer can lie. But on the other hand, if the interviewee himself read the named book, you can start a conversation about the book itself. After all, the main task of the interviewee is to determine how much the candidate is a fan of his job, and what, in essence, he can quit after the same year and a half.

5 favorite refactoring;

The most commonly used combinations in the IDE;

Эти два вопроса я оставил напоследок, так как они, наверное самые нестандартные из всех приведенных выше. Хотелось бы мне увидеть лицо человека, которого спросили эти два вопроса, особенно если он абсолютно не знает на них ответа, зато знает, чем отличается ArrayList от LinledList’а :). Я убежден, что они всего лишь действительно позволяют находить программистов из всей той массы людей которые приходят к вам на собеседования. Ведь есть люди, которые занимаются этим, потому что это им интересно, а есть люди, которых просто привлекают перспективы IT сферы и существующие здесь зарплаты. Просто ответив на эти два вопроса, человек может показать программирует он что либо для себя или просто сидит и ждет, когда попадет на работу (иногда правда почитываю для разнообразия «Основные вопросы на junior собеседовании»).

The article turned out to be more than I initially thought. Thanks to everyone who read to the end hoping to see at least one picture).

Immediately I will answer a possible question in the comments that yes - I found a job. And not even one)). If anyone has their own examples of good patterns / antipatterns, please comment.

Also popular now: