I Can’t Ask Your Salary History? Thanks!

The Mayor of Philadelphia recently signed a measure that would ban Philly employers from asking candidates about their salary history. The intent of the bill is to curb wage discrimination and close the wage gap.

The Chamber of Commerce and Comcast (one of the city’s largest employers) have threatened legal action, citing the First Amendment and concerns about Philly being able to compete with other markets. There are similar bills being considered across the US, and Philly’s bill was inspired by a similar one in Massachusetts last year.

I say, “Good”, for two reasons.

If removing the salary history requirement will help end gender wage disparities and discrimination, that is something we should all be on board with in our industry (and any other). The optics of gender in technology aren’t good, and whether the reality is better or worse is up for debate.

I’m also grateful for the new law in a more selfish manner.

Talking Money

As a recruiter, asking about salary history was often a point of contention when screening a candidate, and the first question that might start to break the trust between us. The reason I would ask history was driven by my clients (hiring companies), who would typically require me to provide salary history and expectations on all candidates submitted. When a candidate was submitted without history, it wasn’t uncommon to have the client respond with a request to go back and get that information.

I was trained to save any talk about salary history until late in a conversation, with the theory that if you have built some rapport with the candidate you are more likely to get honest answers. You can’t just call someone and say “Hey, how are you and how much do you make?” The conversation about their background and interests might be going great, and at some point you’ve got to segue into the money talk.

Usually I would make that segue after a question about job search criteria. I might ask “What are the top three things you are seeking in a new position?” If one of the answers was related to compensation, I’d transition into drilling down a bit on those details. If there was no mention of money, I would say something like, “Well nobody works for free. Let’s talk about salary for a minute.”

At my first recruiting job, I was instructed to abruptly end conversations with anyone unwilling to answer the question (usually after being asked in a few different ways).

Trust

Taking the salary history question off the table may enable recruiters and their candidates to have a bit more of a trusting relationship. This bill doesn’t do much to alter any natural misalignment in incentives that exist between recruiters and job seekers, but it will at least prevent recruiters from having to ask (and candidates from having to answer) a question that they were probably not all that comfortable with from the start.

What’s Next?

I hope more bills like this pass elsewhere. I expect they will.

But even without a law in place, there is nothing preventing employers from instructing their recruiters (both internal and third-party agencies) to explicitly stop asking for salary history. Employers can work to solve this issue without legislation.

 

Soft Skills on Technical Resumes

I was in Google Docs collaborating on a resume for a Resume Raiders client the other day when a comment popped up regarding soft skills. The client was an accomplished mobile developer with many years of experience, but he wanted to be sure that his “ability to communicate with clients, present ideas, and collaborate on designs and specifications” was prominently featured on the resume.

It’s incredibly difficult to demonstrate soft skills on a resume, and spending significant amounts of resume space in an attempt to do so is typically ineffective. These attempts often become long lists of self-assessments that come across as entirely trite and cliche, and they end up wasting a large amount of space that may be better dedicated to other things.

Some writers choose to use some kind of key skills/attributes section somewhere in the top third of the resume, which often looks like a tag cloud with phrases like “requirements gathering” and “business analysis,” or even more generic, “interpersonal skills” or “excellent communicator.” These sections are again somewhat useless self-assessments that I generally refer to as “fluff” when speaking to clients. It’s noise, not hiring signal. Don’t waste the space.

Telling a reader that you gathered requirements or worked with end-users provides insight into a responsibility, but it doesn’t provide much information about skill level you demonstrated during those interactions. This is where some will pepper a sentence with words like “adeptly” or “skillfully”, which again has no real value to the reader.

A brief mention of having responsibility for some human interaction is helpful in showing that you’ve at least performed that task before, but trying to expand with self-assessments is probably not the best way to get your point across.

Is There a Better Way?

