Whiteboard programming Talk about--why, what, how

Http://www.cocoachina.com/programmer/20150603/11993.html

Lucida

Weibo: @peng_gong

Watercress: @figure9

Original link: http://lucida.me/blog/whiteboard-coding-demystified/

This article excerpts from a book I am writing about fresh graduates interviewing for jobs, and you are welcome to comment or tweet (@peng_gong).

Interview is difficult, technical interview is more difficult-only 45 ~ 60 Minutes is difficult to examine the level of the participants. So Liu Weipeng in how he spends two years interviewing a person. Encourage the interviewer to create a GitHub account, read technical books, and build technical influence to provide the interviewer with a real, clear, measurable experience.

This method works well for the interviewer, but it works for the interviewer-the interviewer faces a large number of interviewers who may have only a handful of technical blogs, but that doesn't mean they're not technically strong enough (maybe they're not interested in writing); On the other hand, some people have technical blogs, But it does not mean that their level will be very good (perhaps they are in the mouth).

In summary, technical blogs and GitHub accounts are added, but technical interviews are still essential. So, the question is back, how to conduct an efficient technical interview? Or how to study the skill level of the participants as accurately as possible within 45 ~ 60 Minutes?

Before answering this question, let's take a look at some of the FAQs in technical interviews:

FAQs in Technical Interviews

The questions in the technical interview can be broadly divided into 5 categories:

1. Coding: Study the interviewer's coding ability, generally require the interviewer in 20 ~ 30 minutes to write a demand-specific small program (example: Write a function to divide a shape array, put negative numbers on the left, 0 in the middle, positive numbers on the right);

2. Design: Examine the interviewer's design/presentation skills, generally requiring the interviewer to give a systematic design in about 30 minutes (example: Designing a system similar to Weibo)

3. Project: Examine the interviewer's design/presentation skills and the authenticity of his or her CV (example: Describe the difficulties in the XXX system you have done and how you overcame these difficulties)

4. Brain Teasers: A study of the interviewer's "Response/Intelligence" (Example: if you become an ant size and then thrown into a blender, how will you get away?) ）

5. Leak checking: The interviewer's proficiency in a particular technique (example: What are the basic types of Java?) ）

Among these 5 types of problems, brain teasers have long been extinct in foreign companies (because it is unable to determine the true ability of interviewers), and the problem of checking out problems because the actual value is not very small (after all, we can use Google) in foreign companies, the incidence rate is also getting lower, the remaining 3 types of problems, project and design issues require the interviewer , only the coding problem does not require any prerequisites, so almost all technical interviews include the coding class.

However, these coding problems are the most troubling for the interviewer-because almost all of the in-person (on-site) technical interviews require the interviewer to write code on the whiteboard rather than writing it out in the IDE or editor that the interviewer is familiar with. In my interview experience, more than one interviewee complained to me: "If I can program on a computer, I'll get it done already!" Even I doubted the validity of the whiteboard code at the beginning of the interview: "Why not let the interviewer write code on the computer?" 』

However, after several rounds of interviews and interviews, I was amazed to find that whiteboard programming was a fairly effective way of technical investigation. That's why I'm writing this article--I hope this article will explain why Whiteboard programming (why) is the right Whiteboard programming topic (what) and how to do whiteboard programming to help interviewers better prepare for interviews and better interviews for interviewers.

Why Whiteboard programming

Many interviewers want to be able to write code in the IDE, rather than on a whiteboard, because:

1. Mainstream IDE with smart hints, which greatly improves encoding speed

2. The IDE guarantees that the program can be compiled by

3. You can run/debug code through the IDE to find bugs in the program

I admit that 1th, whiteboard programming is much slower than IDE programming, but this is not a reason to deny Whiteboard programming-because whiteboard programming is often an API-independent (and therefore does not require you to recite the API) a small segment (typically no more than 30 lines) of code, And the interviewer will allow the interviewer to make the appropriate abbreviation (for example, to abbreviate the iterable type to ITER), so it is not a reason to deny Whiteboard programming.

As for the 2nd and 3rd, they can't be a pretext to deny whiteboard programming-if you use the IDE just to write code that compiles, or to debug bugs, I don't think you're a qualified programmer-I think programmers can be divided into two types:

1. First confirm the pre-condition/invariant/termination condition/boundary condition, then write the correct code

2. Write the code first, then adjust the program through various use cases/test/debug, and finally get the code that seems to be correct

I personally estimate that the former development efficiency is at least 10 times times the latter, because the former does not need to waste a lot of time on coding-debugging-coding This extremely time-consuming cycle. Through the Whiteboard programming, the interviewer can effectively determine whether the test is the former or the latter, so recruit into the right talent, and the old fritters or mouth to remove the people.

In addition to judging the interviewer's development efficiency, whiteboard programming also helps to showcase the interviewer's programming ideas and facilitates communication between interviewers and interviewers:

The goal of Whiteboard programming is not to ask the interviewer to write the perfect code at once, but instead:

• Let the interviewer in the process of solving his/his thinking process and coding habits in front of the interviewer, so that the interviewer to determine whether the interviewer has clear logical thinking and good programming quality

• If the interviewer is caught in a dilemma or trap, the interviewer can also provide appropriate assistance to prevent the interview from falling into the awkward position of no one speaking.

What is the right Whiteboard programming topic

As mentioned earlier, whiteboard programming is a very effective method of technical interviewing, but it is based on an effective programming problem: if the programming problem is too difficult, then the interview is likely to fall into the "at" situation, if the programming problem is too simple (or the interviewer has the title), Then the interviewer can give the right answer without thinking. Neither of these situations can achieve the purpose of examining the interviewer's thinking process, which makes it impossible for the interviewer to evaluate the interviewer's ability correctly.

Since the programming topic is very important, then the question comes, what is the appropriate (reasonable) programming problem?

Before answering this question, let's take a look at some of the programming topics that are inappropriate:

What should I ask?

Being asked about programming problems

I found in the job search, the technical interview programming topics are often the same--for me, the reverse single-linked list was asked 5 times, the number to the string was asked 4 times, the random array was asked 3 times, the most ridiculous is in the interview of a foreign company three interviewer asked me how to reverse a single linked list, So that I have to take the initiative to change the subject to avoid misunderstanding.

Coincidentally, when I was looking for a job, I also found that many interviewers were carrying a book or printed material, which was full of common interview topics, and some of the interviewers even prayed that they would be asked the above questions.

In this matter, I and my classmates and later colleagues discussed, the answer is that many interviewers do not prepare the interview before the interview, but from the network (for example, July algorithm blog) or the beauty of programming, such as a question set randomly pick a question. If the interviewer makes (or backs out) The topic then passes, if the interviewer can't do it, hang up.

The problem with this type of interview is obvious: if the interviewer is well prepared, the questions are simply not distinguishable-the interviewer is likely to recite the answer directly, and if the interviewer is not prepared, he/she is likely to be aha! by some need. Moment's problem is trapped. In short, if the interview question does not evaluate the level of the interviewer, then what is the point of asking it?

Here are some of the most problematic programming issues :

• All the topics in the book of programming Beauty;

• The vast majority of topics in July's algorithmic blogs (including all topics in the 100 interview questions);

• Most of the topics in Leecode;

involves library functions or API calls

The goal of Whiteboard programming is to examine the interviewer's programming skills, rather than to examine the proficiency of the interviewer using a language/class library. So the Whiteboard programming topic should be as far as possible the library function--for example: Writing an XML reader is not qualified, because the interviewer does not need to memorize the function name in the XML library (otherwise to be Intellisense), while eliminating the repetition of the string space (example: "AB C D e" =& Gt "Ab C D e") is a qualified subject, because even if the library function is not used, the qualified interviewer can complete the problem within 20 minutes.

An overly straightforward (or simple) algorithm problem

Such problems are similar to the problem of being asked about programming problems, which are characterized by being too direct, so that the interviewer can give an answer without thinking, thus making the interviewer unable to examine the interviewer's thinking process. Quick sorting, Depth-first search, and binary search all fall into this category.

It is important to note that although an overly straightforward algorithm topic is not suitable for interviewing, we can change it a bit to make it a reasonable topic, such as the Stability division and the binary search count (given the number of occurrences of an element in an ordered array), although they are actually a variant of fast sorting and binary search.

Too complex a topic

With overly straightforward algorithmic problems < rather, overly complex topics are at the other extreme: these topics often require the interviewer to have a strong algorithmic background, even though the algorithmic problem is too complicated to vary (in the eyes of some ACM programmers, there may be no complicated topic –_-), But I personally think that if a problem satisfies any of the following, it is too complex to be suitable for an interview (but if the interviewer is an ACM programming competitor, you can ignore this rule):

• Need aha! Moment (refer to brain teasers)

• Some "non-mainstream" data structures/algorithms need to be used to solve

• Takes too long (such as inserting/removing red-black trees)

Brain Teasers

What is a brain teaser?

• Do not examine the programming ability

• dependent on the aha! Moment

• All or nothin: or not, or the final answer.

In some books (for example, who is the person Google wants?) : To crack the interview code of the world's top companies and the film's rendering, interviews with foreign companies such as Google and Microsoft are so mysterious that many people think that foreign companies really ask strangeness questions such as "why the manhole covers are round" or "How many cars can fit in the truck." In fact, these topics have not been able to examine the interviewer's technical ability and has long been extinct in foreign companies. Instead, some domestic companies began using brain teasers as an interview topic –_–#

What questions should I ask?

Therefore, technical interview topics should not be too difficult, nor should it be too simple, not a brain teaser, nor directly from the network.

The first three points are not difficult to meet: we can go to the introduction of algorithms, Programming Zhu Ji Nanxiong, as well as the computer programming art of these classical algorithms books in the book of the following topics/exercises to choose the right topic, you can also create their own problems. However, due to the existence of such sites, there is no topic can be absolutely original-after all, no one can prevent the interviewer to send the topic to the Internet, so any programming problems will not escape the fate of the public. Careercup

However, although the interviewer will send the programming questions online, there will even be some "good people" to give answers, but this does not mean that the interviewer can not continue to use the problem: because although the topic is open, but the question of the point of inspection and extension of the problem is still only the interviewer know. This is a bit like public key cryptography, public keys (interview questions) are public, but private keys (solutions, research points, and extension issues) are only known to the interviewer. In this way, even if the interviewer knows the interview question, it will not hinder the interviewer's ability to study the interviewer's skills.

Next, let's see what the problem is for Whiteboard programming.

More than one solution

Good programming problems will have more than one solution. In this way, the interviewer can give a less intelligent but achievable "rough" algorithm in a short time, and then through thinking (or interviewer tips) gradually get more optimized solution, the interviewer can through the process to observe the interviewer's way of thinking, so that the interviewer to conduct a more objective assessment.

In the case of the maximal subsequence of the array, it has a very obvious O (N3) solution, the O (N3) solution is slightly modified to obtain O (N2) solution, using the divide-and-conquer thought, the O (N*LOGN) solution can be obtained, in addition to it has an O (n) solution. (Programming Zhu Ji Nanxiong and data structure and algorithm analysis C language Description of the problem are very wonderful description, interested friends can read by themselves)

The investigation point is clear

Good programming problems should have a lot of research points, the interviewer should be in the heart of these visits, so as to give more objective quantitative interview results. Here you can refer to the To_upper I mentioned earlier in the interview from the Swordsman to the programmer.

Extension issues

Good programming issues should have an extension problem. The extension problem can not only deal with the interviewer's back problem, but also gradually (Incremental) examine the interviewer's programming ability, and also ensure the continuity of the interview (continuity).

Take the traversal of the binary tree as an example: interviewers can start questioning from a non-recursive, sequential traversal of a binary tree, and the interviewer may quickly write (or recite) a solution that uses the stack. The interviewer can then use the extension to determine whether the interviewer is in the back: using constant space to traverse the two-tree with the parent pointer , or to find the small nth element in the two-fork search tree. Here are some of the extensions to the middle sequence traversal binary tree:

1234567891011

|--中序遍历二叉树    |    |--非递归中序遍历二叉树        |        |--常量空间，非递归遍历带父节点的二叉树        |   |        |   |--在带父节点的二叉搜索树寻找第 N 小的元素        |       |        |       |--可否进一步优化时间复杂度？        |        |--常量空间，非递归遍历不带父节点的二叉树

The above problem can not only be used positively (gradually enhance the difficulty), but also can be used in reverse (gradually reduce difficulty): Also from the non-recursive binary tree traversal began to ask questions, if the interviewer can not complete the problem, then the interviewer will be able to reduce the difficulty, ask the interviewer to write a recursive version of the middle sequence traversal binary tree.

How to do whiteboard programming

What the interviewer should do

Before the interview

Before the interview, the interviewer should have at least the following information:

1. Candidate's resume

2. Candidate positions for candidates

3. What questions have the interviewer been asked before?

Next, the interviewer should confirm the interviewer's expectations based on the interviewer's CV/position, and then prepare the programming questions (rather than improvising on the topic during the interview). The interviewer should prepare at least 4 questions (2 simple questions, 2 puzzles) to cope with all kinds of situations.

During the interview

During the interview, the interviewer should clearly state the topic and confirm the interviewer's real understanding by using several sets of use case data (lest the interviewer take a long time to do irrelevant topics, I have done this kind of setback in the previous interview –_–#)

When the interviewer is solving the problem, the interviewer should keep quiet (or listen), if the interviewer commits a particularly serious mistake or is stuck in a puzzle, the interviewer should give the appropriate tips to help the interviewer to get out of the problem, if the interviewer can not complete the topic, then the interviewer should change a slightly simple topic, Be aware that the purpose of the interview is to find the interviewer's strengths, not to embarrass the interviewer . (some domestic companies seem to be the opposite)

After the interview

After the interview, the interviewer should take a photo (or transcribe) the code written by the interviewer, and then send the question to HR and the next interviewer (to make sure the problem is not repeated). Next, the interviewer should write the interview feedback (interview Feedback) to HR for the next recruitment process according to the interviewer's code and his interview performance.

What the interviewer should do

Before the interview

Before the interview, the interviewer should have at least the following preparation:

1. Have a solid data structure/algorithm base

2. Know how to use pre-condition/invariant/post-conditions these tools to write the right program

3. The ability to implement basic data structures and algorithms on a whiteboard (or on paper) (if 1 and 2 do this step)

4. Practice on Leetcode or careercup to learn about common technical interview topics (I personally do not encourage brush questions, but it is important to establish the "feel" of the opposite question before the interview)

During the interview

Identify requirements

The most important task for the interviewer in Whiteboard programming is to understand the topic, confirm the requirements -determine the input/output, determine the data range, determine the time/space requirements, and identify other constraints. Take the most common sort as an example:

• Input: From an array? Linked list? Or a different machine?

• Output: Do you have duplicates? is stability required?

• Data range: How many elements are sorted? 100 of them? 1 million of them? 100 million of them? Are these elements within a range?

• Time requirement: 1 minutes? 1 quarter? An hour?

• Space requirement: is constant space? Can I allocate a new space? If so, how much space can be allocated? Do you want to sort in memory?

• Other restrictions: Do I need as few assignments as possible? Is there a need for as few comparisons as possible?

Sometimes the interviewer will not be very clear about the topic, then it is necessary for the interviewer to confirm these requirements, do not think this is a waste of time, different requirements will lead to a completely different solution, in addition to confirm that the requirements will leave the interviewer a good impression.

Whiteboard programming

After understanding the topic to confirm the requirements, the interviewer can start to write code on the whiteboard, here are some of my own Whiteboard programming experience:

• Write outline (outline) First

Whiteboard programming cannot be copied and pasted, so it is very difficult to adjust the code structure later. Therefore, we'd better write the approximate structure of the program at the beginning, so as to ensure that there will be no big changes.

• Determining pre-condition/invariant/post-conditions

We can give the code a pre-condition/invariant/post-condition in the form of a comment, as an example:

123456789

int* partition(int *begin, int *end, int pivot) {    int *par =  begin;    for( ; begin < end; begin++) {        if(*begin < pivot) {            swap(begin, par++)        }    }    returnpar;}

is better

123456789101112

int* partition(int *begin, int *end, int pivot) {    // [begin, end) should be a valid range    int *par =  begin;    // Invariant: All [0, par) < pivot && All [par, begin) >= pivot    for( ; begin < end; begin++) {        if(*begin < pivot) {            swap(begin, par++)        }    }    // Now All [0, par) < pivot && All [par, end) >= pivot    returnpar;}

• Use instance data to validate your own programs

Although the invariant is sufficient to verify the correctness of the program, proper use of the instance data will greatly enhance the trustworthiness of the code, taking the above partitioning procedure as an example:

1234567891011121314151617181920

Given range [2, 3, 4, 5, 1] and pivot 3[ 2, 3, 4, 5, 1 ]  ^             ^ p,b            e[ 2, 3, 4, 5, 1 ]     ^          ^    p,b         e[ 2, 3, 4, 5, 1 ]     ^  ^       ^     p  b       e[ 2, 3, 4, 5, 1 ]     ^     ^    ^     p     b    e[ 2, 1, 4, 5, 3 ]        ^     ^ ^        p     b e[ 2, 1, 4, 5, 3 ]        ^       ^        p      b,eNow we have all [0, p) < 3 and all [p, e) >= 3

• Using abbreviations

Whiteboard programming does not require the interviewer to write code on the whiteboard that can be compiled at once. To save time, interviewers can use abbreviations based on communication with interviewers. For example, use Iter instead of iterable and BQ instead of Blockingqueue. (This method is particularly suitable for java–_–#)

• Leave at least one line and half a line wide

Due to nervousness or neglect, the general interviewer will make various small mistakes in the Whiteboard programming, such as forgetting a certain condition or missing a statement, and the line width can help the interviewer to quickly modify the code so that the code on the whiteboard is not a mess.

This extends to another problem, if the use of large line width, then the whiteboard can not write what to do? Some interviewers are smart enough to solve the problem: they will bring their own pen with a fine handwriting in the interview, specifically for Whiteboard programming.

Can't do what to do

I believe most of the interviewees have encountered the situation that the interview question will not do, here say my own countermeasure:

1. At least a violent (Brute force) solution is given first.

2. Find the right data structure (e.g. stack/queue/tree/heap/graph) and algorithms (e.g. split/back/dynamic planning/greed)

3. Try starting from a small data set

4. If there is still no clue, reconsider the pre-condition of the topic, think about whether the condition (or the implied condition) is missing.

5. If there is no thought after 3 minutes, ask the interviewer for tips, do not feel embarrassed--after the prompt to give answers far stronger than no answer

After the interview

Individuals do not recommend to the interviewer after the interview to send the topic to the Internet, many companies before the interview will greet the interviewer, and some will sign the NDA (Non Disclosure Agreement) provisions to ensure that the interviewer will not reveal the interview topic. Although they are seldom really checked, it is not worth the candle if they are found.

I will write the programming questions in the interview after the interview myself (unless the topic is too simple and not worth it), so as to be able to verify the code you write, but also to ensure that you do not fall in the same place two times.

Reference

Books

1. Elements of Programming interviews:the Insiders ' Guide

2. Programming Original

3. Programmer Interview Gold (5th edition)

Article

1. How to spend two years interviewing a person

2. 5 Whiteboard Coding Tips for interviews

3. Is "white-board-coding" inappropriate during interviews?

Whiteboard programming Talk about--why, what, how