Disclaimers: Everyone's situation is different, this is just advice from mine and my friends' experience going through the interview and negotiation process. I don't necessarily agree with the current state of technical interviewing, but this piece presumes the status quo - though there are much better interviewing methods. I'm no expert, there are plenty of those who you should listen to.

Tldr;

READ @patio11's classic Salary Negotiation post. Every one should read it and then re-read it. This covers bits of it, but assumes the reader has already gone through it, so this focuses more on tactical techniques.

The best leverage is another offer (always have a good BATNA), or a well positioned starting place.

The best way to get good offers is to do well on the interviews:

practice a lot, mostly for the things you'll be tested on

for most engineers this means coding questions, system design questions, (sometimes) debugging code, and project review.

It's a numbers game and timing matters quite a lot.

Practice negotiating, all the usual tips:

Don't mention numbers, get them to give you an offer (you can nudge them that you're expecting "competitive" offers given the other companies you're interviewing at)

Don't haggle or go back and forth too many times. Ideally you get all the initial offers, then progressively use them against each other 1-2 times at most.

Figure out which levers matter to you the most (equity? location? level?) and when they don't have freedom to adjust in one, try another. Be willing to give in one dimension that matters less to you in order to take in another that matters more.

Having recently gone through the tech interview loop, and discussing it with half a dozen friends who did the same, I realized how much private knowledge there was around optimizing the whole process. The unfortunate truth is that a lot of this information can make a $10k-100k+ difference in salary for otherwise the same engineer. Some of it is common sense, but a lot of it is learned through word of mouth or collecting various sources online. So I wanted to level the playing field and put it all in one place in the hopes this helps a few folks who perhaps have less access to this information.

A little bit about myself: throughout my (6) internship experiences at the University of Waterloo I went through many dozens of interviews. It served as preparation for new grad interviews where I got several offers including Shopify and Google (where I eventually signed). After four years at Google I decided to go through the process again, and eventually received four offers at all the places I had onsites with: Square, CloudKitchens, Robinhood and Stripe. I even consulted with a negotiation coach (highly recommend him if you're not excited about the prospect of doing this yourself) and was told I had done everything I could have to get the best offer. I'm by no means an expert in this whole thing, but I've gotten to see a lot about how it works and had fun trying to pick it apart, while also learning a lot from others doing the same.

This guide is targeted at those who already have engineering experience, or perhaps are just going through their first round of interviews, but not those still learning computer science - for that there are plenty of other great sources. Otherwise, I'm assuming that you've decided to look around for an opportunity and want to do it in the most effective way possible. I hope this guide is as tactical as possible, so I'll keep things brief and actionable.

Getting the interview

In the ideal case (and I'm not quite there either, but want to be more deliberate about it) you'll naturally have made friends and acquaintances throughout the industry that will think of you when they need to hire someone. A lot of times, these sorts of referrals will bypass parts or all of the standard interview process. Even if this is the case, unless you have a really good sense of the job market and the offer ranges for your experience level, I still recommend doing a couple of other interviews before taking such an offer so you can be confident it's competitive.

Most people, especially starting out, will have to seek out their own opportunities and that's fine! Define a criteria for yourself of things that interest you, locations you'd be willing to relocate to (remote?), and values you care about in a company. Don't necessarily restrict yourself to these for applying since you want to cast your net as wide as possible in the beginning, but keep your criteria in mind as you get closer to making your decision. Be sure to apply to companies that you know give out very high offers, even if you're not thrilled about working there because you may be able to use their offers as leverage.

It might be helpful to create an Inteview Tracker. I used a Notion Kanban board to keep track of the different stages I was in for each company.

Once you've applied to all the companies on your list, try to reach out to people in those companies to get 1) information about the interview process and the company culture and 2) potentially fast tracked through it. If you know someone at one of these companies, reach out to them! Even if you don't, pass around a list of companies you're interested in to people you know working in tech, there's a good chance they know someone who does. Cold reach outs work too, Jake does a great job of covering how to do this in his post A Hacker's Guide to Job Hunting, I can't recommend this approach enough. Twitter is another great place to cold reach out to people at companies you're especially interested in. Most companies will have a modified process for referrals, and there's lots you can learn about a company's internal process for evaluating candidates that will help your chances, so this step can really help.

The Interviews

The best way to get great offers is to do well on the interviews. Your performance on the interviews is more than just pass/fail. Going above expectations on them gives you and the recruiter ammunition to push on the higher end of their allowed band, so try to really invest in practicing deliberately.

The format of the interview should be pretty familiar to you, 90% of companies follow something like this: Phone screen (coding question) -> Onsite (2-3 coding questions, 1 system design, 1 project review). Sometimes they'll have a do-on-your-own-time project based interview instead, with a shorter 1-2 hour onsite. Lots has been written on how to practice for these already so I'll just link to some of the best resources and describe my general approach. 4-6 weeks of a couple of hours after work and on weekends should be more than enough time to prepare for the phone screens and onsites.

If you're intimidated by the open endedness of practicing for coding questions, I recommend starting by following a guide like this one. You don't need to do every question for every week, and the dynamic programming week could be just skimmed through (in practice these are rarely asked), but it serves as a good path to make sure you cover most types of questions and continue making progress. On top of that it's useful to spend a couple sessions on:

algorithms and data structures; their trade offs and use cases and time complexity. These are good starting points.
object oriented programming and patterns
locks, parallelism and multi-threading. It's rare to get these in coding questions, but you should have some sense of what they are and how they're used. They sometimes come up when discussing follow ups to questions or in system design interviews. I mostly just reviewed the concepts with this post, and made sure I knew how it was done in my programming language of choice, Python.
quirks about your programming language of choice. This probably isn't a deal breaker, but being able to drop some niche knowledge about the programming language you're using when it comes up in an interview makes you look like you really know your stuff. For example, I make sure to mention Python's Global Interpreter Lock (GIL) when talking about parallelism. Here are some notes about things particular to Python I took along my practice. This is part of the reason I choose to interview with Python, it tends to have fewer things that "experts" are expected to know (compared to say, Java, where there are a million best practices), ie. fewer gotchas.

The system design questions are a whole other beast, and deserve their own practice. You may not encounter them depending on the type of role you're interviewing for, but they're common for full stack and backend. They can be intimidating at first because they tend to be so open ended and have no "right answer", but once you've gone over a few examples you'll get familiar with the template you use to answer them.

Go through a primer, taking notes on the different components that are used. Take note of the different failure modes that each part of the system can have and solutions to them (ie. retries, redundancy, timeouts, throttling, etc).
Impress the interviewer by naming actual services that represent each of the abstract components you're using (ie. Load balancer -> NGINX, HAProxy, ELB ; cache -> redis, memcache) and mention the differences between them or whether you've ever used them. This shows you have real world experience.
Practice answering some! Read through some examples to learn how to structure you answers. Youtube is a solid resource for this.
Consistent hashing, concurrency models, partitioning, and caching are all important topics to understand.

The bulk of questions you get will be covered by these, but there's a long tail of styles of questions you could also get: refactoring, debugging an open source project, designing an API, extending an existing class. It doesn't make sense to optimize for these, but know that they exist and try to get some "real world" practice as well beyond just Leetcode questions.

Timing

Timing matters. Try to schedule your interviews in a way that increases the chances you'll do well on the ones that matter the most to you - this means I try to leave my favorite companies to last so I know I've gotten as much practice as I can for them. You also want to line up your schedule in a way that you receive all your offers around the same time, so that you can use them to negotiate against each other. The worst thing to have is a single offer that expires before you hear back from other companies, it might force you to take a suboptimal offer out of FOMO or laziness.

For me, this means I try to do all the phone screens up front (in order of least to most desirable company) over 1-2 weeks. Once you start to hear back, try to stall the first few so you can be sure you'll be able to have all the onsites during the same period - ideally over 1-2 weeks as well. Jake's post, once again, covers timing the whole process just right.

Negotiation

Once the offers start coming in, you can begin the negotiation process. All the classic tips apply here, like "don't say a number first", "don't ask for a deadline" and "show enthusiasm and positivity the entire time". @patio11's classic Salary Negotiation post is a must-read for this stage (although you'd do well to read it much earlier) and Zain's post has some great tips as well. I also read Never Split the Difference right before my round of negotiation chats, which although not necessary, helped frame my approach. If you want to brush up on negotiation best practices, these are my notes from the book.

It's expected that recruiters will ask you for your salary expectations, to which you can repeatedly reply that you don't have specific numbers but you know the company - and the other companies you're receiving offers from - are able to give very competitive offers (ie. nudge them that you're expecting something on the high end of your band). Once you've collected all the numbers (again from Jake's post):

