On my journey to becoming a software engineer without a college degree, I encountered generous individuals who went out of their way to assist me.
I am not a self-made man.
To get to where I am, I had to stand on the shoulder of giants. My goal in writing this post is to attempt to give back.
Software engineering has changed my life in every way possible. Not only am I able to provide my family with a remarkable stable life I’m also doing work that challenges me and that I find purpose in.
I tried to interlace my personal story with tips, often bolded, to showcase exactly what I went through and to provide you with a way of navigating all of this brain dump.
I also pulled inspiration from all of the interviews I’ve conducted throughout my software career.
My goal here is not to motivate you but to show you that I’m not unique in any way and that all of this is possible should you choose to follow this path.
I hope you enjoy it. 🙂
What I wanted to do when I grew up changed with the passing of every season.
I first wanted to be a soccer player, then a chef, pilot, theoretical physicist, astronomer, CIA agent, investment banker, cosmologist, venture capitalist, and more. Many more.
There was just way too many exciting options to settle down on just one!
Photo by Yoyo Hins
In high school, I found my true love; creating things.
I built a fitness website, a stock trading community, a news site where the news was written, curated, and reviewed by users, and an online book community with a monthly new book release.
I loved every step of creating new ventures, whether it was building out websites, taking care of the legal side of things, customer service, and even accounting!
But what happens when you’re in your late teens, have no clue what you want to do or where to go, and your family expects you to follow the standard path?
You do what most do.
You apply for college and hope to land a fantastic gig.
I chose to pursue a finance degree, primarily because that was my father's field, and I wanted nothing more than to make him proud. I also had a natural inclination towards it.
Throughout college, I continued building side projects. That remained a constant for me.
To keep a long story short, which I will write about soon, I was presented with a great opportunity and decided it was best to put school on hold. During this period of my life, I learned far more than school could have to offer.
I understood its purpose and stranglehold in much of adult life, but I struggled to see its value.
And so, I pursued multiple endeavors and kept on building my life’s resume, which all ultimately led me to take a hard look at software engineering.
Photo by Clement Helardot
Since my early teens, I have been fascinated by computers and the internet.
I loved tinkering around with WordPress and fiddling with all of the PHP goodness that I didn’t understand a lick about. I loved writing unsementic HTML and sprinkling in some terrible CSS hacks.
I never thought about it from a career perspective and didn’t associate building apps with a profession. I was just oblivious to it all. But I always wanted to learn how to program.
Like many of you reading this, I was bombarded, out of seemingly nowhere, by all of the coding boot camp advertisements. I mean, I had never seen anything like it.
I also had a difficult time believing all of the hype.
Do you mean to tell me that I can attend a boot camp for 2–3 months and land a $70k+ job? Some even claimed six figures!
What world was I in that that was all it took?
By this point, in internet years, I was already a vet. I knew that learning something as elusive as programming to any satisfactory proficiency in a couple of weeks wasn’t realistic for most people.
I decided to attempt instead to teach myself how to program; Udemy, the place where all of our half-completed purchased courses live.
I spent so much time mindlessly hunting for information, hoping that I was learning the right thing, skipping the “hard” stuff, and bouncing from tutorial to tutorial.
The problem with learning something yourself is that you have no clue how to optimize your time.
You don’t know if what you’re even learning is necessary or if you possess the suitable mental models to understand what you’re being presented with.
Amidst all of this chaos, I found Launch School.
A place that never claimed that mastering programming fundamentals would be easy. They tell you it’s hard.
They borderline attempt to get you not to sign up because it will be hard and will take a long time. It is a place that prides itself on not messing around with the latest frameworks/languages but with the pursuit of what matters — the fundamentals.
This was music to my ears.
And so I gave the program all that I had. I went above and beyond in every which way possible.
I put in thousands of hours and tracked every minute of it with the help of a mobile app.
What gets measured gets done.
All of this isn’t to say that you can’t learn programming on your own or with the use of some open-source resources, such as Free Code Camp or The Odin Project.
The fact of the matter is that many people do! Many people don’t have the means, so they have no other options.
My only advice is to try your best not to get caught up in the “learn quick and get rich” schemes, focus on the fundamentals and not on the latest frameworks, and don’t give up.
I would also air on the side of following one of the stated resources above because they’ve been battle-tested and because you don’t know what you don’t know.
Photo by Nihal Demirci
You might require less or more time on this step than others.
Learning to program is usually very different from anything else you’ve ever had to do, so it takes some time. Just keep your head up high, take breaks when you need, fail, ask all of the questions in the world, fail some more, keep building up your patience levels, and again don’t give up.
I promise you that you can do it.
I’ve seen every possible kind of person learn how to program.
You can too!
Mastering the fundamentals of programming armed me with the confidence that I could learn any technology put in front of me.
It empowered me to believe that I could tackle engineering problems well beyond my years. Confidence combined with the discipline required to learn programming is a dangerous combination.
And so, together with my two best friends, whom I met through programming, and with the guidance of Launch School, we decided to build a solution to tackle failures in distributed systems.
Here’s our white paper where we explain the problems and solutions in-depth.
Building a project where you showcase your technical knowledge is of the utmost importance.
It’s where you get to shine.
It’s what you get to talk about during your interviews. So definitely spend time here.
Most people build simple rudimentary apps, think todo apps or clone of this and clone of that. I recommend that you spend some time here researching exciting and challenging problems and tackle one of them if you believe you can do it.
There’s no need to write thousands of lines of code here. Some of the most interesting projects I’ve ever seen are pretty simple.
They allow the problem to speak for itself.
There’s also no reason to pick an extremely hard problem. Keep it manageable.
You also want others to understand the problem you’re solving, and if what you solve is very niche, then no one will be able to relate.
Lastly, I recommend that you take some time to write an in-depth technical case study where you walk your readers through the problems you faced and how your solution fits into the grand scheme of things.
Most people will never take the time to look at one line of your code, but they will take the time to scroll through your write-up. So package all of that information in a neat and organized format.
Make it pretty because, as you might know, or will learn through your software engineering journey, you can have the best code ever that solves a significant problem, but if your UI and UX are subpar, people will probably leave or look for alternatives.
This is an area where you’ll have a high return on your time investment.
Photo by Yannick Pulver
I spent a few weeks on and off practicing algorithm problems from Leetcode because a few companies enjoy torture and make you recall how to reverse a binary search tree on the spot.
I didn’t get hung up on this portion, though, because I knew that no matter how much time I spent here, there was no way I would ever become as good as I would hope to be, and it just wasn’t exactly where I shined.
Also, quite a few of the companies I interviewed at either had no Leetcode gotcha style questions, had take-home projects, or asked me to talk through a project I created in the past in depth.
Part of this entire process is learning how to prioritize your time best. Certain activities will yield greater returns than just solving hundreds of Leetcode problems.
However, it would be best if you still spent some time here.
Moreover, whenever solving problems, try and talk through your thought process and, if possible, try and solve these problems with a friend who will act as the interviewer.
The goal here is to simulate the same conditions as an interview.
I’m a big believer in what the Greek poet Archilochus once said:
We don’t rise to the level of our expectations; we fall to the level of our training.
You don’t want to show up to an interview and forget how to map through an array…
Some companies also ask system design types of questions. The resources I found best for these types of interviews were:
Most companies I went to never had me do a systems design interview, but knowing how to theoretically design some of the more complicated systems out in the world today will make you a much better engineer.
It will also give you a lot of confidence walking into interviews.
You also want to practice answering behavioral types of questions, e.g., tell me about a time where you had to overcome adversity, or what are you looking for in your next role?
I researched these types of questions and answered every single one of them. I even wrote my answer down to a lot of them to engrain the answers in my head.
Again, we fall to the level of our training.
You don’t want to show up unprepared and make up a lie to these questions on the spot. So take some time to think about scenarios and have a shortlist of examples you can always fall back on.
These questions will always repeat during interviews or be a variation of a question that you saw earlier, so I found it helpful to have a list of real-life scenarios that I went through to always tie things back to those examples.
Photo by Caleb McLean
After entirely devoting a year and a half of my life to learning programming, I was ready to hit the job market in full force.
I spent time crafting my resume to showcase all of my skills and highlighted my achievements.
I like to think of a resume as a scientific paper.
There is no room for fluff here. Be direct, state the facts, and back them up whenever possible. If someone even looks at your resume, they do so for a minimal time, so it’s essential to get to the point.
And that’s perfectly fine. There are still multiple ways for us to stand out.
First off, make sure to drive attention to your project, as that’s where you get to showcase your technical prowess. Most roads should lead to your project.
Mention previous jobs or experiences that you’ve had, but don’t write storybooks about them. Keep them concise.
Now you might be asking, “Gabe, how did you bypass the pesky education section of a resume?” And that’s a great question.
I chose to state the college I attended and the time I was there. I didn’t say that I had a degree, only what my focus was.
My strategy here was to showcase that I did have some college education and that if I were ever to be asked about it, I would explain why I didn’t finish getting my degree.
However, some of you don’t have any college education, and that’s perfectly fine too!
I’ve seen multiple high schoolers become software engineers and have even heard of individuals who have never graduated high school getting paid to program from their couch!
If that’s your case, I would maybe list some certifications, courses you took in high school that might help you stand out, and any program you completed to learn how to program.
And if you notice that something in your resume is not working quite well, change it, remove it, or replace it with something else.
All of these limiting beliefs that we tell ourselves are the reason why no one would possibly hire us is complete nonsense.
Stop trying to comprise the great and prosperous future that’s ahead of you.
Write what you can, back it up with facts, and move on!
Photo by Wolfgang Rottmann
Try and keep your resume to one page. This will force you to take out a lot of the fluff and make it easy for anyone to look over your resume.
With all of that being said, I came up with a version of this resume. It’s not flashy like some others out there. There are no colors, images, progress bars, just facts about what I’ve accomplished. It worked.
Remember the saying, great artists steal…
Take a bit of time to create your personal website. It doesn’t have to be the greatest thing since sliced bread.
The format that lots of other people, including myself, follow is to include a profile image on the top of your site, a short bio below it, a section showcasing your main technical project, a few blurbs and images showcasing some small projects you’ve built using some popular frameworks, and a few calls to actions to funnel people into your main project and resume.
It’s imperative not to link everything on your site. You are trying to get hired, so direct viewers into things that will move the needle for you, i.e., your main project and resume.
Here’s my personal website (I know it needs some work).
Before diving too deep into the application process and what helped me get to where I am, I just wanted to shout out to the folks over at Launch School's Capstone program.
Working through Launch School's Core curriculum helped me master the fundamentals, but attending their Capstone program is what helped me gain the confidence and knowledge required to not only get interviews but excel at them and succeed at my daily job.
I'm forever grateful to them, and I am where I am today in large part because of all that they've done for me.
It’s vital to take some time to think about what it is that you’re looking for. For example, are you looking for a front-end position, back-end, full-stack, or specific sector? Although, I don’t think you should be too limiting from the get-go in terms of the sector.
Decide if you have any preferences between startups or larger companies.
Maybe you’ve worked for startups in the past and enjoy wearing multiple hats and moving quickly. On the other hand, perhaps you prefer a more stable situation.
What would you like your working conditions to be like?
For example, are you interested in working out of an office, or are you looking only for remote or hybrid roles?
The answers to these questions will dictate how broad your search will be. But, again, you don’t want to be way too narrow here as your ultimate goal is to get your foot in the door.
Photo by Slidebean
Fundamentally, you should strive to get into an engineering-centric company.
What I mean by that is a company where engineering is the profit center — the money maker. That is because engineers are valued at these types of companies.
Keep in mind that it’s easier to become a Michelin-starred chef if you start as a dishwasher in a French restaurant than as a proverbial burger flipper in Mcdonald’s (no knock on anyone who works or has worked at McDonald’s).
So getting into the right place makes a massive difference in your career trajectory.
To further clarify, working at a company that builds software for financial institutions would make it much easier to launch your career than working as an engineer at a paper company.
I would stay away from them unless they’re recruiters from the actual company. I’m sure there are great recruiters who are helpful out there. I just haven’t had much luck.
There are many places where you can find companies to apply to.
I used Twitter, LinkedIn, AngelList, Hacker News, Glassdoor, RemoteOk, and more.
There isn’t a shortage of companies, only a shortage of talented engineers. So you will not have a problem finding places.
People always go back and forth on cover letters. I believe that you should do everything that you can.
I wrote a cover letter to every company I applied to.
I made my cover letters extremely personal. None of this “To whom it may concern” or “Dear Smith” nonsense.
I would often start my cover letters talking about a connection or appreciation for the company. Then about how impressed I was about what they were doing. Then in another paragraph, I would talk about what I was working on most recently to show that I wasn’t just anybody.
Here’s an actual cover letter that I sent to a company:
Hey Linear team!
My name is Gabriel, and I’m a software engineer based out of West Palm Beach, FL. I’ve been keeping up with Linear’s progress ever since I saw it on Hacker News earlier last year. I’ve been incredibly impressed by the product and think that the idea of revolutionizing issue tracking is such a cool idea! I’ve also been fascinated by the sheer quality of the product. Everything from its usefulness to the design and presentation on the frontend is truly world-class, which led me to think, “I would really love to work on something as impactful and exciting as Linear is in the everyday lives of all of its users.”
I’ve recently co-created Campion, an edge-based serverless middleware for implementing circuit-breaking functionality for synchronously called distributed services. I’ve also had multiple years of engineering experience and have been in the tech industry for my entire professional life as a founder with a successful exit and growth director. I’d love the opportunity to interview for the senior fullstack engineering position if possible. Thank you all so much!
I’m a firm believer that a candidate who takes the time to write a genuine cover letter will receive more attention and consideration than one who hasn’t.
Our goal is to differentiate ourselves in every way possible.
We are not like the other candidates. We’ve taken the time to master the fundamentals, we’ve taken the time to build our project, we’ve written in-depth about our project, we’ve designed a great website, and now we are setting ourselves apart by showing that we care.
Photo by Luis Eusebio
The more places you apply to, the more responses you will get, and the more interviews you will go on. It’s as simple as that. So don’t mess around.
Apply to multiple places every day.
You might be surfing Twitter one day and notice that a founder has posted about their company, so you decide to send them a message on Twitter.
This particular exchange is high on the personal points scale. You’re one of them and not just a faceless person applying through a crappy form on a website.
So be alert and try different things.
Opportunities may also come from companies you weren’t even that interested in in the beginning. Be open-minded and try not to rule anything out too quickly.
Photo by Camylla Battani
The only expectation you should have going into an interview is that you hope to learn something new and have fun.
Don’t go in to crush anything or impress anyone. Expect to fall to your level of training, and if you trained yourself well enough, you’ll do great regardless.
Again, zero expectation.
Interviews are often very similar. If you’ve been to one, you’ve usually been to them all.
There are typically multiple interviewing rounds, but some companies choose to have technical interviews, some don’t, some choose to have system design interviews, some don’t.
After the first round, some companies prefer that you spend an entire day with them where they’ll run through the other rounds with you, while others want to work alongside you for a day, or a few days, to see if you’d be a good fit.
What I’m trying to get at here is that these vary wildly from company to company, but the styles and format of questions and what’s expected of you remain relatively similar.
For the sake of providing you with an idea of how it usually works, here’s how it typically went for me:
Length: Usually 15–30 mins
Purpose: To make sure that interests align
Interviewer: Internal recruiter/HR or someone in a technical role
- Tell me about yourself
- Talk about your project
- They dive a bit into your background and project
- You ask any questions you may have
Length: Usually 30–60 mins
Purpose: To assess your technical capabilities
Interviewer: Most likely someone in a technical position
- Typically, they ask you to solve some problem, emphasizing the role you’re interviewing for. For example, if you’re interviewing for a front-end or full-stack position, you might be asked to do something with a front-end framework like React. If you’re interviewing for back-end, you might be asked to solve a general problem, like manipulating an array’s values and sorting the outcome.
- You might also be asked a systems design question
Length: Usually 30–60 mins
Purpose: Behavioral questions
Interviewer: Technical position or multiple people from different departments
- Behavioral questions
- You ask them questions
Length: Usually 15–30 mins
Purpose: Offer or not
Interviewer: Technical or HR
- Present you with an offer or not
Photo by Javier Allegue Barros
Learning to talk about your previous experiences and what has led you to where you are is extraordinarily important.
You will be asked to introduce yourself in every interview you go into. So take some time to write your story down and get used to repeating it a lot.
I rehearsed my story quite a few times before going on interviews. The reason for that is we often tend to forget things during interviews, or we gloss over some critical aspects of our background, so having a clear message in your head allows you to drill down on your essence.
An important point to make here is that you shouldn’t go talking for 15 minutes nonstop about yourself. I’ve been on interviews where the candidates spent most of the interviews talking about their background.
Remember, we are all humans.
Interviewers only have so much time and usually have more than one question to ask. You want to be concise, but you also want to be detailed.
I find that the sweet spot is anywhere between 3 and 5 minutes.
Hi, my name is Jenny!
I was born in Seattle, WA, and moved to NYC three years ago.
My love for computers began when my parents purchased my siblings and me our first computer when I was 11.
Ever since then, I’ve been hooked!
I also grew up playing computer games which led to a deeper appreciation for what these machines that have overtaken our everyday lives can do.
After high school, I had the option of attending Washington University but decided that it was best to put it on hold because I wanted to help my parents financially.
I had the privilege of working as a digital marketer for a clothing line, which allowed me to understand user behavior and what constitutes excellent UI and UX.
I also had the opportunity to work as an editor at a local magazine, which taught me how to be more patient and revise my work multiple times before the final product, much like programming.
I was also surrounded by world-class editors, which taught me the effort and perseverance needed to master one’s craft.
After leaving my last job, I took some time to reflect on what I wanted my future to look like.
I remembered just how much I loved editing the HTML and CSS while working as a digital marketer and how I became enthralled in the necessity for clarity and logical transitions while working as an editor.
So I decided to take time to master the fundamentals of programming.I knew that if I wanted to truly make a name for myself and produce quality work, I wouldn’t learn it in a weekend.
So I spent the last year honing my craft. I learned all that I possibly could about front-end development.
I’d love to talk more about it if that’s okay with you, but I want to be mindful of the time constraint.
Oof! I hope that gives you an idea of how to structure your introduction and present yourself in the best light possible.
We managed to tie everything back to software engineering, talk about how we were interested in mastering the fundamentals, and touch on everything that would be present in the resume (imagine that we had one).
This person didn’t even go to college, but I can guarantee you that they would receive offers and that their lack of college education would probably never come up during interviews.
The beautiful thing about this intro is that you can give it to anyone, and they would get the gist of who you are.
You also provide room to expand into your main personal project at the end.
Your goal should be to drive the conversation in that direction. It’s how you seal the deal. It’s how you prove that you deserve to be at the table.
If you were to dive into your main personal project, however, you wouldn’t go into as much technical depth with an interviewer who’s not in a technical role as you would with the company’s CTO, for example.
That’s to say that you should be able to explain your project to a five-year-old and have them get the idea.
Another point that needs to be made here is that you shouldn’t shy away from your uniqueness.
People love to have conversations about all sorts of things.
Getting to work alongside someone who has had a varied and exciting past is way cooler than someone who hasn’t! So talk about your love for baking, how you thought you could be the next Michael Phelps, or your girl/boy scout years!
Photo by Mike Kiev
Most of your interviewers will either be someone in a technical role or a recruiter/HR person.
They are people like you and me, and there’s nothing special about them either! Some technical interviewers will even know much less than you do, and by the same token, some will be award winners in their field.
With technical interviewers, you’ll be able to geek out over your love for engineering and past experiences.
With non-technical interviewers, you’ll have to give them a 30,000 feet overview of your background and focus on stating all of the languages and frameworks with which you’ve worked and built projects.
This is because non-technical interviewers are often trained to listen to specific tech stacks and keywords and will only move you into the next round if you say what they want to hear.
They do this even if you’ve told them a million times that you’re confident you can learn Vue, in a working capacity, in a few days.
Always have a list of questions to ask companies you’re interviewing with.
These can be related to matters that are important to you, such as what the company does to ensure an inclusive culture. There are excellent resources that can be found on Google relating to company questions.
I recommend that you compile a list with at least ten questions that you can refer to during interviews.
You do not want to be the person that asks no questions.
Interviewers, including myself, often leave a considerable amount of time to allow interviewees to ask questions.
Keep in mind that the types of questions you ask also allow you to set yourself apart.
Photo by Caju Gomes
If you had to take away only one thing from this entire write-up, it would be to be positive and smile during your interviews.
The people interviewing you will not remember most of what you said during the interview, but they’ll remember how you made them feel. So, were you a positive person? Were you someone they’d enjoy working with? Did you keep things light and fun?
It’s not what you say but how you make them feel.
I’ve seen with my own two eyes individuals who have aced every part of the interview process, who had the best background, the best code, show up to an interview and be absurdly pessimistic, be very serious, and not smile once.
Is that someone I’d be jumping up and down to work with? Is that someone I’d go to bat for when making the final hiring decision?
It’s also essential to be friendly to everyone you meet. I assumed that at least one person wouldn’t like me for whatever reason in every company I spoke with. So my job was to convert all of the others into really liking me and wanting to fight for me come decision time.
At the end of the day, this is just a conversation between two or more people. So just be yourself, smile, laugh, joke when appropriate, and have fun!
You don’t want to be the person who gives yes or no answers in an interview. I’ve seen this more often than you’d probably believe me.
On the other hand, you also don’t want to blabber forever. I’ve also experienced this a few times.
The goal here is to find a balance.
Don’t be the person showing up like they just rolled out of bed. There’s no need to dress in business attire but don’t look like a slob either.
As you start to receive responses and start scheduling your interviews, you might feel a bit overwhelmed. That’s fine. And if you don’t receive many responses, that’s fine too.
But, regardless of the outreaches’ turnout, you should get back to everyone, and if possible, you should go to every interview.
You will learn so much by attending them and exposing yourself to the world.
I can’t tell you how many times something from one interview helped me at another interview. By the end, you will be an interviewing powerhouse!
After every interview and stage within a company, email your interviewers thanking them. This is one of those small things that allow you to set yourself apart, and it’s something that I did with every interview I attended.
Photo by Sander Weeteling
You only need one company to say yes. One. So eat rejections for breakfast.
Keep track of how many rejections you receive and try and strive to get that number higher and higher because that means that you’re putting yourself out there.
Most of your rejections will come from automated emails. Some rejections will come after your first interview, and that’s great because you won’t have to waste your time with that particular company.
Other rejections will come later on in the process as a result of your technical or behavioral interviews. All of these are perfectly fine, and you will get them.
So let’s get those rookie rejection numbers up, baby!
There will come a time when you’ll undoubtedly have to juggle multiple interviews and companies at once.
I’d recommend not to schedule more than four interviews a day and no more than one technical interview in one day.
Technical interviews are very exhausting and take a lot out of you. Give yourself time between these interviews so that you can recharge.
Don’t forget to keep track of these interviews somewhere. For example, I used the note-taking app Notion and had a table where I tracked all companies I had applied to, companies I was interviewing at, the interview stage, and the outcome.! Also, make sure to add your upcoming interviews to your calendar!
Having multiple interviews gives you tremendous confidence. You no longer feel like you need to hit a home run during an interview.
If you bomb any of them, you know in the back of your head that tomorrow is a different day and that you have multiple great companies to talk to!
It also allows you to say on interviews that you’re currently speaking to various companies, which sometimes is helpful to get a company to move faster, given that some of them think that you have all the time in the world to wait for a response.
Photo by Mika
I will preface this by saying that there are excellent resources on salary negotiations that are a Google search away that you should check out. There’s some real science behind this stuff, and I won’t pretend that my way is the best.
Sometimes interviewers find it cute to ask what your expected salary range is very early on in the process, and I’m not too fond of these types of questions.
They put you at a disadvantage, and some companies use this to get a leg up on interviewees.
More often than not, I respond with something like, “I’m not comfortable sharing a number just yet,” or “There are more important things to me than hitting a specific salary number, such as company mission and fit.”
Sometimes, if I’m not sure if there’s a fit or if I’m at the end of my interviews, I might say something like, “I’m looking for a role with a base salary in the number-number (ex: $100k=$120k) range.” A range gives you wiggle room and doesn’t force you into a specific spot.
How do I find out the range, you might ask? You can look for average salaries in the area. You can check out GlassDoor and see if anyone has posted salary numbers for this specific company. You can pick a number that seems fair to you and one that feels a little uncomfortable.
In my opinion, in a perfect scenario, they’ll tell you the salary range upfront or will give you a range. I prefer when it happens like this because it feels fair to me and doesn’t create a culture where you feel like your coworkers, who do the same thing you do, are getting paid much more than you are.
Sometimes, however, they won’t, and that’s perfectly fine.
At the end of the interview rounds, they will give you an offer if they like you, and I’ve seen people receive an extra $30k boost on these salary negotiations alone.
The way I approach these is by thanking them for the offer, telling them how much I enjoyed the entire process and getting to meet the team, and in closing, I tell them that this is a huge decision that I’d like to give some thought to and that I’d like to speak to my family about.
Every company I’ve ever received an offer from was completely fine with that.
If I have other offers, I’ll take a few hours to decide which company I like best. Then, I’ll write them an email thanking them again for the opportunity, telling them I have multiple offers, and ending it by saying that I’d love to be a part of the team, but the only thing holding me back is the salary number, and I give them a number that works for me.
If I don’t have other offers, I tell them that I’m interviewing with multiple companies and that I’d be willing to join their team if they offer me a higher salary number than the one they initially gave me.
It’s essential to keep in mind that you also don’t want to be wasting your time interviewing for companies offering far lower than what you’re willing to accept.
You shouldn’t feel bad about negotiating your salary.
This is all a game that many companies out there still enjoy playing. They usually have a salary range but don’t disclose that number.
It’s your job to figure it out.
Some companies prefer to have you do a take-home project instead of conducting a technical interview.
I’ve been asked to build simple apps and program APIs in the past. They usually give you a few days to submit these.
Listen carefully. You have to stand out.
You have got to do any and everything to stand out here. Most people will half-ass these. They won’t go above and beyond.
That’s not you.
You will make sure that it’s the most beautiful thing on this planet. You will polish it up. You’ll make sure your code is clean and concise. You will document what you did.
You do whatever is necessary to stand out here.
Please remember, you only need one yes. That’s it. Only one.
This process can take a toll on you as it did on me.
I found it hard to stop thinking about applying to places and always felt like I could be doing more.
The critical thing to realize here is that this is a marathon and not a sprint. Take breaks. Give yourself a hard stop time where you’ll shut your computer off no matter what and go wind down.
This whole process goes by relatively quickly.
Months from now, you’ll be working at a great company and solving unimaginable problems. All of this will all be a blip on the radar.
So have fun with it.
Photo by Eilis Garvey
One thing I love about this field is the ongoing opportunities to learn. There is never a shortage of topics and holes that you can dig yourself into.
So just because you’re a baller making the big bucks doesn’t mean that you should stop learning.
In software, things also change rapidly. So it’s essential to keep yourself up-to-date, and you do that by learning. Your learning can come in the form of books, videos, courses; you name it.
Time is linear, but experience is not. Many companies believe that the best proxy is to look at years of professional experience when attempting to assess candidates, but that’s a terrible metric.
Compare and contrast the following two people:
Person A is someone who has worked professionally for five years, but all she did was the job that she was asked to do, and nothing else.
Person B has been a professional engineer for two years but has built six side projects with varying degrees of difficulty and multiple technologies.
Sure Person A has more years on paper, but Person B has far more experience. Be like Person B.
I know. There’s a lot to unpack here. I just had a lot to share!
Below I’ve outlined what I think are the most important things to be mindful of as you embark on this journey:
- Master the fundamentals of programming
- Build an impressive project and write about it
- Practice algorithm and systems design problems, and behavioral questions
- Create a resume that showcases your skills and achievements
- Create a website and funnel everyone into your project and resume
- When applying, write a cover letter and focus on engineering-centric companies, and apply to as many companies as it takes
- When interviewing, don’t have any expectations other than having fun and learning something new. Be prepared to talk about yourself, be positive, be detailed, have questions, dress well, go to every interview, email the interviewer thanking them when you’re done, eat rejections for breakfast, be willing to negotiate, and sleep
- Enjoy the ride
I plan to keep working on my craft. My goal is to keep learning more and challenge myself through personal projects. There are just so many cool things out there!
I’m not much of a content creator. I love to consume. However, one of my most recent goals is to document what I learn through this incredible journey. If this interests you, you can follow me on Twitter 🐣.
This article was originally posted on my blog at Six Figures Engineer.