About interviews (by Eric Lippert)

Earlier, I re-published two of my old articles (originals: one , two - approx. Transl.), Concerning the process of technical interviews. I suppose that I could describe in more detail how I conduct interviews and to which I pay attention.

Here are my main goals:

• do not hire bad workers;
• hire good workers;
• leave the candidate with a positive impression of the company.

Of course, avoiding hiring a bad employee is much more important than hiring a good one. If we don’t get a great employee, this is very bad, but a bad recruitment can reduce a team’s performance for years.

The last point is also the key; if we want to hire someone, then obviously we must make a good impression. But I also want all those who are refused - also to have a good opinion of us. They have friends who may want to talk. Someday they may decide to purchase our product, or recommend it. Interviewing is an expensive business process; if he does not lead to hiring, then perhaps we will get a client, or at least a greater favor for ourselves.
')
The interview is as follows.

First of all, I have to make sure that the applicant is comfortable, has something to quench their thirst, I do not want to go to the toilet, and so on. Then, if the person has already interviewed someone before me, then I ask, “How are you?”. The purpose of this question is to defuse the atmosphere, start a conversation, and see if the candidate has any questions regarding the interview. Sometimes I have information about how the candidate has already shown himself, but it is not intended for decision-making. (Microsoft was encouraged to give feedback to the following interviewers as soon as possible so that they could dig in the direction of potential problems; in Coverity, we are more inclined to ensure that each interviewer starts to be impartial. Both approaches have their pros and cons.)

After that, I choose something interesting and not too old from the candidate’s resume, first I ask you to give me “Elevator Pitch” - a few sentences describing the project, what it was interesting for, important - and then I ask you to describe the problem solved in this project in more detail .

This, again, will help the candidate to relax, as he talks about something from his resume, and is probably good at it. I want to find out first of all - can the interviewee communicate normally? You will be surprised how many people cannot tell with one or two sentences about things from their resume. Secondly, what did they actually do on this project? This may be a shock, but people constantly embellish their merits. Having studied the details of what exactly the candidate did, I can understand whether he is really “smart and brings the matter to the end” (smart and gets stuff done) or not.

Then we move to a really interesting stage: a technical challenge. The goal is to find out whether the candidate is able to write the kind of code that will need to be written every day. I know that writing the code by hand on the board is criticized, and I agree with this criticism. This is an unnatural environment, not the same as when writing real code, this is a stressful situation, etc. I try to come up with questions that minimize such difficulties, but still able to show me whether the candidate will cope with the real work. (And if a person does not want to write code on the board, we can do it on a computer. However, the questions I ask rarely require writing more than six lines of code. The best applicants should be able to write half a dozen short lines without using a text editor.)

And this stage is really important. I check that applicants meet an unusual set of requirements. Candidates for teams working on language analysis tools should be strong in the theoretical foundations of computer science, and at the same time capable of working in the real world of imperfect code. I interviewed to break through the deep understanding of the theory of scientists, while unable to write real code, as well as experienced industrial programmers who could not tell me what a binary tree is.

A good technical problem has the following characteristics:

• can be supplied and solved with a small amount of code in a short time;
• does not require a sudden insight, which is difficult to achieve in a stressful situation;
• it's not a dirty trick;
• if desired, it can be made more difficult, or easier, in order to better assess the level of the candidate;
• similar to the problems that the applicant will have to solve in the workplace;
• tests not only writing code, but also other skills, such as the ability to read existing code, or deal with fuzzy requirements;

The task that I have been using for a long time at Microsoft, and which works even better in Coverity, has the following scheme:

First, there are two methods written in C ++ from the public API, each of which consists of three lines of very simple code. The API manages “tasks” on a “server”, and is used by a “client”. The script is intentionally very blurry, but the code is clear. I spend the candidate on each line and make sure that he understands the code. Here I need only a basic understanding of simple syntax (the vast majority of candidates are familiar with C ++ according to their resume, since this is a necessary requirement for the job).

Next, I instruct the candidate to investigate this code for any problems . And I observe in which direction he digs in the study of someone else's code. The code presented has design, reliability, security, testability, and portability issues. I see what problems the candidate finds on his own, and if he misses something, I can tell: “If the client intentionally tries to disrupt the server, what will you do?” Or “What happens if you compile this code to run on a 64-bit machine?” and see if he understands the hint.

This is a real skill that I need to use every day - first, with code review of my own code and the code of my colleagues. And secondly, my business is writing programs that analyze a buggy code and determine that it is buggy. If the applicant is not able to check someone else's code, it is unlikely that he will succeed anywhere at all. A person who cannot find any of a dozen errors in a program containing six instructions is unlikely to write a code analyzer that finds errors.

