Top 8 resume tips for Dojo Graduates
Since 2011, I have coached a lot of my former students at Coding Dojo on how to improve their resume. A few simple changes could dramatically improve the number of interview requests one gets, often from less than one interview request a week to several interview requests per day.
Here are the top resume tips you should follow.
Tip #1: Don’t use tables or multiple columns in your resume
A lot of resumes are parsed and screened through the Applicant Tracking System (ATS) first. These parsers/programs don’t know how to parse a resume with tables or multiple columns. Never use tables or multiple columns in your resume.
Tip #2: Add at least 30–40 technology keywords
In your skillsets section, how many technology keywords do you have? If anything less than 30–40, beef up your resume and add a lot more keywords. Go back to your optional assignments, get exposed to additional tools/libraries you were exposed to, and add those in your resume.
For example, do you remember how LESS/SASS, PyTest, Jasmine, CoffeeScript, TypeScript, Redis, Postgres, Bootstrap, Materialize, Foundation, etc, were introduced during your bootcamp as either optional reading materials or optional challenges? If you don’t remember, go back through your Coding Dojo’s learn platform and review these materials. Get exposed to these technologies and list these in your resume also.
Unfortunately, a resume with a lot of technologies gets a lot more attention than a resume with just a few technologies. Resumes without certain keywords will also get screened out automatically by either ATS or by hiring managers who are not technical and are doing a keyword scan.
If you lack keywords still, go through job ads in your area, learn what keywords are mentioned, and spend some time getting yourself familiar with the common keywords mentioned in the job ads. Then update your resume with those keywords, even if you’re not yet an expert at it.
Once you get an interview request, you can spend some time getting better with your new technology skill sets, but for now, any technologies you’ve had some exposure to, put them in the resume.
Tip #3: Stop using Github links and start following this 15-second rule (explained below) for each of your projects
I am not sure what’s going on but why are people putting Github repository links for their projects? At this stage, hiring managers don’t have time to navigate through your source code. In fact, they want to see within 15 seconds how complex your project is (and do this without having to click on anything else once they clicked on your project link).
For example, imagine that you are a hiring manager, clicked on a project that seemed impressive (with a list of technologies that are relevant for what they are looking for), only to find out that it’s requiring them to login/register and they still don’t really have a clue what features you’ve built. Hiring managers have 15 seconds to review your project. Sending them to Github repository is also wasting their time as there is no way they can know in 15 seconds how complex your project is by going to Github.
If hiring managers can’t know how complex your project is within 15 seconds of clicking on your project link, you’ve lost them and most likely, your resume will be thrown out (by others who did follow this 15-second rule).
You can solve this with two options.
The first option is for you to create a personal portfolio site and put videos or screenshots of your projects. Then in the resume, when the project name is clicked, have it go to your portfolio site, have it automatically scroll down to your project section, and open up the appropriate project that was clicked. Then have the screenshots move from one to another, with a 3–5 second time in between. If you put a video, have the video automatically play. This way, within 15 seconds of the hiring manager clicking on the project, they would get to know all the important features of the project without having to click on anything else. This is huge, especially for those who have less than 3–5 years of industry experience, as hiring managers often base their hiring decision heavily based on junior candidate’s projects/portfolios. The downside of this first approach is that it will take you a lot of time building this portfolio site as a portfolio site will be a mirror of what you’re capable of building and you don’t want this site to look ugly/un-professional. You probably need to make it responsive as well as make the site look professional.
The second option is for you to create a profile at Data Compass (a platform I’ve created), and once your profile is created, upload screenshots of your projects. When you do this, the platform generates a unique link you can paste to your resume that once clicked, takes the hiring manager to your profile at Data Compass, opens up the appropriate project, and shows the screenshots. You’ll need to take a Programming IQ test before being directed to your profile page which would take you 30–40 minutes to do. Once you create your profile, you can also get introduced to the companies in its network also.
Tip #4: The first two projects should take other experienced developers at least one week for them to replicate
This is probably the biggest mistake I observe in graduates who are not getting enough interviews.
Imagine that I am a hiring manager, click on your project link, and saw, in 15 seconds, major features of your project. I give you +2 points for making it easier for me to see your project scope, especially as I just finished reviewing dozens of other resumes where they were either sending to me a Github repository (which I usually ignore and throw away the resume unless other parts of the resume really stood out for me) or to a live site where I have no idea how to navigate the site (which I often assume they just built the front-end of the site as there is no way of knowing what the back-end features are). Having a resume with a project link where in 15 seconds, I could see the key features for your project made your resume stand out.
However, imagine that after now being educated with what your project is, I find out that your project is something an experienced developer in my team can replicate in a few hours. I would instantly throw your resume out.
Why?
Because I would assume that no one in the right mind would ever put a project that took them less than a week to build, especially if they appear as the first or second project in the resume. What I would assume therefore is that if your project is something my engineer or myself could replicate in a few hours, I would assume you are at least 20–30 times slower than me or my engineers (as you’ve probably spent at least a week). I would throw your resume out thinking you’re just not experienced yet.
If your project is something I could build in a day or two, I would still throw our your resume.
If your project is something that would also take me at least a week to replicate, your resume will not be thrown out. Assuming other parts of your resume look strong, I would invite you for an interview.
What are some examples of bad projects?
- Login/registration — I would expect an engineer to build this in a few hours.
- Live Chat — I would expect an engineer to build this in a few hours. In fact, this used to be one of Coding Dojo’s assignments as part of the MEAN stack where we had students build out a live chat from scratch using Socket.io in a few hours.
- Anything that resembles a difficulty level of a Dojo assignment - Anything that I would expect you to complete in a 3–6 hours, never put these as your projects, even if you were learning a new language/tool. Hiring managers will assume you’ve spent at least a week to build something they could build themselves in a few hours, again making a judgement that you’re not good enough yet (and 20–30 times slower than who they need).
What are some examples of good projects? Remember these three wireframes from the bootcamp? A good project needs to have an equivalent number of features as these three examples.
Example #1 — Full E-commerce website
Example #2 — Employee Clock In/Out System
Example #3 — User Dashboard
How does your project (especially the first two projects you’ve listed) compare with the three examples above? If you project has less features, beef up your project before showing your resume to anyone. It’s better that you beef up your project now rather than waste weeks of your precious time reaching out for interviews without hearing back from employers, especially if they thought your projects were too weak.
They would never flat out tell you that your projects sucked (as this would go against their HR policy). Even if they were not advised against giving such direct feedback, they simply don’t have the time to give each rejected candidate a reason on why the application was rejected.
If you know your projects are weak, beef up your projects and then start applying for jobs again. It will take you less time to find a job this way than to apply to hundreds of jobs and get hundreds of rejections. It will also feel better going this route.
Tip #5: Fix all spelling and grammar issues
English is my second language and I haven’t been so good with grammar and spelling. Even then, when I look at resumes, I have a hard time looking kindly at resumes with multiple spelling and grammar errors. Compounded with the fact that I usually have to review 50–100 resumes in an hour, when I am on the resume screening mode, I am looking for reasons to throw away resumes out. I know subconsciously I may be throwing out some good resumes but as I just don’t have time to read through all the resumes in detail, I have to believe that those whose resume had spelling errors or grammar issues, or inconsistent style, must be from those who lack attention to detail. As I don’t want my engineers to lack attention to detail, I throw away these resumes.
If I am harsh on spelling errors and grammar issues (even when English is my second language), how much harsher do you think other hiring managers would be where English is their native language? Note that spelling errors and grammar issues can be spotted within seconds, which is why it’s a great filtering tool for hiring managers to quickly weed out resumes.
Tip #6: Follow consistent style for your headers, bullet points, etc.
One way a hiring manager can quickly weed out “bad” resume is by throwing away all resumes that have inconsistent look/style. For example:
- Do your headers (Education, Work Experience, Projects) all have the same font size, margin (for top, bottom, left, and right), and style (italic, bold, etc)?
- Do the dates for appropriate education, work experience, etc, all show up consistently in the same place? Any that’s not placed on the same side of the resume compared to the rest of the dates?
- Do the bullet points show up all aligned? Do they follow the same line-spacing and margin/padding on the left/right as well as top/bottom throughout the entire resume?
- Do you use too many font sizes in your resume? If your font size changes so often, you’re making it harder for the hiring manager to quickly review your resume. As a rule of thumb, I would not use more than 2 colors in your resume and no more than 3 font sizes. Anything more than 2 colors or 3 font sizes distract the eyes and make your resume look disorganized.
Do not ignore these style inconsistencies. These also show a sign of lack of attention to detail, which you do not want to show in your resume.
Tip #7: Don’t list job descriptions. List accomplishment statements.
I usually review the first two bullet points in the candidate’s first two work experiences or education (if they are recent grads). If it’s a generic job description and not an accomplishment statement (something that only A players can state), then I get wary about interviewing that person.
My assumption is that those who only put mere job descriptions could be those who were hired to do that role but who could have been fired for not delivering the results the company wanted or those who lagged behind the top performers in the team and was laid off finally after years of mediocre performance.
For each of the work experience you’ve put, ask yourself how you would answer, if the hiring manager asked you, “So for this role, what specific accomplishments have you made that you’re proud of?” Or what if they asked you “how did your performance compare with your peers during this role?”
Write down how you would answer these two questions and then turn them into bullet points in your work experience section. Highlight any promotions, rewards/recognitions you’ve earned, important projects you were assigned, how your performance stood out from your peers, etc.
Tip #8: Make your resume look dense
Hiring managers usually look at your resume for about 10–15 seconds before deciding whether to throw your resume out or whether your resume is worth another 15 seconds for them to click on one or two links in your resume.
How your resume looks in the first few seconds is therefore extremely important. Any resume that doesn’t look like it’s packed with information will give the first impression that you’re not good enough.
For example, see below:
How does your resume look in terms of the word density? If it looks like the left, I would assume 90% of the time, your resume would be thrown out by hiring managers. If it looks like the right, regardless of the content, your resume will be seen for 5–10 seconds longer than the left.
If you have a lot of work experiences, it’s okay to make your resume into a two page. Not all resumes have to be a single page, especially if you already have years of industry experience (even if it wasn’t coding related).
Summary
A resume gives the first impression of you as a developer and hiring managers will give your resume at most 10–15 seconds. How your resume impresses hiring managers (as well as pass the screening by algorithms in the ATS system) is critical to whether you get one interview request per week or dozens of interview requests per day.
I have had numerous graduates go from no interview requests each week to dozens of interview requests each week by simply following the steps outlined above.
I do understand how it’s a pain to craft your resume. I also understand and agree that resume is not the best tool to gauge one’s ability. However, let’s recognize that resume is really just a first impression tool and even if you’re a really good developer, if your first impression is not good, that would be like going on your first date wearing pajamas, with your hair all messed up, and with food crumbs all over your face. We all understand the first impression at a date could be misleading. Similarly, a resume could also be misleading. However, when everyone is showing up with their best behavior, you must also put in the effort to make your resume look decent also. If you don’t, even if you’re a great developer or have great potential to be a great developer, your resume may be the biggest stumbling block for you to unlock your potential.
Spend the time to refine your resume based on the 8 tips above and continue to practice algorithms while your resume is being refined. Utilize Hacker Hero (www.hackerhero.com) to also continue getting better with algorithms and data structures. If you do this, your chance of getting interviews and finding the ultimate job you always wanted will significantly increase.
If you did your best revising your resume based on these tips, and you are a Dojo alumnus, you can also email me with questions or have me look at your resume to give you some feedback. My email is michael@village88.com.
Good luck! You do have an advantage as you’ve picked up a lot of skills from the Dojo and once your resume is refined, you’ll do much better in scouting for opportunities. You can do this!
Feedback?
I do want to make this article more polished and have it read better. However, I am struggling. Not sure exactly why but I am not sure if the points in this article are being communicated effectively or whether I am not explaining my point of view that well. If you have suggestions on how I can make this article better, please let me know.
