Category: Resume tips

Java Developers and Their Long, Horrible Resumes

Let me start by saying that I consider myself a longstanding friend and ally to the Java community. As some readers will know, I founded and ran a large Java Users Group (I miss you Philly) for 15 years, and much of my career was spent focused entirely on recruiting Java professionals. In one capacity or another I have probably helped thousands of Java developers get jobs, and even though I no longer focus on Java in my practice or run the JUG I will always be linked to Java.

But now we need to have a talk.

I read a lot of resumes. I get them from applicants who apply to jobs that I have posted. I get them from (mostly) junior people on Reddit where I mod a career questions subreddit /r/cscareerquestions. And I get them from my Resume Raiders clients who are looking for me to either review or rewrite their resume for them.

So although my data is anecdotal, I have a lot of it — about 18 years’ worth to be exact.

When I get resumes from Java professionals, I’d estimate that on average they are 1.5-2x as long as resumes from other developers of similar career lengths.


One could think it might have something to do with age. Java has been popular for a long time now, so the age of the average Java developer might be higher than say those doing Ruby or Python work. Anecdotally, I don’t think this is it, as I see relatively shorter resumes from highly experienced candidates that don’t use Java.

Some might think it could have a cultural element. The Java community in the US may have a larger contingent of international talent than other language communities, and other countries have different resume/CV styles and acceptable lengths. Java resumes from those who were born overseas tend to be noticeably longer than their US-born counterparts, but I also see non-Java resumes from foreign-born developers that tend to be shorter than the Java devs.

Do Java devs move around more than those in other language camps, and more jobs results in longer resumes? Generally speaking, I don’t think so, and in many cases the opposite may be true, with long tenures being somewhat common for Java devs at large firms. Workers on visas under contract do tend to get moved frequently between projects all across the US, and this can account for length for those in this type of work.

One might surmise that the lengths could be related to the vast number of tools and technologies available over the years in the Java ecosystem. Listing an abundance of frameworks, app servers, IDE’s, testing tools, etc. that one has used over the years could require a good deal of real estate, and those who are writing their resume may be a bit liberal in their skills listing if they are aware of ATS products (robot readers) that scan and score the resume for keywords. It’s true that the skills section of the average Java dev resume is almost always a couple of lines longer than those from other language camps, but the skills section is a rather small percentage of the overall document.

I’m not going to make the link between Java being verbose and Java resumes being verbose. But perhaps I just did.

Why Does it Matter?

I’ve written a ton of material about resumes, and resume length raises a few major concerns.

  • Communication skills: Efficient word usage is a desirable trait for an employee who will be potentially writing documentation (not to mention code) to be consumed by other employees. Unnecessarily verbose resumes don’t reflect strong communication skills.
  • Signal vs. noise: There are elements of every resume that account for signal (the reasons that a hiring company will hire you) and then there is noise (anything else). A long resume tends to make it hard for readers to find the signal in a sea of noise.
  • Intimidation: Hand a recruiter a resume and say “This one is only five sentences”, and the recruiter will read every word. Hand a recruiter and say “This one is 20 pages”, and the recruiter will immediately start trying to look for reasons to stop reading. Even a minor indication that this candidate isn’t a perfect fit could be used as an excuse to hit delete and move on.


Unfortunately, I don’t feel I have a good answer to explain this one. I’d be happy to hear from anyone who feels they might. In the meantime, if you are one of those with a resume over three pages, try to optimize what you have. Your inclusion of every minute detail is not helping the reader.

The Worst Resume of the Week: Who are You?

Anyone who has either been a client of Resume Raiders or has read my articles about resumes knows that I am a firm believer in powerful summary/profile statements. There are many who feel a summary is not necessary, and in some cases that may be true, but I see an increasing number of resumes that either include a somewhat cryptic profile section or exclude a summary altogether (sometimes including an objective instead, which is worse).

This Week’s Resume

The inspiration for this post was a resume that led off with a somewhat long summary that I won’t include to protect the innocent, but here are some highlights:

Quick learner…motivated…team player…self-driven…solutions-focused

