"Long Wen" Google interviewer to step through the analysis of their own before the leak of the face questions, super-dry and advice

This article is translated from Google engineer/interviewer Alex Golec's article: Google interview Questions Deconstructed:the Knight's Dialer; translation: The experimental building floor sweeper; link

As a Google engineer and interviewer, today is the second time I've issued a proposal to share a technology company interview. Here we declare that this article represents only my personal observations, opinions and suggestions. Do not act as an official recommendation or statement from Google or alphabet.

The following question is the first question in my interview career, the first one to be leaked out, and the first one to be banned. I like the problem because it has the following advantages:

• The problem is easy to articulate and easy to understand.

• There are several solutions to this problem. Each solution requires varying degrees of knowledge of algorithms and data structures. Moreover, a little bit of foresight is needed.

• Each solution can be implemented in just a few lines of code, ideal for time-limited interviews.

If you are a student, or a job seeker, I hope you can find out through this article what the interview question will be like. If you're an interviewer, I'm happy to share my style and ideas in the interview, how to better convey the message and ask for advice.

Note that I will use Python to write code; I like Python because it is easy to learn, concise, and has a huge library of standards. Many of the interviewees I met were also fond of, and despite our "language-free" policy, I interviewed 90% of people using Python. And I'm using Python 3 because, come on, it's been 2018 years.

question Think of your phone dial-up page as a chessboard. A pawn can only walk in the shape of an "L", two steps in a vertical step, or two steps in a horizontal step.

now, let's say you dial the "L" shape just like a pawn. The starting position is also dialed once for each "L"-shaped dial-out number. Question: How many different numbers can you dial in n steps, starting at some point? Discussion

For each interview, I will basically be divided into two parts: first we find the algorithm scheme, and then let the interviewer in the code implementation. I said, "We find algorithmic solutions," because this process is not a silent dictator. At this high pressure, design and implement an algorithm, 45 minutes is not enough.

I usually let the interviewer lead the discussion, let them to produce ideas, I, just beside, occasionally leaking a little "secret". The more powerful the interviewers are, the less I need to spill the "secret", but so far I haven't met an interviewer who doesn't need my cue.

one thing I want to emphasize is that it's important to be an interviewer, and it's not my job to sit there and watch everyone fail and screw up. I want to give you positive feedback and give everyone a chance to show what they are best at. Give them a hint, it's like saying, "Now, this is the way I'm going to lay it out for you, but it's just for you to show me that you can go farther on the way back."

What should you do when you have heard the interviewer's question ? Remember not to write the code right away, but try to break it down on the blackboard in a step-by-step way. Decomposition can help you find patterns, exceptions, and so on, and gradually form a solution in your brain. For example, you are now starting from the number 6 and can walk 2 steps, there will be the following combinations:

6–1–86–1–66–7–26–7–66–0–46–0–6

A total of 6 combinations. You can try to draw on the paper with a pencil, and believe me, sometimes it's more magical to do something unexpected than to stare at your head.

What do you think? Do you have a plan in mind?

No. 0 Order: Get to the next step

The most surprising thing about using this question interview is that too many people are stuck in the calculation of how many possibilities, that is, the neighbor neighbors, to jump out of a particular point. My advice is: when you're not sure, write a placeholder and ask the interviewer if you can get to that part later.

The complexity of this problem is not calculated in neighbors; I care how you calculate the total. All the time spent on calculating neighbors is actually a waste.

I will accept "let's assume there's a function that gives me neighbors." Of course, I might also let you have time to do this later, and you just have to write it and go on.

Moreover, if the complexity of a problem is not here, you can also ask me if I can skip it, generally I am allowed. I don't mind that the interviewer doesn't know where the complexity of the problem is, especially when they're not fully aware of the problem at first.

As for the neighbors function, since the numbers will never change, you can write a map directly and return the values that match.

1th Order: recursion

Smart you may notice that this problem can be calculated by enumerating all the qualifying numbers. Here you can use recursion to produce these values:

This method can be, and is the most common method of interviewing. But please note that we have produced so many numbers without using them, and after we have counted them, we will never touch them again. So I suggest that you meet this situation, try to think about whether there is a better plan.

2nd order: number of numbers

