Whether it’s your first position out of college or a more advanced, senior role, receiving a job offer in development is an exciting accomplishment. It can be easy to get wrapped up in the excitement, but you need to keep your wits about you for just a little bit longer so you can get through the process of negotiating your salary. While your salary is one part of the package, it’s important to understand that it is probably the only part of your package that changes when you get a raise (assuming equity is not part of the compensation package). It’s crucial for long term happiness to negotiate a salary that represents your own self worth.
Software development is not unskilled labor. You’re not going to be working on an assembly line, adding one screw to each cog that passes. You’re not going to be swiping groceries past a barcode reader. Each line of code that you write has concerns that come with it, from whether or not it actually accomplishes the goal that needs to be accomplished, to how well it handles edge cases, to how easy it is to make changes to when requirements get updated. This is important to understand because it means companies are not simply setting a price to have screw put in a cog. The quality of the work is a concern in how companies price developer salaries. Companies with more challenging problems are willing to pay more for developers with the skills to solve their problems.
The presentation above shows your own self worth on the top and how much the company values your ability to solve their problems at the bottom. The scale from bottom of page to top of page is the package they offer you, of which your salary makes up the largest component. You should strive to work for companies that value you at least as much as you value yourself. In the image above, you should strive to work for companies where your self worth overlaps the worth the company places on your skills.
Determining Company Worth
The first step to successfully negotiating your salary is to do your homework. You need to have a realistic idea of what the talent market looks like that the company is competing for a share of. There are many factors that go into calculating the going rate for a developers: the location of the job, the problems the company needs solved, the financial well being of the company, and the full employee package that includes vacation/insurance/etc. It’s difficult to say with certainty what a specific company should be paying for a specific job, but you can estimate what a reasonable range is using tools like Stack Overflow’s new Salary Calculator. You can put in some basic information about the job to determine what salary developers doing similar work are earning right now. Once you feel like you have a pretty good idea of the range that company you are interviewing with should be hiring at, store that information somewhere that you won’t lose it.
Determining Self Worth
When I say self worth here, I don’t mean your self esteem, I mean where your income should be relative to others in the same market. Should you be paid more than the average for your market, about at the average or a little less than the average? This has a lot to do with your experience and more so with your accomplishments. If you have no accomplishments to show, expect to be a little below average. If you have some accomplishments, expect to be around average and if you’ve had significant ownership of big projects with positive results, expect to be paid more than average. There is a lot of nuance here, but in general previous success in software development is indicative of future success in software development and the amount and difficulty of your prior work act as multipliers in the expectation that your prospective employer builds for you. Increased expectation of your productivity leads to higher salary offers. The trick here is to find the lower bound for what you think your salary should be relative to others in your market. Take a toll of all the things you’ve done (more specifically all the things on your resume because that’s probably all the company will know about you to begin with) and how difficult they were for you. I stress thinking about how hard they were for you because if you get into the trap of comparing your accomplishments to others you’ll make two big mistakes. The first is that you think everything you have done is easy after you’ve done it, and everything you haven’t done is much harder because you haven’t done it. The second is, it’s not your job to determine how important something is, it’s the company’s job because each company needs different work done and needs to fill the gaps they have in their current collection of devs. When you’ve got an idea of how hard the challenges are that you have solved and how much work you’ve gotten done successfully, it’s time to find out about where in the range you should be. If you’re a new grad or not classically trained and have never had a developer position before, put your finger on the 25th percentile. If you demonstrably outperformed your classmates in terms of score (GPA or some other widely accepted measure), move your finger up a little. If you have a masters degree, move your finger up a little. If you have public artifacts showing the work you’ve done or the things you know (blog posts, live on the internet working projects, etc), move your finger up a little. That’s it. That’s about where you should be, maybe as low as the 25th percentile, never below it and very likely below the 50th percentile.
If you’ve done some solid dev work such that people would consider you intermediate (professionally or not) and built things that people rely on, or you are a fresh grad with a Ph.D., then you start out at the 50th percentile. This implies that your developer tooling is mature enough to solve problems quickly and evaluate multiple solutions. If you feel like your collection of work is difficult on the relative scale of your field, nudge your finger up a little. If the success rate of the projects you have worked on is 60% or less, nudge your finger down a little. Greater than 80%, nudge your finger up a little. Be honest about this one, and notice I didn’t say your projects, because we pretty much all work on teams and projects can fail beyond your control. Also be aware that this failure rate doesn’t have to be on your resume; this is a method you are using to help guide your own thought process only. If you’ve done a lot of professional dev work with significant project ownership over primary features of your products, start with your finger on the 75th percentile. How you should move your finger here has a lot more to do with how well you can make your case.
Making The Case
The basic process companies use when making an offer is pretty simple. You pass all the interviews, they want to hire you. All of your resume information is sent to a specific person whose job it is to rate you much like the process I described above for rating yourself. They are using the materials you provided, resume, cover letter, etc as well as the write ups from each of your interviewers and they plot you somewhere in their range. This person comes up with a salary and then passes it back to HR who writes up the offer. The HR person sends you the offer with this amount. At smaller companies, the person who decides your salary might also send you the offer. Once you have received the offer, you have the opportunity to review and initiate salary negotiations if necessary. The most important thing to remember during this process is that any respectable company that has made you an offer won’t rescind it if you ask if the salary is negotiable. If they do, there is a strong likelihood will you not enjoy compensation review season at that company and them rescinding it is actually doing you a favor. You won’t get a better offer if you don’t ask for one and you won’t lose a good job by initiating salary negotiations. It’s still not easy to talk about for a lot of people and I get that. Just realize that the salary you agree to now will guide your raises for the rest of your time at this company and maybe even the next. It gets easier to talk about the more you practice and it can make a huge difference on your long term income. Once you decide to initiate salary negotiations, the big mistake many people make here is to simply ask if the salary is negotiable. This is a mistake because they can easily respond with a “no” and you have forfeited your opportunity to reiterate your qualifications. When you wrote your resume and cover letter, you had no idea what the company was looking for, what skills they needed to bring in an what kinds of problems they were facing with their products. If you used your interview Q&A periods wisely, you now know the answers to all these things. You may have only addressed these things in a single bullet point on your resume (or maybe not at all) but now is the time to make these things shine. It shows a deep interest in the company to talk about their problems and how you are the answer, so when you ask to negotiate your salary, specifically include your relevant qualifications. This will often be enough to get you a bump. One last thing of note: the most influential leverage you can have in salary negotiations is competing offers. If you already have an offer in hand that is competitive with or better than the offer you just received, do not waste time, just tell them about it immediately along with a note letting them know you would still like an offer from them. If a company refuses to budge on an offer that doesn’t meet your expectations, it’s okay to walk away. There are other companies that you may find are a better fit and offer compensation you’d be happier making. If you’re looking for a new position in development, Stack Overflow Jobs can help you find the job that’s a great fit for you. Check out open roles at thousands of companies today.