Disclaimer: All opinions in this article are only personal and do not represent the position/opinion of the company, department or team. The right and wrong of the content and values are decided by the readers themselves. Friendly communication and discussion are welcome.

Let’s start with a soul-searching question: What is it about you that sets you apart from others?

There are two levels of problems here. One is how to identify your advantages. After all, most people are probably doing business most of the time. The second question is that you may have found your strengths, but how do you structure your resume, how do you express yourself in a way that will stand out and get the interviewer on the spot?

This is not easy. Many resumes I have seen, especially those under 5 years old, are not as good as expected. Some are really plain and some have good experience, but do not express it, so it is difficult to get highlights within a few minutes. Recently, a lot of people came to me for internal promotion, and I tried my best to help them see if there were any obvious problems. In the process of communication, I gradually summarized some common problems, so I wrote this article, hoping to help students who are looking for jobs or are about to find jobs.

This article will not cover too many basic issues, such as format, size, font, etc. There are already many articles on the web, so there is no need to rehash them. This article will focus more on content. It will focus on how to highlight your personal strengths in a limited space, including how to find highlights in your daily work, how to structure your words so that the interviewer can quickly understand your highlights, and how to avoid any pitfalls that might be negative. Any thoughts and opinions are welcome to leave comments, if it is really helpful to you, I hope you do not spare your likes, this is very important to me, can inspire me to continue to write more articles.

How to find the bright spot

The key is to record consistently and accumulate enough material. Learn to identify what’s a plus and what’s not for your job search.

Adhere to the record

Writing needs material, and writing a resume also needs material. The material of a resume comes from our accumulated work over a long period of time. We can form the habit of consciously recording some experiences in the form of text.

There are many ways to do this, such as technical blogs, project logs, annual summaries and even weekly reports. These are written summaries that can be reviewed at any time. A good memory is better than a bad one, and this information can eventually become important material for your resume.

Of course, there’s no need to keep track of every detail. You can focus your limited energy on a few key points:

• The process, thinking, argument and conclusion of the technology selection at the start of the project
• At the end of the project, review, reflection, key points and difficulties, data indicators of the implementation process
• Debug process, logical derivation, solution when encountering problems using open source framework
• When learning a new skill,
• When solving performance problems, how much improvement is made before and after optimization, what specific optimization measures are taken, what tools are used, and how to implement them

These milestones are great opportunities for personal growth. Write them down. Write down what problems you encountered along the way and how you solved them.

Identify bright spot

After you have accumulated enough information, you can organize your resume based on the company, business and target position you are interviewing for.

Highlights should be experiences that set you apart, such as:

• Have done some in-depth performance optimization, and have a relatively large performance benefits, can be quantified to improve the space
• I have done some projects with particularly complicated business logic and great business influence
• I have promoted some systems and tools, which have profoundly influenced the working process and working mode of the team and even the whole company, and have improved the overall effect
• Used some less common technology to solve the front end of a relatively difficult problem, such as live video
• Worked on open source projects with a reputation for solving technical problems, except demo and awesome-xxx
• In-depth study of the use of some tools to solve some engineering, development efficiency, performance problems
• Submitting truly complex and meaningful MR and Typo class fixes to well-known open source projects is not one of them
• Have studied the principles of some frameworks, and can consistently produce enough articles of technical depth, or clearly solve complex problems in a project
• .

The list could go on. Different people, or even the same person, will have different judgment criteria at different times with the increase of experience and cognition, so there is no standard answer here, just try your best.

What’s not a highlight

Be careful to avoid any information that won’t give you credit. Ask yourself intellectually if the experience was complex enough. Is it enough to perform at your highest level? Do you really have a good command of the techniques involved?

Here are a few anti-patterns:

• A single technical breakthrough is not a highlight, such as solving a single style bug in a UI framework that is too small
• Doing a lot of projects isn’t a highlight, it’s just evidence that you’ve probably been working for a long time
• The technical framework and tools remain in the stage of use, and the internal implementation principle is not clear at all
• It’s not a good idea to just solve a problem that’s so common, so common, and there are so many solutions on the web

How to express highlights

Having accumulated enough material, the next step is to explore how to effectively communicate your resume to prospective readers. Interviewers are usually very busy, especially in large companies, where they may review hundreds or thousands of resumes every day. How do you organize your content to effectively convey your message? How to grab the interviewer’s attention in a short time? Furthermore, how to guide the content of the follow-up interview?

