Salary Negotiation and Job Hunting for Developers

Salary Negotiation and Job Hunting for Developers

On Twilio Radio, Patrick McKenzie dropped knowledge on how developers can find a fulfilling job and add $X0,000 to their salary. He’ll be speaking more on this topic at SIGNAL (use the promocode RADIO for $100 off your ticket).

Listen to the full interview here or find the Twilio Radio podcast on iTunes. Below is an abbreviated and edited transcript of the conversation.

What is broken about dev hiring?

Many parts about the way the tech industry and many other employers of developers do hiring are unsound, unserious, probably unsafe. There’s many other “uns” you could put in front of them. Unfun. It’s just a frustrating process from beginning to end.

What typically happens is that people are screened into a hiring process on the basis of what’s on their resume. Then some crazy percentage of resumes are discarded at that point and never seen again, no matter how much raw talent the people have. It gets compressed and filtered down into a resume, and then those resumes are screened by, in most cases, non-technical people, just on the basis of the keyword scan. That already throws a lot of the baby out with the bathwater.

Then people are given interviews. The interview process at most tech companies is enormously stressful for the candidate. They’re asked to do tasks which are very unrepresentative of what we actually do as engineers, like, “Oh yeah, you’ve been writing web applications everyday for the last five years. Great. Can you please go up to a blackboard and using chalk write out how to reverse a binary tree?” Which I can guarantee you there is no practicing engineer in the entire United States of America or the entire world whose primary choice for an IDE is a blackboard and chalk. It’s not how we operate. It’s like saying, “Juggle bananas instead of balls. Then just juggle bananas so that we can extract a signal about your engineering talent.” It has very little to do with the work.

The false positive rate for hiring is absurd. The false negative rate for hiring is absurd. Rather than fixing the underlying problem, people instead make hiring more of a hazing ritual with the idea hopefully discouraging some of the people who would otherwise get through it. This has a variety of negative impacts on the industry. Candidates hate the hiring process. Every company is causing many good candidates who would otherwise interview with that company to not interview with that company, simply because they dread the hiring process so much. People who are incredibly talented get selected out of the process very early on, simply because they don’t have the right university on their resume or because their last several jobs don’t read as software engineering jobs. For example, someone who’s spent time in network administration, and then systems administration, and actually has quite a lot of skill in, say, writing Python will generally not receive a call back for an interview at a software engineering position, simply because the people who are making the comparison say, “Oh, no relevant software engineering experience.”

This is crazy. Rather than measuring proxies for talent, [at Starfighter] we just decided to try to measure talent directly. Matt is someone we introduced to a client in the last week. Hopefully we can go to a client and say, “I know this person, technically speaking, has never had a software engineering position before. I know they have an educational background which is not associated with many software engineers in Silicon Valley. I know [they haven’t] demonstrated experience in an open source project.”

“I understand if I start to read through the resume, it doesn’t look like the most promising candidate, but when given a very complicated engineering task which involved both security research, and then a complicated open-ended data analysis task, they not only successfully solved the task but produced a deliverable which could literally be published in a research journal in terms of what the thought process was to do the number crunching and data analysis — including three different theories of independent approaches that one could take to do the data analysis given a variety of world preconditions and what that would do to the strength of the analysis that one could perform.”

I tell the hiring manager, “Clearly this is someone who is worth an hour of your time to get together and talk about bringing them in for a internal group which does a lot of programming that involves data analysis.” An interview later, I got a call back from the hiring manager like, “So that candidate that you referred to us, yeah. Do you have clones? Can we have ten of them, please?”

It’s not rocket science. I think that many, many companies could do something similar, if they were willing to take a little bit of a risk with what they do for hiring practices. At the moment, a lot of companies feel like they’re firing on all cylinders for doing the other parts of the business. We’re kind of taking a risk on the hiring process for them.

What should a developer know about job hunting?

I’ll give you my most important piece of advice first. This is something that goes against a lot of the expected habits of middle class Americans. We think that the job search process starts out by sending a formal application or formal resume into some place which is labeled “deposit formal applications and resumes here.” Then, if the company is interested in you, they take the next step.

