This document is intended to provide concrete, helpful advice for people entering into the software engineering industry who do not yet have recruiters stuffing their email inboxes.
When I say "top-tier" in this document, it's meant solely to refer to the relative level of compensation between companies for tech employees. It's not meant to imply any sort of qualitative or moral difference between them, or even imply that working for a "top-tier" company is better than working for a non-"top-tier" company. It's just shorthand for compensation.
Due to various social, economic, cultural, political, and bullshit factors, the tech industry has several clear tiers in terms the the quality of positions that can be obtained in the field. This isn't fair, it doesn't make sense, and it sucks, but my goal with this document is to inform you of the way I see the industry, and make sure you have the right information to make informed decisions about your career.
In the United States, you can be a Java engineer for a local insurance firm and make $80,000/yr. Not a bad salary at all, by any means. With very similar skills and experience, you can write similar Java code for a larger, well-funded company and be paid $250,000/yr or more. Jobs are more than their compensation, but you should be aware of the wide disparity. It's very easy to not know about opportunities on the top end of the scale, much less how to find them and how to receive an offer.
For entry level positions, a number I've seen floating around lately is $170,000 USD/yr total compensation. This vibes with what I received as a new grad, and offers I've seen from my previous employers to new grads, but I'd say anywhere there +/-15% would be what you'd expect from a top-tier entry-level offer.
Historically, these salaries were only available in the Bay Area, and to a lesser degree other US tech hubs such as Seattle and New York City. That's still fairly true, but with the advent of remote work, a very common strategy is to stay where you are, but work remotely for a company that pays a high salary. Generally they'll pay you 15-20% less than if you were in San Francisco (because, y'know, the same person magically changes value when they move for some reason), but that lower salary is still usually much better than competing local companies in non-tech hubs.
Of course, new tech hubs are growing, and large multinational tech companies have presences in places like Dublin, Ireland; Milan, Italy; Tokyo, Japan; Singapore; etc. Suffice it to say that if you're not based in the US the opportunities are probably more limited, but they are still available, generally.
Once you've had your first job making a large salary at a well-funded tech company, it's generally easy to keep your career at that level. Everyone you work with will be looking for jobs with similar or higher salaries, so the referrals you get through your network will be highly compensated. Recruiters from these companies know which other companies have similar profiles to their own, so they reach out to you more often. Plus you have the confidence to know that you were paid that much once, so you can point-blank ask for that salary without blinking when a new company comes knocking on your door wondering if you'd like to work for them.
It is worth noting that it does not work in reverse. That is, you don't need to get your first job out of college, or your first job in the tech industry at a top-tier company to make that salary. It often takes people 3+ years before they get and pass an interview at a top-tier company. That's totally fine. Over the course of a 30 year career, or even a 10 year career, that's not a massive difference. There's no point at which you have to give up, and with the right amount of effort toward studying to pass weird bullshit interviews, your chances are very good that you'll get into a top-tier company. If it's a goal you want, getting that $200k/yr+ offer after 5 or 10 years is better than never getting it at all.
So don't stress yourself out and push yourself to the breaking point. If you have a stable job and you're not in dire financial straits, take as much time as you need. It's also possible to transition to this type of career later in life at 40 or even 50 years old. The tech industry is extremely young and likely will continue to be that way for a variety of reasons, and half a career's worth of experience in another field is worth a ton to many tech companies.
So, given that we do want to get a top-tier offer, how do we get that first position?
There are three primary steps to getting a position at a top-tier tech company.
- Identify whether a company is offering the level of compensation/benefits you want.
- Get past the resume filter and be offered an interview.
- Pass that interview process.
Now, I don't recommend preparing for each step in order. Step 3 requires by far the longest amount of prep time to be successful, and is the highest stakes part of the process, so it's worth preparing heavily for step 3 before you embark on steps 1 and 2.
It's not just FAANG (or I guess MANGA now with Facebook becoming Meta) companies that offer these salaries. Smaller companies in the Bay Area and on the international stage have to compete with these companies for employees. They might offer 10-20% less, or be missing some nice perks, but at high levels of compensation that doesn't really matter all that much.
Use sites like Levels.fyi, Payscale, Glassdoor, etc to look at salaries. Levels.fyi tends to be most accurate for the tech industry, because many sites just report averages across jobs, which makes Amazon look like they pay very little because they employ so many warehouse workers (and they do, in fact, pay those employees very little). But as a software engineer or tech worker, Amazon offers you compensation extremely competitive with other top-tier tech companies.
Reach out to people you know in the industry and ask them what their company offers for an entry level software position.
Reach out to recruiters on LinkedIn for various companies and ask the same question.
Email recruiters' emails from LinkedIn, it's often easier for them to respond this way because they have a ton of helpful automation tools for their job.
Recruiters may refuse to give you a range because they don't want to reveal too many details, but generally if you ask "is it over $130,000/yr total compensation" they will be happy to respond "yeah, of course" if it's a top-tier company.
Look at job postings available for Denver, CO or (soon) California, because they are required to post salary ranges.
Look at the most recent Hacker News "Who's Hiring" thread, often posts there include salary ranges. (example thread).
Also, levels.fyi has a "still hiring" page for companies which is theoretically kept up-to-date: levels.fyi - still hiring
Once you've identified a few companies that don't seem totally awful to work for and are in your desired compensation range, you've gotta get an interview.
Nothing I write here will be mind-blowing, but it's worth being written because not everyone will have access to the same information at the same points in their lives as everyone else, and if you learn anything at all from this document, I will have succeeded.
In order of personal preference and estimation of effectiveness, here's what I recommend.
- Get a referral from someone currently at the company. See if anyone you've worked with before, any of your college friends, or extended personal network works there. Have them refer you. Generally this is zero-cost (or beneficial) for the referrer, and gets your resume instantly past the resume filter and on to the interview stage.
- Reach out to recruiters' work emails by finding them on LinkedIn, search engines, or the company website. Include your resume and ask for an interview. This is surprisingly effective. Recruiters are essentially paid to find people to recruit, and if you reach out to them you're doing a chunk of their job for them.
- Use online portals to apply to as many companies as possible. This is mind-numbing, but it's very low-effort. Put on a podcast or TV show and dump like 100 applications. Hopefully you get like at least 5 responses.
There's certainly more that can be written here but I've only started my career once, and the above 3 worked for me, so it's a little hard for me to keep trying new things.
Once you have one or more interviews lined up, you have to pass them.
In my experience, once you're in the interview stage, your resume matters a lot less. People will primarily judge you on how you perform in the interviews (at least for junior and generalist positions, specialist roles may be different). I've never heard someone in an interview decision room say something like "oh, they did well on the interviews, but their GPA was low/their school isn't prestigious/they don't have a bachelor's" or conversely "oh, they performed kinda poorly, but they went to an Ivy league! we should probably hire them!"
That's not to say it doesn't play a factor. It has some effect behind the scenes both explicitly and due to implicit bias, and every company or interview process is different, but in my experience the resume gets you the interview, the interview gets you the job.
The following sections outline what to expect for the interviews and how to prepare for them to have the best chances to pass them and receive an offer.
The tech industry is large and there are many styles of interview. Generally though, they follow a pattern established by Google and other large tech companies, and you'll go through the following stages.
-
First, you'll talk to a recruiter and go over some job details and your personal work history, and you'll both think about whether it's a reasonable fit. For most generalist software engineering positions, this is mostly a formality, but for more specialized roles this is where you're both trying to figure out if you mean the same thing when you say "systems engineer" or "security engineer".
-
Then they'll schedule you for a phone screen. This is generally a technical interview that attempts to test your programming skills. If you pass this, you move on to the next step.
-
They invite you to an "onsite". In the heavily remote post-COVID world, this may or may not actually mean they fly you out to their main office (it used to mean that). It might just be over Zoom or whatever. This is generally 4-5 45m-60m interviews that further test your programming skills, as well as related relevant career skills. You'll generally need to pass all but one and get close on that last one, with some wiggle room in either direction for especially strong or especially weak performances in individual interviews.
-
They want to give you an offer, and you negotiate. At this stage, you should ask to have lunch with the team, visit the office, etc. and try to figure out if it's really a good fit for you. But for someone just starting out their career, it's of course probably going to be very exciting to have a piece of paper in your hand that says someone wants to give you hundreds of thousands of dollars.
-
You accept the offer, process employment documentation (and visa stuff if necessary) and you start work!
A very, very brief overview of the types of interviews you'll see.
An interview question may have multiple parts to it, so if something looks too easy at first, it probably is. Generally once you finish the first part, they give you the second part, and so on. Often these are structured so that a passing candidate finishes part 2 successfully, but there's a part 3 that if they finish it, they're very strong.
These will be essentially exactly like leetcode or hackerrank problems. You will be expected to write code that solves the given problem and fits within the expected time and space complexity.
These interviews are extremely common among FAANG/MANGA companies, and at those companies they are used almost exclusively.
This will look a lot like a leetcode or hackerrank problem, but your interviewer will explicitly tell you that they don't care about algorithmic time/space complexity. You just need to focus on solving the problem at hand. These are usually multi-step problems, and you usually get extra points for clean code, clear functional boundaries, good variable names, writing comments and tests, etc.
These are similar to the Programming Exercise problems but they generally involve interacting with some specific external state. You might have to hit an API, or store data in a file, or set up a webserver, or something like that. For this you'd generally have access to whatever language, libraries, and packages you want to use. This is where it pays to be comfortable with libraries like Node, Flask, Requests, SQLite, and whatever else.
These types of interviews are more common for smaller startups, or companies with a more "practical" or almost anti-academic kind of viewpoint.
This will often look like the mini-project interview, but typically a bit larger in scope. They give you an assignment, and you have maybe a week or two to complete it at home without supervision. Sometimes there's a timer when you start and you have 1-2 hours to complete it. Sometimes they'll require to use the shitty test-taking software that records your room while you do the exercise. Sometimes it's a larger task that might take 1-2 days to complete. Once in a while, a company will even give you real work, and they plan on using the resulting code, but they don't tell you that.
In any case, it's just a mini-project you do on your own instead of in an interview setting.
This is the interview where someone (typically your potential future manager) sits down with you and has a chat about projects you've worked on, where you've been, and where you want to go.
Generally this is not a make-or-break interview, but a strong performance here means being able to speak in-depth about anything listed on your resume. Interviewers are looking for where you sit on the spectrum of "were they on the team that made this product, and like, contributed when given specific directions" versus "they really know this project inside and out, and if they didn't lead it, they probably could have if they needed to".
It also pays to do some classic interview preparation, like having a story in mind about a "time you faced a challenge at work" or whatever. Be prepared for them to drill deep, so it's best to pick something honest, but it can sometimes be helpful to make up a fake event as a sort of chimera composed of real events you experienced.
These include things like:
- frontend interviews where you have to build a React component
- CTF-style red-team exercises, data analysis case studies
- systems/architecture design problems
- etc
If you want to specialize into a subfield, you should find more resources about the interviews that might show up for that subfield. I really only have experience with systems/architecture design problems personally.
With many of the above interview types, they may give you an execution environment (either you bring your own computer, they loan you one, or they use something like coderpad.io or repl.it so you can actually run the code you write.
In this case, run your code early and run it often, verifying correctness as you go. If you forget the name of a function or something, ask your interviewer if you can Google it. Usually this is not a problem, the point is not to "get" you for forgetting a function name or what module something lives in.
You may also be asked to write it on a whiteboard with a marker (ugh) or in something like Google Docs (somehow even worse).
In this case, your code doesn't need to be perfectly syntactically valid. You don't even need to write in an actual programming language. You will need to leave extra space on the whiteboard in case you need to go back and add a new line. It's easy to forget, but try to leave space between each line so you can add more code if you need to.
In broad strokes:
- Learn Python or JavaScript if you don't already know one. Possible via CodeCademy, LearnPython, exercism or whatever else.
- Read Cracking the Coding Interview by Gayle Laakmann McDowell. Maybe read it front to back 2-3 times.
- Practice interview questions on LeetCode and HackerRank to prepare for the "traditional" algorithms-focused interviews. Generally top-tier companies give something between a Medium and a Hard on LeetCode, so make sure you're confident you can pick an arbitrary problem of that difficulty and complete it.
- Work on toy personal projects and on sites like Exercism to get comfortable with things like webserver frameworks (Flask, Ruby on Rails), HTTP libraries (requests), storage libraries (SQLite, PostgreSQL, MongoDB).
Beyond that, there is more out there written about passing these interviews by people way more invested than I am.
Here's a few links I found with 10 seconds of Googling:
- https://github.com/yangshun/tech-interview-handbook
- https://github.com/jwasham/coding-interview-university
- https://github.com/Olshansk/interview
- https://github.com/DopplerHQ/awesome-interview-questions
- https://github.com/TSiege/Tech-Interview-Cheat-Sheet
These languages are very expressive with relatively little syntax, which is what you want in a time-pressured environment. The costs of these languages include becoming unwieldy in large codebases and potentially running slowly, neither of which matter in an interview context.
Almost every company will let you use Python or JavaScript, compared to something like Ruby, Haskell, or even Java which just depends on whether or not they have someone on staff that uses that language.
I have watched candidates with 10+ years of C++ experience fail interviews because in C++ it's pretty normal to spend 40+ minutes writing code to load a file from disk and parse it. I've actually never seen anyone pass a C++ interview that required code execution (sample size of ~5 though). By comparison, opening and parsing a JSON file in Python takes ~3 lines of code, and a candidate that gets hung up on that is almost certainly not going to be able to do well on the rest of the interview.
Java can be fine if it's by far your most comfortable language, but similarly to C++ I've seen many strong candidates run out of time simply because they're setting up classes and remembering which set of dozens of verbose method names they need to call to do something relatively simple. You want to make an HTTP request? Great, get a ClientFactory, make a client, set its parameters, make a request object from a RequestBuilder or RequestFactory, pass it to your Client instance, and then get a null pointer exception and not be sure why. This is again ~1 line in Python.
Nothing above is meant to be an indictment of other languages (although implicitly nullable types can die in a fire please and thank you). It can be difficult to open a file in C++ because you're specifying exactly what you're doing with memory and manually opening and closing file handles. That allows you to do some extreme performance tuning. Java makes you set a dozen variables because it wants you to explicitly think about edge cases so that your code is less likely to fail in the future. These languages just aren't great for interviews.
You should always use the right tool (read: programming language) for the job, and for interviews, currently that's Python or JavaScript.
If an execution environment is available, make an effort to run your code often just to verify it's doing what you think it should. Add print statements to look at values. If you write a whole solution and run it once and it doesn't work, great, you have to find your mistake at the end of an interview in all the code you've written. If you run your code after every 2 lines you write, you'll find errors much more quickly, and they're all but guaranteed to be in those last 2 lines.
This is also often good advice for writing code outside of interviews as well.
I've seen so many candidates use "pointer", "pointer2" and "inner", "outer" for loop variables, or 3 different variables called like "sum", "total", and "running_total" and get tripped up by using or modifying the wrong one.
Using clear variable names leaves a good impression, but more importantly, it's easy to think because the code will be thrown away that it doesn't need to be "maintainable" and you can give everything a single character variable name. Turns out, people write bugs in interviews all the time, and the same things that prevent bugs outside of interviews also prevent them inside interviews.
Many interviews are something of the form "given a structured file like the following:
A: 1234
B: 2345
C: 3456
do some stuff with the file's inputs and return a thing"
Loading the file and parsing it can take a deceptively long time. There are a million ways to typo and write something buggy that looks functional but breaks on every other test case.
You should consider beginning with structured data and just verbally tell the interview "I want to focus on the main problem first, and if I have time later I'll go back and actually complete the parsing."
Then you can start with some structured input like:
class InputLine:
name: str
value: int
def main(inputs: list[InputLine]):
...
which frees up a lot of mental overhead compared to if you do a quick parsing job and you're trying to access the second line's name by typing parsed_input[1][0].
If you run out of time when doing this and you regret not doing the parsing, don't, because you just would've spent time on the parsing and gotten less far on the main problem where they're really trying to evaluate your abilities.
I have had to fail candidates that were probably strong programmers just because they fiddled with opening and parsing a file for too long and they didn't have enough time for the core of the problem. I just didn't have enough information about their thought process and abilities to say they passed the interview. Don't be that person.
After you finish a part, briefly mention some test cases and write them down. You don't have to set them up and execute them, but just saying "oh I'd test for case sensitivity, null input, an empty string/empty array", etc and writing them down with bullet points without being prompted can take you from a decent candidate to a strong candidate instantly.
If you're sure there's no additional parts to the question, consider taking the time to actually set up the tests and run them (if you have an execution environment available). It's usually very strong positive signal if a candidate is unit testing in an interview.
It's also a good habit to get into more generally.
- CS Career Hub - great place to ask people for advice and find information from real humans
- See the rest of my advice here