It is basic format above all, this respect is simpler, get online to look for the most concise and relaxed template that you feel went, MY individual likes this quite. More important than the basic format is the content. How to present your competence, professionalism, and personality in just one or two pages is described below.

Set up technical personnel

The hypothesis can be simplified to what we have done and what we are going to do.

Do any

Project experience is the core component of the resume. Most interviewers value this part very much. Do not write blindly.

• Consciously pick a few projects that highlight a particular skill set. For example, if you want to highlight a VUE, try to focus on that theme. Avoid the vUE and Lua, and let the interviewer immediately recognize that the VUE is your technical expertise
• Organize the language, project experience in the timeline from far to near, and gradually refine and deepen around the theme you set. For example, in the initial project experience, you just used this technology, and then gradually began to apply ecology better. Better understanding of implementation principles and ability to solve complex performance and engineering problems; Even further developed some valuable open source tools, or output some high-quality documentation back to the community. Let the interviewer feel that you have grown up through the project experience
• The first two points are in the performance of depth, for students who have worked for more than 3 years, usually require both depth, and a certain breadth, vision, to tell the truth, this is not easy to do, one method is to build around the depth established above, expand to supplement the work experience strongly related to the front-end foundation. Such as HTTP, TLS, HTTP2, TCP and other network stack related performance optimization, version upgrade experience; Or, memory leak detection and repair experience, FPS, FCP, FMP index is too low optimization experience and so on; Or more complex development scenarios, such as editors, compilers, visualizations, complex animations, multimedia, and so on

In conclusion, try to be versatile, both depth and breadth, depth can help the interviewer quickly judge your technical stack, reduce the mental burden, not tired; Breadth helps interviewers identify your ability to learn, your potential, and your tolerance for complex development scenarios. In addition to basic technical expertise, it’s a good idea to convey depth of knowledge about your industry, which we’ll talk about later.

What are you going to do in the near future

Many interviewers like to ask: Where do you see yourself in your career in the next 3-5 years? Many people find “career planning” a bit of a sham and don’t want to take the time to sort it out. In my opinion, career planning is for yourself first and foremost. It sets a path for you to make choices in daily work. The clearer the path is in your mind, the lower the cost of making decisions will be.

For the interviewer, this question is mostly about whether you have a clear understanding of your career and a sense of purpose. Second, look at your ceiling. If you don’t show technical or professional ambition, it’s easy to judge your potential. Finally, look at how well your plan matches the team. It’s a matter of opinion.

So it’s important to take some time to figure out what you want to be doing in the next 3-5 years, and how far you want to go, and set a clear career goal. This topic is a bit off topic because it’s hard to convey your career plans on a resume, but instead, include additional materials on your resume, such as a personal blog or Github.

Blogging can be a way to write multiple posts over a period of time around a career you’ve set out to show interviewers that you’re both thoughtful and committed to that direction.

Github’s words are the same, output some good code quality warehouse on this topic for a period of time, usually the interviewer comes in first look at the star, then look at the code style, if can’t save more than 100 star, try to write a better code, this is also a bonus.

quantitative

Numbers are a killer! Using metrics correctly can give your resume more focus, credibility, and recognition. Many things can be quantified, such as:

• Performance improvement: Performance optimization is usually a very comprehensive and complex scenario, which requires sufficient depth of knowledge and flexible use of various debugging tools. Therefore, interviewers usually pay more attention to this experience. It would be better if they could infer the indicator changes before and after optimization
• Business improvement: This is usually the introduction or creation of tools that change or optimize existing workflows to achieve local or global solutions to improve overall efficiency, not just within the development team. This kind of optimization is closely combined with the business, and the interviewer who changes the business direction may be difficult to get the point from what you do. If you can provide some specific optimization values, it is helpful for readers to make judgments, such as improving the process efficiency by XX %, improving the completion rate of work order by XX, achieving XX, and improving the response time by XX, etc
• Business Advancement: If you were fortunate enough to work on a project where you were a core member, consider summarizing how much the business metrics increased from the time you started to the time you were ready to leave
• Influence: The concept of influence is subjective and difficult to quantify, but it can also be supported by other indicators, such as xx times of sharing within the department, XX times of sharing within the company, xx times of large-scale sharing in the industry; Or, you know, xx blogs or something

