Tagged: Technology

In August 2012 I published a blog post Why You Didn’t Get The Interview, which received a good bit of attention from readers and was republished a few times (most notably by Lifehacker). Of course one article could not list every possible explanation that an employer or recruiter might use to discard a résumé, so I decided to revisit the topic once again. This is not intended to be a comprehensive list, but rather an addendum to the previous post that may help explain a lack of response to your job search.

No submittal content – Online applications often consist of several fields and check boxes that don’t always give job seekers an opportunity to express interest or differentiate themselves. However, when you send a résumé via email or are provided some space within an online application to craft a custom message, you are foolish not to take advantage. Simply sending a résumé without any supporting information about your experience or interest in the job comes across as lazy or aloof, and can give the appearance that a job seeker is simply blasting résumés indiscriminately (perhaps even in an automated fashion). SOLUTION: Tell the employer at least one or two things that drew your attention to the job and company.

Multiple applications to the same employer for vastly different roles – Sometimes I will open my inbox and find an email from a job seeker about one job that could possibly be a fit, and then find another four or five emails from the same applicant for other jobs that are not remotely connected to the candidate’s experience. This applicant may have received some attention if he/she only sent the one semi-targeted application, but the additional blind stabs have too many negative implications. It typically signifies either a lack of self-awareness regarding qualifications, immaturity, or desperation. SOLUTION: Before submitting your résumé, check several of the company’s listings to make sure that you are applying for the one or two jobs that best fit your experience and goals. If you have a strong desire to work for a specific employer, sending a targeted application to one or two listings is much more effective than spamming your résumé to all of their vacant slots.

Many small red flags – My original article last year referenced 14 fairly obvious reasons that job seekers are not interviewed, but often it’s not that simple. Many times a résumé/application package will contain a handful of items that would not be a problem when considered individually, but when combined add up to a rejection. The recruiter or hiring manager will feel that too many special circumstances would have to occur that make the candidate’s hire unlikely. Perhaps a candidate has a slightly elevated salary expectation, requires relocation assistance, is minimally qualified, and lacks any easily identifiable positive indicators of talent or ability that stand out from others. An applicant with only one of those characteristics would likely be considered, but the aggregate picture makes it too much of a longshot. SOLUTION: There is no real fix to this. You could always try to explain what could be perceived as a red flag. For example, if you are relocating to a specific area, make it clear why you are looking in that specific market to avoid being viewed as someone open to jobs worldwide. Displaying some level of interest or passion for the employer could also help overcome objections and get you a shot.

Personal reputation and your employer’s reputation – It shouldn’t surprise anyone that if you apply to firms where people either know you or are connected to those that do, a decision to interview will typically be based on how these contacts feel and talk about you. However, your employer’s reputation may also come into play here as well. If a particular company has interviewed multiple former employees of your firm without much success, chances are they will not waste time interviewing another. As a recruiter, it is fairly common for companies to tell me “Unless they are outstanding I’m not overly interested in candidates from COMPANY, as we see many and have not had any luck.” Your company’s reputation is more likely to work in your favor if you are employed by a firm known for having talent, but it seems the trend to discriminate against employees of certain shops continues. I wrote about this a bit in a past post regarding discrimination by startups against workers from large enterprises. SOLUTION: Keep your personal reputation in mind when dealing with co-workers and particularly when leaving jobs. Minimize stints at employers that have a negative reputation in your market.

Inconsistency – This can be the result of discrepancies between a résumé and cover letter/application, between a résumé and LinkedIn profile, or just something fishy in the résumé itself. If you changed professions more often than Barbie (impressive list) or have travailed up the corporate ladder and come back down multiple times, your application will raise suspicions. Candidates that list titles progressing from CTO to CEO and then down to Junior Developer will be scrutinized. SOLUTION: There isn’t anything you can do to change the past, but explanations could go a long way if you left an industry to pursue a passion. Make sure all of your online profiles match your résumé details before sending applications. Try to use job titles that reflected your actual duties if you worked for a small firm and had an inflated title. Even if you were CEO or CTO of your dorm room software company, it may not be helpful to list the job that way.

