The perfect technical interview. Tips from Neil Roseman

09.07.2016

We suggest that you approach the interview for a developer position software with humor and perceive it as if you are playing a computer game in which you are moving towards victory and passing levels. Therefore, we have prepared several cheat codes to help the main character of this game.

Benjamin Weiss of Infusive Solutions turned to HR colleagues and computer game developers to create an “interview game.” There will be levels in the “game” that you will need to “pass” to get a position, starting with an interview with a recruiter. The concept of the game may seem ridiculous, but the information that Weiss and his colleagues provided is simply priceless.

Cheat codes for defeating the 4 bosses you may encounter in the quest to become a new software developer

In most cases, long haul Getting a job as a software developer is tortuous and full of difficulties.

Of course, if you are a very talented and creative person, you may be accepted faster than usual. The process can also speed up if the company urgently needs an employee.

But usually, software developers find themselves on a huge, labyrinthine quest to climb through multiple levels to get their dream job.

Wait a second, what is this super quest? What are the levels? Looks like a computer game, doesn't it?

Let's get to the heart of our idea. If you think about it, the managers involved in the technical interview process are similar to the “bosses” that players meet at the end of each level. computer game.

The main player (for example, Mario, Zelda or Duke Nukem) needs to defeat all the bosses in the game in order to advance to the next level: just like managers in IT companies.

The hero needs to learn to build strategies depending on the characteristics of different bosses in order to win the game, because each of them has different characteristics(although there are general tactics).
So let's take the interview for a software developer position with humor and perceive the whole process as an exciting game in which you go to the final and defeat the managers who hire you, who will be:

- recruitment specialist;
- senior developer;
- software manager;
- CTO.

Are you ready? Great! We start with a scrum with a recruiter from the human resources department at the first level.

Level 1: Boss, recruiter

The HR boss has the following characteristics:

- guards access to other bosses;
- the first person to read and evaluate your resume;
- usually not technically prepared;
- interested in you applying for several vacancies in the company.

Jennifer Loffus, regional director of Astron Solutions, former president New York Human Resources Association.

Anyone who has interviewed for a software developer position knows that you will most likely need to meet with someone from the HR department first. He or she usually has a lot of questions for you and also holds the key to the next levels where you will meet with IT department managers. How do you get past that first level where your resume is reviewed, you get a phone call, and you have a face-to-face conversation with your HR boss?

There is an opinion that personnel officers have only one desire - to fill up candidates for a new position. Remember Toby from The Office? So, his image of a HR specialist is greatly embellished.

Perhaps the recruiters have already put a damper on your career plans. However, their main goal It’s not about not being accepted. They are faced with a specific task from management to find the best candidate for the open vacancy, so they look at the following characteristics of the applicant: education, professional experience and qualifications in the required field. Let's explore the alignment strategy ideal relationship with personnel officers.

To get to the first level of an interview with a HR employee, avoid the following mistakes:

Do not send your resume with errors

Your resume speaks about you, your attention to detail and your interest in the job. A resume with errors will tell HR officers that you are indifferent to both the company and the position itself. Carefully check your resume for errors several times, read it out loud to spot any typos. Ask someone else to read it again, as they may find errors that you missed.

Don't send your resume too long

You have achieved a lot in your career and want to talk about it. And the personnel officer wants to understand whether you are suitable for a specific position, while he has very little time to get to know your resume. Edit your resume so that it is relevant to the position you are applying for. The resume should contain 500 - 1000 words and be a maximum of two pages in length. Use 12 font to make the text easier to read (not 8 or 9).

Do not send general resumes and motivation letters

Your resume and motivation letter should be tailored to your specific position, company and business area. For example, if you are applying for a position as an Internet developer in financial company, and in your resume and letter, talk about your interest in information technology management in non-profit organization, you are unlikely to be invited for an interview. Describe!


You have been invited to an interview with a member of the HR department!

Congratulations! You have already received an invitation to the first interview with the HR officer. We have prepared several cheat codes that will help you pass it and meet the senior developer at level 2.

Cheat code: If you send a resume that is too long, not tailored to a specific position, or contains errors, your game will be over before it even begins.

Come early and well prepared

