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:
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/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):
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:
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:
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.
Most extended discussions about the technology industry and software engineering trade eventually find their way to the topics of worker supply and demand, talent shortages (real or otherwise), and compensation. Every Best Jobs of The Year list (examples here or here or here or here) features a Top 10 littered with assorted job titles given to those who code, often including salary data that could cause non-technical readers to regret life decisions.
New graduates entering the industry may receive multiple salary offers that dwarf those of non-coding classmates, and after five years on the job it might seem as if there is no limit on future earning potential.
What they probably don’t tell you in school or during your first few jobs is that most in the industry will hit a compensation plateau, where increases become smaller and less frequent. Market rate for skills increases with experience, but once a certain level of experience is reached the market rate flattens.
As an example, market rates for developers with 10 years of experience vs 15 years can be indistinguishable. Making lateral moves or even taking a pay cut in exchange for some potential asset (acquire a new skill or experience, equity, etc.) start to become best options.
The amount of time it can take to plateau varies. Someone who stays several years at one employer where small raises are standard may take 15 years to plateau, whereas someone changing employers with relative frequency or alternating between consulting and direct hire jobs may plateau early.
Ways to Earn More
When you’ve reached the plateau but have some need to earn more, there are a few methods to consider.
Move out – The most effective means to more compensation is still to get a job with a different company. This method usually becomes less effective at the plateau than it was earlier on, but there is almost always another company willing to pay at least a bit more.
Move up – Gaining more responsibility through an internal move should come with more salary. If the company is top-heavy or there is a line for advancement, moving both up and out may be necessary.
Ask – If money is the impetus for considering a change of any kind, why not ask your current employer first? If the answer is ‘no‘ now, they may become more cooperative when you have other offers in hand (not that I’m suggesting counteroffer as a sound strategy).
Branding your additional benefits – Professionals with similar accomplishments and years of experience appear homogenous and plateau. In addition to the productivity and ability that comes with years, are there other benefits that an employer receives by hiring you? Candidates with higher public profiles due to community involvement, such as Meetup leaders or conference presenters, may command a higher salary due to the increased visibility or prestige that their hire would provide a company. Candidates that are likely to be followed to a new employer by a loyal network of talent might justify higher prices.
Consulting and contracting – Contractors and salaried employees of consulting firms both typically earn above market rate for direct hires. A move to contracting or a consultancy can be a sound strategy for those in traditional non-consulting direct hire jobs, but consultants and contractors will also plateau over time.
Moonlighting/revenue streams – Those that have some extra time might consider taking on off-hours remote contract work to increase earnings. Building and monetizing a product may result in additional dollars with minimal long-term time commitments.
Specialize – Becoming recognized as a specialist in a niche area may make it easier to command rates above market. Those specializing in the newest technologies may be able to take advantage of the fact that a market rate has not yet been established.
Several times a week I am asked by a contact/reader/someone on Reddit for advice on what they should learn next. The question comes from both junior and experienced programmers, and has been posed both as open-ended (“What should I learn?“) and multiple choice (“Python or Ruby?“, “Django or Flask?“, “iOS or Android?“, etc.).
Unless it is someone I’ve worked with, there is usually little (or no) accompanying information or context provided which makes any answer rather speculative. To respond with hard data on compensation figures or even an informed opinion regarding future demand for a skill may be helpful, but offering career advice blindly without any knowledge of the person borders on irresponsible.
The easy answer (the long view) is to just say that overall programming ability and knowledge are the most important factors in maximizing employability, and that languages and tools are mostly interchangeable for experienced professionals. “Any good engineer can learn a new language in n weeks/months” is commonly heard from those at the senior level. Whether this is true or not is debatable, but it still does not account for a multitude of factors that may make a particular language more favorable than another to an individual at any given time.
One needs to think of learning as a time investment, and investors need to consider maximizing ROI. Before deciding where to invest their time, it may be wise to research and evaluate some of the following.
- Programming experience and background – Those with little or no programming experience are usually pushed towards a few languages, with Python and Ruby the most popular among bootcamps and courses aimed at beginners. Experienced programmers that have a larger set of realistic options may consider how quickly a language might be picked up based on the paradigms and concepts that are already familiar. Build on what you know. Many Java developers were C++ refugees in the late 90’s, and Java pros of the past decade are venturing into Scala and Go.
- Availability of learning resources – People learn in different ways, so it’s important to first recognize their best learning method and then research what resources are available. Those who learn best by doing can find it challenging or expensive to find resources and tools for proprietary or highly-specialized languages. Classroom learning opportunities or books on emerging languages often don’t exist or may be cost prohibitive relative to common languages. Documentation and support for newer tools can be spotty or unreliable.
- Market supply and demand – If employability is the impetus for learning (as opposed to intellectual curiosity, boredom, etc.), both the current and projected supply and demand for talent is worth noting. Supply and demand are not necessarily universal trends and can vary based on geography and experience level. As an example, demand for entry-level Haskell talent is almost non-existent but rises significantly with experience. Searching for jobs specifically within desired geographic regions and doing research with a tool like Indeed’s Job Trends may provide some insight into both local and national data.
- Professional goals – What types of products do you want to work on? Those interested in gaming might benefit from different choices than those interested in web development or embedded systems. Do you measure job satisfaction by professional accomplishments or is compensation a bigger motivator? Certain industries pay better than others, and certain languages are more prevalent in those industries.
- Popularity and adoption trends – Learning an esoteric language that employers don’t use can be helpful in becoming a better overall engineer, but useless for putting food on the table. Trying to become reasonably productive in a language after hours can take time, and the adoption levels and/or popularity of a language could potentially change during the learning process. Researching current and historical data can be helpful. In addition to Indeed Trends, other sources include the ThoughtWorks Radar, RedMonk rankings, and the TIOBE Index. Always consider how the ratings are assembled, past performances to determine trends over time, and keep in mind that others may be using the same data to make decisions. Just because a language is “#1″ today doesn’t mean it will be in a year, and identifying and prospecting underserved language camps experiencing high demand is one way to employability before the market supply catches up.
- Community or vendor support – Is there a community of people dedicated to keeping the language vibrant and relevant? Is the language supported by a vendor in good standing, or are the stewards of the language in a poor position to continue? Regarding community, Raganwald tweeted this back in February and it resonated.
What did I miss?
Anyone who has worked with a recruiter has probably been asked “Where else are you interviewing?” or “What other companies have you applied to?“. The question comes from both agency recruiters (‘headhunter‘) representing several hiring firms and internal corporate recruiters hiring only for their company. Candidates are understandably not always willing to answer, and recruiters may stumble to give convincing explanations as to why they want to know. Some recruiters will insist that they need to know.
Technologists with some natural level of distrust for recruiters are likely to question a recruiter’s motives in asking. It’s useful to consider when naming names is relatively harmless, when to avoid the question, and one scenario where it may be in the candidate’s best interest to provide an honest answer. Let’s look at some common explanations given by recruiters and the possible motivations behind the request.
“I need to know so I don’t send your résumé to companies where you are already in play” – This answer is exclusive to agency recruiters, as internal recruiters don’t send resumes outside their company. On the surface this response seems valid. If your résumé is sent to a company that is already considering you it could be costly. Companies that receive the same résumé from two recruiters may fear being invoiced for two placement fees, or even see this as a sign that the candidate has poor communication skills.
The simple solution for candidates is to instruct agency recruiters to divulge client names and ask permission before submitting résumés anywhere. Be wary of recruiters who are unwilling to accept this compromise.
“I need to know if we need to speed things up” – If a candidate is already involved in the interview process with other companies, it is in the candidate’s best interest to inform the recruiter as to how early or late they are in the process. This maximizes the candidate’s chances of being able to have their candidacy expedited if necessary, which raises the potential for multiple competing offers. However, the identities of the companies competing for a candidate’s services are irrelevant unless the recruiter happens to know the typical process and estimated duration at the other firms. Are the competing firms historically slow or fast to act? Many recruiters will claim to know these details, but most will not.
It makes sense to say how far along you are in that process, but identifying the company isn’t useful.
A litmus test for candidate control – Candidate Control is a recruiting concept where a recruiter tries to establish influence on a candidate’s actions throughout the recruiting process which will in theory make it easier to get a “yes” from the candidate when an offer is made. This control is acquired over time, and the recruiter’s process in achieving control starts with the candidate complying to various simple requests. A recruiter can gauge how much control they might establish by asking questions that could make candidates uncomfortable.
Competitor lists – For internal recruiters, the answer reveals potential source companies where the firm can solicit and poach employees. This is harmless to candidates, which is why some may choose to help friendly recruiters by sharing information on where they were interviewing only after they have accepted any offer.
Fishing for new clients – If you tell an agency recruiter that you are interviewing with Companies A and B, that provides two new client leads where he/she can market other candidates with similar backgrounds. This practice is harmless to a candidate unless the recruiter immediately contacts the companies and attempts to insert other candidates into the pipeline that will now compete for the position. If a recruiter does choose to pursue named companies as new clients, they should feel some ethical obligation to wait until their candidate has completed the process.
Leverage at offer stage – If the recruiter (agency or corporate) learns you are considering an offer from a company that has public scandals, layoffs, bad public reviews, or some other negative association, prepare to hear about those reputation issues when the recruiter tries to get you to accept an offer from their client. Unscrupulous recruiters might concoct rumors just to influence your decision. Knowing details about the competition makes it relatively easy for skilled recruiters to highlight areas where their client’s offer is favorable to a competitor’s offer.
This motivation is the most damaging, as it is solely intended to dissuade candidates from taking other offers that may best for them. Independently validate any claims made by the recruiter regarding companies he/she does not represent.
When Should You Answer
In most cases, revealing the names of other companies where you are interviewing is helpful to the recruiter but not necessarily helpful to the candidate. One exception would be to name any firm(s) you are speaking to that has an outstanding employer reputation. This strategy could serve two purposes. First, it signals that your skills are in demand by major players, and suggests your skills are on par with high-end talent. Second, it lets the recruiter know that an offer will need to be competitive with what one might expect from top employers. Recruiters are likely to share this information with clients in order to set the client’s expectation regarding compensation package.
After founding the Philadelphia Area Java Users’ Group in 2000 and leading it for 15 years, I’ve decided to resign my post and pass on leadership to someone else. It’s time. At our first meeting in a small and long-forgotten dot com, 35 Java developers came to eat pizza and listen to a presentation on XML and JAXP. Since then we’ve had about 100 events (a few with 200 attendees) and a mailing list that peaked around 1,500 members.
My experience running this group has revealed some patterns that may be useful for other user group leaders (or those looking to start one), ideas for speakers, and observations on the career paths of many members I’ve known for an extended period of time.
Topic suggesters and early adopters – A group of roughly ten members regularly suggested meeting topics then unfamiliar to me, but became widely popular a few years later. I relied on this group heavily for ideas at different times, and many of the suggestions were a bit beyond the scope for a JUG. Early on I typically rejected non-Java/JVM topic suggestions, so many of these meetings never developed. Consecutive meetings on Scala and Clojure in 2009 come to mind as an example of being timed ahead of popular adoption.
These ten members included both experienced developers and even a couple who were then only computer science undergrad students. Without exception, the career paths of these specific individuals have been noticeably positive relative to the average career path, and more than half have been promoted from developer to CTO or equivalent. I believe all of this small group have now gone on to using other languages as their primary tool, and all still code regularly.
Language migration – Of the overall membership, the vast majority (perhaps 80%+) are still using Java as their primary language by day. About 5% now focus on mobile development. Another 5% combined currently focus on Python or Ruby, and maybe 3% work in functional languages (Scala and Clojure).
Age – Although I don’t have data, it’s fairly clear that the average age of a member or meeting attendee has increased over the years even as the member roster changed. The group has received far fewer membership requests over the past five years than in the past, and new members are less likely to be fresh graduates than they were in the group’s early days.
Groups sense overhyped technologies – Some of our meeting topics were technologies or products that were heavily marketed through multiple channels (conferences, speaker tours, newsletters) at the time, yet failed to gain traction. Many that RSVP’d to these meetings commented on their suspicions, and some admitted to a desire to attend in order to poke some holes in the hype.
Regulars – At any given meeting, about 50% of the attendees were regulars that attended almost every event regardless of their specific interest in that evening’s topic. Many of these people also regularly attend events held by other groups.
Speaker name recognition – This should surprise no one, but our three largest events by far were all with speakers who had a fair amount of celebrity and industry credibility. These were open source advocate/author Eric ‘ESR’ Raymond (YouTube link), Spring framework creator Rod Johnson, and a joint meeting with Hibernate author Gavin King and JBoss founder Marc Fleury. We had Johnson, King and Fleury around the height of their products’ popularity, and ESR (who is not a figure specific to Java) in 2012. Each event was SRO, with many more in attendance than had RSVP’d.
The next level of attendance was for speakers who had either founded a company or created a product/tool, but perhaps did not have top-tier name recognition. We had eleven meetings of this nature (including the three mentioned), most drawing large crowds (150).
For speakers without a product that were relatively unknown, the strength of a bio definitely impacted attendance. Current job title, employer name recognition, overall industry experience, past speaking experience, and even academic credentials clearly influenced our members.
Local speakers were our lifeblood – About 80% of our speakers lived within an hour drive of our meeting space. We had four presenters who combined for fifteen meetings, and another eleven who all spoke twice. Fifteen local speakers delivered almost 40% of our presentations.
Speakers benefit from presenting – Several of our local speakers have shared anecdotes of being discovered by an employer or new client through a JUG presentation. Even though we did not allow recruiting or sales/marketing people at events, most speakers are easy to contact. Speaking allowed some members to start building a ‘brand’ and increased visibility in the tech community.
The best way to sell is by not selling – Our official policy was to forbid pure product demos, but we knew that when a company flies out their ‘evangelist’ and buys pizza for 150 people, we’re getting at least a minimal level of demo. Speakers who dove into a sales pitch early on would almost always see members start to leave, a few times in droves.
The evangelists who were most effective in keeping an audience often used a similar presentation style where the first hour defined a problem and how it can be solved, and concluded with something like “My presentation is over. You can leave now, or if you want to stay another 15 minutes I’ll show you how our product solves the problem.” This usually led to discussions with the speaker that lasted beyond the meeting schedule, and sales. Making the demo optional and at the very end is a successful tactic.
Accomplished technologists aren’t all great speakers – A strong biography and list of accomplishments does not always result in a strong presentation. We were lucky that most of our speakers were quite good, but we did have at least a few disappointments from those active on the conference speaker circuit.
Ask everyone for something – Companies willing to spend money on sponsorship and travel costs clearly understand the value of goodwill and community visibility. There are also those that want to get that visibility and goodwill for free, and they ask leaders to announce a conference or product offering as a favor or “for the good of the community“. These requests are an opportunity to add additional value to the members.
Instead of complying with these requests, I would always request something in return. For conference announcements, I would ask for a discount code for members or a free pass to raffle off. Sponsors with a product might be asked for a license to give away, or at worst some swag. Most were willing to barter in exchange for their request being met.
Maintain control – Some sponsors clearly just want your membership roster and email addresses, which they may try to acquire by using the “fishbowl business card drawing” approach to raffles, sign-in sheets, speaker review forms, surveys, or perhaps through a bold request. Don’t sell your members’ private information to sponsors under any circumstances, and companies will still be willing to sponsor if you deny their attempts. We allowed a business card drawing once for an iPad, and all members were aware that if they decided to enter that drawing they would likely be getting a call from the vendor.
I was recently asked to answer a question on Quora about startups and stability, and as I read some of the other replies I noticed a trend. The question was basically “Would joining a startup be a mistake for someone with the goals of stability and career progression?”. The questioner then defined stability as being able to support a family and have nice things (financial stability).
The answers ranged from a flat-out “Yes” (i.e. “it’s a mistake“) to “startups provide no stability/career progression“, while another pointed out that most startups fail. The responses were familiar, and similar to objections I’ve received when pitching startups to software engineers over the past fifteen plus years.
Before answering, I considered the many I know who spent most of their careers at startups and small companies in comparison to the people who worked for larger shops. Have the ones that stuck with startups achieved less (or more) stability and/or career progression?
Stability vs Employability
Let’s consider Candidate A who has worked for ten years at one large company, most would say that shows job and career stability. After that length of time, we might assume (or hope for) some level of financial stability and at least a small increase in responsibility that could classify as career progression.
When presented Candidate B with experience at five startups over a ten year span, most conclude this demonstrates career instability or even “job hopping”. Without seeing job titles or any duties and accomplishments, it would be difficult to make any guesses about career progression, but many would assume that a series of relatively short stints might not allow for much forward movement.
Candidate A clearly has more career stability using traditional measures. However, Candidate B’s experience, at least in the tech world, is the somewhat new normal. Job security and career stability (marked by few job changes) is what professionals may have strived for historically, but now one could argue that employability is a much more important concept and goal to focus on.
Today, Candidate A’s company announced layoffs and Candidate B’s startup ran out of money. Who lands a job first? Who is more employable?
Startups Fail… But They’re (almost) Always Around
When job seekers voice concern about the stability of some software startup I’m pitching, I may cede that most startups will fail and the conversation may end there. I might even throw in a “Startups are risky“. These candidates are more concerned about job stability (the keeping of one job) than career stability (the ability to consistently have a job).
The fear is that a company will fail, and the candidate would then be a job seeker all over again with some frictional unemployment and the possibility of worse. Given the failure rate of startups, the fear of a company closing is rational. The fear of any sustained unemployment, at least for many startup veterans, probably is not.
Anecdotally, most of the people I know who gravitated towards small/new firms had little or no unemployment, and most appear to have at least the same levels of financial stability and career progression to those at larger firms. The only visible difference is usually that startup veterans had more companies listed on résumés, may have worked for and with some of the same people at different jobs, and some have a wider palette of technical skills. It’s reminiscent of a successful independent contractor’s background.
Once You’re In, You’re In
After the first startup boom/bust some in the industry tied company stability to career stability or employability, as if being associated with a failed startup might negatively impact future employment options. Many discovered the opposite was true, as those who failed were tagged startup veterans unlikely to repeat the same mistakes twice.
I would expect that those who have worked for multiple startups would likely tell outsiders this: “Once you’re in, you’re in“. Let me explain.
While any individual startup may not provide job stability, an ecosystem of startups will provide candidates with career stability and usually increased employability.
When startups hire, most seek those with previous startup experience. It’s usually right there in the job descriptions. Remember Candidates A and B from earlier? Candidate A hopefully has a shot at a startup job, but B already has an interview.
Due to the transient nature of startup employment and the trend of startup employees to stay within the startup ecosystem, the ability for those in the startup community to get introduced to new jobs via one’s network increases dramatically. When Startup X fails, the 50 employees migrate to perhaps 3o other startups. That gives Startup X alumni a host of employment possibilities, which should grow exponentially as additional startups rise and fall over time. In smaller cities one can become a known entity within the startup community, virtually guaranteeing employment for as long as startups exist and their reputation remains positive.
The concept of career stability has changed significantly as increased job movement has become an accepted industry characteristic. When one expects a higher number of job searches over the course of a career, proactive professionals will consider employability and marketability more carefully. Job security ≠ career security. If your main concern is being continuously employed at rising compensation levels, employability will often trump job security.
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.
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.