How to demonstrate those soft skills?

  • Tell the reader about presentations or training that you have given, whether publicly (at meetups or conferences) or in internal company settings. Audience size and frequency is a relevant metric. Link to audio or video if possible.
  • If you’ve been successful in working as part of distributed/remote teams or team members, that is usually an indicator for communication ability.
  • Share anecdotes of when you influenced management to implement your suggestion or reference the negotiation of a vendor contract.
  • Leading a development team meeting, Scrum, or a client demo/sales presentation? That’s worthy of a sentence.

Conclusion

Simply writing “I have good interpersonal skills” seems like it could be effective, but it isn’t. Everybody says it. Use these more creative approaches in describing these skills, and try to associate the soft skills with a tangible result.

How to Get an Interview at (Almost) Any Company

In my line of work (recruiting, job search coaching, and resume writing) and through my comments on Reddit, I’m often asked by job seekers how they can get noticed by a favored employer (which we’ll call COMPANY). A good resume, cover letter, and online profile are the standards if you don’t already have a friend on the inside, but when competing with candidates who might look better on paper, your results might not always be positive.

When you have narrowed a job search down to a few top places where you really want to interview and perhaps your qualifications fall a bit short of the company’s ideal candidate, a bit of extra customized effort can make a major difference in your results. Most people tend to use elaborate cover letters or resume delivery methods, which may work sometimes but aren’t entirely original. Sending a box of cookies with a hidden resume inside might get some attention, but methods like this don’t elevate you as a candidate so much as they make you appear willing to bribe.

Your mileage may vary (read: good luck!) when it comes to the biggest names that get hundreds of thousands of resumes per year, but startups and smaller firms will find one tactic difficult to dismiss or ignore.

What’s the most effective way in?

Use COMPANY’s Stuff!

If you want COMPANY to say yes to the interview, create a project using COMPANY stuff. This could be APIs and data sets, open-source code, or anything resembling the development work you might be doing while working for COMPANY.

Does COMPANY have some publicly available APIs? Create a project that makes some novel use of the API or extends the functionality of an existing related project. Find some public data sets that pertain to COMPANY’s business and create something with them using the tech stack COMPANY lists on their job specs.

Is COMPANY involved in open source? Jump into a couple of their repos and see if you can address a few of their issues.

Read up on COMPANY’s tech blog, find out what the developers are working on and any unique challenges they faced, and make a comment linking to relevant information.

It’s a pretty simple concept. If you are applying for a job with COMPANY, anything you provide that reflects the kind of work you’d be doing for COMPANY serves two purposes. First, this is perhaps the best possible evidence of your work quality using their tools, and second, it demonstrates your interest in and potential commitment to their work.

Java Developers and Their Long, Horrible Resumes

Let me start by saying that I consider myself a longstanding friend and ally to the Java community. As some readers will know, I founded and ran a large Java Users Group (I miss you Philly) for 15 years, and much of my career was spent focused entirely on recruiting Java professionals. In one capacity or another I have probably helped thousands of Java developers get jobs, and even though I no longer focus on Java in my practice or run the JUG I will always be linked to Java.

But now we need to have a talk.

I read a lot of resumes. I get them from applicants who apply to jobs that I have posted. I get them from (mostly) junior people on Reddit where I mod a career questions subreddit /r/cscareerquestions. And I get them from my Resume Raiders clients who are looking for me to either review or rewrite their resume for them.

So although my data is anecdotal, I have a lot of it — about 18 years’ worth to be exact.

When I get resumes from Java professionals, I’d estimate that on average they are 1.5-2x as long as resumes from other developers of similar career lengths.

Why?

One could think it might have something to do with age. Java has been popular for a long time now, so the age of the average Java developer might be higher than say those doing Ruby or Python work. Anecdotally, I don’t think this is it, as I see relatively shorter resumes from highly experienced candidates that don’t use Java.

Some might think it could have a cultural element. The Java community in the US may have a larger contingent of international talent than other language communities, and other countries have different resume/CV styles and acceptable lengths. Java resumes from those who were born overseas tend to be noticeably longer than their US-born counterparts, but I also see non-Java resumes from foreign-born developers that tend to be shorter than the Java devs.

