Dave Fecak's Blog, page 4

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…

$RECRUITER2 calls: “I spoke to the hiring manager today at $COMPANY, and they never got your resume from $RECRUITER1.“
$RECRUITER2 calls: “I spoke to HR at $COMPANY today, and they’ve never heard of $RECRUITER1.“
$RECRUITER1 calls: “I just got a call from $COMPANY and they said your resume was also sent by $RECRUITER2.“
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…

Saw $COMPANY’s ad for $OPENJOB.
Wanted to make $COMPANY a client.
Saw the resume of our victim and called pretending to be an agency for $COMPANY.
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.

Notifies the employer regarding your last day of employment.
Expresses gratitude to the employer and co-workers.
Assures the employer that you will be productive during your notice period and helpful in transitioning reponsibilities and knowledge to replacement(s).
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.

The Recruiter Manifesto

It’s no secret that many agency recruiters behave unethically. As much as I enjoy getting paid to help companies grow and to assist job seekers in finding better opportunities, it is sometimes difficult to be enthusiastic about my industry. There is a segment of the technology population that assumes I must be unethical based on the industry I’m in, which is frustrating.

I’m optimistic that the industry’s reputation will improve as more recruiters are exposed for behaving badly and eventually leave the industry. First we need to have a set of expectations for recruiters to follow.

I believe that every recruiter should agree to the following conditions, and I’d encourage readers to refrain from dealing with any recruiter unwilling to pledge to these guidelines.

Transparency

Where the candidate stands — Candidates are entitled to know where they stand in the hiring process. This includes information on whether or not an offer has been made to another candidate, whether they are still in consideration, the length of the search, and some idea regarding the number of other candidates in competition (if known).

How the recruiter is paid — Candidates are entitled to know how the recruiter’s fee is determined, which provides candidates at least some insight regarding the recruiter’s personal incentives during the process and any negotiation. This includes information on whether the search is contingency or retained and whether the fee is flat or based on compensation. For fees tied to compensation, the recruiter should reveal which elements of compensation (salary, bonus, stock, signing bonus, etc.) are included in the fee determination and which are not included.

The recruiter’s experience and relationship with a hiring company — Candidates are entitled to know how long the recruiter has been working with the hiring company and at least some details on the level of success (whether a placement has been made in the past).

Honest (and ideally actionable) feedback — Candidates are entitled to know how they performed in any interviews and what they could have done better. Keep in mind that both companies and agency recruiters have virtually no incentive (and actually may incur liability) beyond goodwill to provide interview feedback to rejected candidates, so agency recruiters may not always be privy to detailed feedback. Recruiters should make efforts to get detailed feedback whenever possible, and deliver that feedback in a timely manner.

Conflicts of interest — Candidates are entitled to whether any potential conflicts of interest for the recruiter, such as a recruiter representing multiple candidates for the same role (which is common and in itself breaches no ethics).

Salary — Candidates are entitled to know if their salary expectation is above any salary range provided by the hiring company (if one was provided).

Courtesy and Integrity

Timely response — Candidates are entitled to timely responses on any requests for feedback or updates on the hiring process. A successful job search depends on good timing to optimize both available opportunities and negotiations, and any delays in the sharing of information can have a detrimental effect.

Honesty — Candidates are entitled to the truth, whether it be about the companies the recruiter represents or the details of an offer. Whenever there is obvious room for interpretation, the recruiter should defer to the hiring company to relay information directly to the candidate in order to eliminate the possibility of inaccuracies or confusion.

Honoring of requests/information sharing — Candidates are entitled to have the recruiter serve as their liaison during the process, and requests from candidates to either share or withhold certain information with clients should be honored whenever possible.

Privacy

Search confidentiality —  Candidates are entitled to have their job search activities kept confidential and only shared with those that need to know. Situations that may breach that privacy, such as requests for references from a current employer, should be addressed with candidates in a way that describes any potential risks. Recruiters should not share a resume with anyone without the consent of the candidate.

Alterations of resume — Candidates are entitled to know about any proposed resume modifications that an agency recruiter may be required to make (such as adding recruiter contact information), and a recruiter should make no alterations to a resume’s content without the consent of the candidate.

I’d encourage job seekers to share this post with any agency recruiters they are contacted by, and further ask those recruiters to pledge to these standards.

