Every year, there are thousands of people who spend a lot of time and effort trying to get a software engineering job in North America. Companies such as Apple, Tesla, eBay, Google, or Amazon received thousands of applications for these positions, but only very few are chosen. Tier 1 tech companies are known for (and often inappropriately boast about) their <1% acceptance rates.
The question is, do you have what it takes to get a software engineer job - whether you're a CS graduate, a bootcamp grad, self-taught, a graduate student, or front-end developer looking to move into more back-end software engineering.
Over the last 20 years, we've found that, especially in the US, most candidates who apply for software engineering jobs, or even internships or apprenticeships, are not actually ready for the position: they don't have the experience, the technical knowledge, a strong technical portfolio, and they don't interview well and thus don't get job offers. We've successfully built programs where alumni are at just about all major Tier 1 tech companies on a consistent basis, in California, the toughest talent market arguably in the world.
Top-level tech companies, and even smaller companies, demand a high level for entry-level jobs. Doing a CS degree doesn't cut it in the big leagues.
Companies are de-risking and looking to hire capable candidates: you either recognize this and adjust your game, or you keep applying to hundreds of jobs and wonder why you aren't getting offers.
Here we analyze what it takes to get into a job as a software engineer at a Tier 1 tech company.
Link to Real Job Descriptions Examples
It's the 13th of August, 2020, and I've just pulled a collection of job descriptions from the internet on software engineering internships, junior software engineer, and software engineer positions. You can do an equivalent search by typing "software engineer intern" or "junior software engineer" into any standard job search site.
Since job postings come and go, here are quick links to PDFs for each site we looked at:
- Tesla's Autopilot team
- Capgemini Consulting
- Amazon example 1
- Amazon example 2
- Trip Advisor
A few notes:
- There are hundreds and thousands of such job descriptions for other companies and software-related roles, but we find that they are quite consistent in what they're looking for when it comes to hiring for software engineers. Perhaps later we will do a deeper data analysis on entry-level junior software engineer positions in another blog post, but 20 years of experience and hours of sifting through job descriptions and resumes will do for this post.
- There is a difference between full stack developer, frontend developer, software engineer, and data engineer positions. We're focusing on software engineers in this post.
Part 1: Basic Technical Knowledge and Programming Languages
Let's look at the job descriptions and see what programming languages and technical knowledge these companies are looking for. Here's a summary table:
|Writes quality code||x||x||x||x||x||x||x||x||x|
There are some interesting things to note here in these job descriptions:
- There are quite a lot of things in common
- Architecture, large-scale or complex software experience, writing quality code, OOD, data structures, and C/C++/Java dominate the table and most job descriptions
- Few software engineer roles require front-end technologies - at big companies, if they want front-end skills, they hire a full stack developer or a front-end developer
- Companies are looking for at least some experience, likely because they don't want to train noobs who have no experience
All of the major items that companies are looking for are things that you will not learn in a lecture, via a MOOC, or at a bootcamp.
We cannot stress this enough - architecture decisions and design, experience with large-scale or complex projects, how to write quality code, OOD, and "experience with" or "expert in" C/C++/Java are all things that you have to learn by experience or learn by doing. That is why Qwasar is built the way that we are (and we haven't even started talking about the soft skill part).
Part 2: Translating "Experience With" Into What Hiring Companies Really Mean
One of the most frustrating parts of some of these job descriptions is the ambiguity around what they mean when they write thing such as "experience with C/C++" or "familiar with software architecture." Let's look at a few examples from these job descriptions and translate them into more concrete meanings to understand what companies are looking for.
"Code high-volume software using primarily C++ and Java" (Facebook)
This translates to: we expect you to be able to code a significant amount per day, that said code is written to a norm consistently, that it is well structured, that you don't have God functions, that it can withstand a huge number of users and thus is not slow or poorly designed/written (and thus you understand memory management and allocation most likely), that you understand and can exploit the power of a lower level language, that you know both C++ and Java, and that you code efficiently. You need to be able to hit the ground running from Day 1.
"1+ years of experience contributing to the architecture and design (architecture, design patterns, reliability and scaling) of new and current systems" (Amazon)
This translates to: we expect you to actively give sensible and implementable suggestions to meetings and discussions about software architecture and design; meetings aren't for you to absorb and learn only, but we expect you to contribute. You need to be able to identify architecture options and non-options, trade-offs, which languages and frameworks to use for a given architecture, the advantages and disadvantages of various choices in language/architecture, how to go from 0 architecture to a new, high-volume or high-use sustainable architecture. You can quickly read and understand a code base to get a foundational understanding of the architecture of our current systems.
"Strong hands-on experience with debugging and analyzing crashes or core dumps" (Apple)
This translates to: if you haven't designed, written, debugged, and pushed code to production to a norm and at a professional, client-ready standard, and already learned the pain of debugging, then you're not ready for this job. We expect you to be a structured problem solver who efficiently solves debugging problems and who uses crash reports or similar to identify when there is a bug. You need to be able to: ask for the right data, identify when a bug happens or under what circumstances or common variables, break down the problem into potential error areas, prioritize the possibilities for where the error might be, methodically test code or go through it to find the potential bug, find the bug(s), and fix the bug, knowing that any fixes must be tested before deployment and must address any and all dependencies with other code. We're looking for people who are problem solvers, who do not give up when there is a problem, who know how to become unstuck themselves when they don't know how to fix something, and who work in a team to identify and solve the problem together.
Part 3: 6 Quick Questions to Figure Out if You're Ready for Jobs/Internships
Now that we have a collection of job descriptions, some straightforward technical skills, and a translation of what companies are really looking for, it's time to ask: do you have what it takes to get a job as a software engineer?
Here are some starter questions to help make such a determination. We're working on more robust version of this in an upcoming blog post (stay tuned)
- Have you previously coded more than 10,000 lines in C, C++, or Java?
- Do you consistently write code to a coding norm?
- Have you designed and built an architecture and code base for a project that could withstand more than 50,000 users simultaneously?
- Have you translated project descriptions or tech specs into an architecture, set of functions, and code base having also chosen the programming language(s) for more than 5 projects?
- Can you recode a memory allocation function in 3 hours or less?
- Does your technical portfolio include at least 3 projects that communicate the depth and breadth of your coding experience, show that you have experience with the software development cycle and with architecture, and that your code is at professional, client-ready standards?
(We'll develop a more robust set of questions in another blog post. Consider these 6 a start for now!)
Conclusion: Patterns and Trends are Clear, Now Adjust Your Strategy
In many ways, it's encouraging that there are trends and patterns in job descriptions for software engineering, because it's easier to identify what you need to do or learn, make a plan, then execute it in order to better position yourself for such jobs and improve yourself as an applicant.
Further, the fact that the vast majority of what companies are looking for are things that are learned by doing means that there is hope for just about any learner - you don't need to go to an Ivy-league university or get a Master's degree in order to learn these things (on the contrary, degrees and passive learning won't help that much).
Industry has been "announcing" for years what they are looking for in their engineers. Now it's up to you to ask yourself, what am I missing and how do I fill those gaps? Where can I learn what I need or get the software experience to prepare myself?
***In case you missed it, the entire Qwasar Software Engineering Program is designed to address all of the major items that employers are looking for, from technical skills to software experience to debugging and more. It's an elite and comprehensive program, but one that undoubtedly prepares you for industry, and top-tier tech companies at that. Look at the curriculum, look at how learning happens, and you'll see that it aligns very well with these job descriptions.
We want you to have the best opportunity possible!