How Ben Accidentally Became a Developer

In early April I received a message from Ben, delivered to my Reddit account.

I’ve been reading /r/resumes for, well, the whole time I’ve been actively looking for another job. I’ve noticed your comments on other posts and respect your opinion. Even though I’m not a “programmer” per se, I do enjoy reading your site and appreciate the time you take to help folks like me who are trying to make the best impression possible.

Ben wanted some advice on his résumé and career prospects in technology, and he wrote a quick bio. He earned a degree in religion and worked in that field for seven years before deciding that his passion was for technology. During his tenure in the church he dabbled in web development and learned to solve basic networking and hardware issues to reduce the church’s technology expenses. He resigned his church position to pursue entry-level roles, and ended up spending a year in retail before eventually being hired as a Junior Computer Technician.

After spending three years in the technician role, Ben asked his manager for additional responsibilities. He was already performing light systems administration tasks for their small office, and was then entrusted to write a web application. Ben taught himself PHP, JavaScript, and SQL. The web app he built became a major revenue source for his company and a highlight of his career.LineDrawingManComputer

Ben, on paper

After learning about Ben’s work history, I reviewed his résumé. The two sentence profile atop his résumé mentioned troubleshooting, managing hardware and software, vendor selection and training. There was no mention of programming experience.

Below the profile was a listing for certifications. None of his certs were truly relevant to programming.

His experience section was next. The first role listed was Systems Administrator, which had descriptions of his accomplishments in that role.

I was now halfway down the page and I have seen nothing about what he saw as his most valuable professional accomplishment. And then there it was – Web Developer. He had duties in both sys admin and development, and chose to list the sys admin experience first.

His technical skills section led with several operating systems, servers, and virtualization tools. Below that, a mere two lines from the bottom of the résumé (just above his degree), he listed programming languages.

“…not a programmer, per se…”?

After I finished reading the résumé, I thought back to his comment from the original Reddit comment. “Even though I’m not a ‘programmer’ per se…” At this point it was hard to tell if Ben would be more marketable (or happier) as a sys admin or a developer, so more information was required. 

Ben then sent me a random email to tell me about his blog, which he had recently converted from WordPress to Octopress and had subsequently picked up some Ruby along the way. I checked it out and saw he had a couple small GitHub repos. This was all news to me. I asked if he had any other programming experience he was hiding.

It turns out he had done some freelance front-end web development work for a bit. He added that he had also contributed to the development of a template that was adopted by WordPress as a stock theme.

Ben might not have considered himself a programmer, but I expected others would disagree.

The Intervention

I sent Ben an email suggesting he focus 100% of job search efforts on finding a development role, and that his experience should qualify him for intermediate level slots. Ben responded that he had been reluctant to seek programming positions because he’d been doing that work for the least amount of time, but acknowledged that he’d probably be happier (and better compensated) as a developer. We worked together over the course of a couple days to rewrite his résumé, which emphasized his coding accomplishments.


Within five days of our first contact, Ben had a couple interviews lined up for web development positions. Fifteen days later Ben accepted a new job offer as a developer, which came with a 60% increase from his prior salary.

Ben now describes himself as a “Full-stack web developer” on his blog.

How to Level Up

I regularly hear from and read about technologists in a career rut. Unless one is both lucky and adept at predicting the future, experiencing some temporary stall can happen to professionals at any career stage. It may be the feeling of being stuck in an unchallenging role, feeling burdened by an undesirable skill set, or trapped in a company that seems difficult to escape.

Career stagnation in technology could be defined as a prolonged period characterized by limited project variety, no advancement or even lateral movement, few tangible accomplishments, and little exposure to any emerging trends. Some managers are aware that workers in these situations generally leave, so the managers may proactively try to satisfy staff by shuffling teams and providing more interesting tasks. Many managers have to focus on deliverables and may give little thought to the career development of their charges, perhaps throwing money at retention problems instead of providing challenges.

levelup copy