When you arrive at the company office, you may need to fill out some paperwork. so that they can be completed before the interview begins. Managers usually have a busy interview schedule, so waiting 20 minutes for a candidate is unacceptable to them. In addition, bring the contact information of those who agreed to give you recommendations.

Dress formally

A business suit with a tie is required for men, and a trouser suit or jacket with a skirt for women. If you are applying for a creative position in a young company, classic style may not fit. Check with the HR officer for the dress code.

Get yourself in order

Unpleasant odors should not distract your interlocutor. Make sure you don't smell like onions, garlic, tobacco or coffee before your meeting. Stock up on gum or mouth spray.

Focus!

Give your full attention to the HR employee during the interview, be polite to him, turn off mobile phone so as not to interfere.

Almost level 2!

Make sure you are dressed appropriately, smell nice, and are fully prepared for the interview. And now you are at the finish line of level 1! In addition to ensuring that you have all the skills and experience required for the position, you must...

Maintain eye contact

If you look your interlocutor in the eyes, you are showing genuine interest in the work and the company. Look at it, and not at your hands, the ceiling, the door or the window, this will significantly increase your income.

Go on the offensive

Many take a break from their professional experience, especially during times of crisis. Be the first to explain the reasons for breaks in your career and don’t wait for questions on this topic. An open and active position will give you an advantage over those who try to hide such facts.

Be prepared to talk about past employers

Most likely, you will be asked why you left with past work, as well as what you liked and didn’t like to do in your previous position. Prepare credible and tactful responses. Remember that negative information about your past manager or colleagues will not work in your favor.

Speak in clear words

Software developers use many acronyms: ASP, CAO, GAC, IIS, etc. During a conversation with the personnel officer (possibly without technical education), unscramble each abbreviation the first time you say it. Make sure that you speak in a language that the other person can understand so as not to provoke further questions.

Ask questions

Study information about the company in advance and prepare at least 3 questions for the HR employee. Here are some no-fail questions you can ask during your interview:

- What do you like most about the organization?
- Why do you work here? People love to talk about themselves!
- How do information technologies support the company’s development plans?
- What mistakes do new employees usually make?

Say "thank you"

If the interview went well, the recruiter will spend 30 to 60 minutes with you. On the same day, send one traditional email and one email email gratefully for his time.

This proven technique will make you stand out from the crowd, and your interlocutor will definitely remember you. In the letter, indicate a couple of topics that the HR manager talked about to make it personal.

So, you have passed the interview with the recruiter and the quest continues, in the next article meet the boss at level 2: senior developer.



Tags:

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 little overview of the process the average goes through tech company 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).
  • Published on Coding Bat practical questions for Java and Python.

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.

Victoria Pridatko is a well-known expert in the field of positive management of IT personnel: she can be found at IT conferences dedicated to management. This year she is one of the headliners at the Find the Answer conference for HR specialists in IT in St. Petersburg. We are publishing her report from the Software Project Management Conference, which will be held in Minsk this year.
Presentation of the report Video of the report

Text of the report

One of my favorite phrases - I repeat it often because it's Captain Obvious -
You can't create a first impression a second time.
First impressions are very important, and candidates often form an impression of a company based on the first interview. If it was negative, it is very difficult to later convince them otherwise. Why do you need this? Where can this knowledge be useful? The more pleasant the communication with you, the better your reputation, the more money and more choice. When you are famous, in in a good way this word, when they pay attention to you, applicants want to get an interview with you. And what more people they want to get to you, so more companies make you offers. And the better you conduct interviews, the more accepted offers you have. PMs often say this: recruiters can’t find anyone for us, so we can’t create a team. When I come to them for a technical interview and watch how they conduct it, I understand why it is so difficult to find people who would agree to interview there. A good interview is a step towards becoming a manager: if you are not yet a manager, but want to become one, you need to be able to interview.
  • An interview is about communication. This is what we'll talk about,
  • How does this happen? I will talk about my experience.
  • Mistakes in interviews.
  • Signs of a great interview.
  • Who/what can help?

Interview with HR

