November 3, 2015 at 12:41Technical Interviews: Tips
- Transfer
Hello, Habr! Hexlet's
team has a lot of experience in conducting technical interviews. We shared our experience and advice in the webinar " Interviews: a view from the employer ." And today we are publishing a translation of the 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 do not need to try to emulate it.
Before starting a discussion of the code, most interviewers like to discuss your experience. They want to hear:
You must have at least one of these points:
Interested in everyone. 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 work processes.
As soon as you move on to topics about programming, the main thing is to maintain a dialogue. A candidate who needed help during the interview, but who willingly participated in the conversation, could obviously be better than a candidate who did not linger on the topic.
Understand what type of 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 know how to work in a team . The interviewer wants to know what it is like to work on a task as a team with you, so make it clear that you are capable of teamwork. Use "we" instead of "I", for example: "if we had a breadth-first search, we 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 - I'm not sure it will work.” If you are stuck, just say what you think. Say what might work. Say what you think might work and why it doesn't work. This also applies to trivial short questions. If you are asked to explain the closures in Javascript, the answer - “is it something related to the scope and putting something in the function” will most likely count as 90% of the answer.
Admit if you do not know something. If you have touched upon a fact (for example, trifles of a specific language, some details of runtime), do not try to show that you know what you do not know. Instead, say, "I'm not sure, but I think so, because ...". Because it may include the exclusion of other options, while demonstrating that they have meaningless consequences, or comparing with other languages or other tasks.
Do not rush to conclusions . Do not throw the answer right away. If he is faithful, you still need to explain it, but if not, you will look stupid. You won’t gain anything by rushing, and most likely just teasing 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, as a rule, is more important than your ability to reasonably view the task from different angles than the ability to accurately answer the question. When there seems to be no more hope, keep reasoning.
Draw pictures . Do not waste time thinking in silence - think on the board. Draw a couple of different test input data. Draw the process of obtaining 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, ineffective 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 you know. Say what you thought might work and why it won’t work. It may suddenly turn out that this will actually work, or a modified version of your output will work. Or you can get a hint.
Wait for clues . Do not look at the interviewee while waiting, but stop for a second to think - the interviewer may already have decided to tell you something and is just waiting so as not to interrupt.
Think about memory boundaries and runtime . If you are not sure that you can optimize your decision, think about it out loud. For instance:
Easy to stumble about yourself. Focus on getting rid of your thoughts first, and then worry about the details.
Call the helper function and continue . If you cannot figure out how to implement any part of the algorithm, large or small, just skip it. Write an appeal to a reasonably named auxiliary function, say, “this will execute X” and continue. If the helper function is trivial, you may not even need to implement it.
Do not worry about the syntax . Switch back to English for a while if necessary. Just say you'll get back to the syntax.
Leave yourself plenty of room.. You will probably need to add lines of code or notes between lines later. Start at the top of the board and leave a blank line after each line of code.
Leave an accurate check of indexes for later . Don’t worry about what your "<" or "<=" for loop will be. Put a reminder to go back 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
helps you not to get lost in your code. Use names_to_phone_nums_map instead of nums. Invoke the type in a variable. Functions that return Boolean must begin with "is_" (depending on the standard adopted in the language, other options are possible, 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 around your decision manually, aloud, using the source data as an example . Record what values the variables contain when the program runs. you won’t get any advantages if you do it in your head. This will help you find bugs and dispel doubts that the interviewee might have during 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!
Don't be a bore. Some interviewers don't give a damn about putting things in order. If you are not sure, say something like: “Then, as a rule, I check the code for border cases - should we do this further”?
In the end, nothing beats practice. Go for more interviews.
Write the code with a pen on paper . Do not be fooled. At first, it may be uncomfortable. Good. You need to get rid of this awkwardness now so as not to screw it up when it comes to a real interview.
team has a lot of experience in conducting technical interviews. We shared our experience and advice in the webinar " Interviews: a view from the employer ." And today we are publishing a translation of the 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 do not need to try to emulate it.
Chat professionally
Before starting a discussion of the code, most interviewers like to discuss your experience. They want to hear:
- Metacognition about the code. Are you wondering what the “quality” of the code means?
- Responsibility and leadership. Do you consider work in a competitive environment? Are you correcting something wrong, even if it is not required?
- Communication. Will discussing a technical issue with you be practical or painful?
You must have at least one of these points:
- An example of an interesting technical problem that you have solved;
- an example of interpersonal conflict that you have overcome;
- How were you in the role of manager or shareholder?
- the story of what it was worth doing differently in the previous project;
- a couple of little things about your favorite language, and what you like and dislike about it
- question about the current product and business of the company
- question about the engineering strategy of the company (testing, scrum, etc.)
Interested in everyone. 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 work processes.
Keep dialogue
As soon as you move on to topics about programming, the main thing is to maintain a dialogue. A candidate who needed help during the interview, but who willingly participated in the conversation, could obviously be better than a candidate who did not linger on the topic.
Understand what type of 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 tell something. Often questions are asked either (1) about high-level system design (“How would you build a Twitter clone”?) Or (2) about little things (“What is JavaScript hoying?”). Sometimes the little things are preparation for the "real" question, for example, "How quickly can I 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 know how to work in a team . The interviewer wants to know what it is like to work on a task as a team with you, so make it clear that you are capable of teamwork. Use "we" instead of "I", for example: "if we had a breadth-first search, we 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 - I'm not sure it will work.” If you are stuck, just say what you think. Say what might work. Say what you think might work and why it doesn't work. This also applies to trivial short questions. If you are asked to explain the closures in Javascript, the answer - “is it something related to the scope and putting something in the function” will most likely count as 90% of the answer.
Admit if you do not know something. If you have touched upon a fact (for example, trifles of a specific language, some details of runtime), do not try to show that you know what you do not know. Instead, say, "I'm not sure, but I think so, because ...". Because it may include the exclusion of other options, while demonstrating that they have meaningless consequences, or comparing with other languages or other tasks.
Do not rush to conclusions . Do not throw the answer right away. If he is faithful, you still need to explain it, but if not, you will look stupid. You won’t gain anything by rushing, and most likely just teasing 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, as a rule, is more important than your ability to reasonably view the task from different angles than the ability to accurately answer the question. When there seems to be no more hope, keep reasoning.
Draw pictures . Do not waste time thinking in silence - think on the board. Draw a couple of different test input data. Draw the process of obtaining 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, ineffective 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 you know. Say what you thought might work and why it won’t work. It may suddenly turn out that this will actually work, or a modified version of your output will work. Or you can get a hint.
Wait for clues . Do not look at the interviewee while waiting, but stop for a second to think - the interviewer may already have decided to tell you something and is just waiting so as not to interrupt.
Think about memory boundaries and runtime . If you are not sure that you can optimize your decision, think about it out loud. For instance:
- I need to at least consider all the elements, so it’s better than not to do O (n).
- Crude method solutions - check out all the possibilities, and it is O (n 2 ).
- There will be n 2 elements in the answer , so I need to at least spend the same amount of time.
Unload your thoughts
Easy to stumble about yourself. Focus on getting rid of your thoughts first, and then worry about the details.
Call the helper function and continue . If you cannot figure out how to implement any part of the algorithm, large or small, just skip it. Write an appeal to a reasonably named auxiliary function, say, “this will execute X” and continue. If the helper function is trivial, you may not even need to implement it.
Do not worry about the syntax . Switch back to English for a while if necessary. Just say you'll get back to the syntax.
Leave yourself plenty of room.. You will probably need to add lines of code or notes between lines later. Start at the top of the board and leave a blank line after each line of code.
Leave an accurate check of indexes for later . Don’t worry about what your "<" or "<=" for loop will be. Put a reminder to go back 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
helps you not to get lost in your code. Use names_to_phone_nums_map instead of nums. Invoke the type in a variable. Functions that return Boolean must begin with "is_" (depending on the standard adopted in the language, other options are possible, 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 around your decision manually, aloud, using the source data as an example . Record what values the variables contain when the program runs. you won’t get any advantages if you do it in your head. This will help you find bugs and dispel doubts that the interviewee might have during 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!
Don't be a bore. Some interviewers don't give a damn about putting things in order. If you are not sure, say something like: “Then, as a rule, I check the code for border cases - should we do this further”?
Practice
In the end, nothing beats practice. Go for more interviews.
Write the code with a pen on paper . Do not be fooled. At first, it may be uncomfortable. Good. You need to get rid of this awkwardness now so as not to screw it up when it comes to a real interview.