"Let's Talk About Interviews and Recruitment" | Sanvi

This article is Lu Canwei's 25th original piece.

The previous article mentioned a viewpoint about whether technical managers should become technical experts, and many friends shared their opinions.

In fact, I would like to add some points to the previous article. If your team has fewer than five members, and they are all technical in a specific field, then as a technical manager, you should be the most knowledgeable in this area. This is because most of your team members are likely to be inexperienced, so you need to help them solve technical difficulties.

If your team size exceeds five people and consists of different technical fields, you should consider the overall situation and focus more on the team itself.

As a technical manager, it is easy to fall into the trap of being a jack of all trades but a master of none. I have also noticed this issue in myself. Although I am a full-stack developer and can do everything, as the scale of the enterprise grows, you will lack core competitiveness. Therefore, it is essential to combine multidimensionality with the T-shaped talent theory; your breadth must be supported by a certain depth. For example, I previously had very senior experience in Android, but I did not continue to delve deeper, lacking higher-level hard skills, and my backend capabilities also lacked competitiveness.

Although I previously mentioned that the team should be the primary value output, you also need to step outside this concept. If there is no team, do you still have competitiveness? For instance, in the NBA, when a team performs well, everyone praises the coach for achieving good results. When the team performs poorly, everyone calls for the coach to be fired. Everyone should think carefully about where their core competitiveness lies.

Returning to the title, I have recently been continuously challenged and feel that I am not far from learning how to build rockets.

This is also a common joke about interviews where one is asked to build a rocket but ends up just tightening screws.

I have found that different companies have different definitions for the role of R&D Leader, which can be seen from the interviewers' assessment points. However, from my experience, at least 80% of them are primarily looking for a research and development engineer.

At this point, I need to discuss the roles of technical personnel: CTO, Technical Director/R&D Director, R&D Leader, Architect, Senior R&D Engineer.

Do you know the differences between these positions?

Senior R&D Engineer: The team size should be fewer than five people, and they can lead 1-2 assistants to implement planned features. They are the main contributors and personally tackle technical challenges. For example, they handle core feature development, difficult bug fixes, etc. This position is more technical, primarily focused on implementing product functions.

R&D Leader: The R&D team has fewer than 15 people, and you have 1-2 senior R&D engineers. At this point, their main focus is on improving team efficiency, such as task management, enhancing production quality, and professional development within the team. This role is already leaning towards management, primarily focusing on the team's product, including interviewing and guiding new hires.

Technical Director: The team size exceeds 20 people and has multiple product lines. At this point, there is a need for some common technical platforms to enhance the efficiency of the R&D teams across several product lines, as well as to coordinate and manage different product line groups. This role is purely managerial, focusing on improving the efficiency of multiple teams, establishing technical middle platforms, and creating common development tool frameworks.

Architect: When the team size exceeds 100 people, you need someone to handle overall architectural planning and design. The R&D Director and R&D Leader should not be responsible for this; they are more focused on personnel and project management. The main tasks at this point include technology selection, risk identification in technical architecture, workload assessment for technical implementation, and implementing underlying technology frameworks, as well as planning for core system architectural upgrades.

CTO: Once your architect team is established, you will need a CTO who will manage comprehensively across business, product, technology, management, and team aspects. The main tasks at this point are to drive business growth through technology products, capture new business opportunities, develop strategic planning, and ensure that the business and technical teams collaborate on innovative explorations, improving business processes from a holistic perspective, and building the R&D team's hierarchy.

III

In my many years of experience, I have interviewed many companies, interacted with numerous interviewers, and have also been an interviewer for many candidates.

From my current perspective, 80% of interviewers are not well-prepared for their roles.

Lazy Interviews

I believe that most Java developers have encountered questions about HashMap. Interviewers often find interview questions A, B, C, D online to ask you. If you know the answer, you pass; if you don’t, you wait for a notification. To some extent, I don’t quite understand the significance of this. As an interviewee, you find a set of interview questions and memorize them. The interviewer finds a set of questions to memorize, and once the candidate answers, the interview ends.

Taking the HashMap example again, everyone knows that HashMap uses an "array + linked list" data structure. But why use this structure? What problem does it solve? What issues can arise from this structure, and how has it been optimized? Why is the length of the underlying array in HashMap always a power of 2? What is the significance of a load factor of 0.75?

Unfortunately, most interviewers only ask what HashMap is, an open-ended question, and then look at you thoughtfully, giving you the illusion that you haven’t answered well, when in fact the interviewer may not be clear themselves—this describes the kind of interviewer I am referring to.

Another type is: "Do you know A?" "Yes, I do." "Do you know B?" "Sorry, I don’t." "Then wait for a notification."

I found some interview questions, and this candidate answered more than half of them. Although I don’t know if he truly understands, I can’t delve deeper since I also don’t understand; it seems acceptable, so I move on to interview someone else.

I wonder if the rise of LeetCode has led to a trend in algorithm interviews, where everyone rushes to solve algorithm problems, seemingly completing a certain number of questions and then receiving offers from big companies. Many interviews start with algorithm questions, but how many of these are actually relevant to the job you will perform?

