How to Become a Software Engineer (Really)

Softwaring engineers are both highly sought after and highly compensated. By 2026, this field is expect to grow by 24%. With an average pay of of $103,000 per year, people in this field can expect to live a comfortable life with a steady stream of interesting problems, plenty of remote work options, and consistent job security.

While we’ve talked at length about what to do once you find yourself in the role, we have yet to answer the essential question: how do I become a software engineer?

I have personally interviewed hundreds of candidates for top-tier software engineering jobs and I have heard their stories; everyone from the scrappy teenage hacker to the MIT computer science academic. In this post, we will take an in-depth, step-by-step look at what they all have in common and what you need to do to start a career as a software engineer.

We’ll break this down into a few stages:

1. Do you have what it takes?
2. Education
3. Bootstrapping your resume
4. Applying for jobs

Combined, these steps are meant to provide a high level framework for your journey from where are you right now to your first day on the job. Alone, no step will do your ambitions justice. And while I will do my best to provide helpful links and recommendations, it is ultimately up to you to fill in the details and most importantly, keep at it.

Do You Have What It Takes?

The first thing I tell anyone that comes to me looking to make the switch to software engineering (SWE, as it’s often abbreviated in the industry, pronounced “swee”), is to ask yourself if you’re in it for the right reasons.

Some good reasons may include:

• The desire for interesting and challenging work
• The drive to solve some of society’s most important problems through technology
• The search for a medium to express your unique creativity and hone a craft that is both elegant and practical
• The love for constant learning, practice, and application of said learnings

Some bad reasons may include, but are certainly not limited to:

• The desire for a salary boost
• Thinking you’ll get cushy tech job where you can “phone it in”
• It’s easier and less school than a doctor or lawyer
• To work at Google or Amazon where you can wear jeans and play ping pong

While it seems comical, the reality is that many times during university and on the job I have encountered people who, when asked, reveal that they are actually only there for one of the aforementioned reasons.

They can usually even fake it for a few years and land a decent job for a year or two. Eventually, what ends up happening is that their colleagues and the rest of the industry progresses (usually extremely fast, as is the norm) and they’re left behind trying to rest on their laurels. They then become the worst performer on their team, and when no one can rely on them anymore, they’re quickly canned. Software engineering is undoubtedly a team sport, and no one likes it when you’re consistently the weakest on the team.

While yes, in the short term, you may be able to get that pay raise or cushy tech job, in the long run you’ll be left with no job, outdated skills, and a glaring hole in your employment history.

Nevertheless, let’s say you are in it for the right reasons. You have the motive, but you also need to have the skillset. I’m not talking about being able to code in Javascript or whatever, that will come later. I mean more the certain patterns of thinking or ways of looking at the world that underlies a SWE’s trade. Some of these are:

• There is no one right answer. There are multiple ways of solving every problem, each with their own tradeoffs
• You can think creatively and work to define a solution under vague constraints
• You break down big problems into smaller problems that can be more easily solved
• You value people’s feedback and work to incorporate it into your own thinking

You don’t have to have all of these traits, but if you find that you’re the antithesis of many of these, I would advise you to reconsider if software engineering is the right career path for you. Contrary to popular belief, not everyone can or even should learn how to code. This is ok. Being a SWE is a creative, freeform, and group endeavor. I’ve seen musicians and artists typically have a more natural affinity for the work than accountants and biologists.

This is because many of us are taught, especially in school, to memorize and regurgitate information rather than coming up with a unique solution for ourselves. “What year did Columbus discover America” has a single, memorizable answer (to a degree, forgive me history scholars). On the other hand, “create a tool for getting hot food on a plate” does not. It has an infinite number of solutions that could all work. This ambiguity is scary for a lot of people. Sometimes even paralyzing. If you aren’t comfortable working under this sort of ambiguity, software engineering is not for you.

Despite the media representation of the lone hacker taking down The Pentagon, software engineering is overwhelmingly a team-based profession. Rarely are you ever on a project alone. The majority of your time will be spent collaborating with your peers, discussing solutions, and giving each other helpful feedback. Once your project is released for use, you will have to listen to your users’ feedback and incorporate their thoughts and feelings into what you deliver next, even if it’s contrary to your own gut instinct.