After reading the summary, even the most experienced technical professionals would have a hard time guessing

  1. What this person actually does for a living
  2. Whether this person is entry-level or senior
  3. Why this person might be a fit for almost any position imaginable

Image title

Although the claims being made are considered positive attributes, they could apply to candidates in virtually any profession with any range of experience. When the introduction doesn’t bring the reader any closer to a decision, we may wonder how patient the reader will be before abandoning the task. In the case of this resume, omitting a summary (and getting right into the experience) may have yielded better results, as at least the reader would not have wasted any amount of time on material that doesn’t help solve the problem.

No Summary

If you choose to exclude a summary statement, what is the result? It forces the resume screener (let’s assume it’s a human) to go through your document and arrive at their own interpretation of who you are. If the reader’s interpretation does not match the job requirement the resume is trashed. What could possibly go wrong?

The choice to omit a summary is equivalent to blindly trusting an unknown person to read a document and arrive at the same conclusions as the writer intended. From experience, I can tell you that the aforementioned “unknown person” can be almost anybody. At best, it’s a highly technical person with an open mind who understands your experience and is interested in learning more. However, it is almost as likely that the person is a temp six months out of school that doesn’t know the difference between CoffeeScript and COBOL who was tasked with managing the jobs@ email inbox simply because nobody his time is considered the least valuable to the company.

Cryptic Summary

A poorly-written summary can potentially do even more damage than a blank space. Most summaries are only guilty of being a waste of space, with lists of trite phrases, corporate-speak, and self-assessments that mean absolutely nothing to the reader. These don’t necessarily hurt the candidate’s chances of interview, but they require the screener to both read further and interpret correctly. It’s a missed opportunity.

Inaccurate Summary

Being that the summary is essentially the tl;dr of a resume, if a summary seems to indicate that the resume belongs to someone lacking the experience sought (to include relevant skills at the appropriate career level), why would anyone bother reading further? Even resumes of candidates who are highly-qualified for a job can lose their reader if they overshoot on the summary (emphasizing inapplicable expertise, overstating management vs hands-on experience, et al).


Include a summary and use the space to clearly lay out what you do and the amount of experience you have doing it. If a stranger can’t easily determine these things after reading your summary, you are better off removing the summary entirely.

Worst Resume #1: Template of Doom

It’s not surprising to see the increased use of resume templates by technology professionals, as the industry avoids the need for reinventing the wheel by creating new frameworks and templates. I would imagine that perhaps 50% of the resumes I see in my recruiting work and my resume business were built using a template.

So far I have never used any templates when writing resumes for Resume Raiders, but I understand the temptation. The problem with resume templates should be obvious to anyone who has been forced into using a framework/language/tool that was unfit for the task at hand. The resume template has to somehow work with the material that is to be showcased – otherwise the resulting document will have issues.

Our inaugural Worst Resume of the Week candidate, Template of Doom, is a fine example of a template gone wrong.

Image title

This is a relatively common two-column template that I see frequently used by developers and designers with varying levels of success. I’ve deleted the actual content to protect the guilty party, but does anyone see the problem?

Mistake #1

The person who selected this resume surely had the option to include some text fields or other blocks in the left column, but didn’t take advantage. In this case, one can only surmise that the template user simply liked the color red. Unfortunately, now a one page resume has turned into a three page resume because most of the page is just a block of red. Image title

A two-column resume can work for some people, but that format is rarely effective with for resumes longer than one page. This user included name, contact info, and links (GitHub, LinkedIn, blog) in the marked white box. The space below that box could have been used for relatively short bits of information, which might include education, certifications, or technical skills.

If you choose to go with two columns, make sure you actually need (and will use) the second column – otherwise it looks ridiculous.

Mistake #2

The content has been deleted for obvious reasons, but this resume included the words “I/me/my”over 20 times. The use of first person is not generally recommended, but the repetitive use of first person starts to sound like someone taking full responsibility for tasks that may have been a team effort.

Use the first person, but avoid the pronoun. “I developed a…” becomes “Developed a…“, and so on.

Mistake #3

