Interviewing front-end engineers is a very interesting thing for me, because the interview process is also a process of self-improvement to a large extent. No matter how big or small companies are, the reason why they have the same problem in how to recruit truly capable front-end engineers is because those who are in charge of recruiting do not know what kind of people their company needs, and they ask questions when they ask questions. Not to the point. After years of exploration in the industry, I have come up with my own set of very effective methods for interviewing front-end engineering.
Some candidates say I'm not easy to deal with, but I don't want to give them that impression. I think the main reason they say I'm not easy to deal with is because I'm too specific when I ask them questions. I've written something specifically about how to pass my interviews and how to be a good front-end engineerWhat qualities should be possessed, and my interview can be said to be completely in accordance with the standards of those two articles. I don't ask some very out-of-the-ordinary questions, and I don't think that a few logic questions can test a person's true level. My only thought is to determine if you are qualified for the position we are looking for. To this end, I need to briefly examine the following aspects.
basic knowledge
We live in the internet age where almost anything you want to know can be found in 15 minutes. However, just because you can find information does not mean you will use it. I think all front-end engineers should have at least some basic knowledge in order to do their job effectively. If you encounter a problem and stop working and search for solutions online, how can you guarantee that the work will be completed on time? Listen, who else is saying "I don't know, but I can find it online." Ask these classmates to raise their hands and let everyone know (immediately raises a flag for me.). Below I've listed some basic knowledge points that I think a front-end engineer (regardless of age) should know without any outside help.
- DOM structure - what relationships may exist between two nodes and how to move arbitrarily between nodes.
- DOM manipulation - how to add, remove, move, copy, create and find nodes.
- Events - How events are used and what are the main differences between the IE and DOM event models.
- XMLHttpRequest - what it is, how to perform a complete GET request, how to detect errors.
- Strict Mode vs Promiscuous Mode - How to trigger these two modes and what it means to distinguish them.
- Box Model - The relationship between margins, padding and borders, what is the difference between the box model in IE < 8.
- Block and inline elements - how to control them with CSS, how they affect surrounding elements, and how you should style them.
- Floating elements - how to use them, what are their problems and how to fix them.
- HTML vs XHTML - what's the difference between the two, which one do you think you should use and why.
- JSON - what it is, why it should be used, how it should be used, implementation details.
To reiterate, the above knowledge points should be things that you know without thinking. All the questions I asked at the beginning were to find out how well you know all of these areas. Although the knowledge points listed above are not exhaustive, I think you should at least master them before you can sit in an office with me.
few questions
I strongly agree that the fewer questions the interviewer asks, the better. It's unfair and boring to ask candidates questions over and over again. I usually only ask three big questions in any interview, but each question touches on as many aspects as I can think of. There are usually several steps to answering each big question, so I can intersperse each step with small questions. For example:
This question involves a set of basic knowledge points I want to examine: DOM structure, DOM manipulation, event handling, XHR and JSON. If I ask you to change the way you handle stock prices, or ask you to display other information on the page, more knowledge points can be included. For the more experienced candidates, I can also freely expand the scope of knowledge to be investigated, the simplest such as the difference between JOSN and XML, security issues, capacity issues, and so on.
I also hope that no library is used in any solution given by the candidate . I want to see the most primitive code, you just don't include any library in the page. You say how much you know about which library, but I can't use knowledge about the library as a judging factor because the library changes over time. What I need is someone who really understands the mechanics behind the library, especially someone who can write one of their own by hand.
Solve the problem
As a front-end engineer, the happiest thing is that there are many different ways to solve the same problem, and all you have to do is to find the most suitable way. When I ask questions, I often ask candidates if they have a second method after explaining one method. At this point I would say to them, assuming this method of yours is rejected for various reasons, can you suggest another method. Doing so serves two purposes.
First, it can be tested to see if they are meaninglessly rehearsing something from the book. It has to be admitted that some people do have the gift of unforgettable memories, and listening to them gushing over there, you will feel that they understand everything. However, as long as I talk to these people about how to find out why the plan is invalid, and whether they can come up with a new plan, they are often dumbfounded. At this time, if I hear rhetorical questions like "I don't understand why this plan is not good enough", I immediately understand that my problem is beyond their ability, and they just want to use their rote conclusions to fool pass.
Second, they can test out the technical knowledge of browsers they already have (again, "don't even think about it"). If they have a good understanding of the core knowledge of the browser platform, it is not that difficult to come up with different solutions to the same problem.
This is definitely the most important ability for a front-end engineer. It should be said that it is a very common thing for front-end engineers to encounter problems that should be so but not so (say you, IE6). A person who can do nothing if the solution is invalid cannot be a front-end engineer.
Another reason for evaluating candidates' problem-solving skills has to do with my personal preferences. After figuring out what a candidate knows and doesn't know, I'm thinking of asking a question that's outside of their field of knowledge. The purpose of this is to see how they can apply their existing knowledge to solve new problems. At every step of the way, I've also prepared some tips in case someone gets stuck (15 minutes of silence in front of me doesn't help me judge this person). What I'm really interested in is their ability to move from one step to the next. I want to see someone learn something new right before my eyes.
Note: All questions are related to browser technology. I don't believe that a few abstract logic questions can test someone's ability to solve web technology problems. In my opinion, this is tantamount to asking a master sketcher to draw a portrait (or letting Liu Xiang compete with Bolt), which is meaningless and does not get any valuable information.
have passion
To be a good front-end engineer, the most important thing is to be passionate about what you do. None of our skills are learned in school or seminars, so front-end engineers must be self-taught. Browser technology is changing rapidly, so you can only keep up with the times by constantly improving your skills. Although I can't force anyone to read more blogs and keep learning, but I'm afraid people who want to apply for front-end engineers must do so.
How do you know who has a passion for this kind of work? It's actually pretty simple. I'm just asking a simple question: "What web technologies are you most interested in right now?" This question never expires, and it's almost impossible to go wrong...unless you can't answer it. For now, I hope that the technologies you give to this question include WebSocket, HTML, WebGL, client-side databases, and so on. Only people who are passionate about web development will persevere in learning new knowledge and mastering new skills; these people are what I really want. Of course, I'll ask them to explain the techniques they're referring to in detail to make sure they're not babbling a few fancy new words.
the last point
Knowledge of computer science or web design is certainly useful, but that's beyond the basics. As long as the basic knowledge is there, everything has a foundation, and it is not difficult to expand the knowledge. However, if you have to learn basic skills from scratch after you go to work, the difficulty is quite different. In addition, senior front-end engineers definitely need to master more skills than general engineers. And interviewing college graduates with little or no experience, I would have a completely different procedure. What I have listed in this article are the basics.
For people who don't have much interview experience, I always like to tell them that after the interview, just ask yourself one question: Do you want to work with this person in the future? If, for whatever reason, the answer is no, then no.