How to talk about yourself at the interview

When people ask me what you first need to know about the technical interview, I always answer the same way: get ready to talk.

A job interview is a stressful situation, and this stress can affect your ability to communicate. You do not think it through properly. Do not always finish the sentences. Laugh completely out of place. You are so far away from the topic that you can't even remember what was being said. And sometimes, in desperation, just throw all your cards on the table.

Transferred to Alconost
')
Preparation for the conversation is not aimed at filling the time, but at determining what should be told about yourself. Take a look at the problem from the other side and imagine that you are taking someone to work; What would you like to know about the interlocutor? Here is my list:

• What have you created?
  
• Which of the technical problems you encountered was the most difficult?
  
• How did you handle it?
  

That's all; only this kind of questions matter. Please note that all these questions relate to the person who came to the interview, and more precisely to what and how he did. If you have been interviewed by companies that do not know how to do it, you are probably asked one of the following questions:

• Where do you see yourself in 5 years?
  
• Why do you want to work here?
  
• How do you handle differences with colleagues?
  

From the point of view of the company, all these questions are useless, as they relate to the future, which is difficult to predict. Most likely, the person conducting the interview has a bad idea of ​​what exactly he wants to know with the help of these questions, and asks them just to fill the time. But there is one reservation: I work in a company where questions like “would you really work here if you were offered?” (Or, for example, “are you satisfied with our social package?”) The personnel department deals. If you go to a very small company, you will probably be asked similar questions during the main interview.

Training

Take a pack of note sheets and write a task on which you worked, or a project you were managing, on each sheet. Below one sentence describe your main goal, and then make a list of the main tools that allowed you to achieve it. Imagine adding tags to your question at Stack Overflow. Write down as many of the solutions that you tried to apply but failed ; There should be at least 5 such solutions on this list, if only there were indeed fewer of them (which is quite normal). Finally, write down the solution that worked in the end.

Now flip the piece. On top of one phrase, describe what you learned most from this project. You need to write down only the most significant idea, which allowed to find a solution to the problem. If the problem is not solved yet, let it be the last of the ideas that have arisen. Then write down in one line where this idea came from. Repeat this algorithm until the leaflet is full.

People often tell me that they do not know what tasks or projects their interlocutors will want to hear about. So, they will want to hear about what is written in the materials that you gave them. If you sent them a resume, wait for questions about what you did in previous places of work. If you share with them a link to your profile on Github, questions will be about your projects. If you gave them a link to your account on Stack Overflow, you will be asked about the answers you provided.

You should have at least one sheet for each project you specify, and ideally one for each item listed for each of these projects. Fill out all the Github projects you've worked on for the past year. As for the questions on Stack Overflow, just be aware of your most popular questions and answers (there is no need to fill out a separate sheet for each). This way you will be prepared to answer almost any question you may be asked.

Here is an example of a completed sheet for one project from my “Developer History”.

The recipe for a good developer story

Now that you have cheat sheets for everything that can be discussed at the interview, it's time to rehearse what you will say. It is not enough to have leaflets with all the necessary information at hand, you also need to be able to present it in the form of a fascinating story. Fortunately, this can also be learned.

Be specific

At the heart of a good developer story is a conversation in which one person communicates knowledge to another, which may be interesting or useful in his own work. Conversation, as a rule, fades when the interlocutor has nothing to cling to, therefore it is extremely important to avoid such situations. Although large-scale ideas seem exciting and help to demonstrate your remarkable mind, do not forget that your goal is to encourage the interlocutor to constantly ask questions. And the best way to do this is to be specific.



This scene from the film “The World of Wayne” perfectly illustrates the idea that it is not necessary to speak in general phrases. The man does not know how to answer, because he has nothing to grasp. If he didn’t say “I adore you, dude,” but “I adore your T-shirt, dude,” then Garth would easily be able to continue the conversation, knowing exactly what to talk about next. (“Yes, I bought it at a concert in Reno, where the drummer was on such awesome ...” - well, you get the idea.) Focus on specific ideas and avoid general ones. And be sure to tell about the circumstances that led you to this or that idea.

Start with a key phrase.

A good developer story begins with a key phrase. The first sentence should interest the other person and, if possible, make him wonder what it will be about next.

“I created a web interface with which developers can communicate about their ideas,” is a bad keyword phrase. After it, the person who conducts an interview with you, in fact, can only move in two directions: “What kind of developer ideas are we talking about?” And “What technologies did you use when creating this interface?” None of these questions will lead to a story about the interesting things you did. Speaking of developers, you are not talking about yourself, but about completely different people. Yes, and the user web framework, through which the interface was created, before you used a lot of people. But after all, the most interesting things in your project are certainly not related to what framework you used?

"I combined 7 datasets with Google Maps, allowing the sales team to receive real-time reports on the number of developers around the world." Now you probably have a lot of questions, and they all relate to my work on this project. We are ready to start a conversation, because I have given specific information that clearly identifies 3-4 interesting aspects of my project. This is the difference between using a key phrase and any other familiar way to tell about yourself.

Tell from the end