Take Tier 3 offers to Tier 1-2 companies

Take the best offer from there back to Tier 2-3 to match/beat

Take this offer back to Tier 1-2 companies

Be sure to also focus on the factors that particularly matter to you. If a company isn't budging on total compensation, see if you can shift the distribution to one that you value more (ie. more equity). Especially as you start to hit the ceiling on companies' total comp band, there can be other factors you're able to negotiate on: "I see you're limited on comp, how is your flexibility on vacation allowance?" (note Chris Voss's classic "labelling" and use of "how" in requests).

You also want to be able to set yourself up for success in your future at the role before you even get there. While deciding between offers, managers will typically reach out to try to sway you. Use that as an opportunity to set expectations for your trajectory in the team, discussing future promotions and how the manager can align your work to enable you to immediately have impact and career growth. You'll already be negotiating your future promotions before accepting the offer. Similarly, I like to set expectations on work style at this point, where the manager is more likely to concede with your soft requests. It's much harder to ask for things like flexible work hours once you've already accepted the offer.

Ask lots of questions to your potential managers before accepting anything. No amount of money is worth working somewhere shitty, especially if you had other options. During your technical and manager interviews, they will almost always ask you if you have any questions in the last few minutes of the interview. Most people squander this opportunity with soft-ball questions meant to just kill the dead time at the end, especially since they're exhausted from just having completed an interview.

Don't leave it up to your tired self to come up with questions on the spot - prepare with your own set of questions that matter to you. Think of a day at your last job: what did you love and hate about it? What does a dream job look like to you? What's your work style like? Use these prompts to figure out what you should seek and avoid in potential companies, and come up with probes for them. Over time I've developed personal red flags to look out for when interviewing, and ask questions that hopefully draw these red flags out of interviewers. I'd rather find them out during the interview than on the first 6 months working there. Some of my red flags: insane work hours, constant fire fighting, lack of long term investing (on tech and otherwise), politics, arrogance/unkindness, high churn, low energy.

Hopefully by the end of this you'll have received not only the best offers each company can make, but you'll also have acquired all the information you need to make the best decision for yourself long-term - financially and otherwise. If there's anything you'd like me to clarify, any suggestions you have or anything I can help with - dm me on Twitter! And if this helps you improve your offers, please let me know.