Don't help me say No

Common mistakes to avoid when applying for a software job. Plus how to get a job if you have no relevant work experience yet.

In the past 6 years I have been on the hiring side of things. I have read a thousand resumes and have interviewed probably more than a hundred engineers, both senior, junior and interns, and have seen common mistakes that cost people an invitation to even the first interview. In this post I will try to summarize the common mistakes and give advice how to avoid them.

💡 You might want to read the companion blog post Help Me Say Yes.

It is a filter

First, you need to remember, that when a company like Cypress.io advertises a job, we receive a large number of resumes, approximately 10 - 50 applications in the first month per job posting. Thus our primary task is to filter applications quickly to just 2-8 promising candidates we want to interview. I don't feel bad about rejecting candidates, because I know that the market is hot and the applicant will find something else. Still, if you really want to work at this particular job, you probably want to avoid silly mistakes, right?

Here are the common reasons for rejection

A general resume

Yes, I understand that you are probably applying to 5, 10, 50 companies, and that you are sending the same resume to all of them. But if the resume does not describe how you can help our company that writes tools for end-to-end testing of modern web applications, I am going to reject you.

Please, take time to pick relevant skills from your experience and create resume targeted at Cypress. You can "guess" what experience would be relevant by looking at our open source repositories like cypress-io/cypress, reading our documentation about how Cypress works, following @cypress_io on Twitter and most importantly

Reading the job posting

Read it! We list specific requirements and responsibilities. You do NOT have to be the world-class expert on GraphQL, but when you read "Explore emerging technologies like GraphQL" among other job responsibilities that should give you an idea! Do not create a resume just for Cypress though. Create several versions of your resume - one highlighting your DevOps skills, another one highlighting front-end, another highlighting area X - and now you can apply to 50 companies, and easily get through the initial filter.

Again, this is not the keyword matching, it is not automated text filtering - a human engineer is looking at your resume to see if you can bring the skills we need. If you don't start with those skills, it will be hard for us to continue.

The main reason for long, unfocused resumes?

Listing every little bit of technology you have ever touched in your resume

Really. If your resume is longer than

  • 1 page and you have less than 3 years of experience
  • 2 pages and you have more than 3 years of experience

It is an automatic rejection by me.

Look at the Cypress job posting, take your looong resume and copy just 3 - 4 main skills and tools that are relevant and create a resume with them. Take all your previous jobs and pick 1 main thing from each job that shows how you have applied those skills. Done. I will thank you.

Do you want to know how bad it is?

This might be a fluke of this particular job postings site, but go to https://resumes.indeed.com/ and search resumes for something like "React" or "DevOps" and look at the resumes. For some reason, every application we receive through indeed.com comes in like this (I have taken screenshots of each page and have removed job titles and locations, even if there is no personal information in this resume)

Warning ⚠️: you will have to scroll for a while

page 1 page 2 page 3 page 4 page 5 page 6 page 7

Let's summarize what we are seeing here. 7 (SEVEN, S-E-V-E-N) pages in a resume titled "DevOps" with final section "Skills" having "DevOps (less than 1 year)"

Really?

I can already see the resume running for 20 pages after this particular engineer reaches 3 years of experience!

I don't know what prompts people to write resumes like this. I am certainly not reading them. And it is NOT because I am allergic to long-form prose. No. To me this resume screams

I don't know what is important and what is not

And I believe that if you cannot decide what is important for this job position, you will not be able to effectively solve problems working at this job position.

We have noticed that all resumes coming from indeed.com have this problem. So we suspect that this particular website prompts users to check boxes with skills and then creates a resume with a wall of text automatically. Not a very good strategy, but this brings me to a super important mistake people make when looking for a job.

Here is my resume - about 1.5 pages after 10 years in the industry.

Using a recruiter

Here is the sad truth about recruiters:

  • they don't know what they are doing
  • they do not help me screen the candidates in any way. I am still reading the job applications the same way no matter how they arrive
  • they do not provide candidates that are any better than my personal network does, or candidates that apply "organically"