To “level up” could mean a promotion into management or technical leadership, a new start at a firm with increased opportunity, a role with autonomy and decision-making responsibility, or the ability to make significant improvements to skills and marketability. People that think about the leveling up concept often know what they want (or sometimes what they don’t want), but don’t necessarily see the best paths to get there.

Leverage the skills you have to get the skills you want

Most professionals view their current skills as a means to getting new jobs, but it’s useful to also think about skills as the key to acquiring other new skills. This tactic is most relevant when a skill set is dated and a previously strong marketability level is now questionable. Some will attempt to make a clean and immediate break from their old technologies or responsibilities into the new, usually with mixed results.

As an example, many COBOL programmers tried to enter the stronger Java job market following Y2K. Some applied to jobs with no Java experience hoping their COBOL years would be deemed transferrable, while others pursued certifications and self-study to ideally be viewed as a somewhat “experienced” hire. One overlooked strategy was to approach companies that were using both COBOL and Java in some capacity, with the understanding that the candidate was willing to write COBOL if provided the ability to also work with Java.

Most job seeking technologists have at least one ability that will help them contribute immediately to any other team or organization. It could be an obscure technical skill, leadership experience, or domain knowledge. Even if the skill is not something the person wants to use forever, it could be a key component to getting hired. Try to identify companies that may be looking for some specific expertise you can provide, even if it isn’t the most attractive tool in your bag, and be transparent about your willingness to do that less desirable work in exchange for exposure to skills that are in demand.


For those in the most stagnant of technical environments, taking on independent projects or open source may be the best way to gain experience and increase marketability. It’s usually preferable to learn new things on the job (because money), but being proactive about your career and keeping abreast of current marketable technologies will also show initiative to potential employers. The level up from personal projects almost always comes from an employment change.

Sometimes to level up you need to take a step back – or sideways

Careers aren’t always linear, and the expectation that trajectory needs to follow a strict continuous and incremental level of responsibilities is perhaps naive and potentially dangerous. Job seekers are often prone to placing too much weight on a position’s salary or (gasp) title without fully considering the position’s potential opportunity as it relates to future marketability and career development. Somewhat frequent movement between jobs is accepted in our industry, so positions can be viewed as stepping stones to future opportunities.

When evaluating new roles, whether with a current employer or another firm, imagine what a three or four year tenure in that role at that company will look like on future résumés. Will the skills likely to be acquired or improved in that role be marketable and transferrable to other firms? Accepting positions that come with lateral responsibility and compensation is usually a wise long-term decision when provided a more favorable learning and growth environment.

Homakov: Story of a White Hat

In early March 2012, a Russian programmer one month shy of his 19th birthday emerged on the radar of the software world via one “simple” commit that startled both the Rails and GitHub communities.


The exploited vulnerability was known to many in the community, so discussion about the controversy gravitated towards GitHub’s failure to properly protect repos and the potentially insecure default settings of Rails. The attention drawn to mass assignment served as a beneficial public service announcement to other Rails users, although the delivery method put off many developers as well as GitHub admins who quickly suspended (and just as quickly reinstated) the account. It was all over within a few hours, but Homakov had “arrived”.

Who is this guy?Homakov

Egor Homakov grew up in Saransk, a small city of 300,000 residents that sits 400 miles east of Moscow and somewhere deep within Ukraine on a Risk board. He dabbled with Delphi as a teenager to learn how programs worked, and later Pascal. His GitHub dates to 2009, oddly enough on New Year’s Eve. After initially struggling to understand programming concepts, his self-study turned a corner when he transitioned to web apps. Homakov dropped out of university before completing a year, which he admits was a risky move for someone in Saransk, but he found the program far too boring to continue.

Homakov initially focused his career on SEO, but when clients were hard to come by he began advertising PHP programming services on SEO forums. When negotiating a proposal to build a simple news management system for an early prospective client, Homakov requested a rate around $10 per hour. The prospect countered with an offer of $30 if the job was done well. This was a significant wage in Saransk, and Homakov distinctly remembers his mother’s pride.

