How not to fail a technical interview at an IT company. Pass the technical interview

Views: 805

A lot of pain is poured out on the Internet about unsuccessful interviews. Some didn’t like the interviewers’ questions, others were offended by ridicule, others were judged based on their VKontakte page. The interviewers keep up with the applicants and swear about how bad the staffing situation is these days, and what stupid answers inexperienced programmers give to their tricky questions. technical issues.

Unfortunately, there are no universal rules for passing and conducting interviews, and cannot be, because employees are selected not only by their technical skills and personal qualities, but also by matching some (often implicit and very subjective) “profile”, which, according to interviewers, fits into their team or company. As for the guides from the series “how to pass interviews correctly,” they usually cause no less pain in the comments, because they are very subjective and are sure to touch someone’s pain points.

Over the course of my professional career, I've been on both sides of the fence, although I've probably had to do a little more technical interviews than pass them. But during this time, I have accumulated a number of “fads” that scare me away during a technical interview and immediately in my mind put an end to further conversation. This is what I wanted to talk about - from the perspective of the interviewer and the applicant. I would like to immediately make a reservation that the article reflects my personal subjective impressions and does not pretend to be a “guide to interviews.” On the other hand, this is not a momentary outburst of rage from a failed interview, but a long-weighted set of criteria that, albeit on a negative basis, allow me to weed out options, or not to scare away a potentially suitable applicant.

What irritates or stresses you out during interviews? Share in the comments.

Interview from the applicant's perspective

Every time a programmer looks for a job, he has to go through many technical interviews. He walks around offices or talks on Skype, solves problems or takes tests, answers tricky technical questions, trying to demonstrate himself with the best side. However, he himself also evaluates the people who interview and test him, thinking that tomorrow he will potentially have to work with these people. And there are many ways to technical interviews ers to scare away the applicant from an interesting position. I will talk about what has always scared me personally, and what I try to avoid as an interviewer.
1. “What else technical interview?»
The first and most important thing that has always alarmed me about a technical interview is its absence. It happens that the entire conversation with technical specialists - potentially future colleagues - is based on questions regarding professional experience: where he worked, what projects he worked on, what function he performed in them. Regarding technology or knowledge - questions at the level of “what color is the textbook.” Do you know what a Message Broker is? Great, we'll take you!

This approach to interviewing has always set me sharply against a potential employer. They didn't ask me a single question to check that I really knew my business. It looks as if the people interviewing me either don’t understand anything about the topic themselves and are looking for at least one person who understands, or are simply desperate and ready to take on anyone. In any case, I would hardly want to work in a team recruited in this way.

2. “Well, what were you doing there in that…”
It's surprising how often dismissive attitudes toward applicants occur during technical interviews. Yes, perhaps you are a stern and experienced programmer with a bunch of projects under your belt, you were torn away from extremely important work for the sake of some unnecessary interviews with people, most of whom, in your opinion, are completely incompetent. But do not forget that at this moment you are representing your company and your team, and a person will definitely make an assessment based on your behavior about the climate in the team and how they will be treated in this team. Be polite and respectful to the applicant, even if from the first five minutes you realized that he should not be allowed anywhere near your precious code.
3. “Your first name/last name/patronymic name is written incorrectly on your resume!”
This is not at all technical, but, nevertheless, it is a common problem even in technical interviews. Fortunately, I have a fairly simple and common name, and such problems have not happened to me. However, I know that there are a surprising number of people who firmly believe that certain names and even patronymics simply do not exist. They will convince you that the correct name is not “Danila”, but “Daniil”, or that there is no name “Alena”, but only “Elena”. They will offer to correct and write “correctly” in their documents. People with rare or unusual names, and believe me, it's 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 to the applicant and do not consider him so stupid that he is not able to copy from the passport into the resume given name. Even if you suspect a mistake, you can clarify this in a more tactful way.
4. “How many golf balls would it take to clean all the round windows on a school bus shrunk to the size of a nickel during the evacuation of San Francisco, using no more than 3 weighings?”
No article on interviews would be complete without mentioning manhole covers. You can consider this my personal quirk related to the inability to quickly and under pressure solve non-standard problems. But I am sure that brain teasers are absolutely useless during interviews. Or rather, it's great way recruit a full department of brain prodigies with the Brain Olympiad, who will exchange fresh brain teasers all day long instead of working. Real programmer in natural environment life, even when dealing with very cool and non-standard tasks, he still rarely codes under pressure, and spends most of the day sitting and leisurely thinking in a relatively calm atmosphere about how he can beautifully cut the code into methods. He never uses his “brain muscles” to solve tricky problems in this process.
5. “Wrong. Further."
Of course, it is not the job of the interviewer to train people coming for an interview. However, if the applicant could not answer the question, but is still interested, then prompting or at least pointing him to the correct solution before moving on to the next question is a question professional ethics, demonstrating that if something happens, they will help him, teach him, and will not leave him alone with technical problems. Tell him at least a few words, what to google, what to read. After all, interest in the right decision tasks are in themselves positive quality a technical specialist, and you should not demotivate such a person by disparaging his mistakes or inaccuracies.