“Meh“ – Your qualifications and history are virtually identical to the others in the stack of résumés received. You may have met what was listed on the job spec, but so did everybody else. This is of particular importance for jobs where it is expected that most applicants will have similar qualifications, such as entry-level positions for new graduates or jobs that list highly generic specifications. SOLUTION: There has to be something different about you that you can add to give some positive spin to your candidacy. Review the requirement again and try to find an area where your background exceeds the expectation, or a specific experience you have that others probably don’t.

I’ve recently seen a spate of engineers declaring boredom and/or dissatisfaction with their current roles and responsibilities, which leads them to openly question what options are available. Perhaps building accounting software products or maintaining the web presence of an insurance firm just isn’t inspiring you to get out of bed anymore. This problem isn’t unique to the software industry (and based on a 2003 Joel On Software post, not necessarily new), but whenever a professional invests years of their life getting an education and honing their skills, it can be daunting to think that the time was somewhat wasted.

Thankfully, if you are losing your passion for typical web or software development, your training and experience have at least in part prepared you for several alternative roles that perhaps you have not considered. It seems that frustrated developers tend to weigh their options as stay in development or leave the industry, without considering the fact that these other alternatives exist. If the source of discontentment is tied to the role of app or web dev work (and not the overall tech industry), there are some relatively new roles that have become more in demand that may satisfy the itch you have.

This information may also be useful to new entrants into the market and grads that are wondering what they can do with their computer science degree other than just stereotypical development roles.

Here are some examples (some have crossover and similarity):

Performance Engineer – This role isn’t about building a product, but rather improving speed, scalability and reliability. Performance engineers may be thinking about databases or monitoring tools one day and hardware or operating systems the next. It is a highly technical and specialized role with increasing market demand.

QA Automation Engineer – QA is one discipline that seems to have gone through some significant changes over the course of my career (15 years). In the late 90’s, QA meant large teams of manual testers and high demand mostly attributed to the Y2K scare (history lesson for the young). At some point thereafter it became the norm to outsource QA overseas, making QA a lost art in the US and thus making QA talent significantly harder to find. Over the past couple years, there seems to be some resurgence of demand for QA to be performed domestically, and hires typically will be expected to have some automation and scripting experience.

DevOpsEngineer – This is another role that has been growing due to the number of shops that like to deploy frequently. As the trend in delivery will not be changing anytime soon, the ability to automate the process will continue to be in demand.

Configuration, Release, or Build Manager/Engineer – As the look of development teams has progressed from crowded shops to remote employees, combined with the popularity of cloud-based computing, the concept of configuration management is changing. Demand for talent in these areas is relatively steady.

Embedded Systems and Firmware Engineer – Although the transition from your typical app or web developer position may be a bit more complex, one should expect growth in embedded systems to continue as the variety and sheer number of devices continues to increase. The concepts of ubiquitous computing and the Internet of Things are getting one step closer to reality every day, and engineering talent with a unique set of skills will be required.

Project Manager, Technical Writer, Business Analyst – Having a coding background can make the move into any of these jobs a bit easier, and your appreciation for development should maximize your shot at being successful.

Before abandoning the years you have invested in learning how to code, consider whether or not you may be happy in a different role that enables you to reuse many of the skills you have already developed.

My ebookJob Tips For Geeks: The Job Searchhas been released and is now available in most formats. See thebook pagefor details.

Lately I’ve seen quite a few requests for advice from younger programmers, asking questions either directly to me or in public forums about a career decision they are being faced with that is causing some level of stress. Reddit’s r/cscareerquestions is a hotbed for this type of activity, and you might see the occasional similar post on Hacker News. After 15 years in business, I’m quite comfortabel providing insight on the potential benefits and drawbacks of say, taking a job doing mostly Python versus a position exclusively using a rarely seen proprietary language and platform, or accepting a pure technical management position versus staying more hands-on.

Generally, I want to tell all these people the same thing. If you really enjoy the work and want to be successful in the business for a long time, you should try to make decisions, think like, and become an engineer’s engineer.

