Category: Uncategorized

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.

Format

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.

Conclusion

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.

I’m Glad You Studied FizzBuzz, But What About the Guaranteed Questions?

Every company takes a different approach to interviews, so without the benefit of inside information it is impossible to predict whether you might be subjected to a whiteboard session, a code pairing exercise, a written test, random Fermi questions (still a thing?), or a technical trivia game show focused on the minutiae of some framework or language. New graduates often find themselves in the trivia Q&A interview format, as interviewers unable to engage in conversations about accomplishments and experiences will gravitate towards questions testing knowledge or improvisational problem solving.

You can study linked lists and memorize FizzBuzz solutions in Python or your favorite Lisp to your heart’s content, but don’t forget to prepare for the handful of core questions that are extremely likely to come up during every interview (perhaps more than once).

What do you know about us? The subtext of this question may be as simple as “Are you prepared?” or more directly “Is there a reason you think you might actually want to work here, or are we just another potential offer letter for your collection?“.

What are your salary requirements/how much are you currently earning?Whether you choose to answer these questions is a hotly contested topic today, but you need to have a prepared answer in order to prevent potential disasters. I’d imagine at least one-third of the negotiation advice I give my career coaching clients stems from their fumbling of an answer to a question about money during a live interview. Even if you intend on trying to avoid the question, have a strategy in place for when you are asked.

Why are you looking to leave your current job (or last job if unemployed)? This can be a litmus test to see if you are the type to complain about an employer or it can be used to identify potential performance problems.

What type of work do you most enjoy doing? The company doesn’t want to hire employees to do things they loathe — at least not as their primary function.

What are your career goals and professional ambitions? It’s the “five year question” without the cliche, but they want to know if you’ll be happy in the role they have available or if you might be looking for the first chance to move up.

Tell us about a time when _______… Experienced candidates will hopefully have gained some insights based on their past successes and failures. Candidates should be prepared with a handful of anecdotes, which should include both points of pride and regrets.

Studying for tech questions will account for most of the interview preparation time of many candidates, but don’t forget to consider these questions which are non-technical but likely to be asked.

“It Never Hurts to Apply”…except when it does

Job seekers are sometimes reluctant to apply for positions that might be considered a stretch for their abilities or qualifications, and there are several possible explanations for the hesitation. Fear of rejection, underconfidence, or concerns about wasting time are all likely contributors when we hover the cursor over the APPLY NOW button. Of course if you were to ask your friends and family, they are all going to tell you the same thing.

“Go for it!”
“It never hurts to apply.”
“The worst they can say is no.”

In most cases I’d agree with this advice, but it’s not universally true. Let’s talk about the exception. First, some background.

ATS and Interview Policy

When you submit an application to a company, chances are the company stores your resume and an applicant tracking system (ATS) maintains all the relevant data surrounding your candidacy – the date you applied, interview results, notes, etc. This system also comes in handy when a candidate applies for jobs in different areas of the same large company, or applies multiple times over a short time span.

Many companies have a policy as to how often they will interview a candidate that has failed in past interviews. It takes time to schedule and interview someone, and the time of developers (who have a primary purpose of producing code) is valuable, so it makes sense that employers do not want to waste time interviewing the same candidate over and over again over a short period of time.

The Scenario

You see a job listing and realize that it’s probably a long shot. Although you meet some of the minimum criteria, there are multiple required or desired skills that you haven’t acquired yet (and perhaps some you’ve never even heard of). You couldn’t possibly hold a reasonably intelligent conversation about some of the items listed in the job requirement, so you certainly can’t list them on the resume.

Option A — Listen to your dad and APPLY NOW

Pros: You might be an early applicant and get a quick interview.

Cons: Your quick interview might be an experiment early in the company’s hiring process, and as a minimally qualified candidate you may be used simply to measure future candidates.

Possible result: You admit to having no experience with several of the technologies discussed in the interview and give answers ending in “…but I’m sure I can pick it up.” Rejected… and worse, you won’t be considered for any roles with the company for n months.

Option B — Spend some hours playing with those unfamiliar technologies and apply in a few days/week.

