Writing Resumes to Get into FAANG
This is geared towards both students / new grads, with insights into industry.
Overview
Resumes tend to be the hardest for people who are inexperienced. If your resume has two columns, graphics, pictures, lots of white spaces, not standard template, it is probably bad. If it has too much jargon, where people do not know what it means, or only impact driven with numbers without an explanation of what you did and the challenges, it isn’t good enough.
The content should be 1 page, digestible, and the most important things.
Note:
At a certain point, it also isn’t worth grinding a resume too much. If you reach a point where your resume is “solid enough”, like a 75/100, or 80/100, or more, then you’re good! In my opinion, the resume is not the end all be all for tech, rather it’s much more towards your interview performance. And there are many other things you can do to be getting the interview rather than focusing too much on making your words pretty.
ATS System
Larger companies use something called ATS, which is a resume parser, and this is why I recommend doing standard formatting, or a single-column resume. The idea is to make it easy to parse.
Saying that, your resume does not need to be 100% algorithmically perfect. Different companies use different systems, and ATS at the end of the day is not perfect. I used to over-optimize on this, but now I am of the camp that it really matters very little.
Resume Templates to Use:
Use Jake’s Resume Template on Latex : Latex is an easy way to get consistent nice formatting for text.
Use any Mac or Words template as long as it fits the single column criteria
If you don’t have enough to talk about:
There is no excuse. You can literally pick up Udemy courses, go to Youtube, do more projects. Sometimes, if your resume sucks, it just really sucks cause you just don’t have enough to talk about, and that is your signal to go do more. Programming is the one field where it is totally valid to do your own thing.
Bullet points and Common Problems:
This is a great article here about how to write good bullet-points. But I will state the common problems.
Often people use too much jargon - especially if in research roles
Focus too much on soft skill
Try to stuff in too many numbers
Try to stuff in too much technology: ex. I used Python, Numpy, and AWS Lambda to do X. But usually that tells me nothing about “how you did it” other than you magic-wave your hand and something happened.
Too much adjectives back to back, such as, “effectively and efficiently increased productivity by 33% through [more adjectives]”
Useless points that don’t say much about you as an engineer such as, “lead project”, “communicated expectations”
For example, someone might say:
Demonstrated leadership by leading SCRUM meetings
Increased project efficiency by 30% by implementing meeting notes
Implemented an distributed-network protocol that interacted with <Insert proprietary technology> that <insert more proprietary terms>
Why is this bad? B/c as a newbie what they want to see is mainly technical skills. Not leadership, not that you can talk, not random numbers you pulled out of no where. Imagine you are trying to hire a junior engineer: do you hire the person who can lead the meeting? Or do you hire the person who knows the framework you are working with?
Also some people often focus too much on making their sentences too short, I also think this is a problem.
Thus… writing bulletpoints
Other than the article I link that goes more in depth, here are the two ways I recommend to write:
Challenge Format:
This is more for beginners, since some of my mentees really are just bad at writing, so I gave them this format just to have something easy to follow.
What did you do
What were the challenges
So if we deconstruct the above my mentee took a course she did on Vue, and said:
She built a full stack application so people can see where their friends are at
Challenges included … [the challenges she had]
Easy, simple, to the point.
Deconstructive writing
Another way to write more in length and better is to focus on the: what you did, why you did, and how you did it.
Especially the HOW - I find a lot of people missing that which is the most important! B/c again, based off my personal philosophy, as a more junior developer you are trying to demonstrate your technical capabilities.
I worked on a react project to design a dashboard.
Can be improved by writing:
What did I do: I designed a React UI dashboard
Why did I do it: To parse incoming data stream that I had coming from customer data
How did I do: I used React and live visualization modules to display it in a more intuitive manner, and had challenges such as implementing file parsing.
Example reworked:
I developed a React UI dashboard to visualize datasets for our customers. Used D3js to manipulate graphics, and dealt with challenges such as file parsing thousands of data points.
Other variations could be:
Developed a UI dashboard to visualize datasets for our customers. Challenges included dealing with file parsing datapoints and efficiently plotting the datapoints.
Ultimately:
There are tons of ways to write datapoints. I am not saying that my methodology is the “correct” way. But it is an “easier” framework I give to people to just help them have a guide rail to get to a decent stage.
Overview To Specific
Another technique is writing a higher level overview the first bulletpoint and then driving the details later.
Ex.
Implemented a neural network that was able to predict video click through rate for youtube videos.
Implemented clientside chrome plugin for users to do XXX resulting in XXX
Implemented the network to do YYY depending on ZZZ.
Developed dev-op pipeline to deploy models to XXX customers and scaled memory by YYY.
Where to Put Technology:
One of the problems, I want to directly address is a lot of times people write things as:
Implemented features using some magic technology.
And this will repeat on for the whole resume. To fix this issue, try to use a separate dedicated bullet point for just:
Technologies: X, Y, Z
Or put it in the header of the job.
Position | Company | Technology: Firebase, SQL, Python, …
That way you don’t feel the need to stuff it everywhere.
Note:
Not every single point needs to be written this way. For example, your first point could be the project, and following points more details:
Implemented a project that allowed XYZ
<deconstructive writing>
I also find that if you find yourself stuffing technologies into your bullet point, maybe consider putting the technologies in the header of the job / subtitle / as it’s own bullet point. That basically helped me not feel the need to spam what I used.
Common Questions:
What if I don’t have number to say? You can use qualitative descriptions such as: improved experience, so on.
Do I need to have work experience?
No
Should work experience unrelated be above projects?
I personally put projects on the top, and as I gained more projects, I deleted irrelevant work experience.
Summary:
Get more projects if you don’t have it
Focus more on the things that matter
As a junior developer you should be more focusing on proving can you contribute to writing code rather than driving org wide impact. (Which will also naturally come once you become more senior)