If this all sounds familiar or even invigorating to you, by all means, please read on.

Education

You’ve done some introspection and decided that being a SWE is the right profession for you. Welcome my friend. Let’s now talk about how you go about learning the skills you need to acquire to start writing software that people want to use.

These skills can be broadly broken down into two sets, the theoretical and the practical.

Theoretical

These are the skills and concepts that are broadly applicable to all areas of software engineering and underpin everything we do on a day-to-day basis. These concepts are more formally categorized under “computer science” and are what you would learn in the first few years of a more formal college degree. Just like cooking is applied chemistry, programming is applied computer science. It’s the chemical reactions that make the sauce taste good. Only it runs on your smartphone or web browser.

Things that fall under this category that you might have heard before are:

• Algorithms
• Data Structures
• Object Oriented Programming
• Distributed Systems

All of these are very broad categories and each could be years of study all on their own. So the questions is: how much computer science do I actually have to know to be a software engineer?

Here’s the truth of the matter:

Having a strong foundation of computer science fundamentals will make everything else you do easier to learn and apply. However, only a basic understanding of algorithms and data structures are likely enough to land you an entry level SWE job.

That being said, the deeper your understanding of CS fundamentals, the more efficient you are going to be at learning just about everything in the “practical” realm, because it underpins everything you do. You’ll go from “wait how did it work again?” to “oh of course it works that way” when you read the documentation of some new technology. However, once you have a grasp of the technologies that you are using, you can re-apply the same basic concepts to almost everything you do on a day to day basis.

Where this knowledge will be put to the test will primary be in one place: SWE interviews. Since employers don’t have two weeks to see how you do on a project, they are left with testing you on the fundamentals for thirty minutes or an hour. Even though this has been shown not to have a strong correlation with on-the-job performance, it’s the best companies have and as a result, what you should expect out of a technical interview. But more on that later.

What exactly should you know, and where can you go to learn it? Here’s some brief lists:

What you should know:

• At least one modern programming language and are able to make use of it’s complete syntax
• All common data structures and algorithms. Many of them can be found on this cheat sheet.
• Object-Oriented Programming
• Client-server model

Where you can learn it:

• The Structure and Interpretation of Computer Programs - This is the book I first learned from and what they use to teach in most beginning computer science courses. The first three chapters should lay a solid foundation for other learning. The rest is all extra credit.
• Computer Science Crash Course - Exactly as the name suggests, a CS crash course you could go through in a weekend or two.
• Head First Java - While yes, a book on a specific language, learning Java is a great way to familiarize yourself with Object Oriented programming and static types as a concept and works well alongside the next resource.
• Data Structures - Once you have a decent knowledge from the previous book, this is the ebook you’ll really want to dig into for answers to the question “how does X data structure work and what is it good at?”.
• Introduction to Algorithms - This will take you one step deeper than the previous two books, at the expense of being even more dry at times.

Some of these texts can be daunting to beginners. Don’t let that scare you. You only need to have a working understanding of any of the concepts themselves. When in doubt about a topic, take a step back, look for a YouTube video or blog post that summarizes it nicely, and come back to the text and see if it makes more sense. You can also take an online course in any of these topics, but I have yet to find one that I really liked.

When you begin to master these concepts, you start to see the common threads that run through all pieces of software. Things like runtime complexity, state and complexity management, separation of concerns, etc. You will see everything else you do become easier and just a natural extension of the patterns you’re already familiar with.

Be aware, this knowledge is where I really see most candidates who are self-taught or are coming from a coding bootcamp falter. Bootcamps don’t usually teach much of it because it is hard and can be frustrating to a beginner who really just wants to learn to code. Know that understanding these concepts come with time and experience and will make you a better engineer, but should not be considered a blocker to pursuing more practical knowledge.

My recommendation would be to work on digesting computer science concepts alongside your learning of the topics in the next section. Experience in the practical will help inform the theoretical and vice versa.

Practical

The practical realm is what most people refer to when they say “learning how to code”. This is learning a particular technology stack along with its associated language and trying to make something useful. Sticking with our analogy, this is finding recipes online and cooking them in your kitchen, chemical reactions be damned. This is how many professional chefs learned how to cook, so there’s no reason why you can’t learn software engineering the same way.

Examples of practical skills include:

• The Python language
• How to write an iOS app
• Administering a database

Practical skills are what is valuable to companies and what you’ll be using around 90% of your time as a professional software engineer. They are what the majority of software bootcamps teach and resources to learn them can be easily found online, depending on the specific technology. From there, getting a basic application up and running becomes a matter of understanding the documentation, copying the examples, and tweaking it to whatever you’re trying to accomplish.

That leads us to the question: what language / technology / platform do I invest in first? Herein lies the difficult part of this realm.

While computer science fundamentals are fairly constant, specific technologies change at an extremely rapid pace. What’s in fashion and in high demand one year may be completely out of vogue the following year in favor of the next new thing.

This is why having strong fundamentals is important. If you can learn new technologies relatively quickly, a changing landscape isn’t much of a problem for you. On the other hand, if you spend multiple months learning a specific stack and suddenly the landscape changes out from under you, having to start back at square one becomes a problem. Thus, it’s important to keep working at your fundamentals, even if you’ve landed a comfortable job doing technology X all day.

Regardless, you have to start somewhere. Here’s a break down of a few categories of technologies that will be helpful:

Frontend

Frontend technologies let you create programs that display something on a screen to a user. This includes webpages, mobile apps, and desktop apps. Non-technical people usually have the most exposure to this type of program.

Frontend is rewarding because it lets you see the result of your work very quickly. You write some code, refresh the page or app, and suddenly you see the content you just told it to draw displayed on the page. Do that a few more times, and eventually you end up with a website or a mobile app.

Frontend is usually a great entry point for people that are engineering adjacent, such as designers or product managers, because it quickly lets you build a tangible product and benefits from many cross functional skills such as graphic design. It is also the place many people without CS degrees start, because you become productive relatively quickly with minimal computer science knowledge.

The rate of change of frontend is generally the fastest amongst other technologies, so it’s important to keep up with the latest developments lest you be left behind. Web is even more exaggerated, usually requiring you to combine multiple (usually Javascript-based) technologies for a single project.

Some examples of popular frontend technologies include, as of March 2019:

Web

• React
• Angular
• Vue
• Ember
• Javascript
• Typescript

More examples can be found here. Most web technologies are based on the Javascript language, with the option of writing in Typescript.

Mobile

• Swift - iOS
• Kotlin - Android
• React Native - iOS and Android

The mobile landscape is much less fragmented than the web, dominated by the two big players and their respective languages. React Native tries to bridge this gap by letting you write both iOS and Android apps with web technologies.

Backend

Backend technologies let you write programs that run on the servers that power many frontend apps. Any application that communicates with another device or service does so through another backend application. A backend answers questions like “how does a direct message from my phone reach my friend’s phone?” and “where do my photos go after I upload them to Instagram?”.

Backend engineering is far more diverse in application than frontend. You could be working on server logic, databases, photo or video processing, or hundreds of other unique niches. Thus backend engineers tend to need strong CS fundamentals since they aren’t as tied to any particular technology or framework. Rather, they’re tied to a specific domain area like the ones just mentioned. This also means that backend technology hype cycles tend to be quite longer than those of frontend, so learning a backend language like Java could stay relevant for decades.

Since backend engineers tend to gravitate towards a particular domain as their career progresses, you find a lot more older folks who are highly specialized in their particular niche, a phenomenon not as common in the frontend world.

Some languages that are popular on the backend are:

• Java
• Go
• Javascript
• Python
• C++

Guides to various practical skills are all over the internet in the forms of official documentation, YouTube tutorials, and various books on that specific topic. My recommendation is to pick one area that seems interesting to you and focus on learning a single technology alongside your fundamentals with the goal of writing software that you yourself would find useful. Be it a mobile app, video processor, or otherwise. Just do something that adds value.

Tying it All Up

Any SWE worth their salt would loudly protest when they see that I’m making this arbitrary distinction between “theoretical” and “practical”. As if algorithms have no practical use or writing Java doesn’t rely heavily on CS theory. Both of them go hand in hand and one cannot exist without the other.

Consequently, all learning you do while pursuing software engineering is valuable experience. If you find yourself caught up struggling trying to learn language X, or studying algorithm Y, remember that any particular topic is not going to make or break your career as a SWE. Rather, it’s about sticking with the process and gathering the sufficient breadth of knowledge and expertise to write useful software in a particular domain that other people want to use.