Additionally, there are requests like "design a flash sale system" or "design a red envelope system." Are there any specific requirements? Just what you see online; high concurrency has become a standard in interviews—then wait for a notification.

Why do I call this lazy interviewing? Because they do not differentiate between you and others, do not look at your past experiences, and do not understand your other abilities, such as communication, learning, management, problem-solving approaches, etc. They attempt to use a single standard to filter candidates, ultimately leading to companies being unable to recruit excellent talent, and talented individuals being unable to find suitable companies.

In my years of interviewing many people and hiring a large number of excellent candidates, I have also interacted with many outstanding interviewers and learned a wealth of screening experience from them. Many resumes that seem subpar are often dismissed by HR as having poor work experience or backgrounds, yet those individuals can achieve excellent results in their roles after joining the company.

So how should we assess a technical candidate?

The two main points I focus on are:

Past experiences, which you can understand as what they have done, how they did it, and why they did it. Future potential mainly refers to their thinking patterns, learning abilities, and sense of responsibility.

Past Experiences

For past experiences, I mainly assess what the candidate has done before, such as what their projects were about, which parts they were responsible for, and what they accomplished.

Essentially, it involves discussing their projects, from business functions to technical architecture to the implementation of specific features and the problems encountered along with their solutions. This will filter out a batch of candidates who cannot clearly articulate what they have done.

Then you can focus on a few points that you care about and ask questions, as each company has different scales and situations. Try not to ask questions based on your subjective views; all architectures and designs are based on the most reasonable structures designed for the current state of the company.

You can design questions based on their responses, asking how they would optimize things, such as increasing data volume, handling service failures in the architecture, or sudden spikes in traffic, etc. The focus is not on whether their answers are reasonable; if there are errors, you can guide them with hypotheticals, allowing you to assess the candidate's problem-solving approach and their technical understanding limits.

Future Potential

Often, a candidate's work experience does not align perfectly with the current job's tech stack.

For example, React and Vue are two major camps in frontend development. As an interviewer, if our company's tech stack is React, should I ask if you know React? If you don’t, does that mean you shouldn’t come for an interview?

At this point, you should focus on a few aspects to understand the candidate's situation:

Logical Ability

Although I mentioned algorithm questions above, what I really want to express is not to pile up algorithm questions. Practicing questions is fine, but you need to understand why you are doing it. As an interviewer, you can present an algorithm question and then ask the candidate to explain their implementation thought process, followed by implementing a version. You can then increase the difficulty or ask the candidate if they have a more optimized solution, providing some hints to guide them. At this point, you can review the candidate's implementation.

Here’s an example I experienced: for instance, obtaining a deduplicated array from a sorted array [1,2,2,3,3,3]. Later, based on my response, the interview question was adjusted to place the sorted array at the front, changing it to [1,2,3,2,3,3,3] to assess your problem-solving thought process and implementation.

Another aspect is the ability to understand the business. For example, you can present a problem you have already solved and ask the candidate to propose a solution, gradually increasing the complexity of the problem. Finally, you can compare it to your own solution for judgment.

Here’s another example: the question was about designing a read/unread feature. After I completed the design, I was asked how to save space. After I provided a space-saving solution, I was asked how to ensure the correctness of data when there are changes in the group list.

Basic Abilities

This is easy to understand; you need the basic abilities relevant to the position you are interviewing for. However, many people fall into a theoretical knowledge response. It should be more about assessing the candidate's mastery of the knowledge point and its practical application. Taking the previous HashMap example, you can discuss HashMap, then move to locks, from locks to transactions, from transactions to distributed systems, and from distributed systems to service discovery, etc., extending into different areas like databases, caching, message queues, and so on.

Additionally, as mentioned earlier, high availability can be discussed starting from a single-point service functionality, gradually extending to microservices, distributed issues, message compensation, traffic peak shaving, etc.

Often, it’s not that the candidate doesn’t understand; it’s very likely that you are not asking the right questions. You might consider adding a phrase like "Is my explanation clear?" after your question to inquire with the candidate. When the candidate responds that they don’t know, it’s very possible they haven’t even understood your question. At this point, consider giving the candidate some patience and guidance.

Problem-Solving Ability

This area focuses more on assessing how candidates respond to scenarios and handling solutions under special constraints.

For example, I once encountered a very interesting interview question where we asked candidates to create a login feature for Instagram. A significant number of candidates were unable to complete it simply because they couldn’t access Instagram’s documentation. This conclusion may seem a bit subjective, but in the workplace, many problems require you to solve them independently, and not just through technical means.

Additionally, you might ask about how candidates resolve collaboration issues during project cooperation, such as cross-team collaboration or front-end and back-end cooperation issues. This can reveal whether the candidate has thought about how to address these non-technical problems or if they just pass these issues to their boss.

---

We are all moving quickly now, for example, using recommendation algorithms to find things we are more interested in, or using remote interview tools to increase our interview efficiency, etc. We are all trying to use technology to solve all our problems.

But have we stopped to think about whether we are truly finding the right people through these tools? If the interviewer is not prepared and does not have a clear picture of the person they want, no matter how good the tools or channels are, they cannot solve the recruitment dilemma. Is there a way to address this issue?

1024, may every programmer be able to slack off in their favorite position.