Is Your Employer a “Best Place To Work” For Developers?

Glassdoor recently released their Best Places to Work 2016/Employees Choice Awards, and as you would expect the top of the list features several well-known companies from the tech sector (Airbnb, Facebook, LinkedIn, Google) and other firms that aren’t exactly household names. The rankings are based on anonymous reviews and ratings from employees, with the results crunched by a proprietary algorithm. The survey asks respondents to rate their company on the following set of criteria: Career Opportunity, Compensation & Benefits, Work/Life Balance, Senior Management, Culture & Values.

As someone who has asked thousands of job seekers about their ideal employment scenario, I have heard each of the criteria above cited on countless occasions. Glassdoor is not exclusive to the technology industry, so of course the survey criteria are rather generic and applicable to firms in any vertical.

Based on how I hear developers describe their dream job, I would add the following criteria (in no particular order) to Glassdoor’s list when ranking development shops:

Autonomy and Tool Availability

Does the company mandate the manufacturer and operating system of your laptop, your IDE, and whether or not you are allowed to use open source tools? Firms that restrict tool and language use may hinder their employees from developing marketable skill sets, which forces career-focused individuals to either develop these skills after hours or seek new opportunities.

Learning Culture

Is the company committed to allowing their employees to develop their careers through ongoing learning? This could be as simple as letting developers prototype in an unfamiliar stack, holding in-house lunch and learn sessions, formal training, or providing time-off or budget for conference and users’ group attendance.

Variation in Projects/Greenfield Work

Ten years of maintenance on a static project will not be considered ten years of experienceby a future employer. Pardon the cliche, but it may instead be deemed one year of experience ten times. Variety in project work and a favorable new development : maintenance ratio tends to make for happier employees.

Doing Things Right

Developers gravitate toward companies where they can get things done in a professional environment. How the company’s development organization scores on the Joel Test is one way employees might rate job satisfaction.

Challenge

Is the daily work engaging and challenging for the employees? Even well-compensated employees will look elsewhere if their duties are no longer interesting.

Respect and Value On Engineering

Does the company see technology (and technologists) as a core element to their business, and are developers treated accordingly? This is usually evident in software product businesses, but becomes a bit clouded when technology is considered a cost center.

What did I miss?

How to READ a Job Posting

After reading a recent article on DZone about writing developer job postings I started thinking about how job seekers often read and sometimes (mis)interpret job ads. At least once every few days I encounter some rant about how unrealistic job postings are, whether on a so-called Entry-Level Job that actually requires three years of experience or a spec that appears to seek an entirely unrealistic collection of skills. Must have ten years of experience with Node.js is coming to a job ad near you!

As someone who writes job descriptions for companies, I’m not here to defend those in the industry who use a highly exclusionary style that can be off-putting for many job seekers. Until some spec writers learn to do a better job of representing what makes for both an exceptional candidate and an acceptable candidate, I think it is important that readers understand how to interpret what is written to make the best judgment on whether to take the time to apply and to further set their own expectations properly regarding the likelihood of a positive response (interview).

Some key considerations when reading a job post.

Postings (Like Resumes) Are Written With SEO in Mind

You know how some people pepper their resumes or LinkedIn profile with popular buzzwords in hopes that some recruiter will be searching for that term? Well, people writing job specs do the same thing, and writers will include what we might call complimentaryskills listings without those skills actually being considered as a requirement. A Clojure shop might include “Haskell” and a company using Redis might list “MongoDB” somewhere in the posting, as we can’t expect every functional programmer or NoSQL enthusiast to only be searching for their particular stack. Maybe the “ideal” candidate is an expert in Clojure and Redis, but the company doesn’t want to miss out on the Haskell developer either.

Postings Represent “Ideal” Candidates

In most cases a job posting is an elaborate wish list with several requirements and nice-to-haves, but hiring managers or recruiters generally don’t expect candidates to be able to check off every box from the list. Technology hiring varies greatly between companies, and in my career I’ve consulted to companies that demanded at least n years with a specific framework as well as firms open to hiring engineers with programming experience on any stack.

Non-negotiable Requirements Should be Fairly Obvious