The resources here are also far from comprehensive. They’re only meant to be a starting point for your own self-education. The very top of the rabbit hole if you will. Don’t be afraid to explore tangents, look at other posts or resources, and generally get in the weeds on whatever you find most interesting at the time.

Bootstrapping Your Resume

You’ve gone out, learned a programming language or two, can write a merge sort from scratch, and maybe even a few toy applications. Now it’s time to start writing useful software that you can present on your resume. Before you begin:

Keep in mind, you will never stop being in the education phase. The moment you stop learning about your craft is the moment the clock starts ticking on your irrelevance.

This also means that you shouldn’t feel the need to have a “complete” knowledge of everything in the previous section before entering this phase. You’ll never know everything about computer science or software engineering. However, a good litmus test for how you’ll know when to start really working on your resume is when you first start truly understanding how applications are built and deployed end-to-end. You’ll know when you get there.

Okay, now lets begin. Your goal here is to build up your portfolio of projects and connections to get your foot in the door at a company hiring SWEs. There are a variety of ways to do this:

Build Stuff You Have

The easiest way to start adding projects to your resume is to take something like Twitter or Notes and build a simple clone of it yourself. The utility of such a program is very obvious and requires no additional thought on your part from a product perspective. This is great as a first project since it provides a very clearly defined set of features and lets you practice building something from start to finish.

However, this is the least useful to your professional development. Every bootcamp graduate and college CS student has at least two of these on their resume. Having a resume full of these just places you amongst the average masses.

Build Stuff You Want

I’m sure you’ve been doing something repetitive or annoying, when all of a sudden you think “I wish there was an app / website / service for this”. Good news, you’re now in a position to build this thing yourself!

Applying the skills you’ve picked up since the beginning of your software journey, you can now translate “I wish I had a tool to do this for me” to “I now have a tool that does this”. You do this by understanding what the problem is and how to solve it, deciding what parts of the problem can be solved with code, and then writing code to do it in a fraction of the time. You then use it any time you want without a second thought and share it with others at no cost to yourself. This is the superpower of programming.

During the course of this, be aware of what we call “scope creep”. You’ll start out on day one with an app to feed your cat while you’re on vacation, then a month in you’re working on a distributed system to cure world hunger. Focus on the narrowest possible version of your vision and get that working before any additional functionality. Otherwise you risk spending months on a project, never having anything to show for it because it “isn’t done yet”.

Build Stuff Other People Want

Doing this will truly set you apart from the majority of newly minted SWEs, as well as one other important benefit we will address in a minute. Building things other people want is also the hardest, because it requires you actually understanding what other people want. We have the tendency to build things for ourselves, thinking that obviously others would want it was well. Most of the time, this turns out not to be the case.

To really get product development right, you need to go out and talk to people. Then when they tell you what they think they want, be able to dig into that and uncover what they are actually asking for. Then build it for them, usually a couple hundred times. This is called the product development cycle, and frankly it’s beyond the scope of this post.

I know what you’re thinking: “how am I supposed to do this?”. Well, what if I told you that there is a place where you can jump in on a project that already has users, and has a curated list of the features that these users want? It’s called Open Source.

Open Source Software is software whose source code is viewable by anyone (typically on Github) and is generally free to use. It’s worked on by a community of paid and unpaid developers, either in their spare time or part of a larger company’s Open Source division. To become one of these developers, all you have to do is read through the repository, claim an issue, then start working on it. Once you get it working, the other developers on the project will review your work and give you feedback until it’s ready to become part of the source code. You will have then made your first Open Source contribution!

Open Source is an incredible way to get real work experience without having to go through any interview, as you’re doing the exact same thing a professional software engineer does.

The best part of Open Source though is not the coding you’ll be writing (although that is phenomenal, employers love seeing applicants with Open Source contributions since it lets them look at your work and communication in a public space), but rather the connections you’ll be making. Here’s the thing:

After working on the same project for awhile, you’ll start to become a recognized name in that community. If your work is good, you’ll be recognized as someone who does good work. When the other developers in your community are looking to hire or refer people for a paid job, guess who they’ll start with? You.

