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.

Stupid Recruiter Tricks Vol. 3: The Phantom Client and Recruiter Conflict

You get a call/email from an agency recruiter ($RECRUITER1) saying that they saw your resume/profile and there is an opportunity they would like to discuss with you. As either an active job seeker or someone who keeps an open ear to things, you agree to the call. Let the games begin…

$RECRUITER1 discusses $OPENJOB at $COMPANY and tells you a little about the technologies and the firm. After a few minutes, $RECRUITER1 indicates that your resume will be sent to $COMPANY.

The next day, you get a call from $RECRUITER2, and you are again pitched $OPENJOB (or something very similar) at $COMPANY. You tell $RECRUITER2 that you’ve already been submitted to this job. $RECRUITER2 applies pressure to discover which firm submitted you, because recruiters like to know their competition, and it might be an opportunity to tell you how terrible $RECRUITER1 is and that $RECRUITER2 has a much better relationship with $COMPANY because they just sent the hiring manager hockey tickets. (It’s always hockey)

No real problems so far. But here’s where you get to choose your own adventure for what happens next…

  1. $RECRUITER2 calls: “I spoke to the hiring manager today at $COMPANY, and they never got your resume from $RECRUITER1.“
  2. $RECRUITER2 calls: “I spoke to HR at $COMPANY today, and they’ve never heard of $RECRUITER1.“
  3. $RECRUITER1 calls: “I just got a call from $COMPANY and they said your resume was also sent by $RECRUITER2.“
  4. Both $RECRUITER1 and $RECRUITER2 call you to say you have an interview with $COMPANY, at different times.

Each of the scenarios above are examples of Recruiter Conflict, defined as a situation where two or more recruiters are contacting the same individual(s) about the same job opportunity. This is quite common with larger companies that use multiple recruiting or contracting agencies, and it’s inherent to the contingency recruiting world.

These scenarios happen every day to perhaps thousands of job seekers. Those who post their resumes to sites like Monster or Dice are the most vulnerable victims and easiest targets, as they are clearly the most active (and often desperate) job seekers and more likely to be responsive to anything that resembles a job interview or interest from a company.

What Happened?

What is the Stupid Recruiter Trick here? There are a few possibilities based on each scenario.

In Scenarios 1 and 2 (if $RECRUITER2 is telling the truth) it appears $RECRUITER1 never had a relationship with $COMPANY but wanted to establish one. Waving a stellar candidate’s resume to tempt a client prospect is one method to get the company to sign a recruiting contract. So $RECRUITER1…

  1. Saw $COMPANY’s ad for $OPENJOB.
  2. Wanted to make $COMPANY a client.
  3. Saw the resume of our victim and called pretending to be an agency for $COMPANY.
  4. Called $COMPANY: “We’ve got a great candidate. Here is her resume. Can we be a vendor for $COMPANY?“.

In Scenarios 3 and 4, $RECRUITER2 is the bad actor. Once you told $RECRUITER2 that you were already submitted, that firm should not have sent your resume. When two recruiters send your resume to the same company, it hurts you the most. Why? If the company hired you, they may get invoices from both recruiting firms seeking fees. HR would rather not deal with the legal headaches, so when a resume comes twice it may get deleted.

How To Protect Yourself

  • No recruiters! — One natural reaction for many would be simply to stop responding to recruiters entirely. That’s an option, but for every five useless recruiters there is at least one who can take you to the front of the line and get your resume directly in the right hands.
  • Investigate — Ask a couple questions about the nature of the recruiter’s relationship with their client. It’s fair to ask them how long they have worked with the company, how long the job has been open, and how much success they have had in the past with placing candidates at the company. If you aren’t satisfied with the answers, don’t agree to work with the recruiter.
  • Right to represent — Some hiring companies now require recruiters to have candidates sign a right to represent document. This prevents recruiter conflict, as recruiters can send this document to clients as proof that the candidate granted the recruiter permission to send the resume.

Stressed? It’s Not the Industry, It’s Your Employer