Most templates include default section headings, and it’s assumed almost all users will want to include details for common default sections such as Experience or Skills. The issue is when the default headings are kept from the template but don’t apply to the individual user’s career history.

In these situations the headings may actually highlight an area of weakness instead of a strength. Job seekers without certifications, formalized education, or volunteer experience are better off deleting those sections entirely instead of listing “NONE” or trying to force an entry that may shine a light on a shortcoming. Just because a template includes a section doesn’t mean you should list that section on your resume.

Many templates will also include an objective section, which is now considered a bit passé.


Use templates with caution. Two-column templates are almost exclusively beneficial to single page resumes. Avoid using first person pronouns. Don’t think you need to keep every section recommended by the template.

How to Brag: Describing Accomplishments on Resumes

Almost all of a resume’s useful content can be categorized in one of three ways.

  1. Responsibilities – Something that was part of the job on an ongoing basis.
  2. Skills / Traits – These may be referenced as part of an introductory profile/summary at the top or in a skills section. I’ve learned that many people have difficulty differentiating between skills and traits, which is why I mention both (but please learn the difference, and focus on skills).
  3. Accomplishments – These are typically rather unique projects that were completed.

Most of the resumes sent to me at Resume Raiders feature long listings of skills and traits (usually self-assessed and trite), several bulleted responsibilities, and scant mention of accomplishments. This is a problem.

Based on my conversations with resume clients, it seems that the absence of accomplishments is often a function of modesty and an unwillingness to essentially brag about something they’ve done. I find myself coaxing clients into sharing more details than they were initially unwilling to share. Other times it is an inability to recognize what qualifies as an accomplishment in the first place.

Regardless of the reason that a resume lacks tangible accomplishments, employers are looking to know what you have actually done, so it may be a useful exercise to review your resume and try to categorize the content as either responsibility, skill/trait, or accomplishment.

What Qualifies as an Accomplishment?

This can be especially complex for junior level job seekers who are generally responsible for smaller parts of larger efforts. As for some examples of accomplishments worth listing:

  • Cost savings – Any efforts that resulted in significant reduced spending are worth noting. This can be saved licensing fees, payroll, hardware costs, services, or any number of things related to your work.
  • Deliverable met – Product being shipped or projects completed are clear accomplishments worth noting.
  • Measurable improvements – Performance metrics, user acquisition, and other positive measurable improvements are an easy approach to determining an accomplishment.
  • Change – The introduction of new methodologies or product implementations are highly regarded, although the results of these changes may be difficult to measure over small time periods.


We want accomplishments to stand out, and that’s why we have bullets. For any individual job listed on a resume, the ideal situation is to first have a few sentences in paragraph form to describe responsibilities (and perhaps the employer) followed by a handful of bulleted accomplishments.

Most resumes tend to overuse bullets. If you bullet everything, you’ve highlighted nothing.

Phrasing and Structure

Once we have determined what qualifies as an accomplishment, we need to write the description. What are the key required elements?

  • Role – It is usually necessary to clarify the role(s) played on the project in order to avoid being given too much or too little credit. A bullet might begin with “Led” or “Designed and developed”, which allows you to define role quickly and effectively. Projects involving leadership may choose to include team size.
  • Description of solution – This should include the problem solved and reference at least some of the tools used to do it. It seems that most resumes include detail on the problem without any mention of the languages/frameworks/etc., or list far too many details on the tools without any background.
  • Result – Ideally the resume will reference a positive outcome from the project, preferably with data.


Accomplishments should stand out from the other content. Remember that the resume serves as a conversation starter and not a biography, so it isn’t necessary to list every detail of a project. Accomplishment bullets are often the subject of interview questions, which gives the opportunity to frame your own interview. Provide enough information to pique interest, and let the interview provide the platform to dive deeper.

So You Say You’re An Expert?

Whether through my recruiting endeavors or the private resume services I provide to job seekers, not a week goes by where I don’t see the word “expert” somewhere on a resume or cover letter. “Expert in $LANGUAGE” isn’t all that uncommon, and today the expression of expertise may also be depicted through a horizontal bar graph where several languages or concepts are rated as “beginner“, “intermediate“, or (here it comes…) “expert“.  PROTIP: Don’t use bar graphs to demonstrate knowledge.