The easiest way to get your foot in the door for a software engineering job is not by filling out endless resumes and cover letters then scattering them across the internet. Rather, it’s by building meaningful connections with people already in the industry and getting them to refer you for open positions at their company. Online application portals are notoriously black holes, while every referral I’ve ever submitted has at the very least had a recruiter take a look at it.

So, to summarize: the best way to build up your resume is by building things that you and other people want, while simultaneously building genuine connections with other engineers in the industry that can vouch for you when the time comes to apply for paid positions. I would have at least 2 - 3 significant projects on your resume before applying for any positions, at least one of them being an Open Source project with a significant user base.

Applying For Jobs

Alright, you’ve made it. You learned to code. You built up your resume and networked with people in your field. Now it’s time for the final steps: applying for positions, then interviewing. First, let’s talk about applying for roles, then we’ll move into how to go about interviewing and some general tips.

Where Should I Apply

The best but least helpful answer to this question is, obviously, the company whose mission statement best aligns with your own passions and mission. If you can, by all means do this. That being said, this might not always be an option, especially if it’s your first position as a SWE. Thus, there’s a couple other things to consider.

First is company size. Do you want to work for a startup? Medium size up-and-comer? Large technology behemoth? Your experience as a SWE is going to vastly differ based on the relative size of the company. Here’s some pros and cons of each extreme (in general, keep in mind these will vary in severity from place to place):

Startups Pros

• Less bureaucracy
• More power as an individual engineer
• Work mainly with Open Source technologies that you’re likely to be familiar with
• Smaller codebases
• Fast paced environment
• Larger scope of engineering projects

Startup Cons

• Flimsy if any processes or best practices in place
• Less well-designed code
• Smaller scope of customer impact
• Potentially little time for mentorship in favor of launching new features fast
• Projects and general company direction are susceptible to rapid changes and obsolescence
• Lower base pay and higher equity stake (could be a pro depending on your situation)
• More junior engineers
• Longer hours
• Less perks

Larger Company Pros

• Well-defined processes and coding standards
• Large, mature, and well-designed systems
• Larger scale of customer impact
• Multiple avenues for education and mentorship
• Higher base pay
• Clear career track
• More senior engineers around
• Better work / life balance
• Many perks

Large Company Cons

• Heavy bureaucracy
• Less power as an individual engineer
• Smaller engineering project scope
• Use in-house technologies that may not be transferable to other companies
• Bigger, more complicated codebases
• Slower speed of iteration

Mid-size companies will naturally be somewhere in the middle. Choosing the size of company that best fits your goals and engineering preferences is going to have a immense impact on your day to day work experience. Some people thrive in a fast-paced, unstructured strike team, while others like having the full-force of a tech behemoth behind them, even if it means moving a little slower.

There are also smaller teams within large companies that feel like startups, with their own mix of tradeoffs. The best thing you can do is ask your interviewer when interviewing for a specific team about the aspects that you personally care about.

Second is industry. Technology companies aren’t the only ones looking for engineers. Almost everywhere from banking to retail needs SWEs in some capacity. Places like Walmart or your local accounting firm could be a great place to start. These have the added benefit of being somewhat easier to get your foot in the door since the competition is not as high as a traditional tech company like Google.

The tradeoff here is that non-tech industry companies are not always up to date with the times, so be sure to ask them if they’re using an outdated technology stack before starting. If they are, this will certainly need to be an input to your acceptance decision.

What Positions Should I Apply For

Many people get confused with regards to the distinction between titles containing “Frontend”, “Fullstack” , “DevOps”, and the like. Hopefully after being in the community for a little bit you have a sense of what these are and what you tend to gravitate towards, but here’s a quick rundown in case you don’t:

Frontend / UI / UIE / UX Engineer

You work primarily on frontend web code in Javascript or a related language. You like building beautiful user interfaces and are able to work well with both design (bonus if you have some design experience yourself) and product management. You’re user focused and an advocate for your customers.

Backend / Systems Engineer

You work primarily on code that is not user-facing, powering applications or services that the frontend or other backend systems rely on. You know a systems language like C++, Java, or Go as well as a working familiarity with SQL and databases in general. You’re good at algorithms and general CS theory. The word “scale” is cautiously exciting to you.

Mobile Engineer