I know quite a few people I’d describe as an engineer’s engineer, and most of them have some gray hairs or are young but sound like a throwback to times past. Fortunately, some less experienced developers are benefitting from being able to work alongside someone in this category, who are more often that not open to mentoring and showing the way. As a recruiter I look at and treat these engineers like gold, as they are the types that any of my clients would want to hire – plus they tend to teach me new stuff in every conversation.

Who is the engineer’s engineer?

Utility player – In baseball, it wasn’t uncommon in the early years for players to play several positions. Specialization has happened in baseball to the point where there are now pitchers who only pitch in the 9th inning. Similarly, software development shops are now often filled with segmented roles for build engineers, dev ops, QA, architects, performance engineers, database developers, etc. The engineer’s engineer is a utility player that can jump in almost anywhere, and doesn’t see the demarcation as a boundary that cannot be crossed. Little is considered beyond the scope, and they will not want to silo themselves into a singular function.

Initiative – If they see something that is broken, they fix it. Will automating a task make our lives easier? If so, let’s do it, and only ask permission when absolutely necessary. This requires some level of autonomy.

Technical integrity – By this I mean that an engineer’s engineer will have some opinions about decisions being made (if this person isn’t calling the shots) and will make that opinion known when there is disagreement. Instead of just saying an idea is bad, an alternate solution will be given. This is the desire to do things correctly over taking short cuts, which is likely to conflict with the business at times.

Can’t be bought with money or title – This group will never take a job purely based on salary or rate, and are driven by the ability to solve interesting problems and work with a strong team. Job title means absolutely nothing. In my experience, most engineers factor money heavily in job decisions and sacrifice a better career move or additional job satisfaction for what amounts to a difference of $2.00 an hour. If you’ve chosen a job based on a 5K salary difference, this is you.

Sharing – The engineer’s engineer wants to share, whether it be information on how and why they arrived at a particular solution, their favorite tools, or anecdotes about past projects. This is based on a combination of pride in their work and interest in teaching others. Open source is often a part of this equation, where there is a desire to share your solution for the outside world to see and use.

No limitations – The engineer’s engineer doesn’t want to have the toolset options defined and thrives in an environment where they have autonomy over what will be on their machine. Having a company mandated IDE or OS will be a turn-off, as will any roadmap listing few acceptable tech options. Heavy bureaucracy, regulation, or barriers to being able to solve problems are an issue. The shop ideally will be engineering-friendly.

No personality conflict, less ego – Of course, many strong programmers (and some weak ones) have quite a bit of ego about what they do. The engineer’s engineer does not come across as overly self-important, and can be more humble than those much less-skilled. This group isn’t alway the most friendly or popular person on the team, but is never the most hated.

Lack of zealotry – Even though they want to use the best tools, they understand that their weapon of choice might not be appropriate in all situations. This group knows there are no silver bullets, and laugh when others get overly religious about the new hotness. Technology and new products excite them, but they are unlikely to get a tattoo of the latest JavaScript library.

Movement – This group wants things to be progressively moving forward with few delays. Low latency in their process and little downtime at work.

Has the back of team members – Solidarity among other engineers is their goal, and they tend to stay above or away from the drama of interoffice politics. They are there to solve technical problems, and have no interest in gossip or attacks on others.

Know that they are not their code – These people can separate a technical criticism from a personal attack.

Doesn’t need to be a leader – They are often more happy when they are not in charge, and are not instinctively driven to tell others what to do.

Note: In thinking about and doing some mid-article research for this piece, I came across Paul Graham’s 2004 piece Great Hackers which identifies some of the same traits listed here as being shared with hackers. The hackers he describes should share the workplace desires and drive as the engineer’s engineer, but may not always have the same personality or behavioral traits.

Today’s software professional is under constant pressure to maintain a high skill level with an ever-changing palette of languages and tools, and the fear of potentially becoming somewhat irrelevant can be daunting. Those that do not keep up with industry trends and movements are at some risk of losing marketability, but even those that do closely follow tech news need to make choices on which skills to pursue (time permitting), which to ignore, and what methods to use in the pursuit.