This is not how people successfully get jobs. Sending in resumes is not how people get hired for most jobs. What you do instead is find someone within a company who has hiring authority and convince them that they want to hire you. Then the formal interview process starts, but with an internal champion who is invested in bringing you into the company — in many cases, an internal champion who has full or partial decision-making authority on the decision to bring you on.

What that looks like in practice is you somehow find that an engineering company is hiring — which by the way, every company that has more than ten engineers is going to hire engineers this quarter. If you go to a meetup and someone says that they are working on a company that has thirty people on it, they are hiring engineers right now, regardless of what their job site says.

Important lesson number two: you ask them if they are a team leader or higher in their company. If they say “yes,” they either are a hiring manager or they know who is the hiring manager. Then you just talk to them like you would talk to any other person. Geek out about subjects which are mutually interesting to you, whether that’s Python or MongoDB or whatever it is, ask, “What are you doing with your company these days? Oh, that sounds really interesting. We should talk about that a little more.” Then try to, at the end of that conversation say, “I really like what you guys are doing. I think I might want to explore being part of it.” Have them get the ball rolling on a job application.

This is something that you’re going to have to do more times than you’re comfortable with, because the job search process should generally be performed in parallel. Go out to meetups, meet people, get introduced to five people who have hiring authority, have five talking dates, turn three of those into ongoing job applications. Then do that the next week, and then do that the next week, and then do that the next week until you find a job which you feel meets your criteria, whatever those criteria are.

People who do consulting or freelancing for a living might realize this is isomorphic to getting consulting engagements. It really is. It’s fundamentally running a sales process for yourself, which is a really weird skill for a lot of engineers, and it’s something that people in our community unfortunately don’t value enough and are often times actively discouraged from becoming better at. It is transformatively life changing if you realize that a job search is not a series of terrible events that just happens to you, but rather it’s an algorithm that you can optimize for.

What should a developer know about salary negotiation?

Every company’s hiring process is a little different, but at some point in the process you achieve something which I describe as “Yes, if…” rather than “No, but…”. “Yes, we want to work with you, if we can come to a mutually satisfactory offer,” which is distinguished from, “No, we don’t want to work with you, but we might work with you if it turns out that you’re disgustingly cheap.” After you have agreement in principle that, “We want you to work here. What’ll it take to make that happen?” — then and only then do you start talking about money.

People will ask you about money and other various negotiation related topics before that in the process. Your job is to stonewall that question. I know many developers don’t exactly have huge reserves of internal confidence, which is okay. Fake the confidence here. If they say, “What are your salary requirements?” You say, “Well, it’s really too early to talk about salary. I just really want to make sure that we’re a great fit for each other. If we’re a great fit for each other, we can work something out. If we’re not a great fit for each other, it doesn’t matter. We shouldn’t work together no matter what the numbers are.” Whatever you need to say, just do not answer the salary question until you’re actually negotiating.

After the negotiation part, they’re going to say, “Okay, we want you to work here,” which is great. You’ve crossed the biggest hurdle. “Now what’s the number?” Most developers will do something like say, “Okay, I hope to get $100,000.” That might or not be a realistic number in your neck of the woods, but let’s say their number is $100,000. That’s unfortunate that the developer just threw out a number there, because they’re never going to get more than about $105,000 to $110,000 as a result of that negotiation now, no matter what the company’s actual hiring scale is. Instead ideally the developer came in with an idea from their peers what the company’s scale looks like. If you don’t know anybody at the company, you can find people’s Twitter accounts. You can find their email addresses. You can find their information on LinkedIn.

It is well worth your time to take another developer out for a hamburger and say, “Hey, tell me a little bit about the company. Do you guys pay…” Don’t go directly to salary questions, but ask about the working environment, ask whether they like it or not, and then at one point in the conversation ask a fellow engineer, like yourself, “Hey, salaries over there, what’s the range look like?” Surprisingly often people just flat out tell you that, which is now information that you can use in the interview.

When they ask you the salary, you turn the question back on them and say, “You do this conversation with lots of people. You have a great idea of what each engineer is worth to the company. This is the first time I’ve ever had a conversation with you. I’m not in a great position to tell you what my value is to you. You tell me. What number do you think is fair?”

Then they name a number. Then you say, “That number is interesting.” Now that number is now your floor for the negotiation. Absolutely nothing you say from this point on means that you get a result lower than that number. You can only go higher. Then you start going higher by asking for more of whatever it is that you want.