Pros: You can list those technologies you didn’t previously “know” on the resume with some caveat (“exposure to $SKILL“?), which may improve your resume’s chances of getting noticed by a human scanner or ATS for this job and future jobs as well.

Cons: You risk waiting too long and having the position close in the meantime. You also risk wasted time if the knowledge you gain in self-study isn’t likely to benefit you in applying for other positions.

Possible result: During the interview you are asked questions about those unknowns. You tell the interviewers that you did not have exposure to those technologies, but took the initiative to do some research and play with them in preparation for the interview. The hiring panel is impressed by this as it shows serious motivation and interest in the job.

Conclusion

Timing is (almost) everything when it comes to job search, and sometimes it makes more sense to wait a while before applying in order to make sure you are ready to make the best possible first impression. You aren’t likely to get a second chance with an employer in the near future.

Job Searching On Mobile? You’ve Been Warned

A recent article on DZone “Report Finds Job Seeking Going Mobile” reported on a recent survey that showed a moderate number of job seekers were using mobile devices to research and even apply for new positions. Although there is a place for mobile in the job search process, I would advise anyone who relies extensively on mobile for job search to use caution. The obvious shortcomings of mobile technology and the “apply now” mentality of the mobile apps combine to do potential harm to job seekers.

As I’ve written before, I receive many more generic applications today than I did years ago. Sometimes I see a resume with no context, or more often a resume accompanied by a small amount of canned content. I expect this generic approach may be explained by both the popularity of mobile job search apps as well as the way all job search technology seems designed for “shotgunning” resumes out and not for crafting customized applications (quantity over quality).

Let’s look at the pros and cons of mobile job search and use a scenario to illustrate some alternatives.

The Pros

The benefits of mobile for job search are convenience and ease of real-time notification. Those who respond early to job ads are thought to have some advantage, as a company might close off new applicants once a certain number of potential candidates have been identified. The ability to receive/respond in real-time to new open job notifications is a clear asset to any job seeker.

The Cons

With added convenience and availability comes risk. Job seekers vying to be an early applicant often sacrifice the ability to customize both their resume and approach. The difficulty of writing content and performing research/reading on mobile is perhaps the biggest relative limitation, and the temptation to be first will lead some to act quickly instead of taking the time to make the best impression.

Scenario

Your mobile job search app sends a push notification at 3:00 PM.

ALERT: $COMPANY is hiring $POSITION – $CITY – Job posted three minutes ago

You know that this is a popular employer and the competition for this job will be fierce, so you open the app, answer a couple questions (salary, work authorization, etc.) and click ‘apply now’. The resume/profile the app has on file is sent to “jobs@company” or some other general repository for applicants. You get a notification at 3:02 PM.

ALERT: Congratulations! You are now ‘in consideration’ for $COMPANY’s $POSITION vacancy

Clicking ‘apply now’ should be easy on any device, but probably makes for a lazy application. How many job seekers are going to spend time tweaking a resume and writing a well-researched cover letter/email on a mobile device?

Your competition for the job also received the 3:00 PM alert, but that person chose not to click ‘apply now’ but instead to wait and do a bit of research first. Maybe this person found three LinkedIn connections who work for $COMPANY including a hiring manager and an internal recruiter. Perhaps they noticed that their resume didn’t include some recent experience with $SKILL (mentioned in the fine print of the job spec), so they added a bullet point before sending the resume and a few targeted sentences on their candidacy to their connection.

Now that you know what your competition did, would you like a do-over?

Conclusion

Our fascination with one-click technologies will help to save time for users, but that also comes with a cost. Job search apps are primarily designed so companies can receive a high volume of applicants, and that high volume is directly related to the ease of “apply now” features.

Is it most important to be the first guest at the party, or would it be better to arrive a few minutes later as the best dressed?

Negotiating Offers That Meet Your Asking Price

Negotiating job offers is a skill, and many are reluctant to even attempt it. Like interviewing, negotiation is something that most professionals may only do a few times (or less) a decade, so it’s not the type of skill that gets honed through regular use.