Blog posts and discussion threads about the overwhelming stress felt by those in the software industry seem increasingly popular of late, and authors usually infer that the pressures (or combination thereof) are highly unique to software. The commenters usually skew young, but there is no shortage of experienced pros echoing these sentiments. There are clearly characteristics of the software business that might lead to the belief that certain burdens of a software career just “come with the territory”.

I’d like to offer an alternative viewpoint to anyone who feels these pressures are unavoidable. Not only are many of the stressors cited by software professionals not remotely unique to software, but many of these stressors are entirely foreign to a large percentage of the industry in many parts of the world. In other words, these problems aren’t that “special” and are often symptoms of a toxic employer more than a toxic industry.

What are the main complaints and concerns heard from those in the software industry?

Unpaid overtime — It seems as though the younger generation feels that 70+ hour weeks are the norm and not the exception, which may be a function of their observations of a small subset of the industry. I have represented hundreds of companies with a client roster that includes a mix of startups, mid-size firms, and Fortune 500s, and the number of development shops expecting even 50+ hours is dwarfed by those asking for something resembling 9-5.  Your experience may differ.

There will be occasions where even a straight 9-5 turns into 9-midnight, but that isn’t specific to software. Talk to a retail manager about their holiday season hours or ask your accountant to dinner and a movie in March or April (in the US). Every industry has peak times, so unpaid overtime is hardly unique to software.

Most unpaid overtime situations are simply explained. Employers who consistently ask for unpaid overtime are understaffed, and employees that aren’t interested in working those extra hours need to either refuse or find a new job. Companies can get away with asking for more hours when the economy is down. Right now (and for the past few years) it’s a seller’s market, and finding a new job (particularly while you still have a job) isn’t the challenge it can be in other industries.

Attitudes are starting to change and more companies are asking for less time, which may be due to more accurate metrics on how increasing hours does not always result in better project outcomes.

Pressure to deliver on time or fear of failure — Clients (whether internal or external) can be irrational beings with unreasonable expectations, and some projects are destined for failure from the start. Inept management, insufficient resources, or improper tools might make developers feel helpless to remedy the situation.

Are tight time constraints indigenous to the software industry? There are many instances where speed to market is a factor, but an unreasonable timeline can also simply be poor (or overly-optimistic) estimation. Skilled managers don’t regularly overpromise and underdeliver, and companies that care about their employees will protect them from forced marches.

Companies committed to avoiding failure will have systems in place to reduce risk. Complaints about fear of failure often are accompanied with details about the employer having no QA/testing, the absence of process and any real development methodology, outdated tools, or no source control. In other words, if your employer miserably fails the Joel Test you may be more likely to feel pressure. Many who stress over fear of failure are working under conditions where success would be unlikely.

These also are not unique to software.

Competition/keeping skills fresh — I think this is the most valid of the perceived pressures due to the speed in which technologies can become popular and unpopular. By the time anyone gets productive using the hottest JavaScript framework, a new one has replaced it.

Some individuals feel it’s necessary to invest many unpaid hours keeping their skill sets up-to-date to maintain marketability. In technology skill markets characterized by low supply and high demand (see AngularJS today), most employers eventually lower a requirement with the expectation that the skill can be learned by an accomplished professional.

The desire to invest in self-learning can be innate curiosity, but the perceived need to invest time self-learning is largely a function of the challenges provided by an employer. Those who solve complex technical problems with desirable tools by day have less to worry about at night.

Impostor syndrome — This gets bandied about in discussion forums to the point where it sometimes becomes comical, which is unfortunate for those who truly feel it. Saying “I have impostor syndrome” may be becoming an acceptable way of saying “I’m probably a better programmer than I think I am, right?“, and I can’t imagine that the condition is under-(self-)diagnosed among newer industry entrants.

Impostor syndrome probably isn’t directly related to an employer, although how a company does code review/pairing/testing may expose a developer’s work to more open scrutiny than those in other fields. If you are junior level and feel that you know less than the others at your company, you’re probably right – but it has nothing to do with a defect. Wait a few years before diagnosing yourself.