In most cases, you can always ask for more money, and then turn that into an ask for something you actually care about, but money’s the primary thing that they’re keeping in their head for this conversation. For example, if they say, “For someone in your position, we feel like the approximate range is $110,000 to $125,000.” Then you say, “$125,000 is a very interesting number. I think we’re very close. I’m very interested in working with you. Could you do maybe $135,000?” Then the negotiation processes kicks in in-full, but eventually where that negotiation is going to settle is probably something in the $130,000 range, and then maybe some slight concessions on other things in the offer. Like, you get a little more vacation if you’re smart about it and can negotiate that.

Notice how much better that is for your life than just throwing out the number, “How much money do I need? $100,000 would be great.” The company really doesn’t care whether they pay you $100,000 or $130,000. I know that sounds like a crazy thing, but as someone who runs a business, let me tell you: businesses have more money flowing around in them than any developer can… the normal human brain is not calibrated to understand the amount of money that flows through a business that’s operating at that size.

The difference between $100,000 and $130,000 is ultimately not that big for a business.  The difference between $100,000 and $130,000 for an actual human though is pretty huge. That could be the difference of whether you’re able to afford a house, for example. Given that the company perceives very little difference between the two, and you perceive quite a lot of difference between the two, negotiate aggressively. Negotiate like a confident professional who understands that they are worth whatever number that you can successfully extract out of the company.

By the way, it feels like it’s a conversation between two people, because it’s just you and the hiring manager in there talking about the salary, or you and the HR director, whoever your counterparty is. Ultimately, the money isn’t coming out of their pocket. It’s just coming out of a budget somewhere. There’s a cell on a spreadsheet in a spreadsheet that has 68 other cells in that column. The cell is going to be different by a little bit by the standards of the spreadsheet. Just work hard at getting that cell to be the highest number you possibly can.

Where to learn more on this subject

I’ve written a blog post a few times about developer sort of career design and things. One post is called Don’t call yourself a programmer and other career advice for engineers. Another is called Salary Negotiation for Engineers. In terms of people who write very interesting stuff about careers generally are Ramit Sethi, who’s at iwillteachyoutoberich.com, consistently gives some of the best career advice I’ve seen, particularly for people who are younger and very highly driven. He also has some paid courses available, but the free blog posts are pretty good on that, too. He’s been interviewed on my blog a few times. There are the likes of maybe Josh Doody [of Fearless Salary Negotiation].

Then there exists lots of stuff written on this subject. Unfortunately, not that our industry and our time is completely unique, but many people who are in another industry or another generation have a very different set of cultural expectations with regards to work, to careers, to the nature of a career path, which makes their advice, perhaps, not maximally relative to us.

For example, my parents, I love them very much, they have always suggested to me that I get into a nice, safe job at a big mega corp, and stay there for my entire career receiving regular promotions every three years. I’m at the early end of the millennial generation. The nature of careers for us is that just working for 40 years for IBM and then receiving a gold watch is something that very few of us are going to be able to successfully do. And that frankly, I’m not even sure I want. Actually, I’m sure I do not want, do not want, do not want.

I think for the average developer, you’re probably going to be going through quite a few jobs in a relatively compressed period. I would expect your first job as a developer to likely last on the order of two to three years. Then you’re going to do several stints of roughly two to three years prior to really understanding what you know, and focusing on a particular problem or a particular tech stack. You could even go through many more jobs if you happen to do something like working in start-ups where they get shot out from under you every eighteen months. Reading advice that’s written for people whose schema of a successful career is attaching themselves to a large organization and growing with the organization is probably not maximally in your best interests.

What will you be talking about at SIGNAL? 

I’m going to primarily be talking about the ins and outs of doing job searches for engineers. Very similar to the topic we’ve been talking about here, but more about the nuts and bolts details of:

• how one connects a search for positions which are open
• how to present yourself to an engineering manager
• how to know whether you’re a good fit for a position prior to investing a lot of time into applying for it
• how to conduct yourself in a negotiation
• how to use the fact that you have multiple offers on the table to optimize for what you care to get with a particular negotiation.

If you’d like to meet Patrick at SIGNAL, register here and use the promocode PATIO11 for 20% ($100) off!