Technical interview (2) How to prepare for the interview

1. Evaluate what talents the company and team need

Recruitment requires a clear understanding of the original intention, a clear strategy for examining software engineer candidates, and a clear plan in mind to "win first and then fight."

What kind of technical talents does the company and team need? This is the most basic question mark when we establish the entire interview evaluation system.

(1) Common ideas:

1. Those who can work and work overtime

This original intention is understandable, but it is very difficult to implement. Maybe in some industries this is true, but in the world of software engineering it's exactly the opposite.

People who hold this view divide the complex behavior of software engineering using a simple division of labor. In history, it is not that no one has tried this approach, but most of the attempts have failed, or the costs of other links have ultimately become so high that it loses the meaning of doing so.

For example, we can simply divide the software engineering process into several steps: requirements, design, implementation, testing, and maintenance. When we lower the personnel requirements in the "implementation" link and accordingly lower the quality requirements, then we will have to invest more manpower in other links to balance it. In the end, the R&D cost has not been substantially improved, but has been reduced. The implementation process lays hidden dangers, such as poor code design that creates pitfalls for future maintenance and expansion.

Such a balance may be to spend more time to complete more detailed design documents, it may be to add more test staff and perform more comprehensive tests, it may be to spend longer trial running versions and bug fixes, or it may be Recruit more dedicated managers to keep an eye on these programmers' strict compliance with the process.

Although I did not recruit with this idea in mind, due to some objective reasons, the recruitment was more of a large number of novices. And the veteran does not have the ability to teach, so forcing the newbie to teach will contaminate the bad habits of the veteran. The team is also in this dilemma. There is a huge difference in difficulty between developing a person and developing a team. Therefore, I want to put more energy, that is, more management costs and training costs, on the novices.

To put it bluntly, it means doing more work in other aspects of software engineering, and then paying for the poor implementation aspects.

 2. “The algorithm is good”

What started as an interview with a software engineer turned into a question-answering meeting to check your results.

The reason is very simple. To sum it up in four words, it is "to generalize from one part to the other".

Software engineering is a multi-dimensional and complex behavior, of which code implementation is only one part; and algorithms are only one part of code implementation. In fact, there is still a huge gap between being a simple algorithm expert and a real software engineer.

3. “Awesome”

If we understand "talented people" as "people with outstanding technical skills", does the team really need all kinds of talented people? I don’t think so. Compared to “great people”, the team needs “the right people” more.

Let’s start with a technical perspective. An ideal team needs to be technically complementary to a certain extent. For example, in a full-stack team, some members are good at the bottom layer of the system, and some are good at Web applications; some have rigorous system thinking, and some have keen product intuition. Then, whether in system design or problem location, the team's Decision-making can reach a certain balance by learning from each other's strengths .

Let’s look at it from a non-technical perspective. Even if the candidate is impeccable on the technical level, we still have many non-technical factors to consider; even if the candidate is impeccable on the personal non-technical level, we still need to consider the fit between the candidate and the team's style. For example, some people who are particularly skilled in technology have more distinctive personalities, or are difficult to get along with. Should we say yes or no to such a candidate?

It involves a company’s culture and team acceptance. It is obvious that if a team is full of "thorny heads" and there are fierce collisions of opinions, this will definitely be a bad situation. It is likely that the manager will be busy settling conflicts every day; and if a team is full of "thorny heads", "Good old guy" only has praise and recognition of opinions. This is actually a worrying situation, because the lack of opinions often means the lack of decision-making power.

4. Smart and potential”

Whether it is a company or a team, there needs to be a certain balance in the composition of experienced engineers and potential engineers.

Some teams are relatively mature in technology, have a stable structure, and have solid processes. Experienced engineers can have a certain amount of time to guide and help newcomers grow, and the team can cultivate its own backbone. Then such candidates can be said to be the best.

On the other hand, some teams are on the contrary, especially some entrepreneurial teams or product start-up teams. Everyone has to play a leading role, and even everyone is busy putting out fires. In this case, it is particularly necessary to have strong self-management ability, comprehensive quality and experience. veterans, such candidates are not suitable at this time.

Our company's development team belongs to the second category and needs to change this situation urgently.

(2) Investigation angle