Similar to frontend, but for mobile apps on either iOS or Android. You like having a lot of phones around you at all times.

DevOps / Site Reliability / Production Engineer

You really enjoy things like deployment, system monitoring, load testing, and writing bash scripts. You’re generally responsible for the health of the tech stack that your application engineers run their code on. You’re familiar with technologies like Docker, Kubernetes, AWS,TCP / IP etc. You take pride in being the first one called when the site goes down and the last one to leave when it’s back up.

QA / Systems Test Engineer

You enjoy writing excellent test plans and carrying them out. You’re an expert at breaking others’ code and finding edge cases others haven’t thought about. You have a strong product sense and can anticipate the way users might use the product other than how the developers intended.

How Should I Apply

Hopefully this is where you can tap into your relationships with other engineers, but if not, that’s okay too.

By far the best way to get an interview is through a referral. Almost all companies have a referral program where current employees are paid a bonus if they refer a candidate and they end up hiring them. Thus, both you and the referrer have an incentive to get through the interview process, so don’t be afraid to ask to be referred - you’re doing them a favor as much as they are doing you one. This usually guarantees you at least a phone screen with their company.

Networks like the aforementioned Open Source community, Twitter, industry conferences, and local tech happy hours or Meetups are all great ways to start building out these connections. These do take awhile to foster, so a little foresight here goes a long way.

If you don’t have someone who can refer you, it may be useful to try and reach out to the company’s recruiters directly via LinkedIn. “Sourcers” as they’re called are constantly looking on LinkedIn or AngelList for new candidates they can try to recruit for their company. Again, they’re paid a commission if they get a candidate all the way through the process to a hire, so reaching out to them on LinkedIn is essentially doing their job for them. Just look for anyone with the “Recruiter”, “Technical Recruiter”, or “Sourcer” title for the company you’re looking at.

Finally if you strike out in the other three realms, online applications are always worth a shot. Many of them, especially those for larger elite companies, are effectively resume black holes. Although, it’s always worth trying and smaller companies are far more likely to get back to you since they have a smaller number of open positions and generally have a harder time hiring.

There are also things like Google’s Secret Code Challenge and coding competitions like HackerRank that could lead to an interview, but success with them is fairly random and probably not the best use of your time unless you’ve exhausted all other options.

Interviewing

SWE interviews usually proceed as follows once you’re in the process:

Recruiter Reach Out

A technical recruiter or sourcer will reach out to you about interviewing at the company they represent. They’ll give you a little info about the company, the role they’re hiring for, and probably an article or two on a major news site that promotes the company. All you have to do is say yes.

Phone Call With a Recruiter

Your recruiter contact will typically give you a call and ask you a few questions about what you’re looking for, why you want to work at the company, and maybe a project or two on your resume. This is explicitly non-technical; all they want to do is learn a little more about you as a person and screen for any potential behavioral red flags. Stuff like saying “I left my last job because all my coworkers were idiots”. You’d be surprised how often we hear this or other variations. Just be yourself, know a little about the company and their product, and don’t be a jerk.

Technical Phone Screen

Here’s the first time you’ll be asked to code in front of another person. Don’t worry, even after conducting hundreds of these, I still find them scary and intimidating when I’m on the receiving end. Your nerves are perfectly normal and you won’t be penalized for having them.

How this works is your recruiter will give you a scheduled time and sometimes a list of topics to be familiar with (“Know binary search, merging algorithms, etc”), and a link to a collaboration tool like CoderPad. At the scheduled time, a SWE from the company will give you a call and ask you one or two technical questions. You’ll be expected to write the code in the collaboration tool to solve the questions while thinking out loud and walking them through your thought process. More on this in a minute. It pays off to have a hands-free phone set for this, since (trust me) trying to code with the phone pressed between your ear and shoulder is never fun.

The interviewers job here is not to make a yes / no decision on you, but rather to determine if you have a reasonable chance of passing an onsite interview. Thus, the interview is usually a little shorter than what you’ll experience during an onsite, and the bar is somewhat lower.

Onsite