In most cases, writers of job specs will be explicit about requirements that are truly required. There will always be companies that believe four years of Java experience is inadequate but five years is just right (without even considering how we try and justify what a year of experience even means), but most shops will show flexibility on items where years of experience is listed. It’s probably a waste of time to apply for positions with more binary requirements, such as those involving citizenship, education, or a required certification.

Look for the Gotcha

Over the past few years job post writers have attempted to verify that an applicant actually read the full post by including some obscure directive in the post. Please include your salary requirement and favorite color in your cover letter.

Format, Focus, and Culture

Readers of job descriptions should be able to draw some conclusions about the hiring company based on the format of the job spec and what content the writer chose to include and emphasize. Companies advertising for a Software Engineer IV vacancy that dedicate multiple paragraphs to describe employment policies and procedures may be more likely to have a regimented environment when compared to job specs that instead choose to include the core values of the development team.

Job postings are an opportunity for a company to both describe an ideal candidate and explain why readers might want the job. The way an employer chooses to use the space may speak volumes about how the company sees itself and how they want others to see them.

Pythonistas, Rubyists, and Gophers: Hiring Preferences Across Language Camps

For many years I recruited exclusively for clients that were seeking to hire Java developers and architects at all levels. When I opened my new recruiting practice almost four years ago, I made the decision to expand my focus and include development shops that were not using Java as their primary language (or at all in many cases).

My strategy to move beyond Java was based on obvious trends in my circles. First and foremost, I wanted to recruit primarily for startups and smaller companies, and I found that startups were not choosing the Java language as regularly as they had earlier in my career. Second, many of the Java pros in my wide network (including many of the most skilled among them) had moved on to focus on other languages. After over ten years building my reputation as the “Java recruiter”, I decided it was time to follow some of the crowd.

I can only speak from my own experience interacting with perhaps a couple hundred companies and thousands of job seekers, but I quickly noticed some patterns and trends in hiring preferences within these different language communities that were new to me. The standard comment to articles about languages and hiring will be the thought that language is just a tool, and I get that. Hiring managers might use dozens of criteria (some more applicable than others) to evaluate candidates on paper and my observations may not reflect your personal experience, but I thought it would be worth sharing my experience and hopefully hearing from some readers on what they have witnessed.

Some thoughts…

Python or Ruby Accepted Here – Shops using Python or Ruby as their primary language widely accepted devs from the other camp interchangably. I can’t think of an instance where a candidate was rejected for not knowing the used language if they knew the other. If you know Ruby or Python, it seems you can get hired to use either.

 

Young Managers and Java “Discrimination” – Younger CTOs and hiring managers seemed less open to Java devs with particular disinterest in Java devs from traditional enterprises. There might be an inclination to claim ageism based on demographics of the Java community, but I found this trend regardless of a candidate’s age. A Java developer in her mid-20’s at banks or pharmas had it no different than someone twice as old. I also found this trend in shops using other JVM languages. I feel that Java developers from large companies, particularly those with long tenures at one employer, face the most “discrimination” in the startup hiring market today.

 

Older Managers, Flexibility, and Simpatico – Companies with older hiring managers or CTOs expressed openness to multiple language backgrounds, treating language as a tool. The most experienced managers often cited some obscure language or tool commonality with a candidate (“I too wrote $LANGUAGE once…“) or declared that their interest was due to a well-worded project description that caught their attention (“I’d love to hear about what he did on $PROJECT“).

 

For Functional Languages and Go, Interest = Experience – Several clients using functional languages in production treated personal interest in any functional language (demonstrated through self-study, user groups, etc.) as sufficient to grant interviews, and I’ve found this true (with an admittedly smaller data set) in the Go community as well. This may be due to the relative newness of FP, although I don’t tend to find this in other hot language markets with low supply. Self-study and a single GitHub repo seems likely to get you into an interview at a Clojure or Go shop, but might not be enough for companies hiring Node or Angular talent.

 

Java Shops Most Specific – Companies (regardless of age or size) that primarily use Java have been the most specific on their job requirements and are much more likely to give minimum number of years with the language and related tools than my non-Java clients. One likely explanation for this is that Java shops might be more particular simply because they can be. With the millions of Java devs worldwide, hiring managers can probably find someone with experience using certain frameworks and tools.

I’d be curious as to what readers have experienced out in the wild.

The Worst Developer Resume in the World, Redux: Best Practices