What kind of technical talents does the company and team need? In other words, reflected in the interview, from what angle should we examine and select talents? How to grasp the dimensions of software engineer candidate selection from a macro perspective?

1. Commonly used angles

The commonly used perspective is a common and objective understanding of an excellent software engineer.

(1) Technical level

On a technical level, we need to examine the basic skills of software engineers. Including: practical problem solving ability, code design and implementation ability, system analysis and design ability, testing and verification ability .

a. Practical problem solving ability

I don't agree with using more simple algorithm and data structure questions in interviews. It’s not that it’s not investigative, but that its coverage is too narrow. Specifically, the solution to a typical practical problem needs to include two parts:

• 1. Abstract specific problems into several solvable software problems;
• 2. Use software engineering knowledge and skills to solve these problems.

Pure algorithm and data structure issues not only can only solve the second of the above two points, but this second point must also be a problem that falls on the coding level or even the mathematical level, which shows its narrow coverage. As for what kind of question is a good interview question.

b. Code design and implementation capabilities

 This is a basic skill for software engineers. It covers a much broader scope than simple algorithms and data structures. For example, object-oriented skills that some companies particularly like to examine fall into this category.

c. System analysis and design capabilities

Including whether a reasonable system estimate, architecture design, etc. can be given for the problem. This part is closely linked to experience.

Generally speaking, rich work experience should mean certain system analysis and design capabilities. We can simply think of it this way:

 The "system" mentioned here generally refers to "software system" rather than "distributed system."

Today's Internet wave has also brought some unfavorable effects to technical people, such as the excessive pursuit of hot words such as "distributed". It seems that when it comes to systems, it means big data, massive volume, and high throughput. Some simple systems are not looked down upon. I think this is very inappropriate.

For the understanding of the system, just like the foundation of mathematics is elementary arithmetic, we still need to lay a solid foundation.

d.Other comprehensive engineering capabilities

 Such as testing and verification capabilities, etc. It’s not that they are unimportant, nor that we don’t examine them, but that we should focus on the technical examination of software engineers during interviews. For example, we can simply agree to spend only 20% of the technical inspection time in this part.

Where is the basic computer knowledge test? In fact, it is contained in the above-mentioned inspection items.

For example, to design a website system, you need to have a basic understanding of network protocols, especially the HTTP protocol, a basic knowledge of middleware and containers, and a basic understanding of databases.

(2) Non-technical level

 We focus on engineers’ basic character, teamwork ability, learning ability, communication ability, task management ability, etc.

For example, during an interview, if you find that there is a big problem in communication with the candidate, then you can't help but notice this, and there is no need to specifically ask a question that "specifically" tests communication skills.

In summary, for software engineer candidates, the interview rounds should ensure that most of them are covered in the form of technical interviews, while a small number are allowed to be covered in the form of non-technical interviews (for example, 4 rounds of technical interviews out of 5 rounds, 1 round of non-technical interviews). However, the data obtained from each round of technical interviews should cover both.

For engineers who have just entered the workplace, they should pay more attention to qualities related to potential, such as whether they can listen to suggestions and think about it, and whether they have interest and enthusiasm, because this is something that cannot be learned .

For engineers with rich experience, more attention should be paid to vision, depth of technical understanding, and professionalism.

2.Other angles

It refers to different teams and subdivided positions, which have different requirements for software engineer candidates.

At the technical level, for example, some positions require front-end skills, some positions require an AI background, and some teams require work experience in cloud computing.

At the non-technical level, many large companies will set several specific guiding principles. These principles are like a program to guide the process of evaluating the non-technical parts of candidates. For example, Amazon’s leadership principles have been discussed by many people in the past few years. Every interview round at Amazon is required to cover one or two of them.

Even if a specific segmented position has more detailed and clear requirements for skills, we can still find that for interviews with large companies, the proportion of common angles is often larger.

It is obvious that the more subdivided the position and the more specific the requirements, the more likely it is to improve the matching of candidates, but this also reduces the universality of talent screening and makes recruitment extremely difficult. Therefore, these large companies provide vague recruitment standards and choose to further train them after recruiting them. This is both deliberate and helpless.

A software engineer who performs well in the "common angles" part of the interview is more likely to be an excellent software engineer in the general sense. Even if he does not immediately possess a certain skill for a specific position, after a short period of study and Fitting in, he's also likely to be able to fill the role quickly.

