Security information portal. Technical interview with a human face

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. The best interviews are enthusiastic, technical conversations.

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 first do test). The real purpose of this stage, 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"The answer is often to 'Google' a particular feature. Say so! They know you're not a Ruby expert, but they should also know that you can come up with solutions to problems that 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 questions about them in interviews. They don't always reflect programming skills well, but it just so happens that you'll be answering questions that fall into the more academic realm of computer science.

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 big amount material.
• Interviewing.io gives you a chance to practice anonymously and online technical interview.
• How to get a perfect score in a technical interview
• How to Stand Out in Your Next Web Developer Job Interview
• Read 40 key computer science concepts explained in easy-to-understand language
• Google's Tech Skills Guide(for advanced)

Programming test tasks:

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

Algorithm training:

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

Architecture:

Technical test task

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

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

Final interview (“Fit”)

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

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

A little about wages

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

You will always be asked “how much would you like to receive?” Your Answer? “I would like to get paid at the average market rate” (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.

You have already posted an ad on job sites with a good salary and a vivid description that would be of interest to you, you have selected 20 candidates and will begin conducting interviews tomorrow. All that remains is to figure out what exactly to ask.

You have a product, an established team and funding. You (the team) have worked well, and management is willing to pay more money to hire someone in order to, accordingly, speed up development, improve quality and be able to spend resources on technological development product. You have already posted an ad on hh with a good salary and a vivid description that would be of interest to you, you have selected 20 candidates and will begin conducting interviews tomorrow. All that remains is to figure out what exactly to ask. Common situation? Then welcome to cat.

Perhaps the situation is a little utopian, but many cases are also within the scope of this article. Exceptions are companies that “need people yesterday” or companies that new person is not needed at all, they are simply “observing the market” and (or) hoping to find a “rare professional”.
In other words, this is an article for those who want to invest money and effort into making the team stronger.

To begin with, let us note that it is extremely harmful to hire a person for a momentary need. Let's say that right now the development of the server part is slightly slowing down for you. Does this mean that you need to hire a server-side programmer? Actually, no. If you have a fairly active development, the priority of different pieces will inevitably change. In this sense, it is stupid to hire a person for a task for the next month. After all, a month will pass, but you will still have the person. And if this month you patch a hole in server-side development, then next month it will turn out that server-side is written faster than the interface is riveted. So what, next month we need to hire a UI programmer? Or fire the “weak link” in the server-side? No, this needs to be approached differently. Look at what you've done before in product development. Ask sales, investors, or whoever sets the goals for development, and try to build a picture of what awaits you, say, a year ahead. Now imagine what kind of person would help you work more effectively in the past and future. I hope you introduced yourself to more than one person. Most likely it will turn out that it is possible to strengthen the team here and here. And if somewhere it turns out to be too strong (and, accordingly, somewhere too thin), then someone from the existing team may agree to “switch” their activity.

So, you have sketched out several portraits of “ideal” candidates. It's time to conduct a technical interview. By the way, I hope in your company it is the technical interview that influences the decision to hire employees? They often talk about a company as a “family” or “a team where you can have a good time.” So, a company is still not a family. And not the friends you go bowling with. Of course, if a person is sick with kleptomania or leprosy, it is dangerous to hire him, even if he passed the technical interview the best. But don't get too hung up on personal qualities. In principle, before or after a technical interview, it is necessary to find out whether the person will throw out some kind of trick, and in this sense, such a “non-technical” interview will have the role of a “threshold” - anyone who does not pass it will definitely not work in the company, but if he passes, then it doesn’t matter whether he is the “life of the company” or just a conscientious employee. But that’s all; in fact, all other decisions should be determined by the technical interview. If your company's HR is pestering candidates with questions about their career aspirations and "where they see themselves in 10 years" or "why the company should hire you," then it's too early for you to look for technical talent. First, you need to find a new HR.

But what should you ask in a technical interview? Create a test? Find out what the person did at his previous job? Set tricky question? Give me a problem from braingames.ru?
Let's look at these options in order.

The test may seem useful thing to save time. However, it is quite difficult to create a good test - this task itself requires spending a lot of time. A bad test can only weed out candidates who don’t go to many interviews and don’t know the answers to “standard” questions. A very bad test can weed out really great candidates who have just done slightly different things. In general, the test is just some kind of primary filter. You may not hire a person who could not answer five questions that you consider trivial. But you definitely shouldn’t hire a person after a test without asking him a word.

What did you do at your last job? Well, you know, what the applicant did at his previous job, he will no longer do with you. In principle, you can ask such a question to find a topic for conversation. But honestly, it seems like a waste of time. I will give an example from my practice.

What did you do at your last job?
- Well, there was a complex system that simulated the system of urban communications with the search for optimal routes and (...)
- What is Dijkstra's algorithm?
- Um, yes, and I heard something like that.

So, what have we learned? Never mind. Some kind of complex project. It’s not really clear what kind of project it was, what exactly this employee did, what he eventually learned to do well. We wasted 5 minutes without finding out anything about the person. Of course, you can spend half an hour and sort everything out. But there are two “buts”.
First, value your time. If you spend 4 hours on each candidate, then you may simply not get to the one that is truly worthwhile. In general, in my opinion, the interview should be strictly limited to a time frame, say one hour. And try to shake out of the person during this hour everything that you need to make a decision.
Second, don't get too hung up on who the person was. Try to evaluate who he could become in your company. Your candidate says that at his last job he completed a module in a week that you took a month to complete? Maybe like that at my last job cool business processes and a mountain of ready-made code, and you would have him doing this module exactly as much as you? Or did it seem to you that the candidate did nothing remarkable at his last job? It may very well be. But maybe this is a talented person who has vegetated in third-rate “horns and hooves”, and your full potential will be revealed! Believe me, in many situations it is worth fighting for such a person even more than for an accomplished specialist.

Should I ask something tricky? Let's say yesterday you read on Habré that it turns out that a hash code in Java is not an address (as you always thought), but a random number, and you are wondering whether the candidate knows this. Or last week you were poking around in nicks and found out that “[” is not part of a bash script as a language, but a regular program with the name “[”. Would it be helpful to find out if the candidate knows this?
Here it’s worth trying again to play through the question and answer options.
Role play.

- Well, this is the address of the object

And the second option:

What is Object.hashCode()?
- Yes, there is a random number generator, so it returns.

You spent 3 minutes on this question. How do you compare the first and second candidate? Can we say that one of them is better than the other? Maybe the second one was leafing through the grepcode at his leisure. Or read habr instead of work. Or maybe not instead. But does this mean anything to you?

It’s not that it doesn’t matter whether or not a person knows the subtleties of implementation. On the contrary, I believe that it is very important to know the little things. A person who knows assembler is more valuable to me than someone who doesn’t know it, even when I’m looking for a Java developer. But, unfortunately, there are so many little things that the direct question “Do you know what” almost never makes sense. But we can’t ask about hundreds of things, because we have limited time.

So what should I ask?

It seems to me that it is best to conduct a conversation in the context of what you usually do and watch how the candidate solves problems that you often solve.
Let's say your application has UI logic and server code. Ask the candidate what they think is more interesting.
Server code? Great. Let's imagine some typical piece of code in your program. We are interested in what questions the candidate has and how he connects theoretical knowledge with practical needs.
Let's say this problem:

There is a code snippet

void x(List a)

...Some processing

Question for the candidate - suppose in this code we need to sort the list into alphabetical order. What will you do? By the way, yes, you can immediately tell the candidate about Collections.sort - we’re not “ lexicon"We check.
Let's say our candidate wrote something like

void x(List a)

List b = new ArrayList(a);

Collections.sort(b);

...Some processing with b

(I hope our candidate solved this problem in this way and did not start sorting a).

However, solving the problem is not the main thing here. The main thing is discussion.
Why did he create new list didn't you use the old one? Is this always correct?
Why did you use ArrayList and not something else? Does he know what else is there?

The most interesting thing is that the discussion here can be almost endless. The candidate will say that ArrayList the better that it is random access, but you say that sort still copies the data into an array before sorting, and then returns it back. Is ArrayList better now, in the candidate's opinion? What, not anymore? Or is it still better?

A conversation with a candidate should reveal his way of thinking. Look how many details he knows. How does he react to something new? And most importantly, can he correctly use the information you give him? After all, abstract “knowledge of everything” is usually not particularly important; after all, there are colleagues nearby and problematic issue can often be discussed. Colleagues can give advice, but they won’t write code instead of a new employee, so try to understand whether, after listening to the advice, he can write a better program?

Or let's say another example.

Don't ask "what is a garbage collector". Don't ask “how many generations are there?” What difference does it make? What difference does it make whether or not a person can tell you how gc works? For your work, the only important thing may be whether a person can fix a performance problem if one arises, and whether he can tell a heart-warming story about assembly over generations or about concurrent mark sweep gc.
I'm not saying that anyone can solve any interesting problems with GC without knowing how it works. Once, of course, you might get lucky. But in practice, knowledge is extremely important. The problem is different - not everyone who can tell how something works can fix a problem with that something. And, generally speaking, intuition and general technical knowledge are often more important for solving a problem than a description of an algorithm read somewhere.
For example, for gc it would be good to give again some practical problem.
Let's say, “you launched a program with a 2 gigabyte heap and it works slowly, what will you do?”

I'll increase my hip

Will it get faster? And the most interesting thing is, isn’t it worth asking before answering this question, what does “faster” mean to me? See if the candidate understands the difference between throughput and latency. Don't ask what it is or what the difference is. If a candidate, given the above-described formulation of the problem, does not think of asking such trivial questions, then in practice he will not have these questions. However, we should not forget that we are having a conversation. If the candidate jumped right in, stop him and tell him about different performance characteristics. The candidate had never heard of them, but immediately realized that growing a hip might improve one thing, but would definitely worsen another? Well, this is wonderful!

An endless number of such examples can be given. The best part is that such problems are easy to come up with, and there are no numbers of them - you can ask each new candidate about different things and adapt the problems for a specific candidate.

• Recruitment and selection, Assessment, Labor market, Adaptation

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 video 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, intricate 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 approach the software developer interview with humor and embrace the whole process as exciting game, in which you go to the finals and defeat the managers who hire you, who will be:

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

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, ex-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 the main objective 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, untailored for 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 tie is required for men, for women pantsuit or a jacket with a skirt. If you are applying for a creative position in a young company, the classic style may not be suitable. 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, so you 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

You'll likely be asked why you left your last job, as well as what you liked and didn't like doing in your last 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. When talking to a HR person (perhaps without a technical background), spell out each acronym 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 information Technology 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 e-mail 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:

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 You Need It? 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 want to get to you, the more companies make offers to you. And the better you are at 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 test... 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 off;
• 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 take people away from their company's project, we take them away work time 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 for 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 it's called " the 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 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 future. The market is unpredictable - people grow up in different ways, 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 nice 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 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 this 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 for whether 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 compare all the time: this company had a good interview, that company not so much, and if your interview is different from others, it can give you bonuses. July 11, 2011 at 02:36

• IT companies

I have been conducting technical interviews with candidates for the position of Software Engineer for quite some time now, and I have several dozen of them on my account. Today I will try to formulate the main points that personally, as an interviewer, seem quite important to me.

The advice is quite obvious (although, as practice shows, there are also those who do not know these obvious things) and subjective.

1. Replying to general issues remember that the interviewer may not know anything about what you are talking about.
It happens that at the very beginning of the interview the interviewer asks general questions - for example, “Tell me about project X that you worked on at Y” (the list of projects is taken from your resume) or “Tell me about your favorite technology” or something else like that. When answering this question, it is very important to remember that you are not talking about the project to yourself, but to the interviewer - and your task is to ensure that the interviewer understands you.
Don't assume that the interviewer is very smart and knows everything - he probably is really smart, but he definitely doesn't know everything. And what may be obvious to you because you have been doing this for a couple of years in a row may be completely different for the interviewer. new area. And so, don’t hesitate to start with the very basics and ask from time to time whether the interviewer understands you.

2. Don't Google during the interview.
It happens that the interviewer asks a question, the answer to which you vaguely remember, and if only you could take a quick look at Wikipedia... So, don’t do this. The clicking of keys is usually quite audible through the phone and the answer, which is read from Wikipedia without much understanding, is also quite easy to distinguish. Needless to say, what impression does such a candidate leave on the interviewer?

3. Don't lie on your resume.
There are things that are relatively easy to check - knowledge of some technology, for example. And things that are difficult to check - for example, if a candidate wrote that he is in the top 100 on topcoder (this is a site where programming competitions are held). Personally, I’m at the level of “What nickname are you listed there under?” I never check, but from a candidate who is in the top 100 on a topcoder, I expect that he will write simple things without regaining consciousness (I have already interviewed Olympiad participants - and in my experience this is what happens). And if it suddenly turns out that the candidate writes code slowly, with a lot of errors, then this most likely means that either he feels very bad, or he indicated incorrect information in his resume.
Of course, it is not the interviewer's responsibility to assess the candidate's condition, but I will definitely mention this discrepancy in my review.

4. Don't try to talk the interviewer down.
If the interviewer asked a question - for example, "How difficult is bubble sort?" - and you don’t remember whether it’s O(N^2), or O(N), or O(NlogN), then in no case should you disguise your ignorance under a bunch of phrases that you hope the interviewer will accept for the correct answer. The interviewer listens to you very carefully and notices all attempts to casually lead him away from a question to which the candidate does not know the answer. It’s better to just admit that you definitely don’t remember and think out loud - most likely you will come to the correct answer anyway.

5. Speak and explain. But not too much.
There are two extremes - a candidate who is silent and says almost nothing, and even manages to answer a question like “Tell me what you think about X, what are X’s advantages and disadvantages” in at most one sentence. And the candidate who speaks and explains everything down to the last comma - “Here I put a comma, because this is the syntax of the language.” Both the first and second types of candidates are very difficult to interview - you have to drag out answers from some in pincers, while others are constantly cut off mid-sentence.
The explanations should be just right - so that the interviewer understands the essence, but does not feel that the candidate constantly wants to break into an explanation of trivial basics.

6. Test the code yourself.
During the interview, you wrote some code that you think is correct. At this moment, it is important to test this code without waiting for the interviewer to tell you, “Now let’s test the code using a simple example 123.” During testing, it is very important to check the so-called corner cases - for example, null, empty strings and arrays. negative numbers, zero - and even more important to make sure that the code actually works on simple examples. Because a candidate who tests the code, but does not notice very much during testing gross mistake, usually doesn't make the best impression.

7. Don't try to please the interviewer.
There is one moment in the movie "Bad teacher" - one of the main characters asks another about sharks:
1: What do you think about sharks?
2: Oh, those are sharks terrible fish, I heard that they eat people...
1: But some of them don’t eat anyone, and are actually very cute...
2: Oh yes, it's terrible that people are exterminating sharks, because sharks are an endangered species and God created them that way. They are wonderful creatures...
1: But they eat people...
2: Yes, yes, it’s terrible, entire families are destroyed because of sharks...

I don't remember exactly, but the gist is something like this. So, don’t have the “shark talk” with the interviewer. The interviewer asks the question to find out what the candidate thinks about this or that aspect, not to hear that the candidate agrees with him anyway.

8. Try to remove anything that will prevent you from speaking clearly.
This may seem obvious, but I'll mention it anyway - don't chew gum during the interview. And you don't need to eat either. If you have a tongue piercing that tends to make a clicking sound when you speak, it might be a good idea to take it out for the duration of the interview.

Well, and most importantly, the question that the interviewer consciously or subconsciously asks himself is “Would I like to work on the same team with this person?” And the answer to this question consists not only of the candidate’s knowledge and skills, but also of the ability to clearly and clearly express one’s thoughts, the ability to listen, and many other little things.