Here I seek insight, critical thinking, and a basic knowledge of the subject area. Often at this stage there are danger signals. I had applicants with PhD in computer science who did not know, for example, that in a 64-bit architecture, the pointer length is 64 bits. And why should they know? As they say, astronomy is not the science of making telescopes. Extensive knowledge of theoretical computer science does not necessarily entail knowledge of the bus bandwidth between the processor and memory. But a candidate who does not understand how pointers are implemented in common architectures is unlikely to be successful, working in a team to develop analyzers who are looking for errors related to the length of the pointer.

Also, many applicants identify errors in the code, but cannot describe their consequences. Indefinite behavior is not defined by definition. But the description of what can happen if a malicious client assigns a pointer to an arbitrary piece of memory and causes the server to execute a virtual method with such a pointer demonstrates an understanding of how the compiler actually generates .

This is the first phase of the technical task. The next step involves the design, and perhaps some small amount of coding. "You can change the implementation of the API, but not the method signatures - how would you correct each of the errors found?" Again, this is the main working skill that we have to use every day: correcting errors on the “server”, being unable to change the behavior of the “client”. Perhaps the calling code belongs to the customer, or another team, or is already sold, whatever.

At this stage, I draw attention to the following:

• Are there any other danger signals? God, the number of candidates trying to solve the problem of portability by compressing a 64-bit pointer into a 32-bit integer is huge. There are no tricky riddles that I ask you to solve. You cannot put twenty pounds of flour in a ten-pound bag. It should be obvious that you need to find another way to solve the problem.
• What tools can be in the baggage applicant? All candidates ultimately understand that they need to add an auxiliary data structure for mapping from a 32-bit integer to a 64-bit pointer. Are they aware of existing implementations of such a mapping? If not, are they sure they can write like that?
• Can a candidate single out a really difficult part of a task? The difficulty here is not in recognizing the need for mapping, but in ensuring the uniqueness of the keys when adding a new key-value pair (as I mentioned in the previous episode, the original is a comment of the translation). Even when I repeatedly ask: “In your decision, you still haven’t told how to calculate the key value - since this value is generated?”, Some candidates just do not pay attention to it and continue to explain to me how the mapping works. Or they return to the previous point and try to compress the 64-bit value into a unique 32-bit key, which is impossible and what is the cause of the mapping.
• How will the candidate get out of this ambiguous situation? The problem is deliberately blurred, unclear, and the difficult part is to generate unique values. If there are two clients, each of which creates two “tasks” and then turns off, then generating unique 32-bit integer keys is easy. If there are millions of customers who generate millions of “tasks,” then getting unique keys can be very difficult. Many candidates never ask me how many clients and “tasks” there are in this system, and therefore some give out too complicated ideas, and someone offers a solution that is unscalable in principle.
• Can a candidate draw parallels with previously solved problems? It is difficult to do in a stressful situation, but it is still interesting to look at this. Some candidates very quickly realize that the problem “to generate a unique 32-bit number, and not to reuse it until the client has finished with it” should have been previously solved by those who wrote the 32-bit version of the memory manager. In the end, what is a memory manager? (Device memory manager): a device that provides you with a unique pointer upon request, and does not issue the same pointer again until you release it. Therefore, the problem formulated by me can be reduced to the previously solved. Some candidates talk about memory allocation and things like magic. Many realized that the problem was similar to the implementation of the heap; but only one said: “I will solve the problem by getting a bunch of 4 billion bytes from Windows, and then I will allocate individual bytes from the heap in order to generate unique 32-bit numbers” (eng. Windows 32-bit numbers, and then allocate it. This will really reduce the problem to the one already solved!

If the candidate is doing very well, then complicating the task is quite simple. Suppose clients are used by many threads; What synchronization strategy will keep high bandwidth? Suppose task states should be saved when the computer is restarted. What if the server is in a cluster and can redirect the load to other servers. I want to find out how deep their knowledge is. Or I can simplify the task by limiting the number of customers to ten. Suppose that the “tasks” start and end in a certain order, so that the next “task” starts after the previous one ends. And so on. I would like the applicants to feel that they have coped with at least some problem.

At the end of the interview, I try to gain some time so that the candidate can ask questions about the team, job, company, etc. (no one has ever asked: “Would you write a code that expands the linked list?”, and I would be very surprised if someone did this). For me, this is another opportunity to "advertise" our company, as well as to understand from the questions of the applicants, what is important for them.