Technical interviews: tips
Hi, Habr!
The Hexlet team has a lot of experience in conducting technical interviews. We shared experience and advice in the webinar " Interviews: a view from the employer ." And today we are publishing a translation of an article with tips from a company that helps people prepare for interviews.
From myself I want to add that, despite the usefulness of these tips, if the person described here is not you, then you should not try to emulate it.
Before you start discussing code, most interviewers like to discuss your experience. They want to hear:
You must have at least one of these items:
Eagerly interested in everything. Show that you are proud of your achievements, that you are interested in what the company is doing, and you have your own opinion about languages ​​and workflows.
')
As soon as you get to the programming topics, the main thing is to maintain a dialogue. A candidate who needed help during the interview, but who willingly participated in the conversation, obviously, may be better than the candidate who did not linger on the topic.
Understand what type this task. There are two types of tasks:
It happens that you started writing code, and the interviewer just wanted a short answer before moving on to the “real” question. So just ask: “do I need to write code for this”?
Show that you can work in a team . The interviewer wants to know what it is like to work on a task in a team with you, so make it clear that you are capable of teamwork. Use "we" instead of "I", for example: "if we were breadth-first search, you would get an answer for O (n)". If you need to choose where to write the code - on paper or on the board, always choose a board. In this case, you will be next to the interviewer, solving the problem (and not opposite him, with a barrier in the form of a table).
Think out loud . Seriously! Say, “Let's try to do it like this — not sure if it will work.” If you get stuck, just tell me what you think. Tell me what might work. Tell me what you think might work and why it does not work. This also applies to trivial short questions. If you are asked to explain the closures in Javascript, the answer - “this is something related to the scope and putting something in a function” is likely to be counted as 90% of the answer.
Admit it if you do not know something . If you have touched upon a fact (for example, little things of a particular language, some details of runtime), do not try to show that you know something you don’t know. Instead, say, "I'm not sure, but I think so, because ...". Because it can include the exclusion of other options, while simultaneously demonstrating that they have meaningless consequences, or a comparison with other languages ​​or other tasks.
Do not rush to conclusions . Do not throw the answer right away. If he is faithful, you will still need to explain him, and if not, you will look silly. You will not gain anything by rushing, and, most likely, only tease the interviewer.
Sometimes you find yourself in a state of weightlessness. Relax. This does not mean that everything has lost its meaning. Remember that the interviewer is usually more important than your ability to reasonably consider a task from different angles than the ability to accurately answer a question. When it seems that there is no more hope, continue to reason.
Draw pictures . Do not waste time thinking silently - think on the blackboard. Draw a couple of different test input data. Draw the process of getting the desired result. Then think about translating your approach into code.
Solve a simpler version of the problem . Not sure how to find the 4th largest element in the set? Think about how to find the 1st element and think about whether you can adapt this approach.
Write a naive, inefficient solution and optimize it later . Use brute force. Do everything in your power to get at least some answer.
Think out loud more often . Say what you know. Say what you thought might work and why it wouldn't work. It may suddenly turn out that it will actually work, or a modified version of your output will work. Or you can get a hint.
Wait for hints . Do not look at the interviewee in anticipation, but stop for a second to think - the interviewer may have already decided to give you a tip and just wait to not interrupt.
Think about the boundaries of memory and runtime . If you are not sure that you can optimize your decision, think about it out loud. For example:
Easy to stumble about yourself. First focus on getting rid of your thoughts, and then worry about the details.
Call the helper function and continue . If you can't figure out how to implement some part of the algorithm, big or small, just skip it. Write a call to a reasonably named auxiliary function, say, “X will do it” and continue. If the helper function is trivial, you may not even need to implement it.
Do not worry about syntax . For a while, switch back to English if required. Just say that you’ll return to the syntax.
Leave yourself enough space . You may need to add lines of code or notes between the lines later. Start at the top of the board and leave a blank line after each line of code.
Leave an accurate index check for later . Do not worry about what you will have for-cycle "<" or "<=". Put a reminder to return to this at the end. The main thing is to write down the main algorithm.
Use descriptive variable names . It will take some time, but
will help you not to get lost in your code. Use names_to_phone_nums_map instead of nums. Use the type in the variable. Functions that return Booleans must begin with "is_" (depending on the standard adopted in the language, other possible options, for example, "?" At the end of the function name). Variables that contain a list must end with “s”. Choose standards that you understand and stick to them.
Go over your decision by hand, out loud, using raw data as an example . Write down what values ​​contain variables when the program will be executed. you will not get any benefits if you turn it in your head. This will help to find bugs and dispel doubts that might have arisen in the course of your explanations.
Return to off-by-one errors . Maybe you should use "<=" instead of "<"?
Test borderline cases . These may include empty sets, singleton sets or negative numbers. As a bonus, mention unit tests!
Do not be a bore . Some interviewers do not care about restoring order. If you are not sure, say something like: “Then I, as a rule, check the code for borderline cases - should we continue to do this?”
In the end, nothing can compare with practice. Go to the interviews more often.
Write code with a pen on paper . Do not be fooled. At first, it may be not on its own. Good. You need to get rid of this awkwardness now, so as not to screw it up when it comes to a real interview.
The Hexlet team has a lot of experience in conducting technical interviews. We shared experience and advice in the webinar " Interviews: a view from the employer ." And today we are publishing a translation of an article with tips from a company that helps people prepare for interviews.
From myself I want to add that, despite the usefulness of these tips, if the person described here is not you, then you should not try to emulate it.
Chat professionally
Before you start discussing code, most interviewers like to discuss your experience. They want to hear:
- Metacognition about the code. Are you thinking about what the "quality" of the code means?
- Responsibility and leadership. Do you view work in a competitive environment? Do you fix something wrong, even if it is not required?
- Communication Will discussing a technical problem with you be practical or painful?
You must have at least one of these items:
- An example of an interesting technical problem you have solved;
- an example of interpersonal conflict that you managed to overcome;
- how you were in the role of leader or shareholder;
- a story about what to do differently in a previous project;
- a couple of little things about your favorite language and what you like and don't like about it
- question about the current product and business of the company
- question about the engineering strategy of the company (testing, scrum, etc.)
Eagerly interested in everything. Show that you are proud of your achievements, that you are interested in what the company is doing, and you have your own opinion about languages ​​and workflows.
')
Maintain the dialogue
As soon as you get to the programming topics, the main thing is to maintain a dialogue. A candidate who needed help during the interview, but who willingly participated in the conversation, obviously, may be better than the candidate who did not linger on the topic.
Understand what type this task. There are two types of tasks:
- Programming . The interviewer wants to see you write clean, efficient code to solve the problem.
- A short conversation . The interviewer just wants you to say something. Frequently asked questions are either (1) on high-level system design (“How would you build a Twitter clone”?) Or (2) on trivia (“What is hacking in JavaScript”?). Sometimes trivia is a preparation for a “real” question, for example, “How fast can you sort an array of integers? Well, now, instead of integers we have ... "
It happens that you started writing code, and the interviewer just wanted a short answer before moving on to the “real” question. So just ask: “do I need to write code for this”?
Show that you can work in a team . The interviewer wants to know what it is like to work on a task in a team with you, so make it clear that you are capable of teamwork. Use "we" instead of "I", for example: "if we were breadth-first search, you would get an answer for O (n)". If you need to choose where to write the code - on paper or on the board, always choose a board. In this case, you will be next to the interviewer, solving the problem (and not opposite him, with a barrier in the form of a table).
Think out loud . Seriously! Say, “Let's try to do it like this — not sure if it will work.” If you get stuck, just tell me what you think. Tell me what might work. Tell me what you think might work and why it does not work. This also applies to trivial short questions. If you are asked to explain the closures in Javascript, the answer - “this is something related to the scope and putting something in a function” is likely to be counted as 90% of the answer.
Admit it if you do not know something . If you have touched upon a fact (for example, little things of a particular language, some details of runtime), do not try to show that you know something you don’t know. Instead, say, "I'm not sure, but I think so, because ...". Because it can include the exclusion of other options, while simultaneously demonstrating that they have meaningless consequences, or a comparison with other languages ​​or other tasks.
Do not rush to conclusions . Do not throw the answer right away. If he is faithful, you will still need to explain him, and if not, you will look silly. You will not gain anything by rushing, and, most likely, only tease the interviewer.
Get out of the stopper
Sometimes you find yourself in a state of weightlessness. Relax. This does not mean that everything has lost its meaning. Remember that the interviewer is usually more important than your ability to reasonably consider a task from different angles than the ability to accurately answer a question. When it seems that there is no more hope, continue to reason.
Draw pictures . Do not waste time thinking silently - think on the blackboard. Draw a couple of different test input data. Draw the process of getting the desired result. Then think about translating your approach into code.
Solve a simpler version of the problem . Not sure how to find the 4th largest element in the set? Think about how to find the 1st element and think about whether you can adapt this approach.
Write a naive, inefficient solution and optimize it later . Use brute force. Do everything in your power to get at least some answer.
Think out loud more often . Say what you know. Say what you thought might work and why it wouldn't work. It may suddenly turn out that it will actually work, or a modified version of your output will work. Or you can get a hint.
Wait for hints . Do not look at the interviewee in anticipation, but stop for a second to think - the interviewer may have already decided to give you a tip and just wait to not interrupt.
Think about the boundaries of memory and runtime . If you are not sure that you can optimize your decision, think about it out loud. For example:
- I need to, at a minimum, consider all elements, so it’s better than O (n) not to do.
- A rough solution is to check all possibilities, and this is O (n 2).
- The answer will be n 2 elements, so I need at least to spend the same time.
Unload your thoughts
Easy to stumble about yourself. First focus on getting rid of your thoughts, and then worry about the details.
Call the helper function and continue . If you can't figure out how to implement some part of the algorithm, big or small, just skip it. Write a call to a reasonably named auxiliary function, say, “X will do it” and continue. If the helper function is trivial, you may not even need to implement it.
Do not worry about syntax . For a while, switch back to English if required. Just say that you’ll return to the syntax.
Leave yourself enough space . You may need to add lines of code or notes between the lines later. Start at the top of the board and leave a blank line after each line of code.
Leave an accurate index check for later . Do not worry about what you will have for-cycle "<" or "<=". Put a reminder to return to this at the end. The main thing is to write down the main algorithm.
Use descriptive variable names . It will take some time, but
will help you not to get lost in your code. Use names_to_phone_nums_map instead of nums. Use the type in the variable. Functions that return Booleans must begin with "is_" (depending on the standard adopted in the language, other possible options, for example, "?" At the end of the function name). Variables that contain a list must end with “s”. Choose standards that you understand and stick to them.
Put everything in order
Go over your decision by hand, out loud, using raw data as an example . Write down what values ​​contain variables when the program will be executed. you will not get any benefits if you turn it in your head. This will help to find bugs and dispel doubts that might have arisen in the course of your explanations.
Return to off-by-one errors . Maybe you should use "<=" instead of "<"?
Test borderline cases . These may include empty sets, singleton sets or negative numbers. As a bonus, mention unit tests!
Do not be a bore . Some interviewers do not care about restoring order. If you are not sure, say something like: “Then I, as a rule, check the code for borderline cases - should we continue to do this?”
Practice
In the end, nothing can compare with practice. Go to the interviews more often.
Write code with a pen on paper . Do not be fooled. At first, it may be not on its own. Good. You need to get rid of this awkwardness now, so as not to screw it up when it comes to a real interview.
Source: https://habr.com/ru/post/270057/
All Articles