One question that I often hear relates to scenarios where a candidate provides a target salary/range on an application or in the interview process, the employer makes an offer at or above that range, and the candidate suddenly doesn’t know what to do. Conventional wisdom (and perhaps ethics) would suggest that one should accept such an offer, but when an employer matches the candidate’s request without hesitation it can make candidates feel their request was too low.

If you list your house for sale on a Friday and receive five full-price offers before the weekend is over, most people will tell you that you set your bar too low in a competitive market.

It could be that the salary request was “at market”, but one natural reaction to having a salary request met without reluctance is that the candidate “left money on the table“. This feeling is often accompanied with some regrets, and some candidates wonder whether or not they can still negotiate even though they got what they wanted.

What to Do?

It is potentially a risky endeavor, but if you choose to negotiate an offer that met your request you’re going to need a reason. A common negotiation mistake inexperienced job seekers make is giving the appearance that they are negotiating just for the sake of negotiating, and employers that met your initial asking price will feel any new requests are not a good faith negotiation.

Did you uncover new information since setting your target number?

The most effective way to negotiate a matched request is to tie a counteroffer to new information learned after you provided the original number. This new information typically needs to be a detail that one couldn’t have reasonably expected to know at the time the desired salary was provided.

Some good examples of this include:

  1. Responsibility – Does the job have more responsibility than you initially would have assumed?
  2. Work/life balance – Are the expectations for hours in the office above what one would expect? Does the position require you to be “on call”?
  3. Benefits and perks – These are usually discussed later in the interview process or even after an offer is made, so it’s reasonable to assume that many job seekers will be asked for desired salary numbers well before they learn the value of the other pieces of the overall compensation package. The major variables impacting overall package value tend to be health insurance contribution, paid time-off, bonus, and stock.
  4. Your own market value – Admitting that you underestimated your own market value it the least attractive option. A job seeker claiming this will be viewed as someone who was unprepared.

I would expect most instances where candidates submit counteroffers above their initial asking price relate to multiple offers from other employers. In highly competitive markets, above average candidates may expect offers that will include some from companies that pay their employees above market rate. Using other offers as a negotiation tool has become rather common in the industry, though some employers may not be willing to engage in renegotation if an initial request was matched.

Conclusion

It’s important to keep data on any salary numbers (historical and requested) provided during the hiring process and to be prepared with numbers handy in case you are asked. Keep in mind that companies traditionally want information on salary expectations before committing to interviews. The process of negotiating an offer above the listed expectation can be complex, but it’s not impossible given the proper circumstances.

Developer Happiness: What Makes Developers Happy?

First, thanks to everyone who took the time to complete the Developer Happiness Survey originally posted at DZone. I can safely conclude from the >500 responses that the average respondent (as if any are average) is a moderately satisfied yet fairly paid to underpaid engineer who generally avoids user groups and extracurricular coding while boasting a manageable commute to a somewhat quiet office where mildly challenging development is performed by an average team (led by average management) using an ill-defined development methodology and unclear requirements employing subpar/mediocre tools practicing source control/continuous integration and consistently updated schedules, where testers test (and bugs are found and promptly fixed), interviewees don’t code, and software is a source of profit.

Does that sound awesome or what? Forget all that for now.

About The Survey

I designed the happiness survey based on two theories. My primary goal was to test the accuracy of nearly twenty years of anecdotal evidence, amassed over thousands of conversations with developers usually looking for new work (because I’m a recruiter, and that’s why people talk to me). When you’ve asked the questions “Why are you leaving?” and “What are you looking for?” thousands of times, you soon discover that there are only a handful of common answers cited.

Second, I was curious how well the individual elements of the Joel Test and a combination of the Joel Test questions might “stack” up (see what I did there?). I peppered the survey with variations on 8 of the 12 questions Joel Spolsky wrote back in 2000 to try and rate the quality of a software team.

9 of the 19 questions offered an “average” answer option, while the other 10 questions were binary. The question about overall job satisfaction (“happiness” – and yes, I know these aren’t exactly the same) offered an average option, which explains why % happy + % unhappy < 100%.

Survey Results Breakdown

Compensation

Just under half of you feel underpaid, and an almost identical percentage feel they earn at market rate. Both underpaid and at market respondents were mostly in the average job satisfaction category, but among the underpaid the unhappy outnumbered the happy 4:1.