Note that the premise is correct, do not deliberately fabricate or shoot some non-existent numbers in order to quantify, the numbers taken are usually easy to recognize, easy to be revealed in the interview, there is no need. It is suggested to develop thinking with data in daily work, including business and technology, especially when doing some optimization, record the numerical situation before and after optimization, so that there are natural materials when writing resumes.

The depth of the business

First, I would like to share my personal experience. I once worked in a very small and beautiful AI startup company for three years. Although my function was front-end, I did not distinguish my work boundary clearly in the process, and often supported the work of the service end, data and even the operation team divergingly, for example:

• Develop timing settlement system with Python + celery to reduce reconciliation cost and shorten settlement cycle
• Using Node + FFMPEG + Docker to do a set of video streaming processing tools, according to the configuration of a batch of video to do the extraction of frames, clips, compression, formatting and other operations
• In a project of POC nature, Python + Caffe is used to invoke the deep learning model to realize the image recognition service, and the camera picture is sent back to the server to identify the items in the picture together with the media interface called on the browser

Actually no significant gains in the short term, but when I left to write resume, found that these experiences together, let I to the work process of deep learning, principles, limitations, tools, index of the understanding of the concept is enough to support me in the interview process to deal with various problems, later to find a job when talking about this part will be particularly well.

This is not to encourage people to do a lot of things outside of the front end, but just to show that the level of knowledge and insight you have into the business and the team you work with is a reflection of your commitment to the job, and the market tends to favor people who are committed. Therefore, in daily work, we can consciously use various methods to cross functional boundaries to understand what other teams are doing and how they are doing it, which tools and technologies are usually used, whether there are any problems, and whether there is a way to solve these problems with front-end technology, etc.

When you have formed enough stereoscopic cognition of the industry, you may be able to show your horizontal cognition in this field when writing resumes and interviewing. Conversely, if your cognition of the job has been in the front of the field, what the next door is doing, how to do it and with what; Not being able to answer questions about what’s next for the business line, and what new technologies might be needed, can lead to doubts about your commitment to the job.

How about the project experience

Don’t just write about what you did, but more importantly highlight how you did it, what problems you solved, and what the benefits were. Form a logical loop so the interviewer has enough information to judge the value of your project experience.

For example, I introduced performance and exception reporting tools in XXX project, and then the team made some optimization based on the recovered data. I once received a resume that read as follows:

Integrated monitoring SDK, including page speed measurement, error and anomaly, API quality, blank screen anomaly, URL anomaly, collected all kinds of error information in the project and reported it, conducted speed measurement analysis through Performance API, encapsulated basic library AJAX to report API error information; In the resource monitoring system through the indicators reported by each end of cleaning, aggregation and data analysis, error module aggregation sourcemap restore source code, easy to repair online problems; Reconstruct the project code and call chain, and shorten the loading time by 20%;

There are some obvious problems:

• Language organization is too flat to perceive the main point
• What is the monitor SDK? What about the integration approach? How much work is involved? What are the difficulties?
• Poor form and description, expensive to read
• What are cleaning, aggregation, and data analysis? What does the front end do in here?
• Error module aggregation sourcemap? Only error modules? What the hell is convergence? Why is it “easy to fix” online problems after aggregation is restored? How does Sourcemap work?
• How does “Refactoring project code” relate to the “integration monitoring SDK” mentioned earlier? Why are they written together?
• What is load time? What exactly was shortened?

To sum up, I think the main problem is that the description is not clear, and it is difficult to understand what it is, how it is done, and what the final benefits are. A better approach would be:

• Introduce (based on) XXX to build performance and anomaly monitoring system, covering FCP/FP/FMP/TTI/LCP and other performance indicators; Error scenarios such as blank screen, page crash, JS exception, and HTTP exception are covered.
• On the basis of the above monitoring system, the core performance index model was gradually developed, and the measures such as image merging, code subcontracting, cache strategy optimization, first-screen rendering optimization and SSR were gradually implemented according to the decision. The average front-end performance index increased by XX % and QPS increased by XX %
• On the basis of the above monitoring system, the CI process of the project is optimized, and the Sourcemap mapping capability based on Webpack is connected. The online problems can be directly mapped back to the source stack, and the average repair time of online problems is reduced by xx%

It’s not the best way to put it, but it’s a good illustration of how it was done, what the problem was solved, and what the payoff was. It’s more rigorous and easier to understand.