The first instinct to learn something new would naturally be to find some good resources online and perhaps acquire a couple books. You can find presentation slides and videos, articles and blog posts, and even attend live meetups or conferences in addition to your reading. Over the years I have seen hundreds of engineers (accomplished and junior) that invest an extraordinary amount of time to reading about different languages and tools, many of which they may never even get to use professionally. Some even read with the goal of some certification, which they feel will demonstrate mastery of a new skill.

I have also come to know another group of technologists who are inclined to learning in a different manner. This group starts off with some amount of reading as well, which might be limited to the product documentation and a quick tutorial, and then immediately transition into a more hands-on approach. Once they have a basic understanding of a language or tool, they actually try to build something.

As a recruiter, I have had candidates do a quick study on a new language (used by the potential employer) and throw together some common interview coding problem or even a simple app in a GitHub repo. As a Java user group leader, I have had presenters build small apps to help familiarize themselves with a framework they will be describing to others, and then demo the app live. The offer to present could be “I think X looks pretty cool. I’ve read about it but haven’t used it yet, but I’ll build something and present on my experience with X. I can be ready in a month.”

It appears that many technologists are very comfortable with the reading portion of learning, but focus there too long and never get around to creating something. This seems to be common for some college graduates, who obtain a wealth of classroom experience but very little time spent doing. Even if what you build is entirely useless to the world, your creation has value. Learning by doing is not a new concept, so the educational value is obvious. What other value is there?

Marketability and interview advantage
I was prompted to write this post about book learning when I was reviewing my recruiting placements for the past year. The developers I’ve helped into new jobs over the past year have (with few exceptions) had one thing in common – a portfolio of products and code. This was rarely the case ten or even five years go, but today it has become the norm. The Android and iOS developers I’ve placed had at least one app available for download. Web developers were able to demonstrate sites with accompanying code samples. Even the programmers who focused on back end had something to show in interviews.

The biggest example of the value of ‘learning by doing’ and a portfolio is probably exemplified by the mobile app space. It’s hard to sell yourself as a mobile developer if you don’t have any mobile app to show, and “Do you have an app?” is probably the first question mobile devs will be asked. Software developers in most other areas are usually not subject to or judged on this direct a question. Put simply, mobile developers know that in most cases having an available app makes you more marketable.

Programmers who work in more secure environments, such as those who build defense systems or financial software, often find it impossible to produce a work sample when seeking new employment. Without being able to show your past work and with no personal projects, these candidates are much more liable to be subjected to a language interrogation and the game show style of interviews that many job seekers dread. Marketability may be more tied to experience and somewhat arbitrary measurements of skill instead of demonstrable accomplishment for these candidates.

Interview advantageHaving a portfolio gives an interviewee a distinct advantage, in that the interviewee has at least some control over the topics that will arise. Walk into an interview empty-handed and the possibilities for question topics are endless, and chances are you won’t have endless answers. If a candidate brings a work sample to an interview, it will almost certainly be included in the discussion, and one would hope that the code’s author should fare better on questions regarding that sample than on questions on random topics. Even average developers should see performance improvement in interviews when the topic is their own code.

tl;dr
Read enough to get going, then build something. Don’t worry about whether your something is going to change the world. Save what you build, and occasionally look back and improve upon it. Bring what you build to interviews, and practice talking about your creations.

A recent Hacker News post by a man named Andrew was voted to the front page and received over 50 comments (as of my post). The post was called Ask HN: Would you hire me?, and Andrew specified that he was talking about a junior level position.

He provided the following details about himself:

28 years old with a Finance Degree from a non-Ivy league school

Spent the last two years living overseas teaching English and learning to code

Fairly well versed in html, css, javascript, and PHP

He also included links to his:

GitHub – handful of repos, 7 months as a member, pretty active over the last quarter

Blog – Attractive UI, 7 overall posts (a few with some code), with the highlight being details of a Chrome extension he built and demonstrates in a video