Interview from the interviewer's perspective

Every time a new vacancy opens, a leading specialist or department head has to conduct many technical interviews. People come to interviews with different technical experience, levels of training, and expectations. To conduct interviews, you need to think through a conversation plan, draw up a list of questions, and then try to understand from the answers to these questions whether the person is suitable for the position or not. And sometimes applicants say things during interviews that make it immediately clear - no, you won’t be able to work together with this person. Here is a selection of key phrases from applicants that alarm me personally.
1. “Some of your questions are theoretical. I'm not strong in theory, I'm seasoned in practice! Let’s do a better test!”
The word “theoretical” is usually pronounced with a dismissive connotation, as if it were something bad. But that’s not even the problem. Do you think this phrase was preceded by the interviewer's request to prove Cauchy's theorem? Give precise definition third normal form? Not at all. I heard such exclamations in response to the following questions:

  • How is comparison by == different from comparison by equals 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 sufficiently extensive experience in a certain field should be able to explain the most basic things in his own words, or at least not pretend that ignorance of them is normal and natural.
2. “I didn’t expect the Spanish Inquisition here! It's just like taking an exam at the institute. Usually they just ask where he worked and what he did.”
You have come for a technical interview. In a technical interview, you will be asked technical questions to test your technical skills. Leave the testing methodology and choice of questions to the conscience of the interviewer - the questions may not always seem adequate to you, but the interviewer knows exactly what information he wants to get about you by analyzing your answers. Many questions are needed not to test your knowledge, but to force you to think and look at your train of thought. Remember also that not all questions require a perfectly accurate answer, and if you clearly answer at least half of what they asked you, this will already make a good impression.
3. “I don’t need to know that, I specialize in higher level tasks!”
Don't confuse specialization with ignorance of the basics of programming. From the developers mobile applications I've heard similar things about the TCP/IP stack protocols from front-end programmers - in response to questions about sorting and searching algorithms. “Why should I know this, everything is in the standard library, I work at a higher level.” In response to such statements, I long ago came up with a couple of small problems with sneakily hidden algorithms - in the hope of showing that a “naive” solution, issued from ignorance of algorithms, does not stand up to criticism, and to at least encourage self-education. Moreover, these are not some artificially constructed tasks, but things that occur in development every day. Any code is an algorithm. Understanding basic algorithms and data structures is important for any programmer, and Internet protocols are a base, without knowledge of which it is impossible to competently write anything that goes beyond the boundaries of one computer.
4. “And you yourself! / Show me your code! / But I went to your GitHub, and there’s this...”
The last thing an interviewer wants is to hire a person and then have to listen to him criticize his codebase. Yes, she is most likely imperfect. Yes, technical debt is everywhere and everyone has it. 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 this into a constructive positive: I know how to improve, I have experience on this topic, I can be of benefit to you.
5. “You are wrong!”
Anything can happen, of course, but it is better to keep your opinion regarding whether the interviewer is wrong or doubts about his competence until the end of the interview. Then Google it and figure out which of you was right. A technical interview is not a place for discussion or self-assertion, and the questions here are primarily asked of you. The interviewer will not ask about something that he himself does not understand.

Conclusion

Do you know what the nicest thing I heard from applicants during interviews? “I didn’t really answer, did I? Can you give me a piece of paper? I’ll write down your questions and figure it out at home, even if you don’t hire me, at least I’ll know now.” Tears of pride well up in your eyes - it was not in vain that you spent an hour and a half of time on a person, he himself learned something from this interview. Even if now he is too weak for this position, perhaps this will encourage him to educate himself, and in a year or two he will come again, show his best side and get a job - as happened once in my own career.
How it happens

In most cases, another specialist with a high degree of technical competence is invited to conduct the assessment, who, as a rule, does not understand anything about personnel issues and methodologies for collecting information about a person’s personality, and a frontal interrogation of “who knows more” simply begins. Some interviewers simply have a checklist of questions. Many also use the practice of a test task, which must be completed before scheduling an in-person interview. In general, whoever can do the best solves the problem.

In general, this approach can be effective, but it has a number of disadvantages:
1. There is a possibility that the interviewing technical specialist may perceive the discrepancy between the applicant’s experience and his own as a lack of experience at all. For example, they can be specified quite narrowly practical questions, which the applicant has not encountered in practice, which can be interpreted as “How can you not know this, it’s so simple.” But a human resources specialist will never be able to recognize this due to the specifics of the context.
2. Even if open questions like “What problems have you had to solve?” are asked, again, the discrepancy in experience can be interpreted as “He is not suitable for us because he has not done what we have been doing for several years.”
3. Some technical specialists, especially those already with quite a lot of experience, little recognize the fact that ignorance of specific tools is often not a big obstacle. For example, if a person has not worked with GIT, but knows CVS well, this significantly reduces the barrier to entry into owning the tool.
4. There may also be a problem when the applicant has extensive practical experience and answers questions well on specific solutions, but when he is hired, suddenly it turns out that he makes fairly typical mistakes in areas that he has not worked with before. One gets the impression about such people that they are “being stupid out of the blue” or “actively copy-pasting code” from their previous projects.
5. Sometimes you come across a specialist who gives the impression of a novice and his resume shows little practical experience, but it is important to understand whether he will succeed. Because if it works, you can get a good “star” for the team with a small investment. And it’s not clear how to recognize this as accurately as possible.