Over the next few years Homakov bounced between employers, with freelancing gigs followed by short stints at European startups in the online payments and travel spaces. Eventually he decided consulting was his best option, and he is now part of the security firm Sakurity which provides penetration testing and code audit services to clients worldwide. The lion’s share of Homakov’s income comes from consulting, with some additional income via bug bounties (including a $4,000 payout from GitHub earlier this year).

Fame or infamy

Although he admits that he knew little about security before the 2012 GitHub hack, Homakov instantly became a polarizing figure. His action was lauded by some who believed the high profile exposure of the vulnerability would benefit the community by raising awareness for other Rails users. Others felt a more private notification would have been more appropriate, not to mention GitHub’s clear responsible disclosure policy in the terms of service. Supporters saw him as some populist hero sparring the Rails elite, while detractors resorted to mocking his broken English and even criticizing his profile photos. Those on both sides surely realized that he could have chosen the black hat route and done something much more malicious with the Rails repo and any others, and could have done so anonymously.

Some soon discovered that Homakov had indeed opened an issue about the mass assignment vulnerability, and only went public when he felt his warning had fallen on deaf ears. Homakov later regretted much of his behavior, and eventually provided a brief public apology to both GitHub and the Rails team. It’s not much of a stretch to imagine that GitHub’s bug bounty program launched earlier this year was at least partially influenced by their highly public experience with Homakov.

The most interesting man in tech?

Since leaving Russia, Homakov has become a world traveler. His Tumblr feed reads like a poorly edited and NSFW Frommer’s guide, chock full of selfies and commentary on the livability and food/drink from locations throughout Europe, the United States, and southeast Asia. Sofia, St. Petersburg, Barcelona, Istanbul, New York, Shanghai, and Seoul – all while earning a living and developing a reputation in the security space.

From his writing it is clear that he has an affinity for Asian culture, bright city lights, and beer (not necessarily in that order), while showing no affection for his country of birth. After about a year on the road, Homakov finally settled in Thailand, where he intends on living for a year before picking up for more travel on the spots he has missed on his first world tour. India, Africa, and South America are on the agenda.

He seems pretty funny too. His Twitter feed is peppered with various self-deprecating third person references as well as little gems like this…


And now that he’s showing maturity…

joke2… he seems to have the ear of at least some in the industry.


Although much of his security research is unpaid and he is far from wealthy, it’s been quite a trip so far. From $30 to $300 an hour, and from Russia to Bangkok with plenty of stops in between – all in two years. He admits he acted irresponsibly, but now calls himself white hat and takes responsible disclosure seriously. As someone who first arrived to the security field conspicuously, Homakov continues to strive for increased credibility and legitimacy from peers in the industry. For many, his work will speak for itself. As he now approaches his 21st birthday, one has to wonder what his future hold.


Author’s Note: This article is a departure from Job Tips For Geeks normal content, but I see value in profiling technologists who have unique careers. I hope to profile others with non-traditional backgrounds and career paths. Feel free to contact me if you feel you fit into this category.

Why Hire Older Engineers

Another day, another article about age and technology. The comments of these articles usually escalate into some generational war played out with mythology and anecdotes regarding relative energy levels and productivity, work hours, the value of experience, and general competence. These discussions usually make no progress, while some useful topics are ignored.

As someone who has been around programmers (and ran a Java Users Group) for about 15 years, I often guide senior technologists in marketing their skills. When doing business with clients, I find myself advocating on behalf of older coders regularly. During the first dot com boom multiple six-figure job offers were dealt to anyone at any age who could spell J-A-V-A, but the landscape is much different now.

Most companies I’ve worked with give candidates of all ages a fair shake, although I’ve witnessed some who have been less friendly to industry veterans. For firms that need additional justification for hiring older workers, here are a few additional considerations that may go beyond the more common topics of discussion.

mainframe picture