Onsites vary widely depending on what company you’re applying to. The average one in my experience is comprised of traveling to the company’s office (they’ll usually pay for travel, lodging, or both if it’s far), having a short chat or tour with a recruiter, then a series of technical and nontechnical interviews, followed by a closing chat with the same recruiter. The interviews, typically 2-3 one-hour sessions, will consist of coding questions along the same lines as your phone screen, an architecture question, and perhaps some form of behavioral, non-technical assessment.

Offer Decision

Within about a week, your recruiter will contact you about whether or not you get a job offer. If you did not get it, you can typically reinterview at the company once every 6 to 12 months. If you did, congratulations! You just got your first job as a SWE!

How to Interview Well

The best interview advice I can give you is to have a rehearsed processes that you go through for every question. This ensures you hit all the right process requirements without having to worry about them, letting you focus your energy on solving the problem at hand. Some “process” things that interviewers typically look for:

• Think through the question and communicate at least your general approach to solving it before writing any real code. This can save you an immense amount of time going down the wrong hole and will demonstrate to your interviewer that you have a plan of attack and can think through a problem from beginning to end rather than just blindly writing code for a given task.
• Ask clarifying questions. Often interviewers don’t give you all of the information the problem requires, saving some of it only if asked. This extra information usually makes the problem easier.
• Don’t go too long without talking with your interviewer. It’s hard for them to give you hints if you’re just silently staring at the question. Communicate your thought process as best you can, and in return they will help guide you along the right path if you get stuck.
• Communicate tradeoffs and real-world considerations. You may write a solution that has O(n) theoretical complexity and constant space, but on the job you may be okay with a O(logn) complexity with O(logn) space. Let them know you’re thinking about these things.
• Pick a language that you know inside and out. Most interviewers will have a working knowledge of the most popular languages, but showing them you know some esoterica is a strong signal that you’ve taken the time to really know your tool of choice.

This is far from an exhaustive list, but these are some of the common things myself and other interviewers I know generally look for, aside from just “getting the question right”.

On that note, yes, getting the question right is important and in many cases basically a free pass to the next round. Most interview questions are designed to have multiple parts that progressively get harder, so it may be more about how far you get in the progression. That being said, it isn’t everything. If I have a candidate that gets 75% of the way there on my question, but demonstrates all the aforementioned items, I’m very inclined to still give them a “hire” rating. Writing code on a whiteboard under a time limit is far from everyday, real-world conditions, so I like to give folks a little leeway if they still show the proper attitude, mindset, and process.

He’s a sample process that I personally use when interviewing to cover all these bases:

1. Read the question and repeat it back to the interviewer
2. Ask any clarifying questions regarding edge cases, real world considerations, or anything else that comes to mind
3. Start to think of a solution to the problem. Mentally run through all my major data structures that may be of use.
4. Once you come to a general approach, verbally communicate it to the interviewer. Consider and incorporate any feedback, as well as it’s eventual runtime.
5. Write a few test cases that I will use to verify my solution
6. Code up a solution (this will take the bulk of the time)
7. Write out any error handling or base conditions
8. Run through my test cases to confirm the solution works

This isn’t the only process that works and you’ll need to find what specifically works for you.

Let me be honest with you:

It’s going to take quite a few interviews to get fairly comfortable with the technical interviewing process. You’re essentially putting on a performance under inaccurate conditions that in many ways decides the track of your career. No one likes this.

Plan on doing a few practice interviews before doing any real ones. Also, try to schedule some lower-stakes interviews at companies that you may not be as interested in before your top choices so you have some additional practice. Books like Cracking the Coding Interview and sites like HackerRank are a great resource to practice these types of questions with on your own time in a simulated environment.

After awhile, you’ll start to feel more comfortable and confident within the process. Until then, just keep at it.

Conclusion

Once the interview process is over, hopefully you now have at least one offer for a full time software engineering role! Congratulations on your new craft, and welcome to the beginning of your (hopefully) more interesting, fulfilling, and lucrative career.

At this point, I would absolutely recommend negotiation for whatever you can, but that is a whole other blog post.

Hopefully this guide has been a valuable outline as you navigate the unfamiliar world of professional software engineering. I will try to update it as much as I can to fill in the details and day-to-day resources that will help you progress through the various stages we talked about.

I hope this opens some doors for talented people who may otherwise not have had access to guidance or mentorship as they navigate the, at best, rigorous and competitive, and at worst, privileged and elitist, field of software engineering. All the best.