Landing Your First (or Third) Awesome Software Engineering Job, Part 1
Discover more from Engineering Land
Landing Your First (or Third) Awesome Software Engineering Job, Part 1
Getting that awesome software engineering gig you really want can be hard. Competition is tough, interviewing is exhausting, and you may feel that you don’t have a lot to show if you are at the beginning of your career. Missing good opportunities despite all the hard work you put into your craft is a horrible feeling. And this is not limited to first-timers - most folks are not “interview savvy” until they get burned multiple times.
I see many talented, hard working folks struggling to break into tech or to find a role they are happy with. It doesn’t have to be this way. You can do it. Got it? Good. Let’s get to work.
Note to Managers: while this post is geared towards individual contributors (ICs), I think that you can learn something valuable here too. You can make better hiring decisions by understanding the challenges of modern engineering recruiting from the candidate’s perspective and creating great interview prep resources for your company. Or just send them this post.
This is a multi-part series. I will cover the entire tech hiring process, end-to-end.
The Challenge
“People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.”
– Theodore Levitt
In true Moneyball fashion, companies don’t “buy” engineers, they buy results. Companies want to solve customer problems, ship reasonably good products that don’t break too often, and make lots of money. Your amazing coding skills and captivating personality are, essentially, means of accomplishing that.
Recruiting is time, money, and people intensive, not to mention risky. Hiring a developer takes tens to hundreds of people.hours in most companies, and a bad hire can set a project back significantly. To make things worse, most engineering job posts get hundreds, even thousands, of applicants. This means that the time per applicant that staff will dedicate to your post is going to be rather short.
Many inexperienced applicants believe that recruiting is a perfect process designed to accurately assess their skills and generate deterministic, objective results. This is not true.
Tech hiring processes are indeed designed to screen for functional competency. They are also designed for cost efficiency (i.e. in terms of people, time, and money), to screen for several desirable traits (ex: teamwork, delivering results, working under pressure, specific cultural values, etc.), to scale to many applicants, and to minimize risk (which is why folks with unconventional backgrounds have such a hard time interviewing).
Trade-offs include candidate experience and decision quality. They are also driven by real people, further complicating the whole thing. Finally, many tech companies simply don’t know how to hire engineers, which adds a whole new degree of fun.
Interviewing is a stressful process. Not everyone will be nice. Some folks may be downright disrespectful or unprepared. Dealing with interviewers who clearly don’t want to be there or recruiters who ghost candidates is nobody’s idea of a good time.
Anatomy of the Tech Hiring Process
I’ve written about the general tech hiring process before. They can vary heavily from company to company, but they generally look like this:
The first step is the CV Screening. This is where a good CV and customized cover letter will help you. Your goal here is to get to a call. This stage includes:
Recruiter CV Screening: first screening, done by tech recruiters. They won’t dive too deep. They are looking for basic fitness (ex: programming language or years of experience) or red flags (ex: lots of typos, obviously false info, irrelevant background). Has 100’s of CVs to review.
Hiring Manager CV Screening: usually your future (engineering) manager. Will look a bit deeper and decide on go/no go for an interview. Has 10’s of CVs to review.
If you clear the CV Screening then you really are in the game. The next stage is the Screening Calls, where you will speak with the recruiter and, hopefully, the hiring manager.
You won’t dive too deep here - these calls tend to last 30mins or so. Good screeners will be looking for basic fitness and strong red flags (i.e. deal breakers). Whether screeners share notes with other interviewers varies from company to company. You may get a take-home test from some companies. The goal here is to get to the Deep Dive (a.k.a. on site).
The final stage is the Deep Dive. This is it - the bulk of the interview process happens here. This will take anywhere from 2h to 3 days, with 3-5 1h interviews being common. Common interviews are:
Software Engineering Fundamentals: this is your typical “coding interview”. You will be asked to solve technical problems, varying from Hacker Rank to debugging. You will review your take-home test here if you had one. Be prepared to bring your A-game in terms of algorithms, data structures, programming language knowledge, and basic problem solving.
Systems Design: this is a personal favorite of mine. Here you will solve a real problem with real specs by designing a system that a company (preferably the one you’re speaking with) could reasonably implement. Think questions like “design Google Maps”, or “design Uber“, etc. The complexity of the challenge will be fine tuned to the role’s skill level requirements. Good candidates will ask clarifying questions and use their system design knowledge to create a solution taking into account scale, efficiency, implementation difficulty, trade-offs, etc.
Behavioral: interview focused on understanding how you work within a team, how you operate under pressure, how you own and learn from past mistakes, how you communicate with stakeholders, etc. This is a soft skills focused interview, and many engineers make the mistake of dismissing it. This is a mistake. This interview is as important as the hard-skills focused ones.
Bar Raiser (optional): the Bar Raiser is an interesting interview. Bar Raisers tend to be very senior folks with specific training to really dig and find your limits. Good bar raisers are uncomfortable - you’re being pushed, after all. They cover hard and soft skills, and can even factor in notes from previous rounds. Not all companies do Bar Raisers, and they tend to be reserved for more senior roles, but watch out for them! Bar Raisers are highly regarded folks and their opinions hold a lot of sway.
Skip Level (optional): good news, you are likely one foot into the door (but don’t let up, you’re not there yet). This is a call with the boss of your future boss (or even the company founder). It’s not very structured, but the interviewer expects lots of questions and enthusiasm. They will be doing a sanity check, watching out for red flags other interviewers might have missed, and selling the position hard (they like you, after all). Good candidates will have plenty of questions about the company, product, team, career development prospects, and other relevant topics. Pro-tip: leave questions like vacation policy and bonus payment schedule to your recruiter or offer call.
Assuming everything went well, you will get get an offer. Congratulations! Usually there will be a call to go over the offer details, key dates, contract specifics, etc. It tends to be pretty straightforward.
NOTE: while this process can vary a lot from company to company, preparing for this standard will usually leave you over-prepared. There’s no such thing as overkill in interviewing IMHO.
Before the Interview
“Every battle is won before it is fought.”
- Sun Tzu
The road to getting an offer starts before any interview is scheduled. There is no hack, shortcut, or silver bullet that will replace preparation and strategic hard work.
Recruiting is a complex, multi-dimensional process. Shockingly, companies don’t usually prepare their employees to interview elsewhere. Universities and boot camps generally don’t do a stellar job either. Preparing is on you. You need two things to be fully prepared: strong functional skills and interview skills.
Functional skills - i.e. what you need to do the job - can be divided into hard and soft skills.
Hard skills include solid software engineering fundamentals, knowledge of core tools and processes (ex: Javascript and Agile), and the ability to solve real problems by designing good solutions, taking into account reasonable business and non-functional requirements. This is usual the easy part for most engineers.
Soft skills include knowing how to constructively deliver results, individually and as a member of a team; having a growth mindset, constantly learning; communicating effectively, adapting for the audience; being able to self-manage, manage up, and help others. These can be hard to grok for engineers, but are essential.
Interview skills - i.e. you can convince others that you can do the job - revolve around communications, sales, self-control, and time management. Remember, tech hiring is a risky proposition for companies and you have a limited time budget to prove you can do the job. They won’t hire otherwise good candidates if the risk is deemed too high, which almost always happens when that candidate interviews badly.
Cue the training montage!
Tenets
Let’s start by establishing a few tenets. Explaining and proving each one is a post in itself so, for now, take these as self-evident truths.
Competency != offer. Recruiting is an imperfect process, as are the people involved in it. Just being competent will not, unfortunately, guarantee your success. This can be incredibly frustrating, especially if you end up missing an opportunity that you were super excited about and felt like a perfect fit.
It’s a numbers game. Most folks need to apply to 50+ jobs before succeeding. These numbers can be lower if you are an amazing and really well-prepared candidate. It’s easy to get discouraged after applying dozens of times without any success. Keep calm. Power through.
Treat each opportunity as the last job on earth. Many folks who hear the “it’s a numbers game” spiel end up blasting fifty low-effort, generic applications to every role with “Software” in the title. It’s important to read through every description, tailor your application accordingly, write a custom cover letter when possible, prepare a high quality resume, etc. The person screening your application will likely invest 10-30 seconds doing a first scan, and low-effort / generic applications easily stand out (in a bad way). Respond all emails ASAP and be on time for all calls. Being late is not a major issue if you have a good reason, but it doesn’t look good.
Always be selling. Make no mistake, recruiting is a sales process. The product: you. Keep that in mind at every stage of the process. Be polite. Focus on the positive impact you will bring to the company. Show how you’ve learned from past wins and mistakes. Do a bit of subtle self promotion too (I know, it’s hard). You want the best non-fictional version of you to come across at all times.
Failing to prepare = preparing to fail. I think we covered this already, but let me reiterate: preparation is key to success if you want that awesome role. Build a schedule and stick to it. Preparing will require discipline and hard work. Motivation alone is not enough.
Learn, iterate, and move on. Chances are you will fail most of the time. That’s fine. Don’t take that personally. Learn from the process, figure out what you can do better, and move on.
Preparing
First, establish a baseline for the role you are seeking. The job description is the first place to look. I also wrote on engineering levels before, so you can use that to figure out what skill levels and scopes are behind the JD.
There is no such thing as being over-prepared for interviewing. If you follow these practices with discipline and dedication, you will be ready (and likely learn a lot in the process). It may take a month or six, but it will happen.
Fundamentals & System Design
Let’s start with the more technically-oriented rounds: Software Engineering Fundamentals and System Design.
Solid software engineering fundamentals include:
Data structures: knowing basic data structures (ex: maps, arrays, lists, etc.), when to use them, etc.
Algorithms: knowing how to effectively manipulate data and perform work in a variety of scenarios (ex: sorting, looping, searching, filtering, etc.)
Tooling: knowing how to effectively use tools relevant to the target company. Ex: Javascript, AWS, something SQL, etc.
Software Design: techniques and principles to reliably, efficiently, and effectively solve common software problems, like business logic encapsulation and data access. Think Design Patterns, SOLID, Domain-driven Design, TDD, etc. At a more granular level, this includes service objects, repositories, REST, MVC, web components, etc.
Development & Operations: practical skills engineers rely on to develop, build, distribute, operate, and troubleshoot applications. This includes source control, package management, basic deployment and ops (ex: SSH, PaaS, maybe some Kubernetes, etc), application monitoring (ex: using DataDog), debugging, and incident management.
Problem Solving: ability to effectively use all of the above to solve problems, taking into account efficiency, requirements, and constraints.
Start by grinding your way through online code challenges. Setup a regular schedule to solve a couple every day. This can be tedious and frustrating, but it will help you build a good foundation in terms of data structures, algorithms, programming language (part of tooling), and basic problem solving. I strongly recommend using an interview prep platform if you can. My go-to recommendation is Algoexpert, but there are several options online.
The best way to develop strong tooling, software design, development & operations, and more complex problem solving is to implement real world applications. If you had a chance of doing this professionally then great! Reflect on what you did, what you learned, and what you think you could do better. You could even re-implement parts of it to test out these concepts.
Fear not if you didn’t have a chance of building good practical knowledge. The next best thing to on-the-job-training here is to find interesting or common business problems and build fully fledged applications around them. These can vary from simple TODO and chat applications to cloning Google Maps. You would be surprised how much you can learn if you take this exercise seriously!
EDIT: for a fantastic example of the above, check out this blog post from the great Pragmatic Engineer. I love the overkill :)
Moving on to System Design. I love System Design. This is the ability to solve real-world problems from user to server. This interview will assess:
Requirements Gathering: the first step to designing a real world system is to accurately and comprehensively understand what problem we are solving and who we are solving it for (a.k.a. the user). These are then translated into clear business and technical requirements and constraints. Bonus: mapping the jobs to be done.
Domain Modeling: translating the problem, requirements, and constraints to a representation of concepts, relationships, and workflows. Good systems tend to stem from well designed domains.
System Components: these are the basic building blocks of any system. Ex: HTTP APIs, load balancers, background workers, stream processors, databases, block storage, etc.
System Patterns: how you can combine components together to solve problems, when to use them effectively, and the difficulties and trade-offs associated. Ex: CRUD HTTP APIs, pub-sub, work queues, event streams, lambda data architecture, database sharding, two-phase commit transactions, etc. This also includes the basics necessary to “stitch” components together, like networking protocols, encryption, etc.
Infrastructure & Operations: how to deploy and run the system at the scale necessary. Ex: S3, Kubernetes, Data Dog, Jenkins, etc.
The best way to build system design skills is to, well, build systems. If you have previous experience building complex systems, go back with a critical eye and understand why things were done a certain way and what could be improved.
You can create proof-of-concept applications solving problems that require non-trivial design patterns (or at least ones you are not familiar with). Building a chat app will help you learn about pub-sub, web sockets, and data bootstrapping. Building a click tracking app will help you learn about high throughput APIs, event streaming, background workers, and analytics.
I strongly recommend checking out interview prep platforms with good system design sections if you can. Algoexpert is a great choice here too. They have tons of system design videos simulating real interview conditions. I’m not affiliated with them by the way, just love their work. Way to go, Clement.
Finally, there are tons of great system design resources online, many available for free. I’ll link some at the end of this section.
NOTE: many large tech companies put a lot of emphasis on abstract tech challenge, but startups and younger/nimbler companies really want real world skills.
Behavioral
Moving on to the Behavioral interview, a decidedly soft-skills-focused round. This is where many engineers with strong hard skills tend to slip.
Sadly, many engineers take too long to understand the importance of soft skills. They are absolutely essential to getting things done in most work environments. The reason is that most businesses are marathons, not a sprints. A “10X engineer” with terrible soft skills can deliver a POC or address really complex tickets in record speed while killing morale and efficiency for everyone else. Savvy managers know how to deal with them, but nobody likes working with a jerk long term.
Some of the main soft skill clusters employers seek are:
Self-Management & Delivering Results: having strong technical skills is great, but knowing how to apply them to solve problems and deliver results is what employers want. This includes creative problem solving, self-management, working backwards from the desired end-result, and others.
Teamwork: unless you work in a vacuum, you need people to get things done. These can be colleagues, your manager, stakeholders, customers, and others. This cluster includes interpersonal skills, a positive (but not naive) attitude, empathy, and others.
Communications: the ability to effectively get your point across, gather information efficiently, have difficult conversations in a mature way, etc. One key point many engineers take years to learn: adapting for the audience (i.e. what matters to your colleagues may not matter to the Product Manager).
Business: the vast majority of employers want to make money. This means solving real problems to someone for some reason (a.k.a. providing value to customers). Closely related to delivering results. This includes knowing who your customers are, what problems you are solving for them, why those problems are important, what challenges they are currently facing with your solution, etc. Extra bonus points if you remember business KPIs and jobs-to-be-done.
Ownership & Growth: do you take ownership for your wins and your mistakes? Or do you push blame onto others? Do you go the extra mile to identify and fix problems, showing initiative? Do you focus on negatives, or do you learn from your mistakes and move on?
Leadership: leadership does not mean authority. Great engineers, even straight out of college, know how to lead by influence and drive an important project forward. The best “high potentials” are those who are also great leaders IMHO. Managers love engineers with high ownership and leadership skills as they tend to be “fire-and-forget”, being able to operate in an ambiguous environment with little to no oversight.
It’s not easy to prepare soft skills outside of real world experience. Worse, employers are really looking for the practical application of these skills, not theoretical answers. This is hard for first-time candidates or those who did not have good experiences so far. That doesn’t mean that you can’t prepare or shine. I will write a post dedicated to this in the future, but let’s focus on a few things you can do right now.
Self-reflection is your first option. You can reflect on past experiences through the lenses STAR framework. STAR stands for “Situation, Task, Action, and Results” and provides a way to organize past experiences and analyze them. Example:
Situation: Our website was slow, which caused significant customer frustration and lowered our conversion rates.
Task: I had to fix the website load speed.
Action: First, I looked at our monitoring and logging to figure out why the website was slow. I noticed that we didn’t have all the data, so I implemented Solution X to figure out what the issue was. The problem turned out to be our CDN - as in, it did not exist. So I proceeded to setup a CDN with global edge locations to serve our compiled website.
Result: We reduced the website load time by X%. More importantly, I learned that the number of customer complaints reduced significantly, but I do not have the real numbers here with me.
Learnings (BONUS): I learned that it is really important to have good website monitoring. I think that we could have solved this issue much earlier if we knew what the problem was. Since then, I try to setup really good monitoring from day one when creating or changing anything.
Create a storybook in STAR format covering as many of the soft skill clusters as you can. I cannot emphasize this enough. This is the key to confidently answering questions like “tell me about a time that…” without replying with “uh…hmmm…well there was this, uh, time that <insert badly remembered semi relevant rambling here>”.
By writing down this storybook you will be able to reflect on past experiences through a new perspective - possibly even identifying learnings that you did not see at the time. You don’t need to write The Lord of the Rings here - 5-20 stories should be sufficient. And for gods sake they should all be true. Good behavioral interviewers are excellent BS detectors.
Oh, and make sure to include mistakes too so you can crush the dreaded “tell me about a time you made a mistake” question. Here’s an example of how to talk about a mistake in a constructive way:
Situation: We had to deploy a new website for a product launch.
Task: I was tasked with setting it up and making sure that the website was online on date X.
Action: we were on a tight schedule, so I used a static website generator and NodeJS to compile and serve it.
Result: I was able to push the website live on time, but something was off. The site was slow for many users and we got a lot of complaints.
Follow Up (BONUS): I added some monitoring and figured out that, while serving with nodejs worked, it was not efficient given our request load, and we had users from all around the world coming in.
Fix (BONUS): I quickly added a CDN in front of our website with plenty of edge locations, which fixed the issue instantly.
Learnings: I will be more careful in the future when considering the launch plan parameters. Just working is not necessarily enough. Also, I should add monitoring on day one so that I can quickly capture problems.
There you go. That story could have been a major disaster at first, but you were able to communicate it truthfully while remaining reasonably positive and showing that you learned from the experience. This also works even if you were not the one who fixed the issue by the way.
“But Marcelo, I don’t have any experience, this is my first job! What can I do??” I hear you say. That’s alright. You can put together a storybook with situations from your college, open source projects, hackathons, etc. Just make sure that they are relevant to the job (i.e. nobody wants to hear about your last minute beer run in STAR format). If your Behavioral interviewer insist on “real world situation”, you can politely remind them that this is your first job.
NOTE: some folks might think that this is cheating or manipulation. It is not. Employers have a bias towards not hiring if the team is not sure about the candidate. A great engineer that interviews badly will not build that confidence and will not get the job 90%+ of the time. I would much rather interview a clearly well-prepared candidate and make a confident decision than go through a painful one hour call with an ill-prepared candidate. It’s just the way it is.
Another way of preparing is by seeking mentoring or coaching. Many people find it hard to self-reflect at the best of times, and early-career folks may not have the experience to do so objectively and thoroughly. There are great options online to connect with mentors. An example is The Mentoring Club, where experienced professionals mentor folks like you for free. I serve as a pro-bono mentor there.
Finally, there are books and YouTube. There are tons of interview tips or, even better, simulated interview videos there (not as many books though). Many of them are created by companies themselves. Why? Because companies want to hire you for your functional skills, not your interview skills. Managers hate to pass up on potentially good candidates that failed the interview.
All Other Rounds
I will not cover the other rounds in the prep stage (screening, bar raiser, etc.). Your core preparation will target the Software Engineering Fundamentals, System Design, and Behavioral rounds. This is your foundation. The other rounds will largely rely on this foundation, exploring different facets in different ways. The key is in how you go through them, which I will cover on Part 2.
Additional Resources
Other great sources of information are books, blog posts, open sample codebases, online courses, and YouTube. I like them and you can learn a lot from them, but I wouldn’t rely just on passive learning. You have to learn by doing.
Fireship: great YouTube channels with “high intensity coding tutorials”.
ByteByteGo: my go-to newsletter for systems design of all shapes and sizes.
Interview preparation platforms:
Books:
“Cracking the Coding Interview”, by Gayle Laakmann McDowell.
“System Design Interview”, by Alex Xu.
“Domain Driven Design Distilled“, by Vaughn Vernon.
“Answering Behavioral Questions in Amazon Interviews”, by Jennifer Scupi.
Videos:
“Amazon Interview Questions”, by Exponent
Online courses: Udemy, Coursera, etc.
Key Takeaways
Companies buy results, not work. They have a problem to solve. Your skills are a means to an end. The goal of the entire process is to answer this one question: can you deliver the results the company wants?
Tech hiring is not perfect. This is a human and time-bound process. Things will be messy. Don’t assume that competency is enough.
You need functional and interview skills. Functional skills prove you can do the job. Interview skills convince others of that fact.
Preparation is critical. Most people don’t breeze through a strong tech hiring process, and all the great jobs are behind one. Prepare by working smart and hard. Build a schedule, and stick to it. There’s no such thing as overkill.
You can make it. Folks land great jobs (or first jobs) all the time. You can do it, if you do the work. It may take a week, a month, or an year, but you’ll make it.
What’s Next
I will cover the rest of the tech hiring process on Part 2, including how to run the interviews, what to do (and not to do) afterwards, and how to close the deal. There is nothing preventing you from starting today, however. Happy prepping!
If you think someone in your network would like this, then
Want to join the conversation?
Thanks for reading, I hope you liked it! For more content like, feel free to