Andrew received a fair amount of positive feedback, and not one single poster gave a ‘you are not hirable‘ response. No CS degree, no professional experience, yet a highly technical audience were either mostly positive and at worst neutral on hiring (considering is more accurate) this potential applicant. Only a couple responders mentioned looking at the one project he listed, and none referenced the quality of his code samples on his blog or GitHub, so we might assume that no one even bothered to look at his code. Interesting.

Part of the explanation for the positive response is undoubtedly the makeup of the Hacker News crowd, which does not include a large contingent of HR reps from large companies who control a great deal of the hiring decisions. Place this resume and story on Monster or Dice, and I expect that Andrew would receive responses from less than a quarter of his viewers. Possibly less than a tenth.

I admit, if I were to see this candidate’s resume (assuming it reflected the details he put on HN), I would absolutely want to speak to him. The clients I represent, which are mostly startup and early stage software companies, are more representative of the HN crowd (at least in terms of evaluating engineers) than most larger companies. And even if I did not have a great opportunity for him today, I would think that a few years down the road he will be someone that I’d want to represent.

What is it about this candidate with no experience and no highly relevant education that gets our attention? Of the details we have about Andrew, how many could have impacted my decision to speak to him?

When evaluating talent and the decision whether or not to interview a candidate for a software job, I must rely on several attributes that have historically been attached to quality talent that were successful in receiving job offers from my clients.

Let’s break it down.

28 years old with a Finance Degree from a non-Ivy league school – Most readers, including myself, probably didn’t give this any thought. His degree in finance should indicate some math background, and if he had listed his specific school that would have had an impact. Although most might be reluctant to mention it, the age demographic is probably a positive based on the industry, as he obviously has some life experience and maturity but will not fall prey to any old dog/new tricks bias.

Spent the last two years living overseas teaching English and learning to code – Teaching any subject to any students is valuable experience for almost any profession, and should indicate some level of communication skills. The international aspect adds a bit more interesting background than if he were teaching domestically. Some who chose to speak to Andrew may have been strongly influenced by the oversas aspect, as this could also show some willingness to face risk and change.

Fairly well versed in html, css, javascript, and PHP. Just getting started with Ruby – His claim of being ‘well versed’ is only a self-assessment, but that could be at least somewhat validated (or invalidated) by anyone taking a look at his blog’s source or GitHub account. This at least indicates that he is learning technologies that will give him some marketability based on demand for these skills. We may question Andrew’s choices if he were learning a less popular skill.

GitHub, Stack Overflow, and Blog – For those that make decisions about technical talent, the fact that Andrew has both a GitHub and Stack Overflow account is probably more of an indicator of possible talent than what is actually in the accounts. Most candidates in my experience don’t have a GitHub/Bitbucket or SO account, but those who do have accounts are historically more successful with my clients than those who don’t. The attractive blog and few technical posts are yet another indicator, showing some passion as well as the ability to articulate his ideas in writing.

What other details may have led to the decision of HN readers or people like me who would at least want to speak to Andrew?

He reads Hacker News – Even if he isn’t a senior developer, he at least appears to have spent some time in one community where they frequent.

He comes across as modest and doesn’t appear to feel entitled – You don’t see anywhere in Andrew’s post a reference to how awesome he is or how he is ‘kicking CSS’s ass on a daily basis’. His responses to feedback are very positive, grateful, and polite. The choice of ‘well versed’ over some other terms that may be linked to overconfidence was wise. Andrew also will not be accused of sounding entitled to a great dev job, and on the contrary he comes across as someone who knows he has to earn it. Perhaps that is a function of his lack of a CS degree, but either way he appears to be taking the right approach.

He’s already creating product – Although he is only early on in his tech studies, Andrew has a product on the market that you can find in the Chrome Web Store that you can download. There are developers with 20 years of experience that haven’t built any of their own tools or products yet, but this guy is two years in and has that mindset. Some may question how great (or even good) a product someone at this level of experience could build, but the desire to produce and distribute a tool is something that perhaps can’t be taught.

Note: Other indicators I use regularly include:

Past employers – Some companies frankly have a higher standard of hiring

Technical hobbies – Arduino, build robots, or create things at home

Speaking or writing – Presentations and publications are usually strong indicators