For any company or team, it is not about recruiting "good people", but "appropriate people". Our biggest goal is to win together with the candidates, rather than simply cost-effectiveness.

2. Make an interview plan 

(1) Plan analysis

First, understand your team’s needs and constraints and set reasonable expectations. We certainly don’t want to hire the wrong people, but we also don’t want to miss out on good and right people.

What we need to make clear is that adequate investment in time and labor costs, and reasonable coverage of inspection angles, are two completely different and essential things. The effect we hope to achieve is that through sufficient investment, the interview team obtains more comprehensive data that can help evaluate candidates, but without excessively repeating coverage of a certain angle.

If the process is correct and the data is sufficient, the results will be reasonable.

Thirdly, the inspection angle, inspection focus, and inspection content must also comply with the principle of consistency.

Finally, inspection rounds need to be progressive.

When we understand the needs of the team and the perspective of the investigation, and sort out the candidates and plans, although the real interview round has not officially started, it is already half the battle.

(2) Telephone interview and on-site interview

The biggest role of telephone interviews is to "filter out" those who are obviously unreliable at a relatively small cost.

In the plan, there are usually fewer rounds of phone interviews (1-2 rounds). Therefore, the phone interviews should be able to cover the content that we are most concerned about. Decision-making during telephone interviews is usually very quick. The interviewers of the telephone interview meet each other. If the interview passes and the hiring manager feels that there is no big problem, then you can continue to the on-site interview.

If you are hesitating whether to pass the telephone interview, then: Do you think the candidate can properly pass at least one on-site interview? If possible, go for a phone interview.

From a non-technical perspective, we should focus on whether the other party has some clear requirements and whether they match what the team can provide . For example, if this position requires traveling abroad, and the candidate cannot accept this, then it must be communicated clearly before the phone interview or in advance to save everyone's time.

(3) Fresh graduates and veterans

Fresh graduates and veterans are two completely opposite types of candidates, and the focus of our examination is different.

For engineers with little experience, we value potential more;

For experienced engineers, what we value more is ability, which can be seen from the requirements for system design capabilities.

1. Interview for fresh graduates:

• Generally speaking, for fresh graduates or campus recruitment, our time investment can be appropriately reduced.
• System architecture and design should not be the main examination content. Understanding the system is a process that requires time and experience to gradually accumulate.
• Reduce the examination of engineering understanding. If you examine fresh graduates' understanding of project and task management, their understanding of software engineering is often of little significance, for the same reason as above.
• Increase the proportion of "potential qualities" such as interest, enthusiasm, learning ability, and the ability to accept opinions . In a word, do you think he can grow quickly with the help of the team and be promoted to a senior engineer quickly?
• According to the perspective of investigation, a relatively clear and specific demand can be given.

2. Social recruitment interview:

• System architecture and design can be the focus of investigation
• Questions can be vague to test thinking and whether the ideas are rich

3. Problem Design

(1) Bad technical problems

 1. Knowledge-based questions , testing knowledge and memory, rather than any core competency of an engineer. Not suitable for spending a lot of time investigating. Because on the one hand it is not universal, on the other hand it is too random.

Lack of universality means that candidates must understand specific frameworks or libraries. Considering that excellent candidates have different knowledge backgrounds, this requirement is too arbitrary;

Too strong randomness refers to whether the candidate knows this knowledge point. The randomness is too strong and does not reflect the candidate's skill level.

There are some problems that are limited to specific programming languages, frameworks and libraries. One of them is the problem.

"Please implement the atoi algorithm in C++."

This question is fine if the team requires candidates to have C++ skills; but for most teams, this is not the case, so this question is unfair to candidates who usually use Java as their main programming language. This is why many major companies have a guiding principle for interview process training: do not limit the programming language used by candidates .

 2. Too common questions

Questions that have been used too many times are likely to have been prepared by the candidates, which greatly reduces the authenticity of the investigation. Honest candidates will tell you that I have done this question, but you cannot expect every candidate to do this.

On the contrary, we precisely want to examine the candidate’s “old” abilities through “new” questions. This is why we say that problems are ever-changing, but routines are eternal.

3. The problem of overly complex rules

The simplification approach to complex problems is closely related to the inspection items.

