How does hr interview web front-end engineers and what technical questions should be asked?

In recent months, I have been trying to find front-end comrades, but without success. After all the recruitment, I feel a lot. I have always been very cautious, afraid of missing the master, and even more afraid of not recruiting unqualified students into the company by mistake, which will have some impact on the company's projects.

Interviewing front-end engineers is a very interesting thing for me, because the interview process is also a process of self-improvement to a great extent. No matter how big or small companies recruit truly competent front-end engineers, they will encounter the same problem, because the person in charge of recruitment doesn't know what kind of people his company needs, and as a result, he can't get to the point when asking questions. After years of industry exploration, I have always had my own set of very effective methods for interviewing front-end projects.

Some candidates say I am difficult to get along with, but I don't want to leave such an impression on them. I think the reason why they call me difficult is mainly because I ask them detailed questions. I have written something specially before, telling candidates how to pass my interview (survive my interview) and what qualities an excellent front-end engineer should have (how is an excellent front-end engineer tempered? ), and my interview can be said to be completely in accordance with the standards of those two articles. I won't ask some special questions, and I don't think a few logical questions can test people's true level. My only thought is to make sure that you are qualified for the position we want to recruit. To this end, I need to briefly examine the following aspects.

elementary knowledge

We live in the Internet age, and almost everything you want to know can be found in 15 minutes. However, just because you can find information does not mean that you will use it. I think all front-end engineers should have at least some basic knowledge in order to finish their work effectively. If you stop working as soon as you encounter problems and search for solutions online, how can you ensure that you finish your work on time? Listen, who else is saying, "I don't know, but I can find it online." Please raise your hand to let everyone know (raise a flag for me at once. Below I list some basic knowledge points, which I think a front-end engineer (regardless of his working years) should know without any outside help.

DOM structure-what relationship may exist between two nodes and how to move between them at will.

DOM operations-how to add, delete, move, copy, create and find nodes.

Events-how to use events, and what are the main differences between IE and DOM event models.

Xmlhttprequest-what is this, how to execute a GET request completely, and how to detect errors.

Strict mode and promiscuous mode-How to trigger these two modes and what is the significance of distinguishing them.

Box model-the relationship between outer edge, inner edge and frame. What's the difference between the box models in the browsers below IE 8?

Block-level elements and inline elements-how to control them with CSS, how they affect the surrounding elements, and how do you think they should be defined.

Floating elements-how to use them, what are the problems and how to solve them.

HTML and XHTML- what's the difference? Which one do you think should be used and why?

JSON-What is it, why use it, how to use it, and talk about the implementation details.

To reiterate, these knowledge points should be something you "don't even think about". All the questions I asked at the beginning were to find out what you know about all these fields. Although these knowledge points listed above are not comprehensive, I think you should at least master them before you can sit in an office with me.

Ask a few questions.

I quite agree that the fewer questions the interviewer asks, the better. It is unfair and boring to ask candidates all kinds of questions repeatedly. In any interview, I usually only ask three big questions, but each question will involve many aspects that I can think of. It usually takes several steps to answer each big question, so that I can ask some small questions at each step. For example:

Now one is showing Yahoo! Stock price page. There is a button on the page that you can click to refresh the price, but the page will not be reloaded. Please describe the process of realizing this function, assuming that the server will be responsible for preparing correct stock price data.

This problem involves a set of basic knowledge points I want to examine: DOM structure, DOM operation, event handling, XHR and JSON. If I ask you to change the way you handle stock prices, or let you display other information on the page, you can include more knowledge points. For more experienced candidates, I can also freely expand the scope of knowledge to be examined, such as the simplest difference between JOSN and XML, security issues, capacity issues and so on.

I also hope that this library will not be used in any solution given by the applicant. I want to see the original code, so I pretend that the page doesn't contain any libraries. You say how much you know about which library, but I can't take the knowledge about the library as a factor of judgment, because the library will change with time. What I need is someone who really understands the mechanism behind the library, especially someone who can write the library by himself.

solve problems

As a front-end engineer, the happiest thing is that there are many different ways to solve the same problem. What you have to do is to find the most suitable one. When I ask questions, I often ask candidates if there is a second method after explaining one method. At this time, I will tell them that if your method is rejected for various reasons, can you give me another method? This can achieve two purposes.

First, you can test whether they are repeating things in the book meaningless. There is no denying that some people do have a gift that they will never forget. Listen to them talking there, and you will think that they know everything. However, as soon as I talk to these people about how to find out why the scheme is invalid and whether they can come up with a new scheme, they are often dumbfounded. At this time, if I hear a rhetorical question like "I don't understand why this scheme is not good enough", I immediately understand that my question is beyond their ability, and they just want to muddle through with their own rote conclusions.

Secondly, they can test their knowledge of browser technology (again, "don't even think about it"). If they have a good understanding of the core knowledge of the browser platform, it is not so difficult to come up with different solutions to the same problem.

For a front-end engineer, this is definitely the most important ability. It should be said that it is very common for front-end engineers to encounter problems (such as you, IE6) that should be so but not so in their work. People who can't do anything if a scheme is invalid can't be front-end engineers.

Another reason for assessing the problem-solving ability of candidates is related to my personal preference. After finding out what the candidates know and don't know, I will want to ask a question outside their knowledge field. The purpose of doing this is to see how they can use existing knowledge to solve new problems. At every step of solving the problem, I also prepared some tips in case someone gets stuck (15 minutes without saying anything in front of me will not help me evaluate this person). What I'm really interested in is that they can move from the previous step to the next. I hope to see someone learning new knowledge before my eyes.

Note: All problems are related to browser technology. I don't believe that a few abstract logic problems can test a person's ability to solve Web technical problems. In my opinion, this is tantamount to asking a sketch master to draw a portrait (or letting Liu Xiang compete with Bolt), which is meaningless and can't get any valuable information.

Have passion

To be an excellent front-end engineer, the most important thing is to have passion for what you do. Our skills are not learned from schools or seminars, so front-end engineers must have the ability to teach themselves. Browser technology is changing with each passing day. Only by constantly improving your skills can you keep pace with the times. Although I can't force anyone to read more blogs and keep learning, I'm afraid people who want to apply for front-end engineers must do so.

How do you know who is enthusiastic about this kind of work? It's actually quite simple. I just ask a simple question: "What Web technology are you most interested in at present?" This question will never expire, and it is almost impossible to make a mistake … unless you can't answer it. At present, I hope the technologies you give to solve this problem include WebSocket, HTML, WebGL, client database and so on. Only those who love Web development will persistently learn new knowledge and master new skills; These people are what I really want. Of course, I will ask them to explain the technology they mentioned in detail to ensure that they don't just say a few fashionable new words.

the last point

Knowledge of computer science or web design is certainly useful, but that goes beyond the basic knowledge. As long as the basic knowledge exists, everything has a foundation, and it is not difficult to expand the knowledge. However, if you have to learn basic skills from scratch after going to work, the difficulty will be far from it. In addition, senior front-end engineers definitely need to master more skills than ordinary engineers. And interviewing college graduates with little experience will have completely different procedures. What I have listed in this article are the most basic things.

For people who don't have much interview experience, I always like to tell them that after the interview, I ask myself a question: Do you want to be with this person in the future? For whatever reason, if the answer is no, it is no.