As a rule, real stories are told in reverse chronological order. That is why we start with a key phrase. But rehearsed stories, set, told in direct chronological order. If you are telling a story from the past to the present, for the interlocutor this is a clear sign that you are retelling something memorized and, quite likely, your story is not entirely true. An experienced employer will force you to lead the story from the present to the past, constantly asking additional questions about what he was particularly interested. If you are really aware of what was happening and how, this will not be a problem for you, because you know well what you are talking about. The main thing, do not forget, on what you have finished your main story, so that later you can return to this place.

If you are asked to dwell on something in more detail, and you are instead trying to continue your story, it gives a head with your insincerity. Perhaps you are talking about a decision made by someone else as your own, or are trying to create the impression that you know more about how the tools you use work than it actually is. This may not be entirely a lie, so after all, omissions are also not entirely true. Insincerity at the interview is a bad idea, and if the company understands anything at the interview, you will most likely be caught in a lie. However, I want to note that even if you are in such a situation, this does not mean an inevitable failure. Just continue to try to more carefully formulate your answers to questions and talk only about what you really had to do with. If you get caught twice, the interview will probably end.

“By and large, nobody cares about the real decision; as a working skill, far more important is not knowing the answer, but how you came to it. ”

So, the key phrase you have already reported. What to talk about next? Next turn for your interlocutor, who should lead you to a more detailed story about 2-4 interesting points, concluded in your key phrase. As soon as you are asked about something specific, remember your sheet and tell us about what you have tried and what did not work. By and large, nobody cares about the real solution; as a working skill, not knowing the answer is much more important, but how you came to it. This is the difference between your ability to work on a task and simple knowledge of the answer. If you really knew the answer, better tell us about the components of your decision and how they all worked together. But in most cases you are hired to solve problems, and that is why you need to talk about what you were trying to do and what did not work.

There is another advantage in the story of the attempts you have made. As soon as you utter the key phrase, your interlocutor will begin to guess how you solved the problem. Perhaps you have chosen a path different from what he thought about, and therefore, when you talk about how you came to this or that decision, you tell your interlocutor important knowledge. Tell us about your ideas, especially if you really tried to apply them. Focus on the key ideas that lead you to each subsequent step. As an interviewer, and as a developer, I really love to learn a couple of new things during the conversation. And that brings us to the next point ...

Do not guess what your interlocutor knows

In most cases, you will not have a clue about what the person who is interviewing you knows. You will not know which languages ​​he is familiar with, which tasks he is used to solving or which tools he owns. You will have to balance a bit to really use the allotted time. You must assume that certain things are known to your interlocutor; most likely, he knows what developers do for a living, and knows how to solve tasks. Regularly pause in your story to make sure that he has not lost the thread of the story. Use for this body language, listen to the words of consent like “yes” or “so”, periodically sound during your story. You can even stop and directly ask your interlocutor if everything is clear to him or he would like to get more detailed explanations on this or that question.

If you dive too deep into your story without making sure that you are still understood, the interlocutor can come to the conclusion that you simply cannot explain. Actively show your interest in the listeners to understand what you are talking about. In this way, you will be much more comfortable, and they will feel that they have learned something.

Similarly, try not to make assumptions about what is interesting to your interlocutor. Do not speak badly about anything that you did, because that is what might be interesting for him. Even if something seems simple or naive to you, you can still talk about it interestingly. Nowadays, developers have hundreds of specializations, and the fact that you are applying for a web developer position does not mean that your partner has CSS or some javascript functions as well as you. If something in conversation with you will entice him, try to support this interest in every way.

Talk, not interview

If you have not yet understood this, the interview should really be a conversation. The truth is that you do not know what exactly will interest the listeners in the materials you provided or your words. I don't know that either. Do your best to captivate them with your work, and if they do not bite, take the initiative and ask yourself what they would like to hear. This is another case when specifics helps. “What should I tell you?” Is an example of a failed question. “Is there something in my resume that you found interesting?” - this is much better. A similar question will show how well they prepared for the interview. And if someone answers you like: “I didn’t see anything interesting there,” then another question should immediately follow: “Then what do I do at this interview?” Constantly trying to guess what your listeners are interested in is waste of time; where better to just ask. If they don’t want to talk to you about specific things, they probably didn’t prepare for the interview.

Rehearse

Interview rehearsal is my favorite part. Just go and talk with other developers about your work. Start with a key phrase. Be specific, and when they ask you questions, tell us about what you did in reverse chronological order.

Try to remember a few important points: in a conversation with people, use information from 5-10 of your sheets; one is not enough! In most companies, you will have to go through 3-5 interviews; make sure that you do not repeat the same material to different people, because they will compare their notes. Memorize the questions you are asked during your rehearsals. During the actual interviews you will hear almost the same questions, so by answering them several times, you basically learn to speak naturally. Also monitor the emotional reactions of the interlocutors to their words. Teach yourself to say what people are interested in and what they want to hear more about.

The interest in the company that hires you is directly proportional to the interest of the people conducting the interview, to what you say. Telling stories is an excellent way to build a fascinating conversation with people you just met. I hope my recommendations will teach you to tell stories and get more pleasure from interviews.


About the translator

The article is translated in Alconost.

Alconost is engaged in the localization of applications, games and websites in 68 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources, translation of technical texts .

We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.

Read more: https://alconost.com