I can’t speak for Russia, but in Ukraine they are now hiring very pretty, dare I say it, sexy girls who lure candidates in every possible way. As a rule, two interviews are organized: with HR and technical. Often the candidate relaxes at the first interview, but the second interview is very different from the first - a technically strong specialist comes to interview. The problem is that very often such specialists want not only to conduct an interview, but to show themselves. Unfortunately, this process is not always structured in companies, and technical specialists are not asked when it is most convenient for them to conduct interviews - they are simply pulled out of the project. As you know, programmers work in a flow, and then it is very difficult for them to return to it... unfortunately, not all companies take this into account. Accordingly, the technical interviewer’s feelings are as follows:
  • Damn, another interview!
  • Well, tell me what you know...
  • Yeah, you don’t know that, bugger - again the recruiters invited stupid people.
  • But I know this and that, therefore - I am PEPPER!
I once had the following experience: we were looking for a Jawist for one company for a very long time, and then the recruiters found a great Jawist, invited him for an interview, everything was great, he came for the second time, and was interviewed by another Jawist who needed to assert himself. As a result, he said: “Well, shall we... compare or talk?” This impression simply killed the candidate, and the impression was created accordingly. The worst thing is that this information is then broadcast further.
Why can't this be done? Because during an interview, people often form an opinion about the entire company. As you know, people join a company and leave the manager. Let's say that during the interview you had a comparison... and left with the feeling that you are great, and the candidate left with the feeling that he is terrible, and what will he tell people?.. The more such interviews you have, the less, unfortunately, you candidates. Main mistakes during a technical interview:
  • Show-offs;
  • Cleverness and chatter– when people are competent in a certain topic, they tend to develop this topic, and as a result, the interview turns into the interviewer talking about his favorite question. If you want to talk about yourself, go to the conference and tell us what the problem is?
  • Indifference- also a common pattern when technical interviewers sit tiredly, their whole posture indicates that they are terribly bored and generally do not understand what they are doing here... Again, this very much depends on how it is organized in companies. I know companies where this process is organized well, where people conducting technical interviews are also paid for it...
  • Stress interview- this type of panel interview, when five interviewees take turns “wetting” you... Although I have seen interviews when five people were interviewed and the atmosphere was quite friendly.
  • Late. Let's treat candidates with respect: we often pull people out of their company's project, we take them away working hours and at the same time we allow ourselves to be late... My position is this: if a person comes to you during lunch break, feed him lunch. It's a pittance for the company - offer him a sandwich, not just coffee or tea! Or, let’s say, a candidate came in the evening - if the working day ends at 18:00, and you invited him to 19:00, then it is clear that he came to you hungry. Guys! A simple sandwich works wonders! You won't believe how much people's impressions of you change.
  • Lack of feedback. So, we conducted a technical interview, and then we believe that feedback is the responsibility of the recruiter (by the way, I also think so). But feedback on a technical interview should be given by the person who conducted it. When we call a person - no matter whether we hired him or not - we can tell him what we liked and what we think could be improved. The feeling of gratitude that people have after you told them this is simply an incomparable feeling. They will remember this, and you will be surprised more than once at what moments it will come up. After all, there is always something to praise a candidate for, and there are no people who do not understand anything at all, otherwise we would not invite this person for an interview. At the same time, it is very important to say what was good, what can be improved, and what is bad. HR people have this expression “development zone”: it’s not that everything is bad with you, it’s just that you have a “development zone” in some area.
It happens: you searched for a person for a long time, hunted him down, finally called him for an interview and there you ask him the question: “Why do you want to work in our company”? And this is called "cognitive dissonance." But this is a standard question - people simply don’t think about what they are asking. Therefore, be sure to track the resources through which the candidate comes to you - this is really important. If you are hunting a person, then the interview process itself should be different, and the questions should be structured differently. What are the consequences?
  • Don't spit in the well. Sometimes it happens that the person you interviewed may then interview you. I had such a case in my life - I have quite a lot of friends, and, let’s say, our company didn’t interview the candidate very well, and then you get to interview him, and he says, yeah, now I’ll interview you.
  • Be nice or leave… As I said, it’s very important to leave a positive impression on people. For technical specialists, the competence of the person conducting the interview is important, but his “goodness” (in the good sense of the word - his respectful attitude, his “acceptance of the other person”) is no less important than technical competence, and sometimes even more.
  • The person you are interviewing could be yours head or recommender in the future. The market is unpredictable - people grow up differently, move to different companies and, accordingly, everyone knows each other.