These are just a few of the scenarios that are regularly encountered when recruiting new technicians. Interviewing a technician is like a task where you have a huge painting hidden behind rotating squares that you turn over one by one. And your task is to guess the whole picture, provided that your time is limited and the number of possible pictures is huge.
In order to be more likely to filter out these negative scenarios, as well as to conduct interviews of technical specialists more effectively, you can use a special information collection model.

Classification of knowledge

First you need to decide on the classification of knowledge. To do this, they need to be divided into 3 types:
1. Fundamental- This basic knowledge in a specific area. For example, this could be the question “What basic types of queries in SQL do you know?”
2. Applied is a skill for solving specific problems. For example, these could be tasks on correct spelling SQL queries for specific examples.
3. Instrumental is the knowledge of how to use specific tools. For example, what is the difference between innodb and myisam stores?

Fundamental knowledge is necessary in order to use it to understand how best to solve practical problems. Practical tasks form applied knowledge, that is, an understanding of how and what is best to do. With the understanding that individual problems are best solved with the help of specific tools, instrumental knowledge also develops. Often, a person starts with some small practice, then studies “why it works this way,” then tries to do something similar, and then hones his skills with the help of tools.
For example, a person develops language skills in exactly the same way: at first he simply tries to repeat after his parents individual words; then he learns the alphabet; then writes essays, articles or business letters; and sometimes uses reference books and dictionaries for this.

When something went wrong

Since “academic education” in the field of IT is still quite weak, most specialists are largely self-taught. This creates certain deviations, which can be well understood on this model if one of the areas of knowledge is hypertrophied. Here are the classic portraits of candidates and their explanation:
1. Know-it-all– has a significant amount of fundamental knowledge, for example, acquired through some courses and reading books/articles, however, he does not have practical skills in applying them, which does not bother him in any way. Even if you start asking him some practical problems, you will always hear a lot of knowledge about how it should actually work, how the individual parts are arranged, but it will be quite difficult for such a candidate to put everything together to solve the problem, without your tips. A fairly common situation if you ask a candidate about little-used OOP patterns: you will hear a description of the pattern when it is used in some academic example, but the integration into a live task will be difficult.
2. Stackoverflow developer– usually, such developers talk quite actively about their experience, about what problems and how they managed to solve, but when trying to answer the question “How to do...?” from a practical area unknown to them, you will hear either an attempt to “pull by the ears” another solution, or an answer in the style of “Yes, this can be Googled in 5 minutes, I’ve already seen this somewhere.” Such developers often try to pull in some ready-made solutions that they have already made, arguing as “Why do it 2 times?”, or they simply copy-paste code from the Internet and other projects. When asking “Why does it work this way?” or “How can this be done differently?” can often get lost and try to translate the topic.
3. Tools&Frameworks developer. Eat old joke: “How to start making a website in 1995? Open notepad and start writing code. How to start making a website in 2015? Download and install composer, framework, cms-extension, bootstrap, jquery, bower, less, install the IDE, start writing code.” This is about the same for this kind of specialists. Most of the applied experience of such specialists is exclusively related to a specific tool. The concept of “brain bitrix” quite specifically characterizes this case. For such candidates, it is very difficult to give tasks using “native” code, because without a tool it is an almost impossible task for them.
These examples are given for cases when one of the areas of knowledge occupies a leading position, and since the feeling of “superiority” in this area gives rise to a feeling of one’s own “greatness,” the specialist tries to hold onto it with all his might (“everyone wants to be cool”). For example, a Stackoverflow developer, when trying to find out fundamental knowledge, will argue to the last that “I don’t need to know this, I’ve already done this a hundred times and everything worked.”

How effective development works

The most effective scenario for the development of knowledge is precisely the balance between areas. You can achieve it in different ways, but it is impossible to allow “distortion”. For example, you wanted to make a home page and don’t understand anything about it (everyone started with this): you downloaded wordpress (took the “tool”); Googled how to set everything up and made our first blog with several articles (acquired applied knowledge); Now figure out how and why it works, for example, how the database and cache are structured, what the engine architecture is, etc. (gain fundamental knowledge). Then you can look at what other tools and how they can solve this problem, or write your own tool. If you stop only at the first or second step, then you can easily fall into one of the categories of specialists given above, and I’m sure you clearly don’t want this :)

How to evaluate knowledge