And it is far away from the actual problems we want to solve and our work scenarios. It has neither business coverage nor technical coverage, and its value in technical interviews is actually very low. For example, some brain teasers.

(2) Design principles for technical issues

 1. Be consistent with the inspection angle and focus

 Focusing on the interview plan and interview objectives, we can obtain effective investigation data so that we can make decisions after the interview.

For example, an interviewer wants to conduct interviews with candidates, focusing on "solving practical problems and understanding the system." So, he decided to use a "design of online ride-hailing system" question as the main question and discuss it with the candidates during the interview. So, from here we can roughly see that the interviewer needs to grasp these two key points:

• Solving practical problems: The interviewer intends to give practical problems and pay attention to whether the candidate can gradually pass the skills of an engineer and solve the core practical problems of this "online ride-hailing" (such as Didi Taxi, which is an actual system) parts, simplified and abstracted into software problems and solved.
• Understanding of the system: After discussing the requirements with the candidate, the interviewer plans to ask the candidate to design a software system to implement it. During this process, the focus will be on whether the candidate has system design skills and whether he can solve the problem according to the problem. features and make appropriate technology choices.

 2. From fuzzy to clear, from practical to abstract

It is understandable to go from vagueness to clarity, but what does it mean to go from reality to abstraction? Shouldn't it be from abstract to practical? It can only be realized if it is put into practice!

Software engineers are meant to do engineering, and engineering, in essence, is about solving practical problems.

From vagueness to clarity, and from reality to abstraction, they seem to be two processes, but in fact they are exactly the same:

Actual problems are often vague. It may come from a complaint from a customer, a suggestion from a user, or an unclear pain point;

The problems that can be solved by software approaches must be clear and simple. If even the designers of the software themselves cannot clearly explain the requirements and logic, implementation will be impossible. Since they can explain clearly, this description must have been simplified. and abstraction, stripping away the minutiae and retaining only the core of the problem.

Therefore, only some core parts of a specific problem can be solved by software, and most of the rest can only be used as a foil. This principle actually talks about "depth" .

The interviewer asked the candidate technical questions like this:

“请你设计一个网约车系统。”

After some candidates get the problem, they will be at a loss, "Oh my God, where should I start?" Yes, this problem seems very big, but it is also a practical problem that engineers have to solve, often Vague practical issues.

We hope to work with the candidates to create such a transformation process from fuzzy to clear, from practical to abstract. Take the inspection path of system design as an example:

• Based on the vague statement, what is the core problem we want to solve ? The online ride-hailing system is so big. Among the problems to be solved, which type of problems are we most concerned about?
• Based on the issues of greatest concern that we have identified, relevant functional requirements and non-functional requirements are listed . Requirements can be many, and our goal is to identify those that matter during the interview time.
• Design the system according to the needs, including all layers from client, network, service to storage, etc. After having a rough plan, our goal is to select a small part of it that we are most concerned about for discussion.
• If you still want to examine the code level, then select a certain component or mechanism from the above design to discuss the code level design.
• According to the design at the code level, you can choose to implement it. For example, you can require the implementation of core logic, core data structure, etc.

 As you can see from this, the whole idea is this:

                                            Problem > Requirements > System Design > Code Design > Code Implementation

 For the sake of operability, each step forward will narrow the scope and examine candidates' skills at different levels in depth. More than one angle of investigation, more than one solution.

"More than one investigation angle" refers to the same vague description at the beginning, which can be gradually guided to a specific investigation angle according to the arrangements in the interview plan. This principle actually talks about "breadth" .

If the focus of the inspection requires us to take a path of examining data structures and algorithms , that is also possible, such as a simple pathfinding algorithm from the starting point to the end point, and implementing it into the code; we can also take the path of object-oriented design inspection and design key use cases. The classes involved, including their structures and relationships, etc.

"More than one solution" means that at a lower level, after refining to the above-mentioned specific questions, the answer should not be unique, but there should be multiple different methods. For example, for path-finding algorithm problems, we can sometimes use brute force backtracking to solve them, sometimes we can use optimized dynamic programming methods to solve them, and so on.

The more experienced the candidate is in software , the more we can give him a vaguer problem and try to let him lead the process of decomposition and refinement;

For school enrollment , we can give a relatively clear and specific demand. Of course, in this process,