Do Java devs move around more than those in other language camps, and more jobs results in longer resumes? Generally speaking, I don’t think so, and in many cases the opposite may be true, with long tenures being somewhat common for Java devs at large firms. Workers on visas under contract do tend to get moved frequently between projects all across the US, and this can account for length for those in this type of work.

One might surmise that the lengths could be related to the vast number of tools and technologies available over the years in the Java ecosystem. Listing an abundance of frameworks, app servers, IDE’s, testing tools, etc. that one has used over the years could require a good deal of real estate, and those who are writing their resume may be a bit liberal in their skills listing if they are aware of ATS products (robot readers) that scan and score the resume for keywords. It’s true that the skills section of the average Java dev resume is almost always a couple of lines longer than those from other language camps, but the skills section is a rather small percentage of the overall document.

I’m not going to make the link between Java being verbose and Java resumes being verbose. But perhaps I just did.

Why Does it Matter?

I’ve written a ton of material about resumes, and resume length raises a few major concerns.

  • Communication skills: Efficient word usage is a desirable trait for an employee who will be potentially writing documentation (not to mention code) to be consumed by other employees. Unnecessarily verbose resumes don’t reflect strong communication skills.
  • Signal vs. noise: There are elements of every resume that account for signal (the reasons that a hiring company will hire you) and then there is noise (anything else). A long resume tends to make it hard for readers to find the signal in a sea of noise.
  • Intimidation: Hand a recruiter a resume and say “This one is only five sentences”, and the recruiter will read every word. Hand a recruiter and say “This one is 20 pages”, and the recruiter will immediately start trying to look for reasons to stop reading. Even a minor indication that this candidate isn’t a perfect fit could be used as an excuse to hit delete and move on.

Conclusion

Unfortunately, I don’t feel I have a good answer to explain this one. I’d be happy to hear from anyone who feels they might. In the meantime, if you are one of those with a resume over three pages, try to optimize what you have. Your inclusion of every minute detail is not helping the reader.

Google Worship Gone Too Far

Last week, a GitHub repo called google-interview-university popped up on the radar when it hit Reddit and Hacker News. Go ahead and check it out.

The tl;dr is that an early-forties self-taught developer named John with an Econ degree and about fifteen years of varied startup experience has compiled a lengthy and thorough study guide of sorts that he is using to try to get a job at Google. It contains hundreds of links that run the gamut — tips from Google recruiters, books to read, articles on data structures, questions to ask in the interview, and even a link to a PDF file that says “future Googler” with the colorful Google logo intended for printing as some sort of inspiration (you know…because you should print a sign) — all courtesy of a man who uses the domain googleyasheck.com.

According to his LinkedIn, John has been studying full-time since April of this year to reach his goal of becoming a Google engineer.

Insert sound of brakes screeching. 

A guy that has been programming since the TRS-80 days and doing stuff with the web since 2000 and runs his own startup is taking off seven months to try to get a job at Google?

I’m not sure exactly what is wrong with this picture, but something feels wrong.

It could be that someone is investing an awful lot of time into a goal that, when they reach it, might be entirely unfulfilling. This isn’t meant as a knock on Google – but clearly, like every other company in existence, Google isn’t going to be a great fit for everybody.

Maybe it’s that an experienced person already in the industry who is probably qualified for a substantial number of programming jobs and even less hands-on technical roles (Product Manager jumps out at me) at hundreds of other companies still may need (or felt the need) to spend over one thousand hours studying just to get past a few hours of interviews with Google.

And what if it doesn’t work out? I’m absolutely rooting for John no matter what (I can’t imagine his enthusiasm and newfound fame won’t help), and I guess if he has a bad day on the phone screen and fails he could still take his knowledge to some other elite companies that could hire him.

Reaction from the web has ranged from laments on the effect of Google’s “CS trivia” interviewing style on the industry to cringeworthy Google fanboyism to admiration for a guy who is working hard to achieve a goal. All have some level of validity.