When the source is a professional that appears to have deep experience in a subject matter, I’m not likely to even pause. However, it’s exceedingly rare these days that the claim of expertise comes from someone likely to fit that description. I’d venture to say I see it from recent graduates and students much more often than experienced technologists, which in itself may demonstrate my point.

There are two significant issues with claiming expertise on a resume or job application.

  1. The claim demonstrates that you probably don’t even understand what expertise would look like. I’m sure many readers are at least somewhat familiar with the “10,000 Hour Rule” claiming that is the required practice time to master a subject. Whether one agrees with that theory or not is irrelevant, as most of those in the programming world would understand that it’s highly unlikely (if not impossible) to become an expert based on an undergraduate curriculum and a couple internships. A claim of expertise related to a robust programming language may even indicate that the source knows so little about the subject as to even be able to recognize what might qualify as expertise.
  2. You are now a target for people who know more than you do. I’ve seen countless incidents of hiring managers responding with, “So this one is an expert, eh? Schedule him/her for a phone interview with $BESTDEVELOPER and let’s find out!” when a resume claims expert skills. The claim of expertise has now raised the bar for the interview and evaluation process, and your candidacy will face a much higher level of scrutiny than those who are either more modest or more knowledgeable about their own limitations.

There are better ways to demonstrate expertise than a biased claim or a trendy bar graph. Developers who succeed in coding challenges or provide samples of past work for critique can leave little room for subjective interpretation by employers. Quantifying your experience along with some accomplishments is another way to indicate ability.

Think twice about claiming to be an expert. You’re usually doing more harm than good.

How I Read a Technical Resume

I have spent many hours discussing and writing about how résumés are written, but I’ve never shared much regarding the way résumés are read. I’ve reviewed thousands of résumés, and my process has changed with the times. The description here describes how I read a résumé upon arrival in my inbox, with the only decision being whether I will schedule an initial conversation (with me).

Disclaimer: This is not meant to be a piece on résumés as a hiring tool. I hope to provide insight regarding details that trigger responses in an agency recruiter’s mind. I try to err on the side of “let’s talk” and not “no thanks”.

Keep in mind that (as an agency recruiter) my goal is to first determine whether my client would interview, and to potentially save everyone’s time (client, candidate, me). I’m looking for some number of positives where I’m convinced that we should speak, or a combination of negative flags that make it apparent that an interview (much less a hire) is unlikely. Technology has provided candidates the ability to shotgun résumés even when they are grossly unqualified/overqualified or would almost certainly not accept the job if offered.

The top of most résumés I see:

reztop copy

Location The only data point I retain on the first pass is location. Remember that I have to consider whether my client’s offer would even be entertained, which location can influence. Even if a candidate is not local, I continue reading.

A non-local location becomes a possible flag if the candidate seems rooted in their home city. If Jane’s résumé shows that she has worked in San Francisco for 15 years, the likelihood of a move to my client’s city should be lower. Assuming Jane later appears qualified, I would want to inquire about her thoughts on relocation before potentially getting too far along. Maybe she has a move planned already.

Email/Domain For certain positions I will visit a candidate’s domain to see if there are any items (work samples, technical blog posts) that might reveal something worth highlighting to my client.

GitHub I don’t read code, and I don’t click GitHub links on the first pass. Generally I won’t bother clicking it at all unless the experience section is lacking, in which case I check for personal projects or activity that might help get the candidate in the door.

LinkedIn Again, I don’t click it on the first pass. If I have difficulty understanding any of the résumé material or career history I may visit their LinkedIn for possible clarification.

What follows that top section varies, but I hope for a profile/summary:

summary copy

Summary/Profile A well-written summary or profile statement is enough to prompt my decision to initiate dialogue without reading much further. I encourage my candidates and résumé customers to include one. Even if the profile isn’t strong enough to get an immediate “let’s talk” response, it should help steer the reader to which content is relevant.