If it is found that the difficulty is too high, we can actively give tips or help him complete part of the process, which is within a reasonable range.

(3) Design skills for technical issues

 1. Design problems from familiar areas

What kind of problem do you still feel in control of, even when discussing it divergently? It must be something you are familiar with.

2. From shallow to deep, expand in layers

"Please design an online ride-hailing system."

After the question is raised, some candidates can calmly communicate further and clarify the problem, while other candidates need step-by-step guidance from the interviewer - "What does this question specifically include?" Yes, this is exactly an analysis and analysis. The process of refining requirements requires discussion between the candidate and the interviewer.

We can think from the perspective of core use cases, think about what roles there are, and what functions can be accomplished through the system, for example:

• Passengers can request a ride anytime and anywhere;
• The system looks for nearby drivers and forwards the request. If it cannot accept the order, it continues to expand the search scope;
• Drivers can grab rides, that is, accept or reject ride requests;
• Both parties can refresh their positions on the map and view each other's current positions;
• During the waiting period, both parties can view each other's information;
• Both parties can check each other's ratings and rate each other after the ride is completed;
• ……

So we can choose one or a few of the most essential functions to continue discussing with the candidates. After all, interview time is limited and we can’t bite off more than we can chew.

After the functional requirements are clear, we also need to discuss and determine several important non-functional requirements before entering the design step. For example, how many users are there, how many requests are there every day, etc. These values ​​do not need to be precise, but the order of magnitude of the values ​​will affect the design of the system.

The candidate and the interviewer sort out the problem layer by layer together, transforming a vague problem into a simplified business problem, leaving only a limited number of demand points to be realized.

The next step is to consider how to implement it from a technical perspective based on the previously selected demand points; as for technical implementation, we still need to adhere to the same principles, from vagueness to clarity, and gradually refine:

• Looking at the entire system, what are the components or services? (Component calls and dependencies)
• Putting system components and user roles together, how do passengers and drivers interact with the system? (Interaction timing relationship)
• What responsibilities does each service have, and what technology is used for data storage in the system? (storage layer design)

After having a generally feasible system design, select a layer, a component, or a mechanism to further refine and expand it.

For example, in terms of storage, if the candidate proposes to use relational data to store the location information of passengers and drivers, then we can develop it through this idea:

• What table structure do you plan to design to store such information?
• Are there any hidden dangers in such a solution? What problems may occur after the product is launched?
• How do you plan to solve such a problem?

3. Set the highest difficulty level that can be reached by tiptoeing 

Different candidates have different abilities, and the progress they can make on the same problem is also different. The depth of the problem must be hierarchical, gradually refining the problem, peeling off the cocoon, and finally implementing it into a partial implementation that can be completed in a short period of time.

If it is noticed that the question is difficult for the candidate, the interviewer needs to make dynamic adjustments to reduce the difficulty. This can be done by giving question tips, proactively reducing the scope of the question, weakening the question requirements, or even directly promoting problem analysis.

And if the problem is too simple for the candidate, then the time allocation in the process should be compressed and more time should be spent on "follow-up" discussions for further improvements after the problem is solved.

If an algorithmic problem is to implement pre-order and post-order traversal of a binary tree using a non-recursive algorithm, and the candidate seems clueless, then we can:

• Give a question prompt : "What kind of data structure is a binary tree? What are the definitions of pre-order and post-order traversal?";
• Reduce the scope of the problem : "Let's just implement preorder traversal first!";
• Weakened question asks : "What if we could do this using recursion?";
• Advance problem analysis : directly introduce the idea of ​​​​preorder or postorder traversal and use non-recursive implementation.

Whether through hints or explicit suggestions, we will continue to deepen and overcome the challenges of each layer of increasing difficulty. The most ideal effect is to reach the highest difficulty of this mini-project, which is exactly the difficulty that the candidate can "reach on tiptoe" , neither too simple nor too difficult to achieve.

It's too simple and boring, and candidates will also feel that the company and team are not very good;

If it is too difficult, it may have a great impact on the candidate, or cause him to be unable to complete the entire problem-solving process.

We can use the above four methods to guide candidates to clarify their ideas until they can start coding.

This dynamic adjustment process requires the accumulation of experience in order to be able to control it freely. But we can set such a goal from the beginning. We hope that candidates of different levels can be "happy when they come and can't stop thinking about it when they leave."

