Graduating from a coding boot camp is an incredible feeling. You’re tested mentally, physically, and emotionally during your time in school, and when you finally emerge through the other side, you feel like you can accomplish anything. But the journey isn’t over yet, and some might say the hardest part has yet to come.

If your goal going into your coding boot camp was to land a software engineering job after you graduate, you still have more mountains to climb. But this is different terrain than you’ve encountered earlier in your journey. Now you’re dependent on others to validate your abilities, and you can no longer just work harder and longer to get where you need to be.

You’ve worked hard to gain experience in some of the latest technologies, patterns, and trends, but now you’ll need to work on the other aspects of this process. You’ll need to continue to learn and expand your technical expertise, but you’ll also need to improve your soft skills, work on your networking, and might even need to play the numbers game when it comes to landing interviews.

1. Solve an algorithm problem

There are multiple components to a software engineering interview, but for an entry-level role, algorithm problems are the most important. You need to have a strong grasp of data structures and common algorithms to be successful here. A good boot camp will emphasize daily practice in this area during your time there, but it’s up to you to keep it up afterward.

Before you can really solve algorithm problems, you need to know your data structures. In an algorithm problem, your data structures are your tools while your algorithm itself is the set of instructions for how to use those tools. If you don’t understand how your tools work, how could you possibly write instructions for how to use them? Take the time to build a solid understanding of the most common data structures seen in software engineer interviews.

Spotlight

There are common algorithm problems, and then there are common algorithm problems with a twist.

As for the algorithms themselves, you need to familiarize yourself with the different patterns. Essentially all algorithm problems out there today are just variations from a popular base algorithm. There are common algorithm problems, and then there are common algorithm problems with a twist. You’ll need to get experience with the various algorithm design questions.

There are several useful paid resources out there to help you with your studying, but the free resources are certainly good enough to get you some good practice. Web apps like LeetCode and Codewars have extensive problem sets in multiple languages, and they also have a thriving, active community that can be pretty helpful. There are also many paid options out there, but if you’re just getting started, reading Cracking the Coding Interview would be a great option (I still have my 6th edition). Aim to tackle a problem from one of these sites every day.

2. Design an application system

These problems consist of describing how you would design the system architecture for an application, something like: “Describe to me how you would build Reddit’s homepage.” Interviewers are generally interested in an end-to-end (E2E) design where you might break down a rough user interface (UI), the endpoints and services to support the data for that UI, and a database schema to store the necessary data. Additionally, your interviewer might be interested in how you might address common distributed system issues that may occur with your application like data consistency or database bottlenecks.

Spotlight

The more senior the role you’re applying for, the more system design problems you’ll have.

Now, these problems are complicated and not necessarily going to be a primary focus for your interview. Mileage will vary, but typically, the more senior the role you’re applying for, the more system design problems you’ll have. As an entry-level engineer, you’ll have fewer of these types of challenges during your day-to-day, so it’s not as important as if you were at the staff engineer or architect level where you’ll be tasked with these responsibilities more frequently. Also, larger and more reputable companies will generally have more of these types of problems in the interview process. Smaller companies with less of a reputation might not be afforded the luxury to be as judicious during their hiring process. They are competing for the same talent and generally can’t pay as well nor provide the resume-building name, so need to be a little more flexible when it comes to their candidates.

Nonetheless, whether you’re applying to a big tech company or just looking to broaden your knowledge base, it’s a good idea to practice system design problems. Nothing can replace the experience of actually building out these types of systems, but that’s not very feasible right out of a coding boot camp, so we need to build upon the knowledge of others.

As with algorithm design problems, there are a lot of different paid resources out there. But with system design problems, there often isn’t one “right” answer. Instead, there are decisions with pros and cons, so there are fewer problems out there where you can just check your answers against. With that said, there are some example problems that I found useful to get you started. I like InterviewBit’s free resources and problems, as well as Educative’s free examples of how to build TinyURL and Instagram. Since these problems are complex, aim to design a layer (i.e. user interface layer, services layer, database layer) of a system design problem every day. System design problems aren’t always easily divisible into equally sized parts that can be conquered each day, but I think this is a good target to get you going.

3. Practice whiteboarding

Often when we’re coding, we’re coding in silence. So naturally, verbalizing our thoughts can be challenging. And we already know that solving algorithm problems and designing systems are both challenging in their own right. Now instead of setting down with your keyboard in front of you, consider having to write on a whiteboard while standing upright. Whiteboarding is a uniquely difficult exercise that you only get better at with practice.