How to calculate the number without generating these numbers? can do, but need a little tact. Note that the number of digits that can be dialed from a specific point is equal to the sum of the number of digits that can be dialed from all of its adjacent points N-1 times. We can express this as a recursive relationship:

If you think so, it will be very intuitive, jumping once: 6 has 3 neighbors (1,7 and 0), when jumping 0 times each number itself is counted once, so each time you can only dial to 3 numbers.

how can you produce such a witty idea ? In fact, if you learn recursion and study it on the blackboard, it becomes obvious. So that you can continue to solve this problem, in fact there are many ways to achieve this, the following is the most common in the interview:

That's it, combining this function to calculate the neighbors. At this point, you can pinch your shoulders and rest, because you've already brushed off a lot of people here.

The next question I often ask is: how fast is the algorithm theory of this scheme? In this implementation, each call to Count_sequences () will call Count_sequences () at least 2 times recursively, because each number has at least 2 neighbors. This will cause the runtime to grow exponentially.

It's possible to jump 1 times to 20 times, but to a bigger number, we're going to hit the wall. 500 times may require the entire universe of heat to complete the operation.

3rd order: Memory

So, can we do a better job ? Use the method above, and not. I like the problem, too, because he can bring out the wisdom of everyone and find a more efficient way. To find a better way, let's look at how this function is called, taking Count_sequences (6, 4) as an example. Note that this is simplified with C as the function name.

You may have noticed that C (6, 2) ran 3 times, each time being the same operation and returning the same value. The key point here is that these repetitive operations, each time you use their values, there is no need to calculate again.

How to solve this problem? Memory . We have those same function calls and results instead of letting them repeat. In this way, we can give the previous results directly in the back. The implementation method is as follows:

4th order: Dynamic Design

If you look at the previous recursive relationship again, you will find that the recursive memory scheme has a little limitation:

Note that the result of jumping n times depends only on the result of the call after jumping N-1 times. At the same time, the cache contains all the results for each number of times. I say this is a small limitation because it really does not cause a real problem, and when the number of hops increases, the cache is only linearly growing. But, after all, this is still not efficient enough.

What to do? Let's take a look at the scenarios and the code. Note that the code starts with the maximum number of times and then directly recursively to the minimum number of times:

If you think of the entire function call graph as some kind of virtual tree, you will find that we are executing a depth-first strategy . This is not a problem, but it does not take advantage of the shallow dependency on this attribute.

How to implement breadth-first strategy ? Here is an implementation method:

Where is this version better than the previous recursive version? It's not much better, but it's not recursive, so it's hard to crash even with super-big data. Second, it uses constant memory, and finally, it continues to grow linearly, even if 200,000 hops are handled in less than 20 seconds.

Evaluation

Here, the basic is finished. Designing and implementing a linear, constant memory scheme is a good result in an interview. In my interview, if an interviewer writes a dynamic programming design, I usually give him a very high rating: excellent!

when evaluating algorithms and data structures, I often say that the interviewer has a clear understanding of the problem and that he can improve and improve it quickly when he points out that it is not enough, and finally, a good solution is achieved.

when evaluating the code, I would ideally say that the interviewer quickly and accurately translates the idea into code, the code is structured and easy to read. All special cases are summarized and the code is carefully checked to ensure there are no bugs.

Summary

I know that this interview problem seems a little scary, especially the whole explanation is very cumbersome. But the purpose of this article is completely different from the interview. Finally, a little bit of interview-related skills, and some good habits to share with you:

• Be sure to do it manually, starting with the smallest problem.

• When your program is doing useless arithmetic, be sure to pay attention to optimization. Reducing unnecessary operations can make your solution more concise, and you might find a more efficient solution.

• Learn about your recursive functions. In real production, recursion is often prone to problems, but it is still a very powerful algorithm design and strategy. Recursive schemes also always have room for optimization and improvement.

• Always look for a chance to remember. If your function is purposeful and will call the same values multiple times, try to store them.

Recommended Today :

12 weeks, from 0 base to Python engineer

The great god of Linux to form a full guide

6 weeks as a data analysis and mining engineer

J2SE Core Development Combat

Python picture to character painting

Getting started with Go language programming

"Long Wen" Google interviewer to step through the analysis of their own before the leak of the face questions, super-dry and advice