I see Google worship on a fairly regular basis on Reddit, and I’ve previously written about this fixation many new college grads have on the “Big 4” (or Big 5) companies. It’s rare to hear of senior level candidates having the same enthusiasm, and rarer to see someone taking months off of work to try and qualify for a new job.

As much as I admire someone for setting a goal and working towards it, I’m torn.

We Love Older Programmers

I was on the phone yesterday with a senior level hiring manager from a potential new client, and she said something I hadn’t heard in a long while.

“We love older programmers.“

When I speak with CTOs and hiring authorities about their dream hires, some are more cautious than others when stating their preferences. I’m not a lawyer and don’t know specifics on the rest of the world, but here in the U.S. we have laws that try to prevent discrimination in hiring. Some company representatives will describe ideal candidates to recruiters in conversations that could be approaching a somewhat gray line from a legal standpoint, and in these cases a recruiter should clarify that he/she will present all qualified candidates regardless of whether they are a member of some demographic.

Image title

We read so much on ageism working against the most senior in the industry that sometimes we forget that there are firms that prefer some gray hair. The problem, of course, lies with the numbers. As I said, I hadn’t heard a strong desire for hiring the most senior level resources in a long time, and we generally don’t see companies using language in ads that would tend to attract older applicants.

Job specs penned by HR or internal recruiters may describe the company as being young and having energy without any disambiguation as to whether the reference is to the employees themselves or the newness of the organization. “We’re a young company” can have more than one meaning – maybe it means “we’re all 22 years old,” or perhaps it means “we’re in an incubator and angel funded.” We may read about established and stable companies, but how often do you see a reference to a “mature team”?

When we look at company websites that show photos of their entire development teams or just a few select profiles, it can give a sense as to the type of culture the firm is trying to portray. These are usually smaller companies and startups with photo choices varying from the serious and dignified to goofy costumed photo booth style shots that are rather shamelessly trying to appeal to a younger audience.

Maybe it’s because I’m in my mid-40’s, or maybe it’s because of the ageism I hear about (and defend my clients against with words) in my resume writing business, or maybe it’s because I spent 15 years running a Java Users’ Group that had its share of gray hairs, but I’ve always been sympathetic to the plight of the older developer. It’s refreshing to hear someone state that they are welcoming to the most senior talent, and I hope to hear that more in the future.

Negotiation for Contract-To-Hire Jobs

I was recently asked a question on Reddit about a specific contract-to-hire (C2H) scenario that I hadn’t given much thought to recently. With the prevalence of C2H (sometimes called ‘try before you buy’ in the recruiting world) in the market today, I thought the topic was worthy of full exploration.

What Is Contract-to-hire?

For those unfamiliar, contract-to-hire is where a company brings on a resource as a contractor with some level of understanding that there is either an intent or at least a possibility that the resource will be converted to a full-time (aka “permanent”) employee after some contract duration. During the contract period, the resource is often employed by some third-party agency who negotiates the rates.

The Numbers and Terminology

To add a bit of transparency to this, the agency will negotiate a rate with the hiring company (Bill Rate) which is what the agency will charge for every hour of the resource’s service. Then the agency negotiates a rate with the resource (Pay Rate) which they will pay the resource for every hour worked. The amount the agency makes on the transaction during the contract period is the difference between the Bill Rate and Pay Rate (Margin, or Spread).

If $COMPANY wants to bring on $DEVELOPER on a six month contract-to-hire basis, $COMPANY might agree to pay $AGENCY $100 for each hour of service. $AGENCY and $DEVELOPER have agreed to a pay rate of $80/hr, so the $AGENCY gets $20/hr for each hour $DEVELOPER works.