Tool choice – What blogging platform or operating system you run at home

User group and meetup – Shows interest and passion

Conclusion: Hiring managers and recruiters are making quick decisions to interview and consider candidates, and as demonstrated by this HN post it seems that there are several recognized indicators of possible talent. For job seekers, you may want to display links to your accounts prominently, and highlight details such as independent product development.

The saying goes you never get a second chance to make a first impression, and it is well-documented that this is never more true than in the effort to hire great technical talent. Complaints about the interview practices of some companies and anecdotes about how recruiters make foolish approaches are quite popular reads lately. As someone in the hiring business, the criticism can be painful to hear, but when justified with evidence of ineptitude it is certainly understandable.

Demand for elite developers is so competitive (and talent is so hyperaware of this fact) that both recruiters and company representatives rarely get a second chance if their first contact or the ensuing hiring process is received negatively. The best case scenario for the headhunter approach gone awry is to have the attempt ignored, and the worst case is public shaming by a tech celebrity. It is particularly painful when a recruiter or company turns off an attractive candidate (whether through an email or hiring process) that possesses a very rare skill or experience, or worse yet a high degree of both skill and community influence.

Accomplished technologists can be brutally unforgiving to even the slightest perceived breaches by recruiters, and the level of outrage is often congruent to the programmer’s self-perceived industry status. This is most likely a function of the sheer volume of noise received by high-end talent with status, and the frustration that noise can cause. Junior level candidates tend to appreciate any type of attention, while the more senior or recognizable professionals seem to rarely find any recruiter contact worthy of a positive response. Beyond just the recruiter problem, the interview process and practices used by companies cause very strong negative reactions by many in the industry. When offended, those that feel they’ve earned ninja status (used ironically, please stop saying ninja) seem most likely to wield the sword.

Applicants that appear average will probably be treated that way. But when a recruiter or a company hiring manager discover what could be that once-in-a-lifetime potential hire, or even a candidate that would seem to fall into the top 10%, they must be flexible enough to change their standard hiring protocol while exercising an abundance of both caution and tact at every contact. Many companies homogenize the process for all candidates to their own detriment, and when dealing with in-demand talent that typically comes with a bit of ego thrown in for good measure, treating the ninja like a common commodity is a critical error.

What are the most obvious ways that recruiters and companies turn off the most qualified candidates during first contact and the subsequent hiring process?

First, mistakes in the approach:

Impersonal contact and lack of research – The link earlier in the article referencing a recruiter approaching DHH for a Rails role happened more than once, and notably a recruiter for Groupon made the same mistake. These examples are well beyond a typical recruiter infraction, as most Rails engineers are not DHH and most recruiters are not this lazy and clueless. The ‘Let’s connect on LinkedIn‘ invite without any point of reference also applies to this category. Recruiters are given little leeway and must conduct at least minimal research before contact, and then must choose their words wisely. Once you know a bit about the candidate, tell him/her why you felt it was appropriate to reach out. Be specific.

Referral requests – Recruiters are trained from birth to end every communication with ‘Do you know anyone else who might be qualified?‘, and they are often asking complete strangers. Technologists at the lower levels look at this as an opportunity to help a colleague find work (and maybe even get a referral bonus), while ninjas who make plenty of money have no interest in helping most recruiters and view the request itself as a breach. Don’t ask top people for referrals until you have at least developed some form of relationship, and even then only with caution.

Technical ignorance or irrelevance – Recruiters who confuse Java for JavaScript get crucified, and will be forever remembered as being ‘that guy/gal‘. Whether you are a non-technical CEO or a recruiter, be sure that your communication is technically sound.

Approached by the wrong person – When courting high-end talent (particularly for a small company), it is wise to get an internal talent or leader involved as early as possible. Your junior recruiter that started last week should be kept in check until he/she knows how to market the company, and that marketing skill should be honed in conversations with junior candidates that generally require a lower degree of difficulty and thus reduced potential risk. Startup CEO, CTO or Development Managers should be willing to send a quick note from their own email in order to get a ninja’s attention early in the process. Recruiters need to know when it may be appropriate to step aside for first contact.

