This chapter introduces hiring processes, interviews, and job offers—it aims to demystify the intimidating but mostly predictable journey from the wilderness to a job building software.
Many large tech companies’ hiring systems are approximately the same. End to end, the process can take anywhere from < 1 week (for small startups where every stakeholder can get in a room on 5 minutes’ notice) to multiple months (Google is famous in Silicon Valley for processes of 4–8 weeks with many stages of committee review). This section will outline the process, with subsequent sections treating each area in detail.
Before we begin, I’ll note that smaller firms, especially early startups, often work very differently—they’re much more likely to have informal, personality-driven processes, perhaps as simple as a conversation or meal with the team. Coding interviews are also anecdotally less prevalent outside of the United States.
The Recruitment Process
Resume Review and Recruiter Phone Screen
A recruiter screens your resume or LinkedIn profile. If they like what they see, they speak to you on the phone for 20–60 minutes, asking you questions about your interests, experience, and job/salary expectations. The recruiter then makes a decision about whether to pass a candidate on. They do not have technical expertise (though a hiring manager will have given them some keywords and context), so their decision is based on imperfect information, even relative to everyone else. Nevertheless, they have considerable discretion in whom to move forward with and whom to drop.
Technical Phone Screen(s)
You do one to two technical phone screens, each 45–60 minutes, with engineering managers and/or engineers. They ask you questions about your experience and likely have you write code in a shared editor like CodePair (or even a Google Doc).
On-site Interviews
You go to a company’s office and do four to seven interviews of 45–60 minutes, each with one to three engineers or managers. You write code (either on a whiteboard or on a computer), design systems, and answer questions about your experience and interests. In between, you have lunch with a team.
Take-Home Coding Exercise
Not all companies use this stage. You’re given a coding problem to work on for a few days on your own, then send the code to be reviewed by engineers.
Decision
Either a hiring manager or a committee makes the decision about whether to extend an offer. The committee may either be composed of interviewers and a hiring manager or drawn from a central committee (famously the custom at Google); generally, more senior/experienced committee members carry more weight.
The hiring meeting often begins with a simultaneous “thumbs up” or “thumbs down” from each committee member,1 followed by a discussion to try to reach a consensus on whether to make a hire. The criteria are never objective in the sense of being measurable by a machine—instead, each committee member uses their intuition, sometimes against a written rubric of subjective criteria.
Offer and Negotiation
Level/title
Base compensation
Equity compensation
Signing bonus and relocation
Start date
All of these parameters are determined by your experience and interview performance (i.e., the company’s perception of how valuable your work will be) and your competing offers, which they may try to match or beat.
Referrals
Companies usually have internal systems for employees to refer others for jobs; you may well be asked to refer others to your company or want to be referred elsewhere.
A referral with a strong personal endorsement is a big deal—it bumps a candidate to the head of the line at the screening stage, and if the referrer is well-regarded, it can make the difference at decision time. A corollary is that you should save your own strong referrals for people you trust—strong endorsements for bad hires reflect badly on you.
More casual referrals can nudge a resume into view in “Resume Review,” but that’s about it. I personally don’t love making them myself (there isn’t a lot of upside), but they aren’t harmful if you’re clear about your confidence level: “I know George from SprocketSoft; I didn’t work with him extensively, but he’s very interested in WidgetSoft.”
Resumes
Resume formatting is not, in my experience, “make or break” of anything in tech—they can hurt a little, they can help a little, but the content speaks much more than the format. Still, there’s no reason not to get them right. Below are the most important points; follow them, edit, tinker, and when you’re done, get a peer review, ideally from a senior engineer or manager with interviewing experience. Let your friends, not a hiring manager, catch your mistakes.
Section Order
Sections should be ordered as experience, then skills, then education, because those are the priorities of hiring managers. That observation alone tells you something about the importance of internships for a student: they (usually) weigh more than coursework with hiring managers! If you’re early in your career, you may elaborate more on your education (e.g., specific classes and projects); as you mature in the industry, you’ll emphasize projects more and schooling less. Lots of people include hobbies; I think they’re a nice-to-have and can safely be skipped.
Formatting
Resumes should be a single page. You can do it. If you are early in your career, you absolutely do not need more than one; the second page just says “I take myself too seriously” (hiring managers really will see it that way). Also, table gridlines give an appearance of amateurism (I can’t exactly say why, but they do).
Tell a Story
Emphasize what you delivered, where you led, and the results your projects yielded: managers like signs of autonomy and leadership. Never say “Implemented features and bugfixes,” which is well-known to be the most generic line ever added to an engineering resume; help the reader visualize you solving a big problem or taking a project from conception to delivery, not sitting passively at your desk waiting for someone to give you a bite-sized task.
Example
Below is an example of a junior engineer’s resume; it’s not a work of art, but if you’re in doubt, you can copy this format.
Passing Engineering Interviews
This section is a brief overview of how to pass software engineering interviews. It will discuss what interviewers look for, what they’ll ask, how to prepare, and how to behave during the interview. A later chapter will cover this subject from the interviewer’s perspective. Whole books have been written on this subject, and as you look for your first job, you should read one (look at the Appendix to this section).
What They’re Looking For
Software engineering interviews usually look for two things: ability and “culture fit.” As we’ll discuss in “Interviewing Software Engineers,” neither is well understood, and neither is sought in a coherent way. However, you don’t need to solve that problem for the industry: you need to pass interviews, which you can easily do with preparation.
Coding/debugging measured by coding on the fly in interviews and sometimes by a take-home coding problem
Design/architecture measured by a design exercise in an interview
Communication measured by how clearly you express your ideas in interviews
Domain knowledge measured by factual questions and design exercises
Enthusiasm for the role
Positive attitude and friendliness
Whatever interviewers happen to like
All three are measured by questions about your interests and goals and by the interviewers’ general sense of your attitude.
The relative weights of domain knowledge, culture fit, and “raw ability” (i.e., coding and debugging) vary considerably by company and interviewer, but by and large, pure interview coding skill, that is, the ability to solve coding problems on the fly while talking about what you’re doing in a pleasing way, is priority #1 for junior hires, and as of this writing, many companies are willing to give “smart people” a try at a specialization they haven’t practiced before.
Acing Coding Interviews
For passing interviews, coding is king. That is to say, interview coding. Programming interviews are a kind of sanitized, stylized coding, a performance art where you have 30–60 minutes to solve a problem chosen by the interviewer while talking through your work; there’s almost always some kind of tricky algorithmic problem at the core of the question.
You should on no account confuse interview coding with the day-to-day work of a software engineer, which is far messier, mostly driven by the behavior of existing code, mostly about integrations and debugging, and almost never about cracking a tricky algorithmic problem, which I personally do just a couple of times per year.
On my bad days, I’m outraged by the lack of realism of coding problems and the way they favor people who are blessed with the ability to be calm under pressure and a gift for oratory, neither being skills that come up on a daily basis when doing the real job. However, interviewers need to ask something, and while these interviews may not be that realistic, they are reasonably easy to prepare for; you should think of a coding interview as a performance art that you can easily excel at with practice.
Preparation
Solve a bunch of coding problems, with real code, to get your brain in the groove of time-pressured problem-solving. Sites like leetcode.com have large banks of practice questions; question quality varies, but if you do 50 problems end to end, you’ll be more than ready.
Study your CS fundamentals, especially linked lists, hash tables, trees, sorting, and the (Big-O) analysis of the memory and runtime of all of the above. Brush up on dynamic programming if you’re feeling energetic.
Brush up on the specific domain of the job you’re applying for, and prepare to discuss the standard technologies architectures in that space.
Practice talking through what you’re doing to get used to the performance aspect of interviewing; have a friend grill you in a mock interview if you can.
On the Day
Explain what you’re doing: Talk out loud. Explain what line of solution you’re considering, what problems you think it might have, what the problem resembles from your past experience, what the tradeoffs are in your solution, etc. You want to take the interviewer on a journey with you, where they feel that they really understand and relate to your thought process all along the way. Even if you don’t ace the problem, the interviewer should be able to say, “they expressed themselves really clearly. Even though they didn’t quite finish, what they were trying made sense to me.”
Start with a simple solution: Unless you see the perfect solution instantly, it pays to start simple and iterate. Explain what you’re starting with and why. It’s much better to produce a solution that works inefficiently than to never solve the problem at all; professional engineers also take this approach in designing real systems.
Restate the problem and ask clarifying questions: Interviewers love to see you refine the problem’s requirements, because they show that you want to fully understand a problem before starting to code. Restating the problem is similar, and if you don’t understand the problem correctly, the interviewer may set you on the right path.
Stay calm and never give up: It’s not a requirement that you nail, or even finish, every (or any) problem to get a job. Staying calm, trying a variety of approaches, talking through a sensible thought process, and recording whatever you manage to come up with can easily make up for an imperfect solution. Many interviewers ask questions that are almost impossible to completely finish and for which partial credit can be fine.
- Code in a language you know well, and make that language Python if possible: Otherwise Java. I program in Go in my day-to-day life, but I interview in Python; it’s simply the best coding interview language, full stop. Here’s the hierarchy from my experience:
- 1.
Python coders pass interviews; Python helps them with its dynamism, convenient collections, easy-to-use string helpers, and, above all, its conciseness.
- 2.
Java programmers get bogged down in the verbosity of defining a POJO2 or the awkwardness of JSON parsing but probably get there in the end.
- 3.
Go programmers do pretty much the same as Java programmers.
- 4.
Scala, Clojure, and Haskell programmers write beautiful functional code but never quite get the problem working all the way, struggling with some obscure point of syntax, getting stuck on a simple bug their interviewer could help with if they knew the language, or slowed down too much by just-not-quite-right editing support.
- 5.
C and C++ programmers tend to run out of time getting a hash table to work right or some thing else that works effortlessly in Python.
- 6.
Perl programmers should understand the signal interviewing in Perl sends and seem to struggle with defining clean data types.
- 1.
Passing the Rest of the Interview
Prepare a compelling and specific answer to the question, “why do you want to work here?”—the answer should have something to say about both the company’s business and its technology; for example, “I grew up with dogs, I have dogs now, and I actually use puppersoftware.com myself. I’ve also read several of the company’s blog posts and was impressed with the JavaScript performance work you’ve done.” You should spend at least an hour researching the company, especially reading their public technical writing and talks so you’re ready to give credible answers.
Try to balance humility (that you’ve enjoyed learning from people, that you know you make mistakes) with confidence (that you believe you can tackle big problems and are excited to do it).
Show your enthusiasm for technology when you get the chance; mention a tool you love to use, a book that influenced you, etc.
Don’t badmouth your previous employer or colleagues, which shows only that you’re sour and will badmouth this employer in the future.
- Prepare one or two questions about the company and team; at the end of every interview, interviewers will likely give you a chance to ask your own questions. A question highly specific to the team/company is ideal, but generic questions are fine too. A few good examples are
What do you think are the biggest technical problems you need to solve in the next year?
What’s your favorite thing about working here?
What do you think your team does especially well, and where do you think you need to improve?
What do you think are the toughest problems facing your organization?
You should also do your best to be charming, that is, to create a positive feeling in your interviewers and put them at ease; I suggest at least smiling, shaking hands firmly, and expressing (truthful) enthusiasm whenever you can.
Further Reading
Leetcode is an extremely convenient place to practice coding questions. The interface is useful, and the questions are realistic for interviews (though some are too hard and some are too easy). If I were going to interview for a job next week, the first thing I would do would be crank through a bunch of Leetcode problems.
Cracking the Coding Interview is a well-known book of example programming interview questions. It’s a good place to find examples.
Recruiters
This section will discuss who recruiters are and what you need to know about working with them, both as colleagues and on opposite sides of the table.
Recruiters are employees or contractors who help companies find and hire employees. This role exists for many fields, including medicine, law, and consulting; I’ll speak only to tech recruiting, which has become quite polished in the tech boom3 of the 2010s. Tech recruiters usually fall into three specializations, ordered here by increasing seniority and authority:
Coordinators: Organize on-site interviews, including setting up interview panels and booking conference rooms.
Sourcers: Identify potential candidates using LinkedIn or other specialized tools and do initial outreach (these are the people who send LinkedIn messages). Sourcer performance is measured by how many hires come from candidates they identify.
“Recruiters” (per se): Owners of the hiring process after initial sourcing. Responsible for most communication with candidates, discussions with managers, attendance at career fairs, salary negotiations, and recruiter presence in hiring committees. Recruiter performance is often measured by number of hires per month and close rate. A common guideline is about three hires per month per recruiter, with one more hire per month generated by having a sourcer.
In my experience, each recruiter usually supports one to two teams, though different arrangements exist. That means that recruiters usually have an incentive to close chiefly for their own team, and they won’t necessarily be positioned to route you to the right team for your interests unless you speak up.
Recruiting is a two-sided sales job; recruiters sell a company to a candidate and a candidate to a team, and they make a sale when both sides accept the other.
What You Need to Know As a Colleague
Engineers and managers evaluate candidates in detail and decide when to make offers; candidates decide for themselves what jobs they’ll take; recruiters are the conductors of the whole messy process, accountable for ensuring hires actually happen.
This strong incentive to close candidates is the most important context for engineers; it means that recruiters are almost always the gas, not the brake, in a hiring committee. As an engineer or manager, the encouragement to say yes can be surprising or frustrating, but it is more or less the recruiter’s job: to get hires done.
- A.
Is not a technical expert and can only go so far in evaluating the candidate themselves
- B.
Needs to work with both sides of the transaction at once
- C.
Deals with some of the most notoriously cranky, entitled, and antisocial people (us)
- D.
Is subject to many obstacles beyond their control, like the company’s salary bands and reputation
Overcoming those challenges requires considerable social skills, energy, and adaptability; the best recruiters I know are astonishingly positive, energetic, and well-organized.
Finally, it’s underappreciated because engineers (usually) only appreciate engineering skill and don’t respect the difficulty and necessity of recruiting work. In tech companies, recruiters are sometimes considered ancillary to engineers (i.e., lower on the totem pole), but I advise you to start your work with them (as with anyone!) from a position of appreciation and respect for a hard job done well. Now fully understanding this context for the role, let’s move on to how to best work with recruiters as a candidate.
What You Need to Know As a Candidate
Since the recruiter’s job is to close candidates, the recruiter is usually your ally in the hiring process; therefore, don’t agonize about making the perfect impression. Since it’s the engineering team’s job to evaluate your technical skills, the most important criteria they screen on are background and enthusiasm that are credibly specific to their company, so you’ll be just fine if you come to the table with respect, enthusiasm, and something to say about why you’re interested in the job. Remember that recruiters act as a layer between managers and candidates and operate with considerable discretion; they can and should accidentally put your resume in the recycling bin if you approach them with disrespect or indifference.
Getting Properly Routed
Since a recruiter usually supports one team, their incentive is to get you hired on that team; they may need explicit feedback to help a candidate with specific interests or a specific technical background get to the right team within a company. This means that if you’re routed to a suboptimal team, it’s appropriate to be quite vocal (but always friendly and respectful) in expressing your preferences.
Asking Questions
Don’t be shy whatsoever; recruiters are usually happy to help out with just about any questions at all. If you need to talk to an engineering manager (a much more critical audience, I’ll note), they can connect you with them too.
Levels, Titles, and Compensation at Tech Companies
This section will describe how Silicon Valley-style software companies handle job levels, compensation, and engineering performance. Every firm has its own systems, and you’re likely to find more informal practices at smaller companies, but the fundamentals apply quite broadly.
Level and Title
Level is fundamentally an HR concept, one that applies across all disciplines at most large companies: an integer on a role-specific scale, like Data Scientist II or Designer 1. Each level has an associated allowable compensation “band” (allowable range); this observation will come into play in our section on negotiation. Across companies, titles match up imperfectly, but comparisons are often possible (people know that Staff Engineer is higher than Senior Engineer). Companies usually level engineers based on some notion of their “scope,” the level of impact they can have on the company’s outcomes. It is often, though not always, expected that engineers at higher levels have a capacity for greater leadership, coordination, and architecture work—that they will achieve more impact by leadership and decision-making than by what they personally code.
As a young engineer, you’ll wonder: How much does title matter, and why, and what level should I be?
Title matters for two main reasons: your level determines your maximum compensation, and it can help you market yourself as you look for new roles. However, I frequently caution young engineers to avoid excessive preoccupation with title. It emphatically is not its own reward, you may go up and down in title as you move across companies, and, since compensation bands can overlap, increased title doesn’t even guarantee greater compensation. I encourage you to focus, by and large, on the forms of compensation you can use every day—money and personal growth.
There’s one important caveat—as you advance in your career, you do want to make sure to eventually reach Senior Engineer level, which most would consider the first valid “terminal level”—it’s considered acceptable to never advance beyond that title. This is not usually the case for Software Engineer and Software Engineer II, for which there are “up or out” expectations. I’ve never actually heard of someone being fired for failing to advance beyond those lower levels, but it is expected that you’ll be improving and inching toward promotion.
Title | Level | Experience (Years) | Scope | Base Salary |
|---|---|---|---|---|
Software Engineer | 3 | 0–3 | Do what people tell you | $110,000–$130,000 |
Software Engineer II | 4 | 2–6 | Take on a project, do own project management, and work with others | $120,000–$165,000 |
Senior Software Engineer | 5 | 4–? | Manage projects with numerous moving pieces, lead others, and set some direction | $160,000–$195,000 |
Staff Software Engineer | 6 | 8–? | Lead very large projects (or multiple very large projects) and set direction for a large org, almost completely self-directed | $190,000–$230,000 |
Principal Software Engineer | 7 | 12–? | Set direction for significant part of the entire company | $220,000–$250,000 |
Compensation
Your compensation in software engineering has three components.
Base Salary
Your base salary shows up every few weeks as long as you’re employed; it keeps you sheltered, fed, and clothed. You may get a 2–5% raise annually or 10%+ if you’re promoted. I suggest strongly that you treat this as your only compensation for budgeting purposes, since it is far more predictable than the rest of your compensation package.
Bonus
Bonuses usually show up once a year; a multiplier (call it ß) is often calculated based on your performance, then you get ß * salary. 10–20% of is fairly normal, but 0% could happen if you perform poorly, as could 100% if you change the world at the right company.
Equity Compensation Basics
“Equity compensation” means paying you with stock (restricted stock units, or “RSUs”) or stock options (typically incentive stock options, or “ISOs”) in your company. Equity compensation is almost universal in Silicon Valley, but less common in other parts of the world.
You probably know what stock is; stock options are a financial instrument derived from stock, where what you hold is the right to buy stock at a locked-in price (the “strike price”); so, if you hold the right to buy a share at $1, and the price goes to $10, you can “exercise” the option at $1 to buy the share, sell the share at $10, and pocket the difference.
There are two reasons engineers are compensated in equity—the first is to incentivize you to help your company succeed (you want your shares to be worth something) and the second is because stock options can have tax advantages (as well as downsides) over other forms of compensation—a very basic primer on the related tax issues is found below.
Equity compensation is often, but not always, structured as grants that “vest” (become yours) over four years with a one-year “cliff”—the first year’s shares vest in bulk at the end of year 1, after which shares vest monthly. For example, you might be granted 4,000 incentive stock options (ISOs) in Acme Software to vest over 4 years (48 months); you’ll become the owner of 1000 options (1/4) after 1 year, then another 1/48 every month for the 3 years after that (some companies structure things differently, such as “back-loading” the grant; vesting more in later years).
RSU compensation at a large public company can be highly liquid—once the shares are yours, they’re yours, and it’s easy as pie to convert them into cash on the public market. Its value can still vary wildly over time, but you can count it as more or less money when you evaluate a package.
Equity in a small private company, however, can be extremely illiquid—there is no public market for it, it expires after some number of years, and you may be contractually forbidden from selling on any private market. Startups often overstate the outlook for their stock—my opinion when evaluating a package is that if it can’t be sold today, it should be counted conservatively in your financial planning. Your salary pay will almost certainly go home with you, but your equity in a tiny private company could just as well become nothing as something.
Stock options also often come with a critical encumbrance—if you leave the company, you often have only 30 or 60 days to decide whether to exercise your vested options or let them evaporate into nothing, a decision which can have important tax consequences in the United States.
Equity Compensation Taxation in the United States (Why You Should Consider Exercising Early)
This section is not intended to be comprehensive; instead, it aims only to alert you to a couple of important tax properties of option compensation in the United States. If part of your pay is equity, you would be extremely well-advised to consult a tax professional, probably a CPA. It will cost a few hundred dollars, but it may save you infinite headaches in the future.
If you’re compensated with RSUs at a public company, they’re generally taxed as regular income, and your company will withhold income tax in kind when your grants vest—that is, a percentage will be taken right off the top before you get them. That withholding percentage may not match your actual tax rate, so you should double-check, or you may be surprised by your large tax bill at the end of the year.
If you’re compensated in incentive stock options (ISOs), things are a bit more complicated, and I recommend you educate yourself with the well-regarded Consider Your Options by Kaye Thomas. I’ll highlight two points.
Capital Gains Taxes
If you hold a stock for a long period of time, and the price grows in that time, you may pay capital gains taxes when you sell the shares, instead of higher income taxes. For you, it means that if you are compensated in options and exercise them early (which takes money), and then the company grows in value, you may pay much lower taxes than if you had exercised and sold at the same time.
Alternative Minimum Tax (AMT)
Great, lower taxes! This part is the catch, summarized only at a very high level.
The AMT is a mechanism to ensure that America’s taxpayers don’t unreasonably avoid paying taxes by fancy footwork—it’s a floor on your tax rate, and it applies to ISOs. Stock options have a kind of estimated fair market value (FMV) based on a 409A valuation of a company, and they also have a strike price, what you have to pay to convert your options into shares. The AMT says that if you exercise a stock option, you may owe taxes on FMV minus strike price. If a company’s valuation has gone up a lot since your options were granted, that may be an astronomical sum in taxes, but since your shares may not be liquid, you may need to pay out of pocket.
That property matters enormously in at least one specific case—when you want to leave a private company. At that time, you’ll likely have to either exercise or abandon your options within two months; you could be—and I have been—faced with a tough choice about staying or abandoning shares you couldn’t afford to pay taxes on, all of which together means that if you join a company and your options are extremely cheap, you would do well to consider exercising them before the 409A goes up and makes that expensive or impossible. I will reiterate that professional advice is called for.
Share Salary Information As Much As Possible
Before you set out to evaluate offers and negotiate compensation, you should arm yourself with information about the landscape. What are other people with your skills and experience making in the industry? What are they making at this company?
If you know the landscape, you can answer questions like: Is this a good offer by this company’s standards? If not, they probably have room to go higher. Could I get more somewhere else? Armed with those answers, you can get the best offer for yourself by negotiating harder or by simply going to better-paying companies.
Apart from what you may find on sites like levels.fyi, I think there’s only one way to acquire that information: sharing as much compensation information with your friends and colleagues as you possibly can. Engineers are squeamish about sharing this information, and employers love that, because it puts all the clarity in their hands at negotiation time. There’s no reason to be squeamish. Sharing salary information isn’t whatsoever unprofessional. Your employer may try to tell you it is, for the simple reason that they have an advantage if you believe that. You might be worried that you’ll be ashamed if it turns out you make less—you might be worried your friends will be resentful if it turns out you do. Sweep away those worries. Whichever of you makes less is about to be fortified with the tools to do better.
Negotiating
When I got my first few job offers, I was nervous about negotiating for better compensation. Did people do that? What would the company think? Would the hiring manager be angry? Would it get me anywhere? What should I say?
Yes, people negotiate on compensation. This section will argue that you should almost always do so. We’ll first discuss compensation “bands” and what they imply about your initial offer. Then, we’ll talk about the incentives of the parties involved and how you can negotiate effectively without harming your eventual employment relationship.
Title | Level | Experience | Salary | Equity Grant (Shares) |
|---|---|---|---|---|
SWE | 3 | 0–3 years | $110,000–$130,000 | 5,000–8,000 |
SWE II | 4 | 2–6 years | $120,000–$165,000 | 7,500–10,000 |
Senior SWE | 5 | 5–? years | $160,000–$195,000 | 9,500–15,000 |
Staff SWE | 6 | 8–? years | $190,000–$230,000 | 15,000–20,000 |
Principal SWE | 7 | 12–? | $220,000–$250,000 | 18,000–25,000 |
Level is set by experience and interview performance. Most likely, your initial offer will not be “top of band,” and most of the time, if they like you enough to give you an offer, they like you enough to move closer to the top of the range, though going beyond the top of the band (i.e., up a level) may be hard or impossible. In general, there’s very likely money available for the taking, and you should always try to take it.
Let’s take a moment to understand the incentives of the people involved. The recruiter always has the strongest incentive to get you to accept, because they’re compensated based on their hire rates and they don’t care one bit about the cost (the cost of hires isn’t usually held against them). The manager is in a similar boat—they need to hire, and the money doesn’t typically come out of their personal budget, so they just want to get you the best offer they can. However, there’s usually some bureaucrat, director, or committee that needs to sign off on the package, which means that you need to arm the recruiter and manager with a justification for improving the offer. The best ammunition you can give them is another package to point to, either your current compensation or a competing offer.
The most powerful leverage you can have is better current compensation; companies may do their best to match whatever you make today, often exactly to the dime. Therefore, you should feel free to say, “my current compensation is X, and I would like to see that matched to accept this offer.” The second best leverage is a better competing offer—it both signals your quality in general and gives the recruiter and manager something specific to point to. Even if you don’t have a slam-dunk better package elsewhere, your negotiating strategy should probably still be based on some dimension where the alternative wins—for example, if your current company has a better bonus program or another company’s equity is more liquid (e.g., they’re already public).4
Negotiating with a respectful and positive attitude usually won’t harm your eventual relationship with your manager (not without exception obviously—smaller companies can take things more personally). The negotiation will usually take place through the recruiter, who will keep the manager informed throughout. Asking for more usually feels crass to engineers, but it’s just business for the recruiter, who deals with compensation packages all day long. You should negotiate unapologetically and professionally5; remember that negotiating is completely reasonable and that if you stay positive and businesslike, they will too. Especially, you should never get offended or complain; this is business between adults.
The team really impressed me, and I’m excited about the product. My offer at SmartSoft has a base salary of $150k and a similar equity package; can you match them on the base salary?
Thanks for your quick reply. I really enjoyed my interviews, and the team was really friendly. The base salary looks good to me, but my current package has a 20% bonus target, and Acme Startup doesn’t have a bonus program. Can you balance that out with a bump in the equity or base salary?
I suggest the convention of expressing what you want once, firmly, and if they say no, taking that as their final offer to weigh against competitors.