Based on this model, it is also possible, and quite easily, to “probe” technical specialists regarding their learning strategy and the extent to which their current knowledge allows them to effectively solve problems. The interviewing strategy is as follows: having asked a question about a technical area of ​​interest to you in any area of ​​knowledge, move not “horizontally” within the area of ​​knowledge, but “vertically” into an adjacent type of knowledge.
They asked about fundamental knowledge, then ask what problems the person solved using it, or pose a practical problem in which this knowledge would be required, and then ask what tools are available to use this knowledge and better solve practical problems.

For example: What are compound b-tree indexes and how do they work? Can you give an example when such indexes may be required or when, on the contrary, they would be inappropriate? How can you understand that these indexes work effectively and what can be used for this?

If you hear comprehensive answers to all these questions, it means the specialist has really tried to develop solid knowledge in this area and acquire all levels of knowledge. Now we need to draw the right conclusions from this. This will either indicate that the specialist had a huge pile of tasks related to indexes, or that he has a good learning strategy (which does not exclude the first). To determine whether this strategy exists, it is enough to probe a few more areas in which the candidate may not be so savvy; this can often be seen from the resume.

Strong and promising candidates show that even in the absence of knowledge, they understand what they are missing and choose effective approach to compensate for lack of knowledge. If you check several areas in this way you notice that the candidate has effective strategy training, then all you have to do is check the fundamental knowledge required for you. After all, having them and the right learning strategy, the candidate will, with a high degree of probability, be able to solve new problems as efficiently as possible.
An effective learning strategy is a strategy for replenishing knowledge in any area of ​​all types (fundamental, applied, instrumental): try something, understand how and why it works, do something similar, learn tools to do it even better.

Typical errors in assessment

Many people tend to overestimate the importance of applied knowledge in relation to other areas, namely, that people with more experience in performing tasks are good specialists, but this is absolutely not the case. If the practice is not supported by fundamental knowledge, or the specialist has never expanded his tools, then the effectiveness of such a specialist can be very low. Look for those who can develop each area. They are the best, even if they don’t have a ton of experience behind them.

You can often find test tasks that are narrowly focused only on fundamental issues, such as language constructs, typical errors when using “non-intuitive behavior,” questions about OOP patterns, etc. As you can already understand from the above model, you will not identify “theorists” this way, and besides, fundamental knowledge is perfectly googleable. So the effectiveness of such tests is relatively low.

There is also a common belief that it is important to “understand how a person thinks.” Undoubtedly, this is a “beautiful” phrase, but it is very subjective, and, as a result, it is difficult to be confident in the result based on such assessments. In addition, here you can fall into the trap of a subjective assessment: “he doesn’t think like me.” However, if you see that a person knows how to effectively formulate his knowledge and solve problems, then it doesn’t matter how exactly he does it, because the main thing is the result.

If you provide attractive terms of cooperation and the flow of candidates is high enough, then draw up test task. Include several questions not from one type of knowledge, but from different ones. Based on the answers to these questions, you can get a rough picture of what the candidate's strengths and weaknesses are.

What to look for

There are several points that you should also pay attention to during the interview. They relate more to the personnel component, however, they appear specifically during the technical interview.

Inquisitiveness of mind. How hard does a candidate try to solve a problem if he doesn’t know the solution right away? Is he looking for alternative paths, analyzes clues, asks and analyzes the proposed solution. Weak candidates “skip over” everything they couldn’t understand.
Healthy self-confidence. To what extent does the candidate admit that he may not know something? Due to their upbringing, sometimes people have complexes regarding their own knowledge (“honored diploma students”, etc.). Sometimes, such people give decisions in a sharply categorical manner and do not recognize alternative opinions if they indicate a lack of knowledge on the part of the candidate.
The desire for self-development. The best candidates are those who strive to develop as specialists, or who strive to “make the world a better place” by creating some kind of benefit. Weak candidates believe that they are already “at the ceiling of their knowledge” and simply want to earn as much as possible from this. There are also candidates who believe that the employer should develop them, and not themselves, because it is the employer who sets the tasks.

Interviewing strategy

Before the interview, make a list of key areas in which you require experience from a specialist. It’s good if there are at least 10 of them. For example: PHP + OOP patterns; SQL + query optimization; architecture of high-load projects; working with cache, etc.
In each key area, create at least 5 questions for each type of knowledge, for a total of at least 15 questions for each area. This is best done so as not to come up with questions on the fly. It is desirable that such issues provide vertical connectivity among themselves.

For example:
Region: architecture of high-load projects.
Fundamental questions: What main parameters are important to consider when designing high-load systems? What typical architectural solutions do you know? What is the difference between horizontal and vertical scaling?
Application questions: If users can upload files, then what is the best way to solve the issue of horizontal scaling for return? If you have a page with a high RPM, and an information block that has long time generation, how can you speed up page rendering? If a single database has become a bottleneck in a project due to increased workload, what is the best way to approach this issue?
Instrumental questions: What tools can be used to load balance HTTP traffic? What caching servers do you know and what are their differences? How can you measure application performance under heavy loads?

Start with any of the questions of your choice. Consistently ask questions from each knowledge type in the chosen area (vertically). If you see that the candidate has a confident command of theory, practice and tools, then you can be pretty sure that he will also be able to confidently solve related practical problems.