Which is better? It is better to communicate with the candidate as a potential colleague and a pleasant person. Imagine that a person joined your team: how would you communicate with an already hired employee? It doesn’t matter whether you take the person or not, remember that you may intersect with this person, and any harsh judgments may be inappropriate. Ask him out of a desire to learn something new, not out of a sense of superiority. All people know something that we do not know, and we cannot know everything. Therefore, we must conduct the interview with sincere interest and really listen to the person. And it is very easy to understand that we are not really listening - this can be seen in our eyes, in our posture. Even if people don’t speak body language, they still understand whether they are being listened to or not. Ask the person what is important to him. Thanks to this, you will learn a lot from the person himself: what is important to him and what of this may be important for your project. This way you will understand how to better motivate him and how to treat him better. Ask what kind of people he likes to work with? This is a very important question: if you understand that the people on your project are not at all like that, then this will also be an indicator for you. I am always for an honest interview: I am for telling the truth. You can tell a person about the project, about the people, how they differ from his expectations - and let him choose whether it suits him or not. Hire people who love what they do. In IT they really love “seniors”, they go crazy about them, they outbid them. But some "seniors" don't like what they do. Yes, they are “seniors”, they are valued in the market, they get good money, but they hate what they do. Sometimes they come, “star”, leave and thus often move around companies. I know people who are not so mega-competent at the moment, but due to the fact that they are interested and love what they do, they can very quickly become “seniors”. Congruence in values ​​and ability to interact may become more important than knowledge. Skills and knowledge are things that can be acquired. If you don't have the same values, then this is a problem on a deeper level. A conflict at the value level can be resolved, but it is very difficult to resolve... First you need to find out the candidate’s motivation, and then sell the benefits to the company. Each company is different, but often technical and HR interviews take place together. What does HR usually do? Usually he “sells” the company without asking what the candidate is interested in. But all outsourcing, and even product companies, are approximately equal in terms of compensation. But not everyone, for example, cares about insurance. It happens that a person is told about insurance, and he asks: “Do you have people on your team who play basketball?” - he is looking to see if he has common interests with the team. Listen to what the person is interested in and sell him what interests him. Be sure to find out what people on your team are interested in and ask about the candidate's hobbies. When I look at a resume, I pay attention to what the candidate is passionate about, ask him about it, and then talk about it to the team, and then people on the team form a completely different impression of him. By the way, tell the team about the new person in advance - and I am in favor of the interview taking place with the participation of team members. When you ask a candidate about his achievements, ask who can confirm this. Show the candidate the office, his workplace. This point is often missed. A person is usually immediately taken to a meeting room, where they communicate with him for an hour, and then they are taken out through the “reception”. I don’t think that showing an office, showing a project in which you are involved means revealing a trade secret. The atmosphere in the company where I come to work is very important to me. It’s important for me to walk into a room and feel “what it’s like there.” Bring a person to the project, show where you have someone - even if he doesn’t work for you, he can recommend other people. Your external image must correspond to your internal state, the state within the company. Show the person what you yourself like in the company, what evokes emotions in you - people respond to emotions, and when they see that you like it, they like it too. Conduct the interview with humor and energy, there are a lot of UGs in competing companies :). If it is possible to conduct an interview with humor, this creates a positive feeling for candidates. People constantly compare: this company had good interview, in that one - not so much, and if your interview is different from others, this can give you bonuses.

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

I've gone through this process a dozen times in various IT companies in my memory. huge number 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 open access and are ideal for getting basic knowledge for these sections.

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 questions about time and complexity.

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 track of companies' interview preparation and interview process can be quite stressful, but try to stay organized. Make a list of companies that interest you and note the stage of your relationship with each of them. Angel.co and Hacker News are good resources for this.

There is something supernatural about this. You will have to strain all your 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. Good option- send an e-mail to the company's recruiter, making it short and succinct. Include it brief overview 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 learn 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.

When solving 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 better 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. common 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. Passing an interview is also great experience, even if you weren't 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.

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 does test tasks, 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 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 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 tough and experienced programmer with a bunch of projects behind you, 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 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 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 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.