How do I subtract

Your resume should be in “history,” but the preset condition is “brief.” Don’t write a running list, don’t write an autobiography in detail. More content is not the best resume. The more you write, the more expensive it is to read and the harder it is to get to the point.

Note the project path

If you already have a lot of project experience, don’t just start writing down all of your resume. The more projects you have, the better. Select a few representative ones based on your personal situation.

• Can show technical depth, or business complexity, business volume
• Those who demonstrate learning ability, such as having spent some time looking through the source code to figure out how to use a framework with missing documentation, are finally able to
• Be able to build a “growth path”, which is described in detail in the section on “Setting up technical personnel”

Try to avoid these types of projects:

• Simple practice, complexity, business value are particularly low
• Too simple, such as a simple active page
• Imitate XXX type, training class likes to do this kind of exercise very much, many candidates take this as the actual project to write on the resume

Use technical terms with caution

Front-end resume often have a part to summarize their own technology stack, here must be careful, I often encounter a lot of technology stack is particularly wide, but all the technology used to write above the resume, one is to look tired, analysis; One is that the interview process is confusing. I recommend asking yourself before using any technical term:

• Will this technique add to your resume?
• Do you use it frequently and know it well enough? Is it enough to deal with all the technical problems that might arise?
• Will this technology be enough to distance you from the other candidates?

For example, “I built a whole engineering system out of Grunt” is not entirely worthless, but in an age of Webpack, Vite, Snowpack, parcel, rollup, does that give you credit? Instead, it may make the interviewer question whether you are too slow to iterate on your technology.

For example, “I used to write a web page with video” is not enough to say “video codec ability” on your resume. If you go further, “I did dynamic video streaming based on HLS + FFMPEG, To the extent that you can play on-demand with Video-.js (as my other blog HLS + FFMPEG implements dynamic bitstream video service), you can say that you “understand common video packaging and encoding formats, and can build a smooth video playback system according to the application scenario”.

From an interviewer’s point of view, simply stacking nouns raises questions about the depth of your knowledge and the accuracy of your perception of yourself, and tailoring them appropriately can be more effective.

Use adjectives sparingly

When I first started writing my resume, there was an article that impressed me so much that I forgot all the details but it had an important point: Don’t write proficient! I think that’s particularly true, because most people don’t have this level of mastery of most technologies, and if you really think you know something, it could be either true or it could be the fact that you don’t know something.

For example, do you think you know HTML well? So:

• What are the optional values for the Type attribute of the input tag? What are the corresponding functions? How compatible is the browser?
• What is the semantics of tags? Why semantic? Who will consume these semantics? How do you evaluate semantic appropriateness?
• What is the ARIA property? How to write proper ARIA structures? Who and how will consume these attributes?

Or, do you think you know vUE? So:

• What is the two-way data binding for Vue2? How is it done? How does this process affect props, computed properties?
• If you understand the above question, what about Vue3?
• How does Vue convert template to render function? And how to identify the component corresponding to the label? What is the creation sequence between component hierarchies? What is the rendering order?

The list could go on indefinitely. There is no limit to learning, and it never hurts to be modest. My personal rule is never to write “proficient,” because I know THAT I am far from proficient in any technical point; But can write 1-2 familiar technical items, and will write as early as possible; In addition, some understanding will be added, for those grasp not enough points will be ignored. Cover a wide range of topics, such as network protocols, build tools, and development frameworks, but try to keep the total number to 3-5.

There may be students here, especially interns, fresh students worry that the technology stack is not wide enough will not get the opportunity to interview instead? This is also a learning strategy, if you stand in the perspective of the interviewer, put in front of you two resumes, one of the content seems to be small but can obviously feel enough depth; The other is a pile of technical nouns, but the nouns don’t seem to be clearly related to each other. Which one would you prefer?

conclusion

Resumes are not easy to write, especially for technical personnel, so it is necessary to spend more time to develop a good resume for your desired job.

I’ve been working for 8 years and currently do front-end work in bytedance’s game department. I’ve read thousands of resumes, and there are a lot of problems you can see. If you happen to be looking for a job or are looking for a job, I’d be happy to check them out for you. If you happen to want to try out the front end of ByteDance, I can help you with the internal promotion of ByteDance, mock interviews, and share my views on byteDance’s various business lines and working environment. Welcome to wechat: Tecvan.