Last week I published The Worst Developer Résumé in the World, which resulted in three things.

We are not alone – The article resonated with many hiring managers and recruiters who immediately recognized this style of résumé. We’re forming a support group.
RIP Inbox – Readers wondered “Is that my résumé?“, with many reaching out to me or my résumé review/writing side project (Résumé Raiders – shameless plug) for a personal inspection. Some résumés were good. I had to open some reviews with “Are you sitting down? Because you might want to sit down…“.
Thanks…but where is the rest?– A handul of readers asked for details on best practices and tips for résumé writing. “You told us what not to do, now tell us what to do.” OK, I’ll do that.

WARNING: Keep in mind that entire books have been written on résumé writing, which I’m also considering as a future project. I dedicated a full 20 page chapter to résumés in my 2013 ebook, so a few hundred words is only going to scratch the surface of what it takes to craft a résumé that gets results (interviews).

That said, here are some best practices for a good résumé.

A Short, Detailed Summary or Profile

In my opinion, this is the most important piece of a résumé and the section most often overlooked by job seekers.

Why? There are two simple reasons you need a good Summary.

1. Your résumé’s audience. We must assume a human will read your résumé at some point, and we (unfortunately) must also assume that the human is not highly-qualified to assess your background. At many companies the reader will be an HR or recruiting professional who may know little about technology. Startups too small to have dedicated recruiting/HR personnel use administrative or operations staff to review incoming résumés, as dev time is too valuable.

Do you want to miss out on a great job because the résumé screener was an accountant unable to decipher that you have the required five years of Python experience? Or because the reader didn’t understand that the “J” in J2EE is Java? Make it easy for them, which in turnbenefits you.

2. It may be all you need. A well-written Summary can be the only thing a reviewer needs to read before passing your résumé to the next step. In those rare instances where I receive a résumé leading off with a descriptive Summary that includes the skills and experience level we are seeking, I can immediately reply “I like your background. Let’s talk!“. I’ll read the full résumé later as I prepare for our phone conversation, but the powerful Summary got an immediate “Yes” answer from me. The résumé’s purpose is to try and start a conversation, and a Summary alone can do that.

How? A Summary should be written in a way that leaves the reader little room to misinterpret who you are and what you can do/have done. It should be no more than a few sentences. The biggest Summary mistakes, which were detailed in the previous post, are ones that go way too long (and cease to be summaries) or those that contain useless, homogenized, non-descript content.

A Summary that reads “Passionate software engineer with excellent communication / interpersonal skills dedicated to writing elegant code” sounds nice and might be someone I want to talk to, but says nothing about qualifications. Does this Summary make it any easier for the reader to say “yes” to you? No, it doesn’t.

A quick aside: And while we’re talking about self-assessments of communication skills and interpersonal skills on résumés, do you think any hiring manager in history has said, “Did you see this résumé Frank? Says here that Ms. Thomas has excellent communication skills. VERRRRRY INTERESTING… Get her in for an interview at once!” No. Don’t waste this space with self-assessments that every résumé on earth also uses. Show me (don’t tell me) your written communication skills by writing a decent résumé, and we’ll cover speaking in an interview.

Back to the story…

How about “Accomplished software engineer with seven years of experience building SaaS products using a range of technologies including Java, Python, and JavaScript with multiple frameworks.” This quantifies experience and includes more detail on at least some skills that might be required (or requested) for the role.

If you’re thinking “but DAVE, the job spec listed like 50 languages and tools”, let me stop you there. The Summary isn’t the place to test out your ATS-gaming SEO skills. It’s an overview, like a quick plot synopsis for a movie on IMDB. It’s not meant to give every detail and spoiler.

Realistic Skills in a Digestible Format

Why? Long laundry lists of skills gives the reader a few impressions of the applicant. First, we hear the theme song to our favorite game show – let’s play Buzzword Bingo, Résumé Edition!

Recruiters are often accused of just matching keywords, which is a fair assessment at least for the minimum requirements of an initial résumé screening. Development managers are likely to start with the same method. A suitable candidate needs relevant skills and accomplishments. Has this candidate done anything relevant to our job opening? That determination entails scanning for certain required technologies, experiences, etc.

