Dave Fecak's Blog, page 3

Are You Underpaid?

My work requires me to talk about compensation history and expectations with thousands of technology professionals across a wide range of experience every year. We start with a discussion of job search criteria and what types of opportunities are most attractive, then talk about technical background and experience, and by the time the topic of money surfaces I’m usually in a decent position to guess their current salary and talk about their market rate.

The recent DZone Developer Happiness Survey concluded that over 40% of readers felt they were underpaid. 40% was well above what I expected, and from my personal experience I would put the number closer to 15-20%. That’s still a significant number.

Market Rate is Tricky

I’ve never taken the time to try and develop some kind of elaborate mathematical formula for market rate, as I’m not qualified to do so and my expertise tends to fall into a couple specific markets. There is also nuance that needs to be considered on both the candidate and employer side.

A few examples:

 Two candidates with identical technical experience might expect different salaries depending on the business model of the employer that hires them. The consulting company that expects to bill out the hire (say at an hourly rate where rate > salary/1000) probably offers a higher salary than an insurance company, because the employee’s value to the consulting company is easier to accurately quantify. A software product company may fall in between.
Value of certain technical skill sets is also a factor, where someone showing production experience with a new language or framework may benefit from supply and demand inefficiencies much more than older and established language users.
Different employers will place a different value on past experience. Startups may value those with startup experience higher compared to those from larger companies, so three years of Python experience can be worth different amounts depending on where the experience was earned and what company is hiring. When we start to consider both new and old technologies at a variety of employer types, it’s easy to see how confusing market rate might become.
Salary tends to plateau at certain experience levels, so a salary difference between 15 and 20 years of experience is often attributed to the types of work much more than the overall years.

This nuance is a potential issue with much of the publicly available salary data. For one, much of the data is self-reported and unverified, and those in the industry have little personal incentive to underreport earnings in anonymous salary surveys. If tech pros want to maintain high salaries, overreporting salary might be a better strategy, as the data may be used both by candidates negotiating offers as well as other employers trying to make sure their own offers are competitive.

How to Find Out

Agency recruiters (aka “headhunters”) — If you feel that recruiters are useless bottom-feeders on the industry, this is your chance to use a service of theirs for free. Any experienced recruiter with knowledge of your market should be able and willing to give some insight into your earnings potential. The pushy ones will want to meet you face-to-face (a ten minute phone call is a reasonable request, as they will need some info to give an accurate estimate), and of course they will try to recruit you. Tell them that you are first interested in hearing their opinion on your market rate, and if you decide to explore opportunities you may consider their services based on how they handle this request.

Poll some friends — Asking others how much they earn has historically been considered a bit taboo (at least in the US), but industry insiders are exposed to data and their input can be useful in your quest. Instead of the “How much do you make?” question, one alternative would be to ask friends what they think your market rate should be based on your background (just like you asked the headhunter). And use extreme caution if you choose to speak to current co-workers about any compensation topics.

Research — You can spend hours on various sites that claim their data is more accurate than the others. The potential utility of that data has been discussed above.

Interview — This is the most accurate method to get your answer and also might help to keep interview skills sharp, but unfortunately it’s also the most time-consuming. Some in the industry take issue with the act of interviewing in order to discover market rate, but as long as you are (A) at least slightly open to the possibility of accepting a great offer and (B) are honest in all discussions with interviewers I see no ethical issues.

Conclusion

Just because you feel underpaid doesn’t mean it true, but it’s worth exploring to find out. The problem can potentially be corrected without leaving (or even threatening to leave) your current job.

Interview Prep: Ready for Storytime?

Interview preparation often means different things to technologists depending on their level of experience. It seems that more and more material written about interview prep seems focused on junior level developer interviews at the most visible employers (“the Big 4”), causing worried job seekers to spend hours memorizing algorithms and data structures or the code to the most commonly asked problems to solve.

After someone gains a few years of programming experience, their interviews tend to focus less on technical memorization and more on professional accomplishments and to some degree on self-awareness. Being prepared for a potentially deep technical conversation still is important, but studying for an interview should also include a healthy dose of reflection and the preparation for anecdotal questions.

Here are some questions you might expect to see:

What professional accomplishment are you most proud of, and why? Some may take this opportunity to brag while others might stress the value of their team during the efforts.


What are the biggest challenges you face in your current position? Be careful to sidestep being perceived as overtly negative about your employer.


How does your work (or $PROJECT) impact the business? Several hiring managers have privately expressed to me that their biggest pet peeve was when developers had little understanding of their relationship to the big picture.


Tell us about a professional disagreement you had with a difficult boss/co-worker and how the situation was resolved. This one is also tricky, and some humility goes a long way.


Tell us about a mistake that you made that had an effect on your team or product, what caused the problem, and how it was fixed. Everybody messes up, and the ability to both accept fault and learn from mistakes is a valuable trait.

There can be many examples of questions that require reflection. One useful exercise is to review your resume before an interview to refresh your memory of various projects, and consider both the positive and negative experiences for each. Having to improvise stories can be a difficult task in front of an audience, so practicing answers may be helpful.

How to Brag: Describing Accomplishments on Resumes

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

Responsibilities – Something that was part of the job on an ongoing basis.
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).
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.

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.

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.
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.

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:

Responsibility – Does the job have more responsibility than you initially would have assumed?
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”?
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.
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 

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).

“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.
“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.
“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.
“ 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.
“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.