How to Get Your First Software Development Job: 10 Tips to Ace Your Technical Interviews
TLDR: Software engineering technical interviews can be difficult, especially for newer developers. While you can never prepare for every possible question, I have found 10 ways to prepare that will put you in a good position to solve any interview question you may get!
If you’re reading this article, you probably are, or want to be, a software engineer. The reasons for why you want to be a software engineer are plenty. You like solving problems or building things. Or you want to work with driven, likeminded people. Maybe you’re just in it for the money. Whatever it is, you have a clear reason/reward for why you want to do software engineering.
What’s standing in your way? Is it lack of education or lack of experiences? Maybe you didn’t go to college for Computer Science or a STEM degree. Maybe you haven’t even attended a bootcamp and are just self-learning. While your background may dictate how hard it is to network and get interviews, one career hurdle all prospective programmers share is technical interviews.
These interviews can be beasts for both new and experienced developers alike . There are so many different data structures and algorithms that can be asked about and only a limited 30 minute to 2 hour block to complete them in (from here on I will use DS&A to abbreviate “data structures and algorithms”). How can you possibly prepare?
For anyone looking for a week long crash course to master the ins and outs of DS&A I’m here to tell you that there are no shortcuts. I studied for months before I was regularly acing these interviews. No amount of cramming the day before would have helped me pass the tests as the scope of necessary knowledge is immense.
While I don’t have a magic formula to ace your interview tomorrow, I found a set of practices that if done consistently will help you ace your interviews. This list is mostly from personal experience, but some of the ideas came from dozens of calls I had with other software engineers, engineering managers, career coaches and technical recruiters. I hope it helps you become confident in your skills and ace your technical interviews.
1) Figure out the Best Time and Place to Study
Not everyone is a morning person, and that’s alright. A key to DS&A study is to put yourself in the best position to be alert and focused. You may need to study in the morning before work because this is the time you focus best, or maybe at night after you put your kids to sleep so you don’t have to worry about distractions. There is no universal right or wrong answer for when to study. Try many different time slots and figure out which one works best for you!
Along with finding your optimal time to study, make sure that you are picking a study spot that will allow you to focus uninterrupted. Try to avoid places where your family, partner or friends may distract you. Whether it’s your office, a quiet coffee shop or your kitchen, find a place that you can consistently focus and learn.
2) Be Consistent in Studying Every Day
Learning to code is a lot like lifting weights. While lifting for 7 hours one day a week means that you average an hour of lifting each day, this will not lead to an increase in muscle mass. Instead you are likely to end up injured and disinterested in lifting. The key to growing muscle is to stress your muscles and then allow them to recover and become stronger.
Just as muscles grow from cycles of stress and rest, so does your mind and coding abilities. To get better as a coder, you need to code a lot at a high level. You can’t program for 7 hours straight once a week as you brain is not likely to retain all the information, and you leave yourself open to burnout. Yes you may have spent a lot of time coding, but you will see diminishing returns in these longer study sessions as your mind and focus dip.
To maximize your time, focus on smaller and more manageable study sessions. If you can only study 15 minutes a day, then study for 15 minutes. If you have a side job on the weekends, spend 30 minutes every weekday. When I was preparing for my technical interviews I would spend an hour on DS&A questions as soon as I woke up in the morning and spend another 30 minutes to an hour at the end of the day. It wasn’t coding 12 hours a day, but I always felt more confident after my shorter sessions.
While the more time you spend in your sessions can help you learn faster, the most important think is being consistent in how often you study. As you spend more consecutive days coding, you will see the results of your hard work more and more.
3) Keep a Journal of Every Question
If you have been practicing data structures and algorithms for long enough, you may have run into the issue of getting the wrong answer for a question multiple times in a row. You may wonder “am I making the same mistakes every time, or is every wrong answer part of a different mistake?” Knowing the answer to this question is vital to making consistent forward progress in your learning.
In order to improve your DS&A skills, it is good to know what mistakes you make on questions. Whether it is a lack of understanding for a method that leads you to spend some time on MDN, or a reoccurring mistake that you correct, knowing what is not working is as important as knowing what is working.
A good way to keep track of your learning progress is to keep a journal for every question you do. It doesn’t have to be complicated. My journals (https://github.com/dpericich/Ruby-DS-A), which you can see in this repository link, consisted of the date attempted, the problem name, assumptions I was making for my solution, the time and space complexity and finally a section for any issues I had.
The first items, assumptions and time and space complexity are important parts of an actual technical interview that many people skip over when practicing DS&A. By keeping this journal, you will force yourself to slow down and consider what assumptions you are making for the problem. This is helpful as you learn a data structure as you will easily be able to find patterns of what assumptions are shared between all problems of a certain type. If you want even better interview prep, don’t just write down your assumptions. Say them out loud as you are writing to mimic how you would explain your solution to an interviewer.
By writing down the space and time complexity, you will be forced to identify these items for your solution. You will also have to think more about whether the O (N²) time complexity solution is really the most efficient. If you come up with a more efficient approach, don’t erase your old time /space complexity! Annotate that approach and fill in new lines with your final solution’s complexities.
As you write your solution and test it, make notes of the things that went wrong. Maybe you used a forEach instead of a map method on an array and this is why you weren’t able to save your operations to a new array. Maybe you have trouble remembering to set a new head for linked lists questions. Whatever your issues are, it is important to write them down and remember them.
If you are having issues on questions, but after digging into some docs or blog posts you don’t make the same mistake again, that is great. However, if you stumble on a question and see that you have made the same mistake on multiple previous questions, you need to look at how you’re learning and how to change it.
The best way to track your progress is to track your questions and issues. This may have been one of the most important breakthroughs for me when I was studying. Spend the extra 5–10 minutes per question on your journal and you will see results!
4) Use GitHub to Track Your Progress
You should find a good place to keep your journal and question progress. The best place I found to keep my journal was in a GitHub repo. Storing all of my solutions and logs here helped keep everything organized. It also allowed me to easily revisit old code and modify or even add whole new solutions for the questions.
Most DS&A question test sites hold onto your most recent solution. However, if you want to save multiple different approaches for solutions, along with your journal notes, a repo is the best way to go. An added bonus of using Github is you will get extra practice with git workflows as you add to and maintain your DS&A solutions repository!
5) Don’t Jump Around Question Types
When you’re first starting out, you will probably be very eager to master all the DS&A question types at once. After all, the list of question types from heaps to linked lists and binary trees is extensive, why not jump into all of them and get going?
Though your energy is good, this approach is self-defeating because of the lack of concentrated focus it has. Just like learning multiple languages or frameworks at the same time is self-destructive, so is attacking all types of DS&A types at once.
While it may seem to take more time at first, focusing on one DS&A question type until you are fully proficient will save you time. You will see a lot of growth if from day to day you are able to review your progress journal and figure out what areas you are getting stuck on.
As you consistently work through a single DS&A question type you will see the patterns that are common for all questions built on that data structure. Along with this you will hopefully see the mistakes for questions go down as you truly master the DS&A type. Don’t be afraid to spend more time to master a type. Spending an extra few days to learn something well is better than knowing a little about a lot of types.
6) Write your own Unit Tests
Writing tests are just a part of life for software engineers. Though your degree, bootcamp or side projects may not have called for tests, you better believe that your manager will scoff at the idea of pushing your untested code to prod.
Something that I found very helpful in writing better solutions for DS&A questions was to write unit tests for them. At first it seemed like a waste of time. Why should you write a unit test for reversing a string?
As I moved into more difficult questions, I quickly found that I was writing unmaintainable code. This was evident by my trouble in writing good tests to test each part of my solution. While testing can be seen as a painful task, if you write good code that you understand then you should have no problem testing it.
By writing unit tests for all my solutions I accomplished two things. First, I was forced to write cleaner and more testable code. Nobody likes spaghetti code, and having a time limit is no excuse for making pasta. The second thing this accomplished was a better understanding of JavaScript’s Jest testing tools. Though I work with Rspec now, this practice of writing unit tests greatly helped me grow in understanding how to structure and write good tests.
Like the journal, writing tests will take more time but will lead to a better understanding of your code and cleaner, more optimal solution.
7) Read Through Others’ Solutions
Most DS&A question test sites will have a solutions or comments section for each of their questions. While you should not look at this section until after you have attempted the question, these sections are an extremely valuable resource for learning new and more optimal approaches to a problem.
Many times other users’ solutions will give their time and space complexity which you can use as a benchmark for your solution. Their approach may use shorthand syntax that is an industry standard, but is unknown to you as a beginner. You may even find approaches that are not well suited for the current problem, but are perfect for other questions you may see later on.
A useful exercise I found was after reading through a good solution, I would move to something else for 10 minutes and then return to the question to try it again. Without looking at the solution, I would try to answer the question with this new approach. This forced me to learn and think through code rather than just read different solutions.
In learning to write better code you need to read a lot of other people’s code. By seeing different approaches and syntax, you will better understand what will and won’t work for your own code.
8) Diversify you Study Tools
Most people are familiar with Leetcode as a great site to practice their DS&A skills, but there are many other resources to use. One mistake beginner programmers may make is to choose only a single resource for practice. Every site has a slight to extreme difference in how they approach problems. Only having exposure to one site can lead you to be blindsided during technical interviews.
I started out doing practice problems on Codewars and felt confident in my abilities to solve interview questions. It wasn’t until I took and bombed a HackerRank assessment that I realized I was overconfident in my abilities. While not entirely different, HackerRank had enough quirks with the IDE that under a time pressure I did not perform as I wanted to. From this experience I decided that I needed to diversify my study tools.
I started working through a healthy assortment of questions from Leetcode, Codewars and HackerRank as well as studying chapters of Cracking the Coding Interview by Gayle McDowell. From getting exposure to different questions, different ways questions were asked and different development environments, I helped prevent any more freeze ups during interviews. When the IDE wasn’t exactly what I had coded on before, or when the questions were worded ambiguously, I still had enough diverse experiences to keep calm and ace my interviews.
9) Lose Yourself in Language Docs
While you rush through DS&A questions and answer them as quick and possible, you may forget the point of this exercise in the first place. Yes, you are answering these questions so you are familiar with the question types for future technical interviews. Remember that even more important than cramming 50 solutions in your head is learning the approach for writing quality, scalable code as well as learning the nuances of your chosen language.
It’s okay to spend 30 minutes on MDN to answer a question that takes 5 minutes to code. It is okay to go 3 Stack Overflow threads deep to understand an array method. The point of these exercises isn’t always to race through as many as you can. Your ultimate goal is gaining a better understanding of DS&A and your chosen language so you can rip through the questions in interview and write great code at your job. Don’t underestimate the power of a deeper understanding of DS&A and your language’s nuances for your daily coding arsenal.
10) “Get to” vs. “Have to”
I’m not going to lie and tell you that DS&A is the most exciting and fulfilling part of software engineering. There’s a reason why so many new developers struggle with technical interviews and why more experienced developers avoid DS&A. The concepts are hard, dry and often boring.
To start a new project or language is fun and exciting. To stick with it and deploy a finished project or complete a project in a new language is hard and frustrating. DS&A takes this a step further by being purely conceptual. Yes, you can dress up a question by adding a story to it or renaming linked lists as movie theater patrons, but there’s no getting past what you’re solving is a basic data structure.
When I was having trouble learning trees or sorting algorithms I thought about quitting. Not software engineering, but certain data structures. To me, these were items I had to learn. Every day I had to sit down and solve problems, or read posts and watch videos on DS&A theory. This mindset is toxic and can kill even the most ambitious learner’s drive.
What I found helpful, not only in getting me through the questions but to the point of enjoying learning DS&A, was reframing my study as an opportunity. Sitting down with Cracking the Coding Interview each morning was an opportunity I got to have to practice my DS&A knowledge. Learning hashes and heaps inside and out was something I got to do to allow me to apply them more efficiently in the real world.
The wording of my thoughts on studying seems subtle, but it made all the difference in excelling. Having to do something seems like a chore or punishment. When you get to choose to learn and choose to grow, any task becomes much more enjoyable. Start being active in your learning and make the choice. With a different outlook, I guarantee you’ll see an improvement.
Final Thoughts
Your journey to being a great software engineer is a never ending climb. There will always be a new language or framework to learn. While the tools you use change, the means by which you learn them will not. Having a thorough understanding of data structures and algorithms will make learning more fun and quicker.
Don’t get lost in the goal you strive for. Whether it is a first job, or a new job, every time you touch a keyboard is an opportunity to become a more knowledgeable and proficient programmer. Never forget this daily opportunity and enjoy the journey to whatever your goal may be.