Lack of details – Vague, boilerplate company descriptions rarely get the attention of top talent, and may turn off the candidate completely without ever getting the chance to show them more. Provide as much detail as reasonably possible to demonstrate that you have no intention of wasting their time.

And in the hiring process:

The HR phone screen – I cringe when a client responds to my submittal of a top talent with ‘This one looks great! We’ll have Joe from HR do a quick phone screen‘. NO! Some recruiters vet engineers better than others, but if a candidate looks stronger on paper than most you see, forgo the pleasantries and get down to business.

Standardized tests – These are fairly rare with startups and small companies and for midsize and large companies these tests serve as just another way to scare off top talent. Tests for IQ, personality types, and even third-party technical tests tend to give the wrong impression to talent. Development managers at companies that employ standardized tests could be frustrated with the skill level of their applicants, and should want to promote policy change or at least allow for exceptions.

Disorganized interview process and inflexibility – Missed phone calls and making candidates languish in a lobby while waiting for an interviewer is inexcusable when wooing a strong candidate, and tech talent may feel these indiscretions could reflect on your work environment. Even if you traditionally like to keep interviews very loose and informal, use at least a small amount of choreography when entertaining the ninja to keep their engagement level high. Accommodating a request for a call either before or after hours could also be the difference when interviewing candidates that are unable to use business hours for meetings.

Lowball offers and negotiation games – After investing a fair amount of time building mutual trust and admiration during the interview process, the last thing you should do is play games when it comes to sealing the deal. The long term value of the hire should not be risked for a few thousand dollars saved through negotiations.

Conclusion: Companies and recruiters need to do a better job of customizing their approach and treatment of top technical talent. While technical recruiting is generally considered a numbers game focused on high-volume, the courting of the most elite developers requires a completely different and more time consuming campaign to be implemented by your most competent resources.

Have you ever had a conversation with a fellow technologist that you felt wasn’t quite at your skill level, and at some point you discovered that she/he makes $20,000 more than you do? $50,000? As someone who has had a great deal of access to the salary and compensation details for thousands of software engineers over many years, I can report that there can be significant variation in salary between technologists with almost indistinguishable skills and qualifications. This may not be news to some, but the reasons might not be obvious to professionals in the field, particularly if someone has only been exposed to a small subset of industries or companies. Many of the explanations are somewhat unique to this industry or just more prevalent in the software world. Regardless of whether or not money is a primary motivator in your career, it is still useful to understand why others may be earning more (and what you can do to join them).

What are some possible explanations as to why someone equally or less-qualified makes more money?

Public image and intangibles – An average technologist may be compensated above more productive co-workers if there is some advantage that the company sees in that person’s employment. Community influencers such as open source project leads, conference organizers, meetup/user group leaders, speakers, and authors may all fall into this category. In business this is the concept of goodwill, where an asset has a higher value due to an intangible. Google’s high profile hires of James Gosling and Ray Kurzweil and Dropbox’s hiring of Guido van Rossum came with a certain level of goodwill bundled. On a local level, a company may believe that hiring the local Python group leader could make hiring Python pros easier and less expensive, which may justify a higher salary independent of the developer’s quality or production. Regulars on the conference speaker circuit can ask for a premium simply based on the PR provided every time their bio is published on an event website.

Negotiations and raises– Software professionals are often stereotyped as unskilled negotiators or uncomfortable in situations where they are seeking additional salary or perks. This first requires the courage to ask for more (in the form of a raise, or a higher starting salary for a new hire), and then the knowledge and skill to ask effectively. As a recruiter I typically handle salary discussions for my candidates, and I know that for most engineers that particular service is highly valued. A difference of even a few thousand dollars as a starting salary has the potential to dramatically alter your lifelong earnings. Remember that this number is regularly used as the basis for bonuses and raises, and most importantly it usually has some bearing on salary at your next job. Think of starting salary as the principal level for compound interest.