Those who felt they were paid market rate were equally likely to claim happiness and unhappiness.

Only 2% of responses claimed to be both overpaid and unhappy.

Challenge

Many developers cite a lack of technical challenges as a reason for leaving their jobs. Half of you claim to be still learning at the workplace, and dissatisfaction among that “I’m still learning” group is a mere 11%. Half of the underchallenged are unhappy, while only 2% are happy when not learning on the job.

Tools and Stack

Only 25% reported that your employer uses the best tools regardless of price, and a combined three-quarters identify as using a rather standard (48%) or cutting-edge (26%) tech stack. Less than 1% of all respondents reported being happy while still using a dated stack. Only 12% of those who use the best tools are unhappy, compared to the 38% dissatisfaction rate among those using second-rate tools.

People

The competence of co-workers and management is often cited as important to job seekers, and the numbers here seem to validate that observation.

Regarding co-workers, three-quarters rated your team as average (45%) or above average (33%). Just under half of you also claimed to be the most knowledgable person on your team. 10% of devs on above average teams are unhappy. Compare that to 3% of those on poor teams being happy (more than half are unhappy), and the value of a good team is clear. Being the best on your team also comes with a 1/3 dissatisfaction rate, which may be felt by those who can no longer learn from peers.

As for management, about one-third of you described your bosses as ‘mostly incompetent or dysfunctional’, which came with a whopping two-thirds dissatisfaction rate. Less than 1% of all respondents reported being happy under bad management or unhappy under competent management.

Cost vs Profit

I have heard developers regularly expressing more interest in working for companies that either build a software product or are at least a technology business, as opposed to firms where tech is a cost of doing business. The ratio of happy to unhappy developers at tech firms is unremarkable, but dissatisfied developers outnumber the satisfied by nearly 4:1 where software and tech is not the focus.

Remote Work and Commuting

8% of respondents work remotely, with about an equal number of happy and unhappy responses (44% average, 28% happy, 26% unhappy). Only 10% of those with a long commute are happy.

Coding Time

There were two questions asked about coding time. The first was how often code is written during spare time, with 29% coding frequently and 28% rarely or never. Perhaps the only significant takeaway here was that only 11% of those who rarely code in their free time are happy, while 28% are unhappy.

The second question related to whether the developer wanted to write more code, less code, or the same amount of code over the next few years. I have heard job seekers cite both too much and not enough coding as reasons for looking. 1% of all respondents reported both happiness and a desire to code less (or not at all) in the future. Over 1/3 of respondents want to write more code, compared to 17% who want to code less.

Joel Test

Responses to certain questions on the Joel Test were clearly more revealing than others.

There were 14 responses that scored positive for all of the Joel Test questions, and only one of the 14 reported being unhappy. It’s clearly a small sample size, but these respondents reported to mostly be paid at market (50%), challenged (85%), code in their free time frequently or on occasion (71%), have competent managers (57%), work on above average teams (85%), and use newer technologies (64%).

As for the individual Joel Test elements:

Quiet — Only 1% claimed to be both happy and working in a loud environment, while half of those subjected to loud noise are unhappy. The differences between the happy, average, and unhappy in quiet offices were insignificant.

Tools — Companies that use the best tools regardless of price see over 33% happiness rates, and developers that use lesser tools experience 38% dissatisfaction.

Testers — 64% of your employers have testers, but that doesn’t impact happiness (for developers anyway).

Timely Bug Fixes — Just over half of you reported that bugs are fixed in a timely fashion and the developers try to make fixes before moving on to new code, but there the satisfied only slightly outnumber the dissatisfied. Teams that don’t squash their bugs see 44% unhappiness rates compared to a slim 10% reporting as happy.

Source Control — Three-quarters of you work in places where source control is taken seriously. Our data shows that good source control won’t guarantee developer happiness, but only 9% are happy in companies without source control (as compared to almost half being unhappy).

Continuous Integration — NOTE: Joel’s original questions were “Can you make a build in one step?” and “Do you make daily builds?”. I asked a true/false “My company practices continuous integration.” CI is practiced by over half of our respondents. As you might expect, our results here are similar to the source control question. Development shops that have CI in place have an almost identical number of happy and unhappy developers, but the happy are dwarfed by the unhappy at a 4:1 ratio where CI isn’t practiced.