4. Continuously collect data and adjust your questions

“Continue to collect data and fine-tune your questions.” Just like how to do any complex thing well, it needs to be tempered. After a problem is designed, we must use it in practice repeatedly.

On the one hand, data can be obtained continuously. Such data can help you establish your own "coordinate reference system" . When evaluating a new candidate, we know where he is roughly; on the other hand, Problems can be adjusted, improved, or even replaced based on the results, including increasing or reducing the scope of the problem appropriately according to the situation, etc.

Using a problem of your own design will also bring a certain "freshness" to the candidates. Do this mini project and solve a novel and interesting problem instead of searching a lot of them on the Internet. It felt like this was something that came easily, but what he didn't know was that this question was carefully prepared by the interviewer and tempered in practice.

5. Broaden the breadth and set up multi-angle extensions for the problem

“如果你所在的团队拥有一个重要的 service，它的平均请求响应时间为 1 秒，有一天你部署
了软件新版本后，留意到它的平均请求响应时间异常地增大到了 10 秒，你该怎么做？”

Extension 1 - Examine the understanding of user experience and engineering : What should we do in the first place to minimize the impact on users? We might talk about rollback, then we can talk about Ops. How to avoid this problem in the future? This allows us to discuss the software engineering process, quality assurance, CI/CD, grayscale release, etc. This extension can examine aspects of the software engineering process and aspects of Engineering Excellence.

Extension 2 - Examine the design of monitoring and alarm systems : How can we know that there is a problem with our system as soon as possible? This can talk about software monitoring and alerting. What kind of data do we need to monitor and alert? How to collect data, how to send data, that is, how to design an alarm system? This extension can be further refined to a monitoring system design issue, or a code-level inspection.

Extension 3 - Examine problem-solving ideas and systematic understanding : How should we locate the problem, and at what level may the problem occur? For example, maybe the service is fine at all, but there is a problem with the client, or there may be a problem with the network, or it may be a problem with the service. As for service problems, what are the possible causes? What strategies can be adopted to locate the problem layer by layer from high to low? This extension can continue to examine the candidate's understanding of the system, especially through a request and response process, to examine his understanding of the full stack of the system.

Extension 4 - Focus on a certain layer of the system : By refining to a certain layer to further expand, there are many ideas in this part. We can choose several common entry points according to needs. For example, if the problem is caused by too slow statements in a relational database, we can further focus here and discuss the causes of some common relational database performance problems and corresponding solutions. If it is an application-level problem, such as insufficient memory in the application, then you can further expand from this perspective.

Extension 5 - Focus on the system current limiting problem : If the problem happens to be caused by a certain client sending too many requests in a short period of time at that point in time and the system being unable to process them in time, then we can start with flow control. Angle expansion. The problem of flow control is also one of the classic system problems, which can be examined from the perspective of system design or code design.

You see, a vague practical problem can be extended in many directions, and these extensions are closely related. We can choose one of the extended angles to investigate during the interview as needed.

6. Balance the depth and breadth of the investigation

If we can always investigate technology, starting from a simple and vague practical problem, gradually deepening it, and finally ending with a complete problem-solving process, then it can almost be said that we have achieved both depth and breadth.

Why don’t I recommend using simple and crude algorithm questions in interviews? In the final analysis, it is a matter of investigation. Simply examining algorithmic questions is an example of sufficient depth of investigation, but it is easy to lose the breadth of investigation.

There is an interview style that asks the candidate to talk about a project that he is most familiar with or is most proud of, and then grabs certain points from it and keeps digging deeper. This itself sounds like a pretty good idea for the investigation. It’s exactly the opposite of the interviewer’s idea of ​​preparing questions we talked about earlier – the candidate leads the process.

But in reality, I generally don’t recommend the above method to interviewers with little experience. The main reason is that in practice, this method requires very high quality of interviewers: if the project or system the candidate talks about, the interview If the interviewer is familiar with the interviewer, then everything is easy to explain. However, if the interviewer is not familiar with it, it will be difficult for the interviewer to grasp the key points here, and it is easy for the interviewer to be led by the candidate. Maybe the candidate in this round of interviews has been speaking in general terms, talking about There are many aspects, but the interviewer can't ask any sharp questions.