Recruiting – So your efforts to scale your team came to a screeching halt? Inevitably the friends and family network dries up and firms rely on internal recruiters or outside agencies to identify talent. Although young hires may be more connected due to early adoption of social networks, older workers usually come with established professional networks. These contacts are not just other senior engineers, but will also include younger former co-workers. When you consider the costs of recruiting (not to mention the costs of a bad hire), the ability to tap into the network of highly experienced engineers might even justify paying a higher salary.

Beyond just the network a senior engineer may possess, having experienced talent on staff will appeal to young candidates who understand the value of learning and career development. A predominance of junior engineers will typically scare off older applicants, and it’s also likely to be a red flag for some subset of the young. Graduates are typically encouraged to find a career mentor, and they will seek experienced professionals to serve in that capacity.

I generally advise my clients on employing some senior level engineers who are strong coders but will also serve a secondary purpose of attracting other less experienced hires. The term I usually use is “hire magnets“, and those magnets may fit a few different profiles. The magnet could be a recognized authority on a topic, an involved tech community leader, or simply a knowledgeable and charismatic developer who enjoys sharing knowledge.

Fad recognition – Industry experience may give engineers a sharpened ability to sniff out the difference between a passing fad and the genuine article when considering new technologies. This of course isn’t by rule, but once an engineer has seen enough shiny things being hyped by marketers and evangelists it should theoretically become easier to evaluate trends with less bias. Hires with this skill may save a company time, money, and many developer hours.

Less performance unknowns – Older engineers with a documented work history, a list of credible references, and demonstrable work experience should be easier to vet than juniors coming from their first or second job. The ability to rely on past performance to predict the future is a benefit, though never perfect.

Retention/stability – Employee retention is a serious concern and cost for many firms, with demand for talent contributing to turnover. Older engineers and those with families should be less likely to consider relocation for new positions, which limits their other employment options to local or regional opportunities. Although both junior and senior level engineers may have bills to pay, the breadwinner concept changes perspective and may result in satisfied and fairly-compensated developers staying put.

Senior level developers often reach a point where compensation plateaus and money ceases to be an incentive to change jobs. Employees less driven by dollars are surely driven by something. It could be something as simple as proximity to their home or a desire to solve complex technical problems, but competitors are less apt to change these factors and often need to compete with pay.

From my experience, most engineers see fewer significant increases related to job change around their 15th year in the business, and by the time someone reaches that level of seniority it isn’t unusual to have once taken a pay cut. Junior level talent in competitive markets view job change as the most reliable means to salary increases, while the relatively minor compensation differential for senior engineers may not outweigh the uncertainty of a new employer.

Unique situations – There are some scenarios that happen in development shops that are nearly impossible to replicate in a classroom or lab setting, and the ability to face the unexpected comes from being there. This could refer to crisis management when a server goes down, handling difficult customers, or knowing how to navigate office politics. Prior exposure does not guarantee preparedness, but should make the second experience less shocking.

On-the-job learning – Older engineers may now be on their second or third set of platforms and corresponding tools. Developing the ability to learn new languages and tools in a work environment is a skill. It is quite valuable to know how much (or how little) to read before starting a project with an unfamiliar component, or which methods are most effective for you when seeking knowledge.

Any that I missed?

How To Succeed in Software Without a CS Degree

This week I was approached by two individuals seeking advice on finding employment in a programming capacity, yet both lacked the traditional standard requirement for entry-level positions – the BS in CS (‘BSCS’). I get asked about entering the industry often, and each scenario has a unique wrinkle.

The most recent candidates were a fresh Ivy League liberal arts grad and a Physics Ph.D. The former had brief hobbyist programming experience and the latter gained light exposure during school. Both are immediately employable in other industries, but perhaps not in the field they now target.

Of course, both may still be able to earn a BSCS (or MS) and take the traditional route. For our purposes here, let’s take that option off the table. For a Ph.D., the thought of additional classes might be hard to swallow, while costs might serve as a barrier for many others.

