home » Style » How not to fail a technical interview at an IT company. How to Conduct Technical Interviews

How not to fail a technical interview at an IT company. How to Conduct Technical Interviews

I expected to receive quite a lot of questions on this topic. However, the opposite questions - “How to pass it?” - much more poured into the mail and forum of the Quality Laboratory. Following the demand, I continue the series with a response article.

Introduction

2. Test the elevator!

So, you explained what equivalence classes and boundary values are. It's time to check if you know how to use them. And so, you are asked to test the elevator. Or a pencil. Or a calculator, jeans, a cup. No matter what. The task is most likely unusual and non-standard. What does the employer expect from your answer?

The ability to think creatively. This is incredibly important for testers. I have repeatedly met applicants who, when asked “test a cup,” cannot come up with a single test. Most likely, they will also have problems testing the new component.

Structuring. If calculator testing begins with division by zero, then the applicant most likely does not know how to prioritize tests and does not very well understand the main tasks assigned to testing.

The ability to use techniques that seem so simple in theory. If you plan to travel by elevator from each floor to each floor, it means that the understanding of equivalence classes has not gone beyond theory.

Ability to use everything possible types testing. Load testing of an elevator (call from all floors), volumetric testing of a cup (pour maximum water into it), performance of a calculator during the addition operation, usability of jeans and user documentation for a pencil - best ways show that you are “in the know.”

The correct answer to such a question follows from the requirements for the answer described above. Structure your information. Find out as much as possible about the object being tested. Determine what you will test in functional and non-functional testing. Think about how you can optimize your test suite so that you don't have to test everything. And under no circumstances start your answer with specific tests - monkey work differs from competent testing in that it involves preliminary thinking through your actions.

3. Tell us how to create test cases

Or how to write a test plan, how to create a test automation framework, or anything else. The worst thing you can do when answering this question is to try to pretend that you know how to do something when in fact you have never done it. If the topic is familiar to you and you know how to answer, take the flag! If you are not sure of the correctness of your thoughts, be sure to warn the interviewer about this with a phrase like “I have never done this, but the following sequence of actions seems correct to me...”. Sincerity is always captivating, and mistakes in the answer will not be taken seriously. If you tell the “correct” approach without being sure of it, and say nonsense, it’s unlikely that anyone will want to hire you.

4. Why is testing needed at all?

I will not give lengthy advice on this issue - or I will write a separate article. Just make sure you know how to answer this philosophical question.

5. How to determine the quality of a product?

This question, like the previous one, is also quite common. Google will help you be prepared for it.

Technical issues.

My plans for this article do not include stories about setting up DNS and querying databases. But there are some general tips that you should follow:

1. Don't try to pretend that you know something if you don't know it.

Firstly, the lack of technical knowledge is quickly compensated for and employers rarely pay very serious attention to this issue. Secondly, poorly hidden ignorance always causes mistrust: can the rest of the candidate’s words be trusted? And thirdly, a potential employer may share my opinion that people who defend the wrong point of view are more likely to make mistakes in their work. At least, I didn’t hire an employee who was well versed in testing, but diligently argued that “Windows does not support dynamic disks.” Most likely, if he had honestly admitted that he did not know what it was, the decision would have been different.

2. If you see that you didn’t answer the previous questions very well, initiate answers yourself, but on topics that you know better.

For example, if you unsuccessfully answered the question about MS SQL, tell yourself that you have experience working with Oracle and therefore can quickly “re-profile.”

The ability to quickly and independently understand an unfamiliar technology or tool is valued higher than existing knowledge. Don't be shy to praise yourself. If after your words that you don’t understand Rational Robot, the interviewer wilts a little - proudly say that you figured out Silk Test in just a week and managed to do a lot (be specific) in it. Naturally, you need to tell the truth here too!

Conclusion

The main thing is not to be afraid. You are looking for a job, and the employer is looking for a competent employee. Both of you are interested in the outcome. Being hired for the wrong job is significantly worse than being rejected. Try it, don’t be nervous, learn! And develop for yourself – and not for “show off” at an interview. Good luck!