But there is a huge, huge, huge downside to any candidate that comes through a recruiter

This candidate is 25-35% more expensive in the first year

That's how recruiters make money - they take a one-time commission on each candidate that gets a job. Usually the commission is a percentage of the yearly salary, and it is a pretty heavy chunk. So by going through a recruiter, who

  • emails the candidate's resume to me
  • charges me $20k-$40k if I hire you

you have instantly made yourself super expensive. Unless there is something very unique about your skills for this particular job, forget it. Are you looking for a front-end job coding React web applications? There are 30 people with your skills who have applied in the same week. If you are 30% more expensive than the other 29, you are not going through the initial filter.

Of course, the recruiter will not tell you about all applications that they have emailed on your behalf. Instead they will tell you about a few companies that are desperate for any candidates to come in for an interview. But then you are eliminating job positions that are highly desirable, like Cypress.

Something to think about.

Not knowing why you want to work at my company

Here is a trick that 90% of applicants skip (and certainly all applicants coming via recruiters lack). Write cover letter / email / message when applying. One paragraph, 4 sentences - why have you applied to this particular position? How did you hear about it? Why are you excited to apply?

If you do not write this, my first email to you after I read your resume will be

Thank you for applying to our company. Why do you want to work here?

I am not looking for much, just a few sentences that make sense, and show that you want to work here, with this team, in this field, solving the problems we are trying to solve.

Very few applications have a "cover" statement (it does not have to be a letter), and having one automatically propels you to the top 5%. Not a bad return on 15 - 30 minute time investment.

PS: good cover statements are so effective, we would internally email each other saying "check out this resume, this person wrote very well why they wanted to work here". Yup, it is that rare and that effective.

Bonus: applying without work experience

I get asked sometimes about Catch-22 situation. Every job posting needs work experience, but to get work experience you need a job first. So how do you get into a field in the first place?

Here is a secret. "Work experience" should really be "Experience with and knowledge of tools and methods to do this particular work". So if you have never worked yet in the front-end dev position, but for example worked as a designer:

  • make a few web apps by yourself. There are tutorials, boot camps, blog posts, etc. to guide you.
  • put them on GitHub
  • document what you have done and how to run the project in Readme
  • describe what you have learnt in blog posts

Boom, you just proved that you can successfully develop front-end web applications, and that you can communicate effectively with other developers. So much of the daily work now happens through GitHub and writing anyway.

You are trying to break into QA field?

  • take a sample application and write tests for it
  • put them on GitHub
  • document test cases, describe findings in Readme or blog posts

Done, you have proved that you can test.

To be perfectly honest, having a well-described examples of your work that I can see and we discuss, is a massive advantage. I have nothing against people who do not have time to contribute to open source or have projects on GitHub to show me, but if you are just trying to break into the field - find time to do it. Make sure to organize the code, ask your friends for feedback, ask people you meet at a meetup or online for suggestions - and you will build a "portfolio" that will be a great substitute for work experience.

Bonus 2: put links in the resume

If you have a GitHub profile, or a personal blog or a book that you want us to see when we evaluate your resume - please, please,please put it right in the top section of the resume. Do not assume that the application system does anything with additional links you can submit with your resume. First, all links you add to your application are usually shown to us as "Website", "Website", "Website". Second, when we forward your resume to discuss - the links are lost. Put them right front and center, so we see them easily. Here is my resume for example. Link to my personal website with a lot of OSS projects, blog, videos, etc - right there, under my name.

Bonus 3: use PDF

Please, always distribute a PDF of your resume, never use Microsoft Word document. The Word document will NOT look good on Mac! The formatting will be all out of place, making you look bad. Export PDF of the document - it will look the same on every platform.

Bonus 4: avoid weird capitalization

For some reason, a significant percentage of resumes I receive uses capital letters for words that I would not capitalize at all. When I see "tracked Bugs in Jira" I often ask myself "are these bugs so incredibly important and unique to warrant the capital B?" Please use the common nomenclature.

Somewhat related