Non-BSCS candidates are often at a distinct disadvantage when competing with BSCS grads for entry-level positions. It’s becoming more common for CS grads to enter the workforce with multiple internships and code samples to bolster their candidacy. It’s reasonable to assume that typical non-BSCS grads have nothing comparable, in addition to what may be considered a less attractive degree.

One important point to remember is once you’re in you’re in, meaning that the most difficult job search for non-BSCS grads should be the first one. After gaining a bit of experience, your risk factor subsides (assuming you didn’t perform horribly in your first job). After three years no one cares about your major, and after five no one cares about your degree.

What are the common approaches for a non-BSCS grad to break in?

DIY and self-study (AKA GitHub, apps, certifications, blogs, and sites) – This method is based on the philosophy that you get a shot if you have a body of work. The wealth of freely available resources makes this method attractive to both the confident and the frugal. There can be a fine line between rigorous code immersion and post-graduation idling, so it’s helpful to set tangible goals, a schedule, and practice self-discipline.

When given no direction on what to build, people usually struggle to find projects ideas. Look for suggestions like those on Martyr2’s Project list, and improvise. As for reading material, there are extensive lists of free programming books that may be helpful. All the material you need is out there and easy to find.

Bootcamps – Any conversation today about breaking in for the non-BSCS will include bootcamps, and I have mentioned thoughts on them before. Bootcamps may be regarded as a compromise, where the investment of both time and money rests between DIY and degree programs. Some view bootcamps as an accelerated BSCS, or a hybrid internship and apprenticeship with classwork included. Most bootcamps appear as preparatory schools for startups based on the skill focus and instructors. Do your homework, and use caution when discussing the value of bootcamp experience versus degrees to avoid insulting employers.

Internships, or cheap/free labor – Some organizations (think small businesses and non-profits) will let a non-BSCS perform development tasks as an intern or volunteer. This can be a clear ‘win-win’, as the organization gets productivity while you get somewhat valuable real-world experience. A combination of volunteer or internship and personal projects starts to level the playing field for a non-BSCS.

Training in – There are companies that hire non-BSCS for entry-level programming jobs, and the first months include corporate training programs designed for non-CS grads. The positions may pay less than entry-level programming jobs, with curriculum intended to produce effective employees instead of versatile engineers. For example, instruction could focus on proprietary technologies and frameworks instead of popular industry offerings.

What are some key items to consider?

Get out of the basement! – Some DIY’ers bury their head in code and books with no human interaction. Make community learning events and outside communication a part of your diet. This will help you measure your knowledge in a live setting while also providing the opportunity to make some industry contacts.

Don’t enter the job market too soon – For CS grads, the natural time to start the search is around graduation. No mystery there. For the non-BSCS, there is an instinctive rush to start applying to jobs early in order to take the temperature of the job market. Fight the urge. If you apply to a desirable company today and are subsequently deemed unready, don’t expect to be reconsidered in three months (when you are ready). Make sure you know enough to succeed in technical interviews, have your GitHub code clean and optimized, have any apps or sites tested and fully functional, and are prepared to make a strong impression.

Leverage the skills you have to acquire the ones you want – Bringing useful abilities and experience that can pay immediate dividends (no matter how small) to an employer mitigates their hiring risk. If you are able to contribute to an organization beyond just code, providing both a learning opportunity and a decent wage is easier for firms to justify.

Be realistic – Your three months of self-study or bootcamp are not likely to get you the dream job at Google. Be willing to start towards the bottom and pay your dues to move up.

Beware certifications – When faced with a choice of proving abilities with either code or certifications, always pick code. Many industry pros attach a stigma to those who focus on getting certified instead of just doing.

Make learning opportunity your #1 job search criteria for first jobs – The money will come. Trust me. If provided multiple job opportunities simultaneously, opting for a job due to an extra $2K or a commuting difference of five miles will be regretted. Find a place where you can learn and grow.

For more tips on job search for software professionals, see Job Tips For Geeks archives or my book.

When You Can’t Compete on Salary: Tech Talent On a Budget