Whiteboarding has been part of the software engineering interview for quite a long time now, however in recent years due to the pandemic, the interview process has adjusted. With more and more companies becoming “remote-friendly”, you may find yourself in an interview where you’re whiteboarding virtually. You’ll want to prepare yourself for either scenario by practicing on an actual whiteboard as well as a virtual one like Excalidraw.

Try practicing interviewing out loud on a whiteboard every day. Whether it’s writing out some rough algorithm logic or illustrating a system architecture, this practice will come in handy come interview time.

4. Read something

One of the reasons I love being a software engineer is because there is always something new to learn. It’s a bit of a double-edged sword, however, because you also need to keep learning to not be left behind.

One of the best ways to keep learning is to read. There’s a wealth of information out there and no shortage of people trying to teach you. There are blogs, documentations, and even tweets that can provide useful insight. Also, don’t be afraid to read above your comfort level. Go down those rabbit holes to learn about the things you don’t quite understand in articles. You’ll come out a better engineer for it.

As I mentioned before, there’s an endless amount of reading content available to you, but I would start by reading about how to solve algorithm problems and system design fundamentals since you’ll need a strong grasp of these anyway. GeeksforGeeks and DEV generally have useful content. I also periodically write how-to articles for individual algorithm problems with detailed explanations and helpful illustrations. Check out Solving the “Rotate a Matrix” Problem in JavaScript as an example.

It’s also important to make sure you’re reading about the underlying fundamental principles behind some of the technical design decisions you’ll need to make. Knowing when to use CAP Theorem to decide on how consistent your data will be or how to estimate your systems capacity requirements are just a couple of concepts that might be thrown your way during an interview. A Coders Journey is a great resource to explain some of these building block concepts. I also like Grokking the System Design Interview’s Guide which can give you some direction to get you started.

Strive to read something every day. Whether it’s an article, a blog post, or some API docs, take the time to read every day so you can continue to expand your domain knowledge.

5. Watch something

I think it’s a really good idea to hear the ideas explained and the terminology used out loud. Reading is great and speaking the vernacular is best, but hearing and seeing information well help you solidify those concepts in your memory.

During your career, you’ll find plenty of different YouTube channels and keynote speeches that you’ll enjoy staying up to date on, but as you’re honing your interviewing chops, you’ll want to mainly focus your learning on algorithm design. I recommend checking out the Clément Mihailescu and freeCodeCamp YouTube channels because they have a lot of quality content.

Also, watching someone else work through a system design problem is a great way to learn. You’ll get to see how someone else approaches these types of problems, and that person might pick on things you miss or ask questions that you might not have thought of. I really like the YouTube channels for Exponent, Gaurav Sen, and interviewing.io because their content is generally useful and they have a decent variety.

Try and watch a video a day. Pretty soon your YouTube feed will be curated with relevant content and you’ll figure out what you like best.

6. Apply to jobs

Start applying to jobs right away. You might not feel ready, and that’s because you definitely aren’t ready, but that’s exactly the point. Just like anything else, interviewing takes practice if you want to be good at it. You should squeeze in as many practice interviews as you can, but there is no replacement for actually interviewing. The pressure imposed on you and the curveballs thrown at you are hard to replicate at home.

Spotlight

You likely won’t be at your best the first few times you interview, so save your dream companies for when you’ve hit your interviewing stride.

To start, apply to companies you’ve never heard of or definitely don’t want to work for. You likely won’t be at your best the first few times you interview, so save your dream companies for when you’ve hit your interviewing stride. You’ll start to feel more comfortable as you interview more, and you’ll potentially get valuable information and feedback so that you can sharpen your skills accordingly.

Depending on your experience, your professional network, and even the current economy, you may or may not have a tough time getting through resume screening software. In this case, you’ll want to apply to a ton of open positions. Make sure to tailor your resume and cover letter to each application. Thoroughly read through the job posting and make sure your resume best illustrates how you’ll be able to fit into that role. Also, spend 20 minutes reading about the company and tailoring your cover letter to some of those specifics you just learned about. It doesn’t have to be an entirely new cover letter. Just make sure you have a few different templates to address each type of company (i.e. energetic startup, altruistic non-profit, multi-national corporation solving large-scale problems, etc.).

You’ll have a lot of moving parts while you’re interviewing, especially when your interviews go deeper into the process. Try to track everything in a spreadsheet. From contact information to interview questions you were asked, this is all data you can use to your benefit. It can help you better identify your weaknesses, but more importantly, it will help you keep important names and information in order so you don’t have a slip up during an interview.