$COMPANY and $AGENCY may have also negotiated some type of buy-out clause, where at the end of the six months if $COMPANY wants to hire $DEVELOPER there will be a placement fee equal to n% of $DEVELOPER’s salary. Sometimes there is no fee involved in the hire, as the agency is considered paid because of their margin over the six-month contract. Other times the placement fee will vary based on the tenure of the contractor, where the buyout might be n% between days 1-60, n-5% between days 60-90, and n-10% days between days 90-180, and no fee at all after 180 days.

In our example above, if we assume a 40-hour workweek the agency would make about $20,000 during the six month contract period of employment. If there is a buyout clause as well, and the developer is indeed hired, the agency would make an additional flat sum.

Why Are Details Important?

Some readers might not care about the nuances of these agreements, and that’s certainly to the agency’s advantage. The reason these details are incredibly important is because the nature of the contracts will alter the financial incentives of the agency, and when those financial incentives are understood it may serve to better explain the behaviors of the agency.

As one example, suppose the agency is getting paid as outlined in the example above, but the agency receives no buyout upon hire. What would be the incentives for the agency? Obviously, the agency would rather have the developer remain as a contractor for as long as possible without ever converting. The agency is getting $20K for every six month period worked, but that turns into nothing when the hire is made.

Let’s look at a second example where the agency has a buyout clause with a prorated element, where the buyout amount is reduced over time as outlined above. What are the incentives there for the agency? There is some math involved (feel free to program a solution in the comments!), but the agency could look at the numbers to see when the optimum conversion time would be, and the agency would have some incentive to make that conversion happen within a certain range of dates. If we really get into the numbers, we could probably point to an exact hour where the developer’s conversion is in the best financial interest of the agency.

Who Have We Left Out?

We’ve explored the incentives of the agency without even considering the incentives of the developer. In C2H situations, there can be a wide range of incentives for the developer, many based on their own personal situation. Since the hiring company will usually provide the developer with several additional benefits upon full hire (insurances, retirement, paid time off), there is also some tricky math involved with figuring out the value of a perm hire compensation package when compared to the hourly rate.

Often contractors are paid a rate above what they would generally make as a perm hire, so we may see situations where the contractor tries to delay converting in order to maximize earnings. This could be in direct conflict with the agency’s financial incentives if a buyout is involved. As you can imagine, things can get rather interesting when the contractor has an incentive to remain a contractor and the agency does not. When analyzing bad recruiter behavior we need to consider misaligned incentives as a root cause.

Negotiations

An agency is trying to maximize their take, and we’ve established that the agency’s earnings are Bill Rate – Pay Rate. The agency has two incentives to increase margins – they first go to the hiring company and try to negotiate the highest Bill Rate possible, and then they go to the developer to negotiate a Pay Rate as low as possible. This model is vastly different to the recruiter/developer relationship dynamic in permanent hire recruiting scenarios (or even during a buyout in a C2H situation), where the recruiter has an incentive to maximize the developer’s compensation (because fee = n% of salary).

Sometimes a contractor will ask for a raise during the contract period. The agency will almost always object to this unless they are making a solid margin already. Unfortunately, the only party that is typically aware of all three numbers (bill rate, pay rate, margin) is the agency itself. The company rarely knows pay rate, and the developer is usually unaware of bill rate. That lack of transparency is in the best interest of the agency, which is why they will try to control access to these numbers.

Image title

We need to first keep in mind that in hourly contract negotiations, small numbers can add up. $1 an hour might convert to about $2K per year, and that figure translates to both the developer’s compensation as well as the agency’s revenues.

In most cases, the C2H developer won’t have a salary number defined for their conversion. They have accepted a temporary contract rate, but will need to negotiate their salary when the time comes. This can be problematic, as the developer doesn’t usually have much power in the negotiation. They may already have some level of attachment to the job and their co-workers, and the thought of another job search might be daunting. When you combine these with the fact that the developer probably does not have another job offer to leverage, it can make these negotiations more complex.

Conclusion

To protect your best interests, gather as much information as possible from the agency and the employer. Ask about the agency’s arrangement with the employer when it comes to conversion and buyout clauses, and try to learn about what you might expect to see in a perm hire offer.