How to form a development team

Recently, after more than a month's efforts, we finally signed a new project for the company, so we need to set up a development team for this project. After repeatedly screening resumes and interviewing for 50+ courses, the skeleton of the development team has basically taken shape. The following is a summary of the recruitment work during this period: because the development time of this project is relatively tight and the technology used is relatively new, the selection of developers should focus on relatively senior programmers as much as possible. At first, the requirement was more than 3 years' experience, and later, more than half of them were recruited, and they were required to improve to more than 5 years' work experience. I admit that this subdivision may be unfair to some programmers, and there will definitely be technicians who have not reached our working life. But because recruitment also takes time and cost, if you want to recruit more than a dozen programmers, you need to look at hundreds of resumes. This simple and rude method is often the most effective, at least in the first level, 80% unqualified candidates can be screened out. The JD of this position probably describes more than a dozen technical points. Of course, we hope that all candidates have relevant experience, but this is not realistic. From my personal experience, I will put the more important technical points in the first few. If these technical points are not satisfied, we will give up the candidate. Therefore, when you apply for a job in the future, you can refer to the company background and project background to infer the core requirements of JD, which will be more targeted. Interview is a process to examine whether the candidate is suitable for this position, and it is also a channel for the candidate to get to know the company and the project preliminarily. Interview is a very subjective process, and many people will evaluate developers according to their personal preferences. Therefore, many companies will first examine the technical ability of developers from an objective perspective in the form of written tests. Personally, I hate written tests, and I won't apply for a company with written tests. But as a project manager, I also know that the written interview with junior developers is one of the most effective means, but it is not suitable if the interviewed candidates are more experienced. Let's talk about the specific interview process first, because the interview is a two-way selection process. While you are examining the candidates, the candidates are also examining you. I think the recruiter is relatively weak in the interview process. Because we don't know the candidate, we need to try our best to see if the candidate is suitable. If the applicant is proficient in this field, it is easy for the recruiter to find a less suitable person. I don't think it's necessary to torture candidates domineering during the interview. I will interview in the usual way of communication. After all, business can't be straight. At the beginning of the interview, I will introduce myself first, starting with small talk, such as how the candidate came, how good the road is, what to look for, to eliminate the tension and let the candidate get into the state quickly. Then I will ask the candidate to introduce himself. The self-introduction here does not require the applicant to introduce the graduate school, major and company where he worked. Asking for an interview without reading your resume carefully is hooliganism! I will ask candidates to focus on the projects they have developed and the positions they are responsible for in the projects. After all, few resumes I have read will detail the structure of the project and the technology used. After listening to the introduction, I will ask the candidate about the project developed in detail according to the project experience, such as the specific implementation function of the project, the technology used, the number of users, the order of magnitude of the database and so on. By listening to these questions, we can know the candidate's familiarity with the project and infer his general position in the project. Then the corresponding intermediate personnel will ask some related questions according to the technical points used in the project; Senior staff will ask them to draw the frame diagram of the project with me and explain the design ideas. And in the architecture diagram explained by senior staff, I will ask some design or construction questions according to the architecture diagram, and at some point ask them how to improve the existing construction to avoid some problems or how to expand the existing construction. After this communication, we can have a general evaluation of the candidate's technical ability. Then some technical questions about JD related technical points will be thrown, and candidates will be asked to answer them. Questions may include basic knowledge, principles, extended use and so on. Some people will say that as long as such questions are prepared, everyone knows and is too lazy to answer them. But in my opinion, the recruiter belongs to the disadvantaged group after all. We need to make every effort to understand your technical ability. We can examine this ability by answering technical questions and writing code. And if you really want to apply for this job, making preparations in advance is also a kind of attention to our work. And this part will not be called an important factor for us to reject a candidate unless your answer is really unsatisfactory. (P.S. I did meet a random candidate in this interview, and I have five years of work experience, and my resume fits well. Then, for candidates with management experience, such as project managers or development team leaders, I will ask some management-related questions, such as project postponement, risk identification, developer management and so on. There is no standard answer to this kind of question, but here is the systematic thinking of candidates. Through such questions, we can understand your work style and the solutions when encountering problems. The more logical the candidates' answers to such questions are, the more aspects they consider, and the higher the evaluation they get. Finally, I will let the candidates ask us questions, so don't underestimate this part of the time. First, this part of the question is the most direct means for you to understand the company and work; Secondly, this part is also the basis for us to consider whether you want this job or not. Ask more questions in this part. If you ask well, you will definitely get great marks. From my point of view, I would advise candidates to ask some project-related and company-related questions; I will also answer candidates' questions seriously. If the applicant asks questions about the project cycle, progress, development technology, or the company platform and personal development, I think the applicant is more serious and responsible for his work and has a clear position for himself, so it is easier to adapt to the work. Finally, from my personal point of view, I want to talk about some points that need to be paid attention to in the interview. The first is attitude. Modesty is needed in an interview, but being too modest becomes modesty. If you are too modest and cautious, it will affect the interviewer's evaluation of you. I met a candidate with too modest attitude and average technical ability, which gave me the direct impression that he had doubts about his ability and finally gave up the candidate after comprehensive weighing. I suggest that the interview should have a correct attitude and face the interviewer with a normal heart; If you really meet an overbearing interviewer, go find a girl. There are still some jobs these days, so you can eat everywhere. The second is teamwork, which is the most important consideration in recruitment, at least I think so. Some candidates will inadvertently show aggressive and uncompromising personality during the interview. If I meet such a candidate, I will think about whether he is a qualified team player, whether it will bring any bad influence to the team, and whether such a person is difficult to manage. I don't rule out that such a person is probably a technical bull, which is why he is so unsociable. However, most of the projects we are currently facing are labor-intensive and need to be transferred according to Party A's wishes to a large extent, so even if such people are skilled, I feel that they are not very suitable for our projects here. I said a lot of nonsense, hoping to attract the attention of job seekers and recruiters.