One can sometimes predict a candidate’s level of confidence/overconfidence or even a blatant lack of industry knowledge from a summary. Entry-level candidates using terms like expert or master to describe themselves are a slight flag.

There is a trend for candidates to create summaries consisting of several bullets (5-15) of information. A summary is intended to be shorter by definition, and these summaries indicate someone who may not understand what is relevant.

Experience is usually next (education for entry-level):

exp copy

Experience I’m obviously looking for accomplishments and the candidate’s ability to put them into clear and concise terms. Were projects completed? For more experienced candidates, I’m looking for consistency with respect to responsibility and role. An abundance of internal acronyms and company-specific jargon without context is a flag, indicating the candidate may be insulated. Is it clear what the candidate has done?

I’m also observing how the candidate weighs details of their own work history. Candidates tend to lead with and highlight the experience they feel is most important and valuable, which provides insight as to their objective. Those looking to distance themselves from code may list leadership and management responsibilities (project management, mentoring, training, hiring, etc.) before more hands-on duties (architecture, development, etc.), whereas someone disinterested in management will likely emphasize and quantitatively detail a challenging technical problem and the solution.

Dates I look at dates to see if there is a pattern of large employment gaps, but I won’t discount a candidate based on gaps alone. I pay attention to long tenures at organizations and whether someone was able to accomplish several things over years.

Employer Names These are particularly useful when I am familiar with a company’s technically rigorous interview process, as a candidate’s hire by such a firm should at least indicate interview ability (though admittedly not job performance). If I have knowledge regarding how well/poorly a company compensates their employees relative to my client, employer name reveals a high price tag or perhaps an ability to give a significant increase.

Locations As referenced earlier, I notice non-local cities (if listed) and assess the probability that someone would relocate if necessary. When a résumé lists different geographic regions for every job, it can be indicate a candidate willing to go anywhere for an interesting job or someone that chases the highest bidder. If someone is likely to be interviewing nationwide, the odds of any individual joining my client fade.

A skills section often follows:

skillsrez copy

Skills Obviously I scan to see if the list remotely resembles the job description, particularly if the client has any strict must haves. Hopefully by now I’ve determined what the candidate has done by reading the experience and not buzzword searching. I gauge whether the overall skill set resembles the typical preferred profile of my client based on past hires. Listing a clearly unrealistic number of languages or skills is a flag, with the judgment of “realistic” based upon overall experience while allowing for a degree of self-study.

Last (first for entry-level) is usually education:

rezedu copy

Once I’ve come this far the decision is made and the information here is unlikely to make me reconsider. I’ll glance to see if it’s a school I recognize as having a good or bad reputation, whether overall or for the program completed. I check if the graduation year matches with the earliest listed experience experience, as that may expose internships or a past career change. I don’t pay much attention to GPA for experienced candidates, and certifications tend to be ignored with few exceptions.

There may be other details on the résumé that don’t fall into these categories.

Personal Projects/Meetups/Hobbies Some candidates will dedicate a section to these or list them under experience. These don’t matter much for those with interesting professional experience, but can help push a questionable candidate into the let’s talk group.

References I’d never encourage a candidate to list the names of references on a résumé, as I think it’s disrespectful to the reference. Unless the reader recognizes a name, the information is useless at this point and unnecessary. References will be requested when necessary.

Why Technical Résumés Need a Profile (because we’re dumb)

There is significant variation in résumé format across candidates. Name and contact information is always on top, but on any given day a recruiter might see the next section as Education, Skills, Experience, or even (gasp) an Objective.

Career length influences which section comes first. Entry-level candidates usually choose Education, while veteran candidates gravitate towards experience and accomplishments. Unfortunately, going from a glance at contact information to dissecting intimate project details doesn’t make for a smooth transition. It’s jarring. A section that serves as a buffer to introduce résumé content that also subliminally instructs the reader on what content to pay attention to will help.

And remember the résumé’s audience. Most recruiters and HR personnel don’t have the background of the candidates they assess, so reviewers benefit from any guidance (even subliminal) provided to understand content. Since few grow up aspiring to the glamorous world of tech recruitment, the industry is typically stocked with C students.

