Last year, I spent countless hours interviewing candidates for various positions at Facebook. And, since now I had the opportunity to visit both sides of the selection process, I would like to help you - students who are trying to get into their first internship, more experienced developers who are preparing to move to another company, or those who want to go into programming from a completely different professional environment.
In this article I want to outline the most important lessons that I learned from the experience of interviewing programmers on Facebook. I hope they shed light on some features of this process, which very, very many very exhausting nerves.
Format
Interviews for programmers, as a rule, take the form of a conversation, last 45 minutes and are aimed at testing your knowledge of data structures and algorithms. Interns usually only need to go through one interview where they show their code writing skills. Higher-level developers will probably have to attend two or three code writing interviews, one or two interviews where they will test their system design skills, as well as a separate meeting to evaluate their personal qualities. Here I will only talk about code interviews.
Recently I was asked: "What if I just can’t find a solution to this problem right away?" I replied: "Well, if the task is chosen correctly, then you should not immediately find it." Otherwise, what's the point? The purpose of the interview is to understand how good you are at programming. On the Facebook team, information that answers this question is called a signal. The interviewer seeks to get the most out of him. In other words, if we understand that you are already familiar with the proposed task, our responsibility is to give you another.
We need to see how you deal with difficulties. If you, by chance, can recite the solution by heart directly from Cracking The Coding Interview, then we don’t know anything about your problem-solving abilities.
Best Practices for Job Interviews
The best of the best candidates become the driving force for the interview - they themselves have a conversation and practically do not need the company employee to push them in the right direction. Typically, such programmers on a whim, without prompting from the outside, do the following:
- Ask clarifying questions.
- Analyze solution options, their pros and cons
- Draft code
- Show solution implementation
- Testing Your Solution
Do not confuse initiative with haste. An active stance does not mean that you should immediately rush to write code. On the contrary, if you start the code in the first five minutes of the conversation, this can greatly ruin the impression. The first step to a brilliant job interview is clever clarifying questions.
Clever Ask Questions
Before you make a decision, you need to understand the problem well. A few thoughtful refinements can seriously increase your chances of success. Here are a few for example:
- Does this need to be done without additional memory?
- What input should we focus on?
- What is more important - performance or low memory consumption?
This way you can focus on what really matters and get everything else out of your head. Knowing what you can not think about is no less valuable than knowing what needs special attention.
Do not think
Very often, candidates begin to add some kind of speculation on their own (variables are only positive numbers, arrays cannot be empty, all input data is safe). This is a serious bell. Never adjust the conditions so that it is more convenient for you to find a solution. Ask.
“Do we assume that all values are positive?”
Nowhere is easier. If they say yes, that's great. No additional checks are required. If not, then a single condition statement is enough to protect your code from any chance. Often with the help of such questions you can get an indication of in which direction you need to move.
Solution options
Interviewers are very fond of when candidates highlight several solutions. This shows that you understand: you can approach any task from different angles, and, more importantly, it forces the interviewee to tell you without direct requests from you. Yeeee!
We can not just take and lay out the right answer for you. But if you propose two options, A and B, and ask: “Which approach, in your opinion, is more appropriate here?”, Then we will certainly choose what looks more like the desired one.
Draft your solution in code form
At technical interviews, writing is most often necessary on the blackboard. Accordingly, it will not work to insert operators when and wherever it wants. You should have a good idea of what you are going to do before you start writing.
Take a deep breath and start planning your code. It can be draft code, it can be a scheme, the main thing is that you know which data structures will be used in them and which variables will be of interest to you. I think no one wants the result of his work to look something like this:
Write the implementation
At this stage, everything usually stalls, although in a good way it should not be. In theory, the implementation of the solution is the simplest. You asked smart questions, considered different approaches, thought out the algorithm - you just have to paint everything. In the meantime, do not forget about ...
Communication!
Speak out loud. It’s quite difficult to bring you to the right point if I don’t know what you’re thinking at all. If you carry you somewhere in the wrong place, I will intervene. If you are moving in the right direction, most likely I will not knock you down.
However, a caveat needs to be made: personal interviewing style decides a lot. Someone intervenes in the course of the decision more actively, someone prefers to stay away.
Testing
Oddly enough, this step is neglected most often. I would say that 98% of the developers who were at my interviews should pay more attention to checking their decisions.
At the beginning of the interview, the candidate is usually given a test option along with the task. Upon completion of the solution, they run the code through the appropriate test. But there is one problem: we give you the most primitive testing option. It, as a rule, does not affect borderline cases and does not make it possible to check the code as it should. With these parameters, your algorithm gives the desired output; with others, it may not.
The easiest way to show off at a technical interview is to write tests. The bigger, the better. The harder the better. The more comprehensive, the better. In most cases, this will allow you to catch bugs before I point them out. And such things speak in your favor.
What to do if you do not know what to do
So all the same, what to do if you were given a task, and you just can’t find a solution right away?
Proceed in stages. Remember: perhaps the task will seem to you similar to any of those that you solved earlier. Many of the tasks that I proposed at the interviews were basic tasks, which are disassembled at any courses where algorithms and data structures are studied - but with a subvert.
If nothing comes to mind, don't panic. Everything is fine. Do not worry about trying to immediately find the most effective solution - start with the simplest one. Then, taking it to a starting point, think: what are the bottlenecks here? What requires optimization the most? How can this be optimized?
Reduce system weaknesses with strengths of data structures. When you need to make an algorithm more efficient, data structures often (though not always) come to the rescue. Each of them has its own advantages and disadvantages (the hash table is the speed of data search, the binary search tree is sorting them, and so on). The best solutions are obtained when you manage to close some bottleneck due to the strength of one or another data structure.
Well, for example, you have a task:
Given a proposal, calculate how many times each letter of the alphabet appears in it.
If you use the exhaustive search method, you will have to count each letter in turn, and then summarize the data into the final result. The inefficiency of the method lies in the need to store and search for information: we save the data that we received for each letter, and then we extract it to form a total result. If you look at the available data structures, you will notice that one stands out among the others in the way we need:
- Binary search tree
- Array
- Hash table
- AVL tree
- Stack
- Turn
The most efficient is the hash table stores and retrieves data. If you use it, you won’t have to analyze the proposal twenty-six times - just one is enough.
Look for a clue
Often, a clue is introduced into programming tasks that opens the way to a more convenient solution. Usually this is some kind of trifle, an unusual condition due to which you can act with greater efficiency than with other initial ones. Check to see if there is anything like that in your task.
Let's say:
Given two sorted arrays of type Integer, A and B; it is required to merge B from A. It is assumed that A can accommodate all elements from B; the number of initialized elements in arrays is m and n, respectively.
The task is taken directly from the book How To Crack the Coding Interview. Noticed a clue? We could be given just two arrays for merging, but no: in our scenario, one is completely placed in the other. That’s what I’m talking about. If you notice such reservations, be aware that they were not included accidentally.
Here, the free space gives you the opportunity to optimize the merger process. The complete solution can be viewed here .
Ask for help
Sometimes it happens that you went through all the steps, but remained at a dead end. In this case, you should simply contact the people conducting the interview for help.
From the fact that we will sit for ten minutes in silence, it will not become easier for anyone. If you seriously have no idea what to do, asking for clues will be the best way out. Each of us needs tips from time to time. Everything decides how you will be able to use it.
Finally
A technical interview is the same standardized test as those we know from graduation and university enrollment. Tasks differ in details, but the basic concepts and solution strategies remain more or less standard.
Many candidates are cut off on very simple things: they think up their own conditions, do not pronounce the train of thought, poorly test their decision. All these errors can be corrected, and “definitely not” can turn into a “take”. Use the system that I sketched in this article and you will be in good shape.