After watching job-hopping, talk about 5K less, and talk about how front-end development should prepare for the interview from the interviewer’s perspective

The focus of the interview

This year's front-end development engineer interview, many people are quite confused, 1. Worrying about the impact of the epidemic, the difficulty will increase. 2. The new knowledge of Vue and other frameworks increases, will it be tested in the interview?

In fact, it did not have much impact on the epidemic. This year’s interview survey focused on the basics (technical knowledge and programming principles), rich projects (project experience and details), understanding of the work process, and good interview presentations.

In fact, the interviews for these interviews are almost the same as in previous years, but many students don't know how to prepare. Let me talk about how to prepare based on the basic process of interview recruitment. You can prepare in advance according to these aspects.

Interview questions

Basic knowledge not only needs to know what it is, but also how to use it and why it is used in this way. Rote memorization can cope for a while, if you meet an interviewer who wants to talk in depth, rote memorization is useless. Therefore, every knowledge point must be understood thoroughly and clearly stated.

The interview questions can only deal with 1-2 faces. Although it is important to brush the questions, it is also necessary to prepare for the project. Generally speaking, the current interview questions can be prepared as follows:

JS basic / advanced related
HTML / CSS related, there are really very few questions in this regard
Browser / performance optimization / engineering related
The use of the framework is related, that is, the basic problem
The principle of the framework is related. Even if you haven't read the source code, you still have to know its principle. The current interview is basically difficult to do without the principle.
Computer related, such as algorithm/data structure/network, basically these three, plus an operating system at most

The above is the general range. You can categorize the topics accordingly. Of course, there will be other issues besides these, such as design patterns and so on. In addition, brushing the interview questions is only part of it. If you can only apply it mechanically, it will not be useful if you change the question a little bit. A better way is to internalize these contents, understand why this problem should be solved in this way, and integrate it with your own project. For example, performance optimization has been done in the project, then you can talk about the relevant performance optimization answers.

Here are some interview questions I compiled, friends in need can go and see:

How to talk about the projects done

Talking about the project experience is the most important point in the interview process. Even if you answer the previous questions well, the project experience will still be cool.

The first purpose of the project inspection is to confirm whether you have done the project, and the second is to understand your technical depth, whether you have done it, even if you still have your own thinking.

The questions investigated are generally divided into the following points:

The content related to the project foundation, such as the technology stack, functions, and business-related issues involved.
The specific details of the project, such as how you implemented this function, why you did it, and so on.
Investigate in-depth questions. For example, did you encounter any problems when you were working on this project and how to solve them. In addition, it may be combined with the above interview questions.

Based on the above points, you can prepare the project Q&A like this:

1. The content related to the technology stack involved in this project, whether it is basic or in-depth, because here is likely to ask about the framework principle.
Think about whether there are any difficulties encountered in the process of doing this project, and how to solve them in the end. If you really can't remember, you can check Git Commit.

2. Has this project done some optimizations, including code, development efficiency, performance, experience and other related fields.

3. Some problems in this project and possible solutions.

4. The final result of this project.

5. What is the growth that this project has brought to you, let alone of course let me learn such worthless content as XX API.

6. In addition, the project should also be combined with your resume, because the interviewer will ask you questions that the project must be derived from your resume. The following will write about how to write project experience in your resume.

Prepare your resume

The resume is not used to keep track of your account. List a bunch of technical points, what tasks you have accomplished, and your self-evaluation is not of much value, but it creates a stinky long resume.

You can modify your resume according to the following points:

1. Control the number of resume pages to less than 2 pages. The longer the resume is written, the more powerful it is, but the content is used to attract others.

2. Write the technology stack in accordance with the requirements of the employer and the fields that you have but others do not know how to do, instead of listing the technology stacks in large lengths. If you are familiar with React, people will assume that you are familiar with the three front-ends, not to mention writing code with an editor, submitting code with Git, and requesting data with Ajax, leaving the space originally used to list these technology stacks to the more important ones. Project bar

3. When writing the project experience, just take out the key projects and introduce them. You don't need to list all the projects you have done. The specific content can refer to the Star law, that is, what has been done and what results have been obtained. What kind of result is the most important thing rather than listing what tasks you have done. Using data to quantify your results is a good way. If you don’t know how to quantify, you can learn more about how your superiors write PPT and draw pie. For example, if you want to increase your daily activity, then there will definitely be a specific increase value, which is quantifiable.

4. Consider the words familiar and proficient, and don't dig holes for yourself. Finally, make sure that every technical point written on it can say something by yourself. Don't ask the interviewer to ask you a technical point but only answer it.

5. Don't use Word format, it is prone to problems, PDF is a better choice.

6. It is not recommended to use templates. It is either fancy or the logo of the recruitment website. Just write it in Markdown and transfer it to PDF directly.

7. File naming format: name_required for job position

How to chat with HR, such as talking about money, etc.

First of all, you met with HR, indicating that you have basically become one of the candidates. At this time, HR will talk to you a lot of questions, these questions are to understand some of your personal situation. For example, personality, reaction ability, emotional intelligence and so on. In addition, the HR of most companies does not have a veto power. If the interview is not successful, it is probably because there are better candidates instead of being stuck by HR.

Then it comes to talking about money. First, recruiting people in need with the least salary is definitely one of HR's assessments, so it is normal to keep prices down. And the salary of the last company is also a very important reference. Generally speaking, a salary increase of more than 30% is very awesome, usually around 20%.

Your offer is generally the upper limit of the offer. Taking into account the low price situation, you can go up to about 1K on the original expected salary, and then you can make a selective offer based on the situation of the interview.

The noodles are good, I originally wanted 16K, so I had to ask for an extra 1-2K, no problem
If the noodles are average, please report 16 K
The noodles are average or not very good, but I really want to join this company. You can drop 1-2K as appropriate. This is mainly up to you.
I don’t really want to go to this company and ask for a price at will

Nowadays, many HR interviewers will ask about your career plan. This is actually to understand how well you match the development of the company. If you are a code writer and say that you want to make a product, operate, or start a business after a few years, then it might be a bit dangerous. As long as you tell the path that suits your career, for example, you want to be promoted to senior engineer -> architect and so on.

There are also some HRs who like to ask you what your shortcomings are. This question must be remembered to not answer your own personality defects, poor ability, poor communication, etc. You can say some problems encountered in your work. For example, during a certain requirements review, because I did not adhere to my own ideas, the problem of the requirement was not solved, and the final result of the project was not good and did not meet expectations, and so on.

Interview summary

Even if the interview fails, don't be discouraged, but learn from the experience of failure. Know that every interview failure is the basis for your next interview success.

May wish to question yourself in the following directions:

Technology: What is missing in technology? What does the interviewer value?

Soft power: What are your own points? What are the self-lost items? How about your communication skills during the interview?

Reason for failure: What is the reason for the failure of the interview? Is it due to lack of technology? Or did you fail the interview for other reasons?

Of course, you can think more about why? …

The front end itself is a beautiful and interesting area. For many websites or systems, the functions provided by the backend are the core modules, but it is related to whether the website or system can continuously attract users' attention, whether it can stand out among the same type of products, and maybe the front-end interaction is humane and Whether the performance is stable and efficient accounts for most of the factors. The front-end knowledge is many and fragmented, and we need to make continuous progress through systematic learning. Get more front-end dry goods, such as learning circuit diagrams, video tutorials, introductory books, learning tools, interview questions, etc. Welcome everyone to continue to pay attention to me wow~