Since a résumé “states your case” to employers, let’s look at lawyers…

The Purpose of Opening Statements

When trial attorneys present cases to juries, they don’t immediately start questioning witnesses. They start with opening statements. Why?

The opening statement informs the jury as to what evidence they will hear during the trial, and why that evidence is significant to the case. The statement is a roadmap on what the attorney wants jurors to listen for (or ignore) during the trial and which elements are critical to the case. It provides background information and announces what is forthcoming.

Before trial, jurors know nothing about the case. Without opening statements, jurors may get lost in trivial details while missing out on the important elements the attorney wants them to hear. Attorneys can’t trust a jury’s ability to make those decisions independently, so opening statements influence thought process.

It is paramount that attorneys present their case in a manner consistent with their opening statements. Diversions from that roadmap will cause the jury to distrust the attorney and detract from the attorney’s credibility.

Back to résumés… Just as jurors know nothing before trial, recruiters know nothing about applicants until they open the résumé. Job seekers today are less likely to provide a cover letter (with recruiters less likely to read them), and résumés are often given brief initial screening by untrained eyes. This creates a problem for qualified applicants who may be wrongfully passed over. What is the optimal strategy for expressing experience and ensuring that even novice reviewers will properly identify qualified candidates?  An opening statement.

The Purpose of the Profile

Profiles are the opening statement in a case for an interview, with the résumé content that follows the evidence. The Profile introduces experience to be detailed later in the document, which tacitly baits reviewers into seeking out evidence to specifically support (or refute) those claims. A résumé without a Profile makes no claims to be proven or disproven, and doesn’t give the reader any additional instruction on what to seek.

When Profile claims are corroborated by details of experience, it results in a “buy” from the reader. The Profile was a promise of sorts, later fulfilled by the supporting evidence.

When a Profile doesn’t reflect experience, it exposes the candidate as a potential fraud and detracts from any relevant experience the candidate does possess. Qualified candidates with overreaching Profiles put themselves in a precarious situation. Even well-written Profiles are a negative mark on applicants when the claims are inaccurate or unsupported. Just as attorneys must lay out cases in accordance with their opening statements, experience must match Profiles.

Typical Profiles Are Noise, Not Signal

The overwhelming majority of Profile statements are virtually identical. Words and phrases like hard-working, intelligent, dedicated, career-minded, innovative, etc. are, in this context, mere self-assessments impossible to qualify. It’s fluff, and contributes résumé noise that distracts readers’ attention from signal.

Writing Profiles

Useful Profiles clearly say what you have done and can do, and are ideally quantified for the reader to prevent any misunderstanding. If a temp at a startup is tasked to find résumés of software engineers with Python and Django experience, he is unlikely to ignore résumés with Profiles stating “Software engineer with six years of experience building solutions with Python and Django“.

For candidates attempting to transition into new roles that might be less obvious to a reader, a Profile must double as a disguised Objective. These Profiles will first state the candidate’s current experience and end with what type of work the applicant seeks. “Systems Administrator with three years of Python and Bash scripting experience seeks transition into dedicated junior DevOps role” provides background as well as future intent, but the last seven words are needed to get the average recruiter’s attention.

Just as Objectives are altered to match requirements, consider tweaking a Profile to highlight required skills. A candidate that identifies herself as a Mobile Developer in the Profile might not get selected for interview for a Web Developer position, even when the résumé demonstrates all necessary qualifications. How a candidate self-identifies suggests their career interests, unless stated otherwise (see paragraph above).

Based on the importance of having Profile/experience agreement, it’s suggested that the Profile is written last. Lawyers can’t write an opening statement before knowing their case, and candidates should have all of their corroborating evidence in place before attempting to summarize it for clear interpretation.


Assume your résumé reviewer knows little about what you do, and that they need to be explicitly told what you do without having to interpret it through your listed experience. Identify yourself in the Profile as closely to the job description (and perhaps even title) as possible. Make sure that all claims made in the Profile are supported by evidence somewhere else in the résumé, ideally early on.