Schedules — Half of you feel your work is kept on an up-to-date schedule, but that alone doesn’t impact satisfaction. 40% of those with poor schedules report being unhappy.

Requirements — 64% of you are not getting clear requirements. Good reqs result in keeping one-third of developers happy and one-seventh unhappy, while those with poor reqs are almost one-half unhappy and only one-tenth happy.

Interviewees Code — I was quite surprised to learn that only about one-third of you work for companies that require applicants to write code as part of the interview process. Once again, happiness and unhappiness numbers were nearly identical at employers that require interview coding. Where interviewees don’t code, the unhappy contingent is almost triple the size of the happy group.

Conclusions

I would have expected more than 18% of all respondents would have reported as happy when compared to the 30% unhappy.

Across all questions with a third “average” answer available, many or most respondents (43-74%) chose that response.

The ratio of happy to unhappy tends to be similar (and near 1:1) in several of our questions when the answer is positive (using the best tools, CI, etc.), but the ratio jumps significantly when we review the negative responses. It seems that “having” some positive characteristic in your environment doesn’t make workers happy, but “not having” it makes workers unhappy. Developers seem to have some basic expectations that, when met, don’t impact happiness. When unmet, morale becomes an issue.

This survey and my analysis has obvious flaws. Our sample is almost entirely DZone readers, an audience that may not be representative of the global development community. It was intended for fun, some insight, and to take the temperature of the audience.

One major factor in overall happiness which was not addressed is the mission of the employer. Many employees achieve job satisfaction by working for companies that share their values and principles (non-profits or civic groups). There are clearly other questions we could have asked to get a true sense of overall happiness.

What Your Six-Page Resume Says About You (and your “elegant code”)

I see a lot of six-page (or n-page where n >2 for nearly everyone) resumes on any given day, whether in my capacity as a retained recruiter servicing software companies or via my side project Resume Raiders performing resume reviews and revisions for job seekers. No matter how the resume arrives in my inbox, I’m always surprised in 2016 that the six-page resume is still “a thing“. It shouldn’t be.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery

The reasons for unnecessary length are incredibly easy for a trained professional to diagnose, and I’ve written about them in the past. Our purpose today is not to fix the long resume, but rather to emphasize why you should.

For anyone who feels their six-page resume is appropriate, it may be useful to hear what employers think when they learn your resume is that long (before even opening it).

  1. “I’d hate to see their code, documentation, comments, emails, etc.” — Oh the sweet irony of a six-page resume that leads with a summary bragging “Experienced software engineer known for producing elegant code“. When an employer sees six pages, they are likely to assume that the person behind that resume is far from succinct in any form of communication or in their code.
  2. “Garbage collection isn’t working” — Expanded details lingering from older jobs that are typically less relevant to current job searches are a sign that the writer took the lazy route of just adding more content instead of trimming older fat.
  3. “Someone has a high opinion of herself/himself” — When a writer choses to submit six pages, the reader is inclined to believe that the writer intended for all six pages to be consumed. You are asking an employer to consider you for a job, and then asking for 10-20 minutes out of their busy day to make an assessment that should require half that time. If we want employers to respect the time of job seekers during the hiring process, we should start by respecting their time.
  4. “Priorities?” — Employees in any industry are expected to decide which tasks are more important than others, and the ability to recognize the difference between something significant and something trivial is often necessary for success. The inclusion of your most trivial duties leads a reader to infer that you view these as accomplishments to be proud of instead of rote tasks that perhaps you could have even automated.
  5. “Do what you do best, outsource the rest” — Of course I’m well aware after years in the business that technologists aren’t always the best self-promoters or marketers. Regardless, they are generally bright people who might recognize that they need a hand and reach out to a peer or a professional for a second opinion.

There really is no excuse for a six-page resume these days. Collect old garbage, prioritize, and if necessary get help.

Let’s kill the long resume! They are unnecessary, you don’t want to write them, and we don’t want to read them. Spread the word.