Apply to 3 jobs per day. Once you start getting a rhythm, you’ll start landing and nailing your interviews. But until then, play the numbers game and get as much practice as you can.

7. Expand your network

One of the best ways to get an interview is by referral. Referrals are coveted by employers because it provides an extra layer of authentication. A referral means that an employee that they have already vetted and trust has indicated that he or she can vouge for that candidate. That can be hugely valuable in a process where you’re often hiring a total stranger.

Most of your friends and family are going to be willing to refer you for open positions in their company. Even your friends-of-friends or vague LinkedIn connections might be interested in referring you because there are often referral bonuses in place, especially for an engineering referral. But even if your friends, family, or acquaintances don’t have any good positions to refer you for, at least they’ll know you’re looking. So the next time something opens up or someone in your network has a work conversation with one of their friends, your name might pop up. Reaching out to your network is a nice, low-effort way to increase your success odds. You don’t have to aggressively force the issue, just go for the low-hanging fruit and see what happens.

Obviously, reach out to anyone that works at a company you’re applying to, but try reaching out to one person in your network every day. Whether by phone, text, or a LinkedIn message, you just need to politely reach out and have a conversation. Your conversation doesn’t even need to have an “ask”. You can just want to learn more about the company culture and the conversation might naturally gravitate towards an open position.

8. Build something

Cooks cook, managers manage, and coders code. To be a better programmer, you’ll need to keep programming and learning. Maybe you notice a lot of the job postings call for experience in Postgres or GraphQL. Then build something, anything, with Postgres and GraphQL and work with the technologies that you’re inexperienced in. Building something with these powerful technologies that you’ve only heard about may sound daunting at first, but then you’ll quickly realize you’ve already built several applications with technologies you had only heard of while you were in school.

When you work on your side projects or portfolio projects, work on them on Github so that you can pubically demonstrate you’re actively contributing to codebases. Also, find open-source projects that you can contribute to. Your contributions might be small or even trivial, but it’ll get you accustomed to the pull request process and it’ll get your name out there. All of this publically visible work will help demonstrate that you’re an established developer. When I interview candidates and they provide a Github account, I always take a look at what they’ve written because the more data I can take in about a candidate, the more accurate my assessment of that person will be.

Definitely aim to write code every day, and target to have a public commit twice per week. This will help show that you’re consistently and actively learning to become a better developer.

9. Write something

One thing I wish I did after I graduated from Hack Reactor is write. Now obviously your writing should generally be relevant to software engineering, but that can actually be a fairly broad criterion. It could be about your experiences going through a boot camp, what you’ve learned while building your portfolio applications, are some knowledge you picked up while practicing algorithm and system design problems. And while I would say I generally enjoy writing by itself, it also has some particular advantages when it comes to landing your first software engineering role.

Writing helps establish your credibility and domain knowledge. When you’re interviewing for an entry-level role, you’re usually competing against several other candidates. One small way to differentiate yourself is to write blog posts or articles and link them to your resume and LinkedIn profile. When you write about software engineering, you’re signaling that you understand that particular subject. Assuming what you’re writing about is truthful and correct, your post or article will add another layer of authentication for recruiters and employers. It can be hard to get through resume screens, so adding any additional credibility will go a long way.

Spotlight

You don’t know how much you know about a subject until you have to teach it.

Writing also helps reinforce your knowledge. If you’re like me, you’ll start writing on a subject and then realize you don’t quite know one little aspect of whatever it is you’re writing about. One thing I learned when I was a teaching assistant in grad school is that you don’t know how much you know about a subject until you have to teach it. By writing about a topic, you’ll force yourself to make sure you understand a subject fully.

Try to write one article per week. You’ll quickly find that technical writing isn’t easy. You need to make sure you understand the subject thoroughly, write eloquently but also concisely, and potentially build useful diagrams and illustrations to solidify your argument. Target once per week, but adjust this goal so that it’s not slowing you down.

10. Relax

Interviewing is a grind, especially when you’re starting at entry-level. You often don’t have much or any leverage, and sometimes if you don’t have a CS degree your application won’t make it through the resume screening software. So take breaks, go for walks, and make sure you clear your mind. When I was in the interviewing phase, I liked to play soccer because I like the sport and because it forces you to acutely focus on something else other than interviews. Do something that you know will take your full attention.

There’s no need for a target amount of relaxation, just listen to your body and make sure to fully disconnect from the application process.