A long list raises the question as to how much the candidate actually knows these technologies. The barometer for experienced professionals is usually to include something you’ve used (at home or work) enough to answer some questions. When someone posts what is likely an impossible list, the reader may get a sense of some dishonesty which could be verified in a conversation.

The digestible format is also important. If recruiters are playing Buzzword Bingo, they need to know which columns and rows to look in to find their desired words. Again, make it easy for the recruiter in order to maximize your own positive outcomes.

How? Keep the list to a reasonable size based on your overall experience, and remember that listing outdated skills may do more harm than good. If you are now doing Go and Node.js work, listing all the technologies from your days cranking on AS400s might not be a good use of space. You don’t need to be an expert to list something, but show some restraint.

Separate the skills into a few sections. Common categories might be Languages and Platforms, Frameworks, Databases, Operating Systems, and perhaps a catchall like Tools orOther. If you find yourself creating categories for just one or two skill listings (e.g. IDEs: Eclipse, NetBeans), you run the risk of adding unnecessary length to the document and might be better served with using an Other section.

Clearly List and Bullet Accomplishments, Ideally Quantified

Many résumés use the Experience section to bullet multiple responsibilities instead of detailing specific accomplishments. It’s not always easy to point to accomplishments, but it’s important to try.

Why? The reader wants to know what you have done, that you can communicate what you have done, and (most importantly to some managers) that you understand how your accomplishments positively impacted the business. Writing about accomplishments also gives you the opportunity to influence your interview, as projects that are on the résumé are infinitely more likely to be discussed than projects you don’t list.

How? It’s best to list responsibilities before accomplishments, with the responsibilities written in paragraph form and accomplishments bulleted. Just below the employer, title, and dates, you’ll have a few sentences you may use to describe the company’s business (if unknown to most) and how your role helps the business (usually entails either saving the company’s money or making the company money).

Bulleted accomplishments should list your role, some details on the technology used to solve the problem, and outcomes. Quantifying details such as dollars saved, revenue generated, or performance improvement metrics are a nice touch when possible. Accomplishments can be both individual or as part of a team, and it’s important to differentiate so you don’t accidentally claim too much credit.

Trim the Fat, and Optimize For Relevance

Why? There are a few reasons for résumés to be kept as short as possible while still covering the necessary content. First is the signal-to-noise problem, where relevant and impressive accomplishments get lost in a sea of useless bullets. Second, a long résumé intimidates a reader, which is another reason for a lazy recruiter to hit delete. When you see a résumé is seven pages, you may look for reasons to stop reading it on page one or two. Lastly, a long résumé with irrelvant content makes it appear that the writer is overestimating the value of a past accomplishment. Hiring managers mostly want to know what you can do today, not what you did in the 90’s.

How? Most of us can safely eliminate details on jobs from 10+ years ago, as they are usually less relevant to today’s work. Your job title and employer for early jobs is enough to give you credit for the experience without giving the reader the impression that you are clinging to accomplishments that are now distant objects in your rear-view mirror.

Lightning Round

Some other quick tips that didn’t warrant full sections:

Email handles shouldn’t sound like they were created by a teenager, and AOL addresses aren’t retro cool (yet). If you need to ask, you should change it.
Contact info eats up valuable page space if you stack it (name above address abovephone above email), and it’s the least important thing on the document that ironically gets the most prime real estate. Use a small font (like even 6 or 8) and try to keep all of this to a line or two at most.
Personal web pages, blogs, GitHub, and LinkedIn links are nice to have if they are neat. Just remember that if it is listed, it’s fair game.
Nobody cares what you got on your SAT/ACT tests 20 years ago. Same with college courses.
If you decide to list non-industry positions, consider that the reader may have a hard time thinking of you as “Joe the DevOps engineer” instead of “Joe the former pizza delivery guy“. Most of us have had other jobs, but we don’t need to list full employment histories.
Don’t list your references names or email addresses on your résumé, unless you want them to hate you. Some recruiters will try and recruit them even if that recruiter never spoke to you. Provide references when asked for them.
Listing graduation dates gives away your age using the formula 22 + (CURRENT YEAR – GRADUATION YEAR) = CURRENT AGE. If you fear possible ageism, deleting graduation dates and removing your earliest experience is one way to prevent discrimination. It’s a résumé, not a full autobiography. In some countries it is popular to list birthdays and even photos on CV’s, but not in the US.