Uncertainty — A client spec that changes with the weather. A potential project that is yet to receive funding approval from stakeholders. A bootstrapped startup with short runway. These are all uncertain conditions common (but not unique) to software, but they are not unavoidable. Restaurants are also noted to have picky customers and high failure rates.

Conclusion

By many studies and surveys, software developers have one of the best (and best paying) jobs in the world and demand for those skills is possibly as high as it has ever been. Lots of careers are stressful, but we should be careful not to confuse which stressors may be somewhat inherent to the industry and which are signs of an undesirable employer. We may be scaring off some good coders.

How To Leave Your Job: Preparation, Resignation, and Transition

Making the decision to leave an employer and submitting a resignation is typically an emotional experience, and can be stressful the first few times one goes through the process. Valuable business relationships, friendships, and even legal/financial standing can be in danger if things aren’t handled properly. If you anticipate an upcoming job change or are deep in the interview process with a potential new employer, start considering the following:

Review Contracts

Some employment contracts contain clauses regarding the amount of notice required or non-compete limitations on who you can work for and what type of work you can do. When interviewing with companies, it’s helpful to properly set the hiring party’s expectations regarding your availability and any possible snags. Even if these restrictions may not be legally binding, you should read over any signed documents and consult an employment attorney if you have any concerns.

Keep a Low Profile Until the Ink is Dry

It is not ideal to have a current employer discover your job search while you are in the interview process and before you’ve received offers. A manager might get tipped off by several clues or combinations thereof, such as unusual use of sick/personal time, lengthy calls taken on mobile phones in the parking lot, or a sudden spate of LinkedIn activity. If you feel the need to share information on your job search with co-workers, proceed with caution. Be particularly careful if providing references from your current employer, as they may be called immediately (before an offer) without your knowledge by recruiters or hiring managers.

Timing

Opportunity doesn’t always knock at the perfect time, but to avoid burning any bridges it is ideal to synchronize your new job’s start date with the end of a cycle at your current employer (a deliverable, initiative, sprint, etc.). This is not always possible due to the nature of the business, but it’s something that should be kept in mind and addressed during the interview process.

Resignation Letter

No matter how small and non-corporate your employer, you should always write an official resignation letter (even if you deliver the news initially in another format). The resignation letter should be short, direct, and written to serve a few purposes.

  1. Notifies the employer regarding your last day of employment.
  2. Expresses gratitude to the employer and co-workers.
  3. Assures the employer that you will be productive during your notice period and helpful in transitioning reponsibilities and knowledge to replacement(s).
  4. A positive close.

Dear $MANAGER,
Please let this letter serve as notice of my resignation from $COMPANY, with my last date of employment being $DATE. 

I greatly appreciate the opportunity and all I have learned and accomplished during my employment with $COMPANY. I hope to make my remaining time here as productive as possible to transition my knowledge and responsibilities to my co-workers or to help select my replacement.

Thank you for the opportunity, and I wish $COMPANY and my co-workers success.
$NAME

Some are tempted to turn a resignation letter into a treastise on the state of the company with criticisms and suggestions for improvements, while others feel the need to provide multiple details on where they are heading and what they will be doing. These topics are not appropriate for a resignation letter, and the template above is as much information as you should offer in writing.

Transition Period

Once you’ve resigned from a position there are several possibilities as to what might happen, ranging from counteroffers to “pack your desk and GTFO“. Regardless of  the direction things go, your willingness to be cooperative and helpful during the transition period is one of the most important factors impacting your ability to use employees from the company as future references. I’ve conducted thousands of reference checks in my career, and references are often eager to share details of how an employee made a non-graceful exit.

Conclusion

Changing jobs can be a stressful time, particularly if you don’t have a plan. These steps can help in making a smooth transition to new employers while preserving relationships (and references) from your past jobs.

On Job Titles: Juniors, Roman Numerals, and the Elusive “Python Architect”

As I spent the last week of 2015 updating some database records on my candidate network, I began to notice various job titles and how the industry uses a variety of naming conventions for people who ultimately do similar things. I’m sure this isn’t exclusive to technology, but there are industries that appear to have more defined terminologies.

Some thoughts:

Junior Software Developer (or Engineer, Sysadmin/etc.) — What is the benefit (to anyone) of including the term Junior in a job title? When we post open jobs, using the word Junior is valuable to discourage those who will be seeking responsibility and/or compensation well above the level the job provides. But once someone is in the door and hired, doesn’t the Junior title do more harm than good. A team member with the Junior title might be more responsive when pitched jobs that don’t include Junior, with the thought that it is a step up (even if the repsponsibilities and compensation are identical).

Couldn’t we just use the title Software Developer without the somewhat demeaning prelude, and then use more positive terms to reflect seniority?

Roman Numerals — The use of Roman numerals to indicate seniority seems to be exclusive to the enterprise monoliths, and I’d hope that some of these firms would reconsider their titles. I’ve never personally seen a startup or even mid-size company that uses them.

The numerical use is particularly unfortunate when common criticisms of these organizations are phrased “you’re just a number at $COMPANY”, as the concept of being unimportant to an employer is directly equated with numbers. The use of numbers allows for many specific levels within one job title, which primarily seems to serve in limiting an employee’s ability to negotiate compensation. “We can’t pay you $125K until you are Architect IV. You’re only Architect II.”

Where are the Python Architects? — The Architect title has always been a bit of a hot topic. When my business was focused entirely on Java and my clients were larger firms, I saw it every day. Now that I work mostly with startups (most not choosing Java as their primary language) it’s rare that I hear the term from job seekers or hiring clients, except as a verb.

Architect means “I don’t write code” to a segment of the industry, which some seem to translate to “I’m above writing code”. I believe this is the ultimate source of any controversy about the title, and it’s obviously not the case for many who do code or at least don’t feel they are “above” coding because of their title and status.

I rarely (if ever) see the title Architect used in combination with a language or platform other than Java or .Net. (ASIDE: Almost half the 6K Google hits for “Python Architect” go away if you ignore the hits for the Monty Python architect sketch.)

Ninjas and Rockstars — It seems the industry has finally moved away from these references, thankfully. The connotation was often negative and the terms today probably scare away more applicants than they attract.

When Job Hopping Goes Wrong

While surfing a thread about a potential job change in Reddit’s /r/cscareerquestions (DISCLOSURE: I’m a mod), I read the following comment:

“There is no such thing as ruining a career by switching jobs too often”

At the time this was the most upvoted comment in the thread, which troubled me because it is rather poor advice. I’ve written about my appreciation for job hoppers once or twice in the past, but I would never suggest to a reader that unlimited job changes would have a positive impact on a career.

When evaluating candidates that appear to be job hoppers, there are at least a few things that need to be considered.

Holes

A pattern of job hopping combined with multiple periods of unemployment is a huge red flag unless there are verifiable explanations for the gaps. Resumes depicting a number of employers > number of years AND one or two periods of unemployment for a given time period will require some explanation, and sometimes the explanation is a confession.

Accomplishments

The job hoppers that have the most success are those that tended to finish a job and move along. The developer who built the system but didn’t stick around to support it, the smokejumper that was hired into a difficult situation to accomplish a specific task, and the person who worked herself / himself out of a job are generally not faulted for frequent moves.

Mobility

Some job hopper resumes show regular increases in responsibility or employer reputation, while others may be reminiscent of a downward career spiral. A series of job changes that reflect upward career mobility isn’t indicative of a problem child, but rather a rising star that perhaps hasn’t found the appropriate level of challenge.

Comfortable in Their Own Skin

You should be able to spot a job hopper that might become a questionable hire by listening to them describe the motivations behind their choices. There should be a level of both transparency and confidence in their explanations, and they may even admit situations where they made a wrong move. Candidates who fess to being blinded by an employer who made empty promises in interviews or presented an offer nobody could refuse should gain some credibility points. Whether they are excellent employees or not, all job hoppers should have some expectation that they will be asked about their moves, and those most reluctant to discuss their history are likely the ones requiring deeper investigation.