As you answer the questions, moving through the areas, you will form a picture of how the candidate's knowledge is distributed. For example, you may realize a significant lack of theoretical knowledge, or gaps in knowledge of tools. Based on this, you can draw a conclusion about how effective the candidate’s training strategy and his current knowledge in general are. As a rule, the learning strategy is the same for all areas, that is, it is very rare to find candidates who know the theory very well in one area, but in another only solved practical problems and did not even try to ask the question “How does it work?”

Well, then, depending on the requirements of the vacancy, it will be much easier for you to make a decision. Looking for a junior? Make sure that you not only try to solve practical problems, but also replenish fundamental knowledge, and also look for and learn new tools. Looking for a middle? Make sure his skills are rooted in each type of knowledge and he understands where to go next to fill in the gaps. Looking for a senior? Make sure that he has excellent fundamental knowledge and can effectively “assemble” any practical problem with fundamental justifications and appropriate tools.

If you notice any gaps in the required knowledge, and they are not fundamental for you, but are still important, then be sure to write them down and work on them. probationary period a plan to fill these gaps, using this during certification. This will allow you to increase the productivity of your employees in a methodical and deliberate manner. However, the issue of training and development of employees is a completely different and very big story.

Where else can you use the model?

The given model, in fact, can be used not only for technical specialists, but for any profession in general. The only difference will be in how fully certain types of knowledge are realized in these areas. Take, for example, a janitor: What criteria for cleanliness do you know? If you need to clean 10 houses in one day, what is the best way to do it? For which surfaces what cleaning products are best to use?

As a conclusion

I recently decided to compile my notes on interview questions for PHP developers and post them on open access(the project is “on the knee”, so don’t blame me). Of course, not everything is there, but it’s enough to gather your thoughts together and get ready for the interview. You can see the questions at the link:
pagerton.com/hr/question/all
If there are positive responses, I will develop the project as much as possible, I would also like to send links to good courses for developers, so I would be grateful for feedback.
I hope this model can be useful to you too. Not only as an interviewee, but also as an interviewee, because understanding your strengths and weaknesses will help you develop more effectively.
I wish you to be the best and work with the best.

Hello everyone, Javarashites! It just so happened that I recently had an interview and would like to tell you what questions I was asked assuming that I was applying for the Junior++ position. Those. not a middle yet, but not a green junior either. So, the interview went according to this plan

  1. JavaCore
  2. Databases.
  3. The tools you use.