How it happens

In most cases, another specialist is invited to carry out the assessment. high degree technical competence, which, 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, rather narrowly practical questions may be asked that 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 they are asked open questions like “What problems did you have to solve?”, again, the discrepancy in experience can be interpreted as “He’s not suitable for us because he hasn’t done what we’ve 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 a lot of practical experience and answers questions well on specific solutions, but when he is hired, it suddenly turns out that he makes fairly typical mistakes in areas with which he has not worked 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 it will shoot. Because if it works, you can get a good “star” into 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.
To be more likely to weed out these negative scenarios, and also to conduct interviews of technical specialists more effectively, you can use special model collecting information.

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 is 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 correctly writing 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 individual words after his parents; 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 at all. 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. There is an 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 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” within adjacent view 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 are working 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 formulate confident knowledge in this area, 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 good strategy training (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 lack and choose an effective approach to compensate for the 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 true. 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, which are narrowly focused only on fundamental issues, such as language constructs, typical mistakes 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 create a 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? Does he look for alternative paths, analyze clues, ask and analyze 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 disadvantage 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 it down and work on a plan during the trial period to fill these gaps, using this during the 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

Recently I decided to collect my notes on interview questions for PHP developers and put them in the public domain (a project on my knees, 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 the 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.

Programming,

Website development

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 technical questions.

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.

During my professional career, I had the opportunity to visit both sides of the barricades, although, perhaps, technical interviews I still had to do a little more than go through 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 off a potentially suitable applicant myself.

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

Interview from the applicant's perspective

1. “What other 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 turned 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 treat him 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 will it take to clean all the round windows in school bus, reduced 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 point 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 habitat, even doing very cool and non-standard tasks, still rarely codes under stress, but 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 matter of professional ethics, demonstrating that here they will help and teach him if something happens , will not be left 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

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?

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 do I need to know this, everything is in the standard library, I work on more high 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 code base. 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 your code 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.

Siraj Rawal, developer, writer and vlogger, shares how to ace any technical interview in 5 steps.

I went through this process dozens of times in various IT companies, and I remember a huge number of both refusals and offers. And here are the lessons I learned from it. Interviewing takes work: don't believe those who say it should be easy. This is wrong. People talk only about their successes and never about their failures.

I have outlined several steps that will allow you to avoid many mistakes and successfully pass any technical interview.

Step 1. Preparation plan

Learn. Even before you have the bright idea of trying to get a job somewhere, you should concentrate on upgrading your technical skills.

The hiring process for a developer position looks pretty much the same at many large companies. As a rule, it takes place in two stages. First, the recruiter communicates with the applicant by phone to understand how interested he is in their company. Upon successful completion of the first stage, it is followed by 1-2 technical conversations with specialists, during which he is asked difficult questions and problems that he must solve on the board. He must show his thought process in solving a problem, find a suitable solution, and then he will be hired.

The only way to learn this is practice. All my friends who work in cool companies do a lot of work. The point here is not to have extraordinary intelligence, but to work hard and thoughtfully.

The question arises: what exactly should you practice? You will not be tested on your knowledge of the syntax of any language. If you want, you can learn the basics of Ruby syntax overnight. But what the night is not enough for is the basics of fundamental computer science. But at the interview they will test your knowledge of data structures and algorithms.

Start by taking two courses:
introduction to data structures (My Code School)
Introduction to Algorithms (MIT Open Courseware)
Both of them are in the public domain and are ideal for gaining basic knowledge of these topics.

After this, you can consolidate the acquired knowledge on HackerRank and HackerEarth. These resources contain a huge number of problems to hone your programming skills.

After solving a couple of dozen puzzles from both sites, read the books “Technical Interviews as They Are” and “Breaking the Technical Interview.” They'll walk you through many specific tasks from real interviews, from systems design problems to time and complexity questions.

After completing all the above rituals, start rehearsing an interview with one of your friends. Ask him to ask you questions and answer them using only a marker and a white board and explaining your thoughts out loud. I recommend doing this for two to three months, two to three hours a day.

Step 2: Find companies that interest you

If the process of preparing for each interview takes two to three months, then, naturally, you would really not want to waste this precious time on companies that do not impress you.

Keeping up with companies' interview process can be quite stressful, but try to stay organized. Make a list of companies that interest you and note what stage your relationship with each of them is at. Angel.co and Hacker News are good resources for this.

There is something supernatural about this. You will have to strain all your strength psychic abilities, to understand how to best apply your skills in your desired field and find companies that will allow you to do so.

Step 3. Create a portfolio

Large companies receive hundreds of resumes a day, so they simply need to weed out a lot of mediocrity that is not interesting to them. How to stand out from this gray mass? Make sure that all the words in your resume fit on one page and that it is concise but to the point. Highlight the most important work you have done.

It's a good idea to have several resumes: one for each specialty or for each company where you are trying to get a job. In your portfolio, separate personal projects, projects from hackathons, contributions to open source projects.

GitHub is a great place not only to store your code, but also as another portfolio that can serve you well.

Make your best web project your own resume website. Try to make it look stylish and professional so that it can impress a potential employer.

Step 4. Get an invitation to an interview

The easiest way is to apply for a company vacancy on a specialized website. But large companies receive many such responses every day, and it is very easy to get lost among them. A good option- send an e-mail to the company's recruiter, making it short and succinct. Include it short review about who you are and what you want to do, a link to an easily accessible and relevant project, and express a desire and willingness to learn and experience new things.

It's time to move on to...

Step 5. Pass the interview

Sometimes the interviewer may be more nervous than you are, and that's okay. Just smile, be polite, make it clear that you understand him and are willing to cooperate to achieve common goal.

Deciding technical problems, don't be afraid to think out loud. Remember that this is exactly what they want from you: the correct answer is not as important as the correct train of your thoughts. When a job seeker comes up with the first solution, the recruiter often asks him to find more effective options. This is where your computer science knowledge comes into play.

And don't be shy to ask questions. The interviewer is there to help you. And despite the fact that his main goal is to evaluate your skills, it is also important for him to try to find a relationship with you. mutual language, collaborate with you and help you achieve a common goal. So if you come prepared, everything will be fine.

Conclusion

Preparing for an interview and passing it is a responsible and time-consuming process. Never, never, NEVER let rejection get you down. Getting an interview is also a great experience, even if you don't get hired. Therefore, over time, you will achieve the highest skill and be able to successfully pass any technical interview. The main thing is to train, believe in yourself and stay motivated.

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 off a potentially suitable applicant myself.

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 his 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 plenty of ways for technical interviewers to scare candidates away from an interesting position. I will tell you about what has always scared me personally, and what I try to avoid as an interviewer.1. “What other 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 was involved in, 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!

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 treat him 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 often have to deal with such literate and well-meaning people, and believe me, it 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 to the applicant and do not consider him so stupid that he is not able to copy his own name from his passport to his resume. 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 point 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, this is a great way to recruit a full department of child prodigies with the Brain Olympiad, who will exchange fresh brain teasers all day long instead of working. A real programmer in his natural habitat, even when dealing with very cool and non-standard tasks, still rarely codes under stress, but spends most of the day sitting and leisurely thinking in a relatively calm environment 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 matter of professional ethics, demonstrating that here they will help and teach him if something happens , will not be left alone with technical problems. Tell him at least a few words, what to google, what to read. After all, interest in the correct solution of a problem is in itself a positive quality of a technical specialist, and such a person should not be demotivated by a dismissive attitude towards 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 a precise definition of 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 if it does not require 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. I heard similar things from mobile application developers about the protocols of the TCP/IP stack, and from front-end programmers in response to questions about sorting and search 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 the basis, without knowledge of which it is impossible to competently write anything that goes beyond the boundaries of one computer.4. “And 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 code base. 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 not right!"
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

Views