Market knowledge– Remember that conversation alluded to in the first line of this article? If you had three or four similar interactions within a year you may have noticed a pattern and it seems your friends might know something that you don’t. Many engineers aren’t even aware that they are paid below market rate because they just trust that they are fairly compensated and have no reason to investigate further. I have had conversations with experienced and well-qualified developers who are floored when they learn that they have been paid 20-30% below market rate for many years. Know what you are worth.

Self-promotion– Even if the high skill level is there, many technologists are either unable to properly express their own expertise and accomplishments or feel awkward tooting their own horn. The ability to market yourself often starts with a powerful résumé and a confident interview presence when trying to maximize salary at a new job. When staying with your employer, self-promotion requires the savvy to make your accomplishments known without looking like a braggart.

Consulting differential (both independent and staff) – Developers that are independent consultants charge clients a premium to account for expected frictional unemployment and to address the fact that a temporary employer typically will not make any real investment in the career of a temporary employee. It is rare to see independent consultants sent to conferences or trainings by their clients, and independents do not always get the most desired projects. Independents are also on the hook for their own benefits, retirement savings, etc. Salaried employees of consulting firms are also often paid above other similarly qualified professionals, as it is easy to measure a consultant’s contribution to the firm’s net revenues based on bill rates, billable hours, and their compensation package. There may also be regular travel or variable commute that tends to inflate salaries. Salaried consultants who know their bill rate, utilization, and total compensation package have a distinct advantage when trying to justify their value (and salary) to an organization.

Profit vs Cost Centers– Similar to consulting, companies that use technology as their main source of revenue tend to pay higher than firms where it is considered a cost center. Building software products that will be sold usually results in higher salaries than building systems for internal use. There are some major exceptions, but those tend to be specialized to industries where technology utilization is a key differentiator in the performance of the firm’s primary business interests (trading systems come to mind).

Rare skill – The premium paid for even one single rare skill among many common skills can be substantial. When a new language, framework, product, or platform is hyped as the ‘next big thing’ and adoption begins, even junior level talent with that skill can earn above more generally qualified individuals. This is simple supply and demand for a scarce resource. In years past the premium was greater for rare skills, as companies today seem more confident in their ability to train an existing resource than to hire someone new and much more expensive.

Time expectations – Some employers pay a premium because of the high expectations they place on hires. Unless you have some vested interest in the success of the company (stock, profit sharing), a 70 hour work week is probably unacceptable unless you are being compensated accordingly for that level of commitment. Positions that require employees to be on-call are also commonly paid above market. Work/life balance has a price, and some are willing to sell.

Long tenures at big companies – Many large organizations have systems of pre-determined fixed raises and regular bonus or vacation increases for certain milestones. The hire’s value to the company increases over time as they become highly specialized in a certain environment, and the concept of golden handcuffs is born. The downside of this for the employee is that it often leads to compensation well above true market rates, which makes it nearly impossible to find new employment at a lateral compensation rate. When these types are victims of a layoff, the result is brutal.

Location – No explanation needed, I hope.

Conversely, here are a couple explanations as to why someone might make less.

Startups – Startups often exchange equity for cash compensation. These employees are often earning less for the opportunity to receive a big payout. Candidates negotiating with startups must place their own figures on the value of the equity, which is a difficult task. Startup compensation today is much more competitive with large companies than it once was, at least in my experience.

Benefits, work/life balance – Since most professionals refer to compensation in terms of cash paid, employees that receive significant value in their benefits and perks may be mistakenly considered underpaid. Generous paid time-off, tuition reimbursement, and childcare can be major expenses that are covered by some employers and often not included in discussions.

Experience value – The opportunity to work for certain companies, to learn a valuable skill, or to be on a highly-regarded team is a reason that many engineers may sacrifice some salary, and shops that provide that ability may leverage that during negotiations. Many developers are entirely comfortable with accepting compensation below market as a trade-off for the positive effect on their career and marketability.

Conclusion:

If the topic of compensation comes up with other technologists, consider that there may be several explanations and hidden factors for the disparity between numbers. When exploring new opportunities, keep in mind that the amount of your offer is not solely based on your skill level relative to others or the value the company feels you will provide. In situations where several of these explanations apply simultaneously, the numbers become even more skewed.