JavaCore

    First, I was asked to draw the hierarchy of interfaces for Collections (it was not difficult, there are only a few of them (Collection, List, Set, Queue, Map).

    What is the difference between ArrayList and LinkedList (this is one of the most hackneyed questions and answers on the internet, just darkness).

    We discussed the speed of query execution in them and what the difference is between the sheets.

    Question about the Object class. What are his methods, what do they do?

    Reflection. What the getClass() method does. Very interesting question, take it apart. Especially about how to get everything about a class, even if it contains private methods or variables.

    They asked about multithreading. It’s weak, I think, to tell you how you understand what multithreading is. What is needed to start a new thread. Realistically, if you are level 20+, then these questions will seem funny to you.

    What can you say about Stream. This is not about Java 8. It is about input and output streams. Like basic interfaces, what they are (character and byte). For understanding, no specifics.

  • Exceptions. Here again we were asked to draw a hierarchy of exceptions, what types there are, which ones are checked and which ones are unchecked. What to do with Runtime exceptions. Name the most frequently encountered one (NullPointerException).

    • The question is what should be done with checked exceptions (forward further or process - both are clear).

OOP

    What is OOP in a nutshell?

    What other programming paradigms are there? How are they different from OOP?

    What are the basic principles of OOP (inheritance, polymorphism and encapsulation)? Tell us about each of them. So far everything is abstract, not tied to any language.

    System design understanding task: there is a Horse and a Bird. We need to get Pegasus. principle "has a" and "is a"

REST

    What is REST. Wikipedia talks about this very coolly. In fact, an article from Wikipedia is enough to get acquainted with.

    HTTP. There are also general phrases here. His methods, what each of them is for.

    HTTP status codes. What five parts should be divided into, tell us about the most famous ones (200,204,404,500,501). Why do they? They also asked about 401 and 403. But I didn’t know them. They said they were important.

Databases

Here I told you that I know MySQL. Told about three normal forms. I talked about Joins, what they are, and drew the intersection of areas in which different joins are used. I talked about how I understand a relational database. I also didn’t forget about MongoDB - this is a NoSQL database. After some time, I will write about that too.

Other tools

Here we went through my resume. It was written that I use Maven/Gradle for assembly, I use JIRA for tasks, git, Docker, Swagger. For Continuous Integration - Stash, Bamboo, Puppet. For testing JUnit, Mockito, JMeter. I might have forgotten something, so if you're interested - ask in the comments I'll try to answer. This was the first part of the interview. Now I’m waiting for the results and if so, there will be a second part. I will write about it as soon as possible. Anyone who liked the article and found it useful - put "+". Write in the comments. See also my other articles:

There is a lot of material on the Internet dedicated to interviews with HR managers, but almost nothing is said about the intricacies of interviews with technical specialists. This article is devoted to what qualities and skills a candidate must have in order to successfully pass this stage and receive an offer in an IT company.

Dialogue from life:

Candidate: We must perform operation “A” until condition “B” is satisfied.
Me: Great plan. Let's implement it.

The candidate writes a for each loop. Although it's obvious. If a candidate has passed this level, he will sooner or later become a good programmer. But 70% of applicants fail here.

Bogdan Gusev, service station

Let's correct this annoying misunderstanding.

while (bool offer == false)(

Rule 0

If you are interviewing for the role of a Java developer, you need to have a good knowledge of Java and related technologies

//No comments.

Rule 1

Prepare for the interview in advance

Find out from the recruiter in advance all possible details about the project.

Google search for questions that are commonly asked in interviews. Some of them will definitely come across.

Alexander Pitz, Project Manager

Rule 2

Don't lie on your resume

Trying to deceive by exaggerating your knowledge is a waste of your time and the company’s time. You must be able to answer questions about all technologies listed on your resume.

A resume filled with keywords, about which you do not have a proper understanding, ruins your chances of receiving an offer.

Rule 3

Align your values ​​with the company's values

Every company has its own values. One team values ​​dedication and focus on results, and as a result, does not disdain overtime work. The other is innovative at work, and is willing to learn and apply innovations every couple of months. The third is reliability and stability: proven technologies, dedicated people who will not leave the company if the cookies suddenly disappear.

There is an acceptable limit for the discrepancy between values, if exceeded, the company will most likely decide not to make an offer, even if the candidate has the necessary experience and the necessary technical knowledge.

Rule 4

Develop communication skills

I want the applicant to have better communication skills high level than the basic one. In our age of complete agile, this quality comes to the fore among the necessary skills. The candidate should not have difficulty communicating with HR and technical specialists, as well as with customers.

Rule 5

Improve your English

Unlike uncritical failures in knowledge of any technology, you will not be able to improve your language skills in a couple of months. It takes years here. Therefore, insufficient level of English in most cases is a sufficient reason for refusal.

A little motivation: the level of English and the salary of Kyiv Java and .NET middles and seniors with 3-5 years of experience corresponds.

Rule 6

Show your passion for your profession

According to Bogdan Gusev, the fact that you enjoy your work can be indicated by the presence of Open Source projects, participation in thematic conferences, and mastery of text editor or IDE features. And, of course, interest in details further work. Programmers who are indifferent to their work are not in high demand among employers.

Rule 7

Show intelligence and abstract thinking

The candidate must:
- be able to solve problems corresponding to his position;
- know the required programming language and frameworks;
- navigate the technologies of the project for which he is being interviewed.

If the position is poorly defined, then general erudition and intelligence are tested, as well as the ability to think structurally and find solutions.

It is very important to demonstrate the ability to use your knowledge. If you know approaches and methods for solving problems and know how to obtain missing information, then you will be able to cope with the tasks you receive.

Rule 8

Demonstrate a desire to gain new knowledge

Sometimes a candidate will say, “I have studied technology X and I only want to work with it. Why should I study technology Y if I know X?” The chances of such a candidate getting an offer are sharply reduced. Technologies are just tools. After some time, X will become irrelevant, and with it the specialist himself, who only knows it.

Maxim Kovtun, Solution Architect

Rule 9

Show results orientation

I rate:
- the ability to compromise with one’s “religious beliefs” (for example, if a release requires it, use a “hot fix” rather than approach the solution fundamentally);
- the ability to insist on one’s own when necessary;
- and even more important - the ability to maintain the right balance between the two points above.

Andrey Mudry, Project Manager

Rule 10

Don't say "I don't know"

Exception: if you have never worked with this technology and it is not listed on your resume. In this case, it is better to be honest and ask the interviewer to explain the correct answer to you.

If you don't understand what we're talking about, ask a clarifying question.

If the question is specific and you are not sure of the answer, then you should admit it and be sure to make assumptions based on your experience. Explain your thought process. If the question is open-ended, then there is no single correct answer.

The worst answer is silence or “I don’t know.” You must try to solve the problem, no matter how stupid your solution may look. Even the most naive answer is better than nothing. Two or three answer options are generally great. Pepper these answers with considerations about their applicability and additional questions to clarify the problem - and it will be great.

Alexey Kolupaev, service station

Rule 11

Don’t be shy to learn even during an interview.

It's impossible to know everything. I once worked on a project that required knowledge of a rather specific technology stack and cartography. Experience has shown that few programmers can convert the classic coordinate notation from WGS84 to decimal notation. In such cases, I think a good answer in an interview is the question: “Can I look into Google?”

Artem Polyukhovich, CTO

Rule 12

Think about what you say in response

You don't have to pretend to be mentally active for a minute, but try to think about the problem as broadly as possible. Moreover, during interviews there are often trick questions.

It's good if the candidate tries to "infer" the correct answer to the question. He does not guess, but uses his existing knowledge, as well as logic, intelligence, resourcefulness and the ability to quickly make decisions under pressure. This quality is very useful in a flexible development approach, when the customer requires quick solution problems, sometimes even during an online conference.

Sergey Chirkov, Project Manager

Rule 13

Admit mistakes you've made

The ability to analyze and admit your mistakes indicates that you will be interested in both your own professional development and the result of a specific job.

Rule 14

Don't ruin your reputation

A careless answer to the question “Why did you leave such and such a company?”, disorganization, being late for an interview without warning, or a refusal to complete a test task can ruin an opinion about you.

Rule 15

Build a partnership with the interviewer

It seems to me that in the expression “working relationship” many people focus on “working”, but they should put more emphasis on “relationships”. In this sense, an interview is similar to a date: you both take a closer look at each other, figure out whether you will be good together. And when someone tries hard to seem better than they are, it can be irritating. Sometimes a candidate can be so captivating that it’s easy to turn a blind eye to even serious shortcomings.

Alexey Kolupaev, service station

Rule 16

Behave properly

“Correctly” means politely, respectfully. Arrogance, ingratiation or flattery towards the interviewer will only spoil the impression. Humor is also not always appropriate.

Several failed behavior patterns can be identified:
  • Friend- moves the conversation to an informal level in order to avoid specific answers to specific questions.
  • conqueror- takes the initiative into his own hands, speaks loudly and a lot, and does not allow questions to be asked.
  • lazy- after an hour of interview, he shows that he is experiencing real torment - such a person is unlikely to be able to work intensively for more than 1 hour a day.
  • architect- creates a large number of useless classes before outlining a solution plan. As a result, it itself cannot take advantage of its own “architecture”.
  • theorist- the most dangerous type, ready to communicate on any topic, as long as he is not forced to show practical knowledge. Can easily describe a solution algorithm, but is not able to program it.

The latter is easily determined by the following dialogue:
Me: Bring your laptop to the interview
Candidate: Why?

After such a dialogue, it is immediately clear that the candidate believes that the main thing in being a programmer is talking about cool technologies in the kitchen. He doesn't know that programming on a familiar keyboard is much easier than on a foreign one. Consequently, he spends little time on it. I wonder how his work day is going?

Bogdan Gusev, service station

Rule 17

Be adequate :)

Adequacy is a fairly broad concept. First of all, it includes a reaction to difficult situations. What does a person do when faced with an incomprehensible piece of code or a complex algorithm? How will he behave with colleagues when he needs something from them (or needs them)? What does he do if a conflict of interest arises? What if he is given an impossible or difficult task?

Artem Polyukhovich, CTO

Rule 18

Be optimistic

Positive attitude - very useful quality. It is much more pleasant to work with a person who knows how to notice positive moments in life, in work, in everything.

Rule 19

Feel free

An interview is a discussion between two equal specialists. Thus, stiffness is more of a minus than a plus. It will prevent you from expressing yourself at the proper level.

But too much self-confidence is also a minus. A monologue for 20 minutes without stopping can serve as a reason for refusal.

Behave naturally, don't be shy. For example, if you find it easier to process information visually, don't be afraid to ask for paper and pen.

Rule 20

If you fail, learn from your mistakes

Think of the interview as an opportunity to learn something new and get feedback. This will be beneficial even if you don't receive a job offer.

Alexander Kaganovsky, service station

Interviews rank high on the list of most people's biggest fears, along with public speaking. Not only are you performing in front of someone, but you are also constantly being evaluated the entire time... brrrr!

Of course, we're far from trying to understand and overcome your psychological barriers, but it's definitely best to view interviews as a chance to show off all the cool things you've created and all the interesting new skills you've learned. Best interviews- these are enthusiastic conversations with a technical slant.

The first step before all this is preparation. You'll want to think about the possible questions (and the most common answers that highlight your brilliance) and research the hiring company. Your knowledge of the company will help you present yourself in a way that suits their needs, and will also allow you to ask smart questions about their products and technologies when the time comes. Once again, refer to Happy Bear's article for practical tips.

What is this whole process?

Just a quick look at the process the average tech company goes through when hiring developers:

  1. Preliminary interview by phone (Phone Screen)
  2. Technical interview
  3. Test terms of reference
  4. Follow-up interviews to ensure you are a good fit (Fit Interviews)
  5. Job Offer
  6. Discussion of offer terms (Offer Negotiation)
  7. Offer Acceptance

Preliminary telephone interview

Congratulations! Your resume turned out to be not the most disastrous and you were invited for a telephone interview (note that sometimes you do a test task first). The real purpose of this step, which often involves a half-hour conversation with someone in HR (rather than the hiring decision maker), is to make sure you have a good chance of making it through the rest of the interview process. So think of it as a lighter version of the other steps.

You'll probably be asked about some of the technical stuff you put on your resume, but don't go too deep (although some employers do ask some pretty tricky questions), and you'll likely be asked some "softer" questions about why you chose this job. and what you did before. Telephone interviews can vary greatly from company to company. The main tactic here is not a tactic at all, just be honest, energetic and open. And don't be afraid to practice talking about yourself in front of the mirror.

A FINAL NOTE - This is not a one-size-fits-all method and many companies skip it in favor of diving straight into the depths of a technical interview, so you need to prepare just in case. The link below to Coding Horror is the most illustrative of this case.

  • Achieve Phone Interview Excellence with Monster
  • 7 Steps to Achieving Excellence in Telephone Interviewing

Technical interview

The technical interview is usually the scariest part of the selection process. This is where they will assess whether you have the required technical skills. This means that they will not only ask you in great detail about your work, but will also ask you to decide logic problems or write code right there or sketch out a diagram of some new components.

In fact, one of the purposes of such an interview is to take you to the very edge of your capabilities, just to see how you react to unfamiliar things. If you do an exercise too easy, they will move on to something much more difficult. There will always be places to stumble, especially for beginners. Your greatest asset is your honesty and curiosity.

When solving a problem, make sure you do it in a clear and logical way, explaining out loud why you are doing a particular step. Talk through all the obstacles you encountered and give examples of how you would solve it in " real world". Often the answer is to "Google" some specific function. Say so! They know you're not a Ruby expert, but they also need to know that you can come up with solutions to the problems you'll inevitably encounter on the job.

It's also completely normal if you use brute force - an inefficient method - to solve a coding problem. This is often the best starting point for getting a proper feel for the problem. Most likely you will be asked how the solution can be improved, but this is much better than trying to come up with the perfect solution and not having time to write anything in the end. Once again, your job is not to be a standout candidate, but to show that you are adaptable and resilient when faced with challenges.

And if you don't know something, it's better to say it honestly and try to think it through with the interviewer. Believe me, they want you to succeed just as much as you do, because there is nothing worse for an interviewer than seeing someone silently trying to solve a problem, getting more and more stuck without asking for help and not letting anyone know what he was thinking.

You'll have to read about large quantities things that were not emphasized in previous courses, for example, data structures and algorithms, simply because they are very popular to ask about in interviews. They don't always reflect programming skills well, but it just so happens that you'll be answering questions that fall into a more academic area of ​​computer knowledge.

Links

  • Let's look at the interview for programmers: MUST READ MATERIAL who will be yours best friend. It takes a comprehensive look at all types of challenges you will face in an interview. It goes beyond what we've already covered in this course and touches on things that are good to know because you're likely to encounter them. Take the time to get to know as many as possible a large number material.
  • Interviewing.io gives you the chance to practice anonymously and online technical interviews.
  • How to get a perfect score in a technical interview
  • How to Stand Out in Your Next Web Developer Job Interview
  • Read 40 key computer science concepts explained in easy-to-understand language
  • Google's Tech Skills Guide(for advanced)

Programming test tasks:

  • 8 queens is a classic problem.
  • Programming for Interviews: Know the Standard Libraries may be overkill for a beginner, but it never hurts if you take the time to do it.
  • On Project Euler you will find more general and complex problems that need to be solved efficiently (they may require a lot of computation).
  • Practice questions for Java and Python are published on Coding Bat.

Algorithm training:

  • Algorithms course from Udacity (not synchronized)
  • Algorithms course from Coursera (partially synchronized)

Architecture:

Technical test task

Test homework may occur either before or after a personal interview, depending on the company. You will be given a task that will require a full day to complete at any time convenient for you. Examples of such an assignment might be creating a sample web application with tests or solving a complex algorithmic problem with writing code.

The evaluation will be based on the completeness of the solution and the quality of your code. If this occurs before the technical interview, then it is good method check your interest (up to half of applicants do not even return with a solution).

Final interview (“Fit”)

The last step before making a decision is usually to get to know the team and offices for a few hours. You may be tested technically, but the main goal is to make sure you will be a good colleague. If some other team member says that you won't work well, they most likely won't hire you. Advice? No need to be weird or awkward, even if you're at home :)

This is also an opportunity for you. If you've made it this far to get to this step, there's a good chance you're generally eligible. You need to consider whether you want to work for this company, so prepare a list of questions and get answers to them.

A little about wages

Not. Voice it out. Yours. Salaries. Expectations.

You will always be asked “how much would you like to receive?” Your Answer? “I would like to get paid at the average market price” (unless you are so arrogant as to ask above the market price. Let's see how that works out for you). You won't gain anything by naming your desired salary level. If it turns out to be lower than what they wanted to offer you, they will simply lower this level. And if it is higher, then they will simply interrupt the whole process, deciding that you are too expensive for them.

Once you get an offer, you can check how it compares to the average market pay by asking a few people (hopefully you already know a few people to ask) or by going to Glassdoor (just remember you're a beginner, which means you will not receive an “average” salary). The most important thing is not to harm yourself when asked.



Related articles