When trying to hire developers, startups and small companies now find themselves in the unfortunate predicament of having to directly compete with the unlimited resources and mass appeal of market heavyweights like Google and Facebook. New grads are laser-focused on getting jobs with what many call The Big Four, and some grads will land. Most founders and hiring managers know they can’t match compensation, name recognition, or facilities that the big players provide, yet they do a poor job marketing themselves to talent to demonstrate where they actually can compete.

A quote on a recent Hacker News thread echoed the frustration that countless others surely feel:

I hire engineers at an academic medical center who work on really tough biomedical problems. Let’s just say that I would have to move heaven and earth to get annual percentage raise amounts that are being thrown around here. I wonder how industries like healthcare can hope to have the best people with this job market. At some point, even if you are doing work that really matters in a big way, you can’t be stupid about your career and leave money on the table. – HN user JunkDNA

The commenter is correct that the medical center’s employees are likely ‘leaving money on the table’, but this does not mean that hiring managers must resign themselves to subpar talent. A defeatist attitude leads to a host of problems down the road, and mediocre teams create mediocre products and a poor company reputation (which then makes competing for talent impossible without massive compensation packages).

My experience has put me in a position to observe candidates with multiple offers many times. Candidates don’t choose the highest bidder as often as one might expect, and once you’ve had enough conversations on the choice between Job A and Job B it becomes clear that there are several situations and characteristics that technologists are willing to take in lieu of dollars and a recognized name on their résumé.

Firms competing for tech talent on a budget should consider how the topics below influence candidates’ decisions when weighing money against intangibles, and how to market themselves to increase appeal to potential hires.

Work visibility – Many developers derive job satisfaction when they can show friends, parents, children, and significant others what they actually do. Whether they coded an e-commerce site, a video game, or even a device driver, many developers relish the ability to say “I built that“. This value gets overlooked, but it can be one competitive advantage in hiring. If a company builds a visible product, that can be a selling point.

Remote work – If you feel demand for remote work is overstated, post a remote job and see for yourself. Some of the applicant pool’s volume and quality is obviously explained by the geography barrier being lifted, but job seekers are specifically including ‘remote‘ or ‘telecommute‘ along with their tech search terms. The groundswell supporting remote work is impossible to ignore, and remote hires are often willing to accept less money (which can create other problems). If 100% remote work isn’t feasible, even implementing “Remote Fridays” may make a difference.

Autonomy – This could be defined as the ability to make decisions on tools and vendors, final say on hires, or being able to choose a machine and operating system. If autonomy is offered, it’s often worth noting.

Languages and tools – The importance of languages and toolsets became apparent to me when several more lucrative offers were rejected by candidates due to concerns over future marketability or distaste for the tools and languages. Hiring managers are beginning to appreciate the weight some job seekers place on being paid to code in a certain language, and those managers may attempt to justify using an emerging language in some production capacity for the purpose of attracting new talent.

Impact on the business – Most candidates that interview at large companies don’t expect that their contributions will significantly impact the firm’s direction or bottom line. Smaller firms offer the potential opportunity to make a measurable impact, and can use that opportunity as a selling point.

Interesting problem domains – All technical problems won’t interest all candidates, but savvy technical interview teams should learn to discover a candidate’s interests and articulate how the job will allow that itch to be scratched. For most industries, it is vital to get the candidate to look past the non-technical business (widget selling) and focus on the technical challenges (supporting 10M widget buyers). Complexities around scalability and concurrency can make a mundane business quite appealing to top talent.

People – I ask all candidates how they choose jobs, and “people” has consistently been a top 3 answer over my career. For some this means the broader company culture, while for others it is the ability to work with experts. Even at a rate above market, hiring a couple high-level talents who can act as magnets for other talent can be a wise investment if it makes future hiring cheaper and less time-consuming. Companies competing on intangibles should always put their best people in front of candidates during the process.

Reasonable hours/flexibility/vacation – It is somewhat rare for companies to advertise the length of their work week, due to inconsistencies related to events or the sobering realization that the hours are undesirable. For most companies, a reference to a week in the 40 – 45 hours may be considered a genuine draw to candidates, while under 40 is notably positive. Flex time is another perk that can make a company’s expectations more reasonable.

Equity/interest – Parting with equity is often not a founder’s first choice, but when up against deep pockets it becomes one potential equalizer.


Those involved in the hiring process should be aware of their company’s potential competitive advantages over the larger employers in their market. This is most important when it is impossible to outbid well-known market leaders. Tech talent does not always go to the highest bidder or the biggest name.

Counteroffers, Secrecy, and Fear

Counteroffers are a fairly common occurrence in technology and other competitive job markets, and much of what we think we know about counteroffers seems to originate from agency recruiters. Google counteroffer and we find articles with fear-inducing titles.

counteroffer copy

Check the bylines for these articles and you’ll discover that many are written by recruiters. Some agencies are so bold as to direct their counteroffer article right at the candidates they represent. Or a page of Counteroffer Facts, which go on to list things like “Your loyalty will always be questioned” (which is probably not a fact). It’s pretty clear how recruiters feel about counteroffers.

There is nothing wrong with recruiters writing articles about counteroffers. You are reading one now. Many provide ‘statistics’, while others contain anecdotes revealing the unfortunate fate of those who accepted. Spoiler Alert – In recruiter articles, those who accept counteroffers always die alone and penniless. These pieces aren’t necessarily biased or untrue just based on the source, but when recruiters are the source you need to understand one thing.

Recruiters NEVER benefit from an accepted counteroffer.¹

Counteroffers are the bane of a recruiter’s existence. Put yourself in a recruiter’s shoes for a minute. Over a few weeks you’ve identified a strong candidate, screened, set up interviews, debriefed, negotiated a salary, checked references, and an offer was accepted. You will be rewarded handsomely, as a fee might be in the neighborhood of 30K (sometimes less, sometimes more). If the recruiter is independent or self-employed, that’s a car. And then you get a call saying “My company made me a counteroffer, so I’m staying.” You just ‘lost’ a car. I’ve had it happen, and it burns.

Even if a counteroffer makes all the candidate’s wishes come true, it’s still never in the recruiter’s best interest for it to be accepted. Recruiters get paid when they get you a job with their client – not when their efforts result in a better job at your company. This is part of the reason the recruiter/candidate relationship has flaws, as the interests of the two parties are not always aligned. It’s no wonder some recruiters invest significant time in talking about counteroffers.

How do recruiters prevent counteroffer acceptance?

The best way to prevent a counteroffer from being accepted is to prevent a counteroffer from even being presented, and recruiters may take a two-pronged approach to protect their fee and the interests of their client. Here is a peek into the methods. (NOTE: These details are provided to benefit job seekers, and not as any endorsement.)

1.  Find out why a candidate is considering new jobs.  Why are we talking?” This question sounds innocuous and usually comes across as an ice breaker, yet the answers prove valuable if a counteroffer is presented.

2. Get the candidate’s opinion on counteroffer early. “Have ever accepted a counteroffer?” may come up in your first conversation with a recruiter. Candidates rarely admit that they would consider a counteroffer. If the recruiter can get that opinion in an email, expect to see that email when a counteroffer is made.

3. Tell stories and provide ‘statistics’. Many recruiters cite a National Employment Association study that says 50-89% (depending on where you find the statistic) of people who accept counteroffers will not be with the company after six months. I was unable to find any reliable source for that (date, sample size). Of the 34,000 Google hits on “National Employment Association”, over half contain the word counter or counteroffer. Seems odd, no? It appears the organization somehow merged or morphed into a couple others (NAPC or NAPS), but the statistic lives on. I’ve seen anecdotes that this stat has been used since the 70’s.

Others mention a Business Week figure at 90%, but all I was able to find was an article from 2004 that cites “some studies” and puts the number over 50%.

One may get the impression that recruiting firms are using statistics from other recruiting firms, as these studies seem difficult to verify. Anyone got a source? To get decent statistics, you need consistent methods of gathering data. Even the definition of what qualifies as a counteroffer is up for debate, so any stats are questionable.

Even without numbers, anecdotes work just as well.

4. Fear, shame, worthlessness. The statistic is delivered as “Most who accept counteroffers are gone in six months, either by choice or (dramatic pause) … termination.” People have a strong fear of being fired. Candidates will be told how they will never be promoted or given raises, will be a social outcast, and they will not be given interesting work. These are all possibilities, but obviously not guarantees, and someone who habitually forgets to buy the donuts could suffer a similar fate.

The recruiter may also remind you that your employer never really valued you in the first place. They might say “Sure, you got a raise – but you had to hold a gun to their head to get it. How much do they really care about you?”

5. Resignation. If a recruiter has ever offered to provide you with a resignation template, or to even tender your resignation on your behalf (it’s rare but it happens), it may have been a genuine act of kindness to save you time. A recruiter’s resignation template may include language intended to prevent counteroffer, and some are direct. “Let’s not waste time discussing what it would take for me to stay, as I have already passed on my firm commitment to a new employer.” If the candidate emphasizes that he/she does not want a counteroffer, resigning with a letter that says is appropriate.

6. Transitioning. Once a candidate accepts an offer, a recruiter wants the candidate’s loyalty and interest to shift to the new employer. A lunch may be scheduled before start date to discuss projects. If there are skills that will need to be learned, the candidate might choose to get a head start. Interactions between employers and new hires have obvious benefits beyond the prevention of a counteroffer acceptance, but that will be in the recruiter’s mind.

I remember discussions in one recruiting office about which day of the week was most common for counteroffers to be given, and then suggesting that the recruiter get together with the candidate on that day.

When It Happens

When a candidate accepts a counteroffer, it usually sets off recruiter panic mode. The recruiter will remind the candidate of some things – why they were looking in the first place, opinions expressed about counteroffer, the dangers, their firm commitment to the new company, etc. As a last resort the recruiter might make a personal plea and mention the fee, or even their own family. Some people will say a lot of things for 30K.

I don’t have a problem with some of the things recruiters say as warnings against accepting a counteroffer, as much of the script contains real possibilities. Accepters might not get promotions, raises, or interesting work. We can question the morality of using fear to get someone to do what you want them to do. If the recruiter is honest and believes that the new job is best for the candidate’s career, it’s easier to justify what is said. I do have a problem with the statistics, and the recruiting industry’s willingness to throw around questionable numbers.


Statistics about counteroffers are impossible to measure when you consider the interests and incentives of the parties involved. Companies that counteroffer departing employees are best served to keep that fact private. as employees may pursue offer letters just for the sake of a raise or improvement and outsiders may question if the company pays market rates.

Likewise, those who accept counteroffers may be concerned with the word getting out, as it may genuinely impact attitudes towards the employee. Employees who accept counteroffers are likely asked to keep quiet about what happened, and it’s usually in their best interest to do so.

Based on the secrecy incentives on both sides, one might assume that the prevalence of counteroffers is likely higher than reported, and success/failure rate of counteroffer is difficult to assess.


Regurgitating outdated or questionable statistics as fact hurts the credibility of the recruiting industry. Counteroffers are all very different and impossible to classify or evaluate without knowing countless other details about the candidate’s situation and the organizations involved. When listening to recruiters’ opinions (including this article), it’s vital to keep the source in mind and make important career decisions based on all the information available. Ask yourself if the counteroffer will solve the issues you had with the employer, and if so whether your means of achieving these results (resignation) will make it difficult to stay.

¹ There is one extremely rare instance where a recruiter might benefit from a counteroffer. Say the recruiter places a candidate at Company A, and during the recruiter’s guarantee period (usually 90 days) the candidate accepts an offer from Company B, and then gets a counteroffer Company A. In this case it benefits the recruiter for the placement to accept the counteroffer from Company A so the recruiter will not have to refund a fee.