Welcome Back, World!
This edition focuses on our younger audience who will be returning back to school in the fall. While we always suggest and have followed BTB’s guidance, we understand that not everyone’s path is the same. This is post is designed to help you secure your first (junior) role as a software developer (agnostic of the industry you decide). To a certain extent, this also applies for those aiming for FAANG positions, but our personal path was that of a Numeric/Software Developer (as outlined by BTB back in the WSP days).
There are many guides out there today, but we aim to focus on what worked for us.
We have broken down each step in sequential order below:
Interview Prep
Resume Review
Acing the Interview
Offer Negotiation
Interview Prep
Interview prep instead of resume prep comes first in our opinion. This is arguably the hardest part of the process given the current landscape for junior software developer positions that are worth pursuing. The time to complete this step in the process? 7-10 weeks. The steps to complete this are as follows:
Data Structures and Algorithms (1-2 weeks)
Programming Competitions and Problem Solving (4 weeks)
Systems Design (1-2 weeks)
The above can be applied for mid level positions as well, and to some extent, senior positions. If you followed our last two substack posts on getting started along with learning how to write code, chances are you may have already discovered some of what we are about to cover.
1. Data Structures and Algorithms
These tend to be covered in your typical undergraduate curriculum. Given the hype around CS these days, we have seen low substance programs that do not cover this in enough detail. If you are unsure of what a good reference is to understand where you are in your prep, refer to these books:
The Algorithm Design Manual by Steven S. Skiena
Introduction to Algorithms by Thomas H. Cormen (known as the CLRS book)
Algorithms by Robert Sedgewick
If much of the content in each of these seem foreign to you, you have much to catch up on. If not, you still have work to do. Your goal of the technical interview is to display practical applications and confidence in the usage of data structures and algorithms. Often times as an undergrad, you may be used to your text editors and IDEs, along with the compiler giving you helpful warnings or detailed reasons as to why your code is not compiling.
Our suggestion here to knock this section out of the park? Implement popular data structures like binary trees, hash maps, linked lists, stacks, queues, etc. by hand. This also includes popular algorithms such as mergesort and binary search by hand. Yes, we mean break out a notepad or whiteboard, and write them by hand without an IDE helping you. Once you are done, type out what you wrote and try to compile and run your code. Is it extreme? Maybe, especially given that more and more companies are relying on typing code in an editor these days. Does it minimize your chances of failure? Yes.
We encourage this approach since it helps you think and reason about your code, as well as develop a sense of what will work and what will not. The more your develop the ability of being able to look at a piece of code and understand what it will do without having to spend minutes compiling, running, reading the output, debugging, etc. the better you will be. Anyone we have seen do this has had a higher success rate in the interview process, and overall better at their jobs.
As you write by hand, you will have an easier time remembering things such as run time complexity, design trade offs, and avoiding pesky “off by 1” errors in your interview questions.
Again, YMMV, and our experience has been from a perpsective of software development that focuses on pure algorithm development. Other readers who have focused on other areas in technology will have a different view on this, and we welcome different opinions in our comments! For example, we have never built UIs, so someone who may be focused in that type of work may have different suggestions for you. In our experience so far, many interviews tend to focus on your foundations.
2. Programming Competitions and Problem Solving
Assuming you can easily code up the ability to implement the main data structures, along with the ability to implement widely taught algorithms in the above, now you need to practice using them. Many tend to skip #1 and go right to problem solving. Do not do this as you are setting yourself up for failure.
If you go into problem solving right away, you have a higher chance of solving the problem inefficiently. In today’s interviewing landscape, it is not a good look if you have an algorithm that takes O(n^2) time when an O(n) implementation is easily (and obviously) achievable.
Our main suggestions for prep are:
Leetcode
HackerRank
There are other sites such as Codility, but these two should suffice. Leetcode is arguably the most popular, and our personal go-to. Do sign up for Leetcode Premium, it is more helpful than you think. If you are part of the Jungle, you know that the price can easily be met by being smart. If you won’t invest in yourself, there is no saving you.
When using Leetcode, the approach should be as follows:
Timebox each question to 30 minutes. Do not look at the answer
Spend the first 5 minutes thinking of the solution in your head, pseudocode this on your notepad/whiteboard
Spend 20 minutes implementing the solution, brute force is fine in the beginning, and optimize for the remainder of the 20 minutes
Spend the last 5 minutes testing your code
If after 30 minutes you cannot figure it out, only then should you look at the answer. An alternative that we would encourage is to cut your teeth on the problem until you get an answer, if it takes days, so be it. However, we understand that you may be under a time constraint, and this tends to do the job as well.
In terms of problems to tackle, along with the appropriate distribution of problem difficulty, we would recommend:
50 Easy
80 Medium
25 Hard
If you can do more, great! We encourage you to do more if you can, but this is the bare minimum. At this point, you start to see patterns in the problems as you read the prompt, and can quickly figure out what the solution should be.
As you do these, there are weekly/bi-weekly programming competitions on various sites (including Leetcode). Please participate in as many of these as you can, since the solutions are not readily available. This forces you to think and not rely on looking up the answer. Yes, we are aware that FAANG may recycle questions, but it is better to be more prepared and knock it out of the park. In our experience, being better prepared can make a great impression for your career, and even lead to better compensation packages.
If you can comfortably complete programming competitions within the alotted time, you are in the ideal shape that we recommend.
3. Systems Design
This is a great topic, as you get more annd more experienced, this becomes key in the interviewing process. However, we have seen this pop up at a junior level to some extent. If you have been following us, you know by now that it is important to build things. The more you build, the more you will understand what makes a good system. Of course, depending on what your projects were, you may or may not have had the appropriate exposure (we have even seen seasoned 15+ YoE devs not work on sophisticated systems).
If you haven’t had the exposure, here are resources we recommend:
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann
Grokking the System Design Interview (found on Educative)
Our best suggestion is to go through both resources and try to implement specific portions that the authors refer to. For example, if you aren’t too familiar with weighted round robin load balancing, try implementing it to develop your understanding further. Again, we do not encourage the behavior of copying tutorials. Try it yourself first, and if you truly do get stuck, then go ahead and look up references.
When approaching these types of problems, you want to develop the following framework:
What are the requirements (i.e. what is this supposed to do)?
Based on the requirements, think of any edge cases and how to handle them
Based on #1 and #2, think about what you can do based on the resources above, along with your data structures and algorithms knowledge to solve the problem
Implement and test
In the beginning when you do not have much experience, it is difficult to grasp, so please keep building new projects. As you work on larger and larger projects, you begin to develop the ‘taste’ for design since you will come across things break in production, have to face unhappy clients (the client could even be yourself), and have to deliver under tight deadlines.
Final Comments on Interview Prep
As you continue, make sure you develop daily habits regarding practice. In the beginning, you will spend much more time on this since you may not be in interviewing shape. As you hit your stride after completing enough problems and familiar enough with design, you can allocate a couple of hours out of your day to keep practice on a daily basis to keep your skills sharp.
Resume Review
Now that you are in interviewing shape, time to focus on your resume. At this point, you should have a daily habit in place, and should be able to complete problems with a certain degree of ease. When it comes to your resume, focus on your impact based on what you did. When you are junior, this can be difficult as it depends on the quality of the projects that you worked on, and the opportunities to work on key products during your time at any internships you may have had.
Why does impact matter? Too many developers focus on the technologies they used. In reality, your foundations matter, and you can pick up the latest language/framework/tech stack since you now have the habit of continuously learning. What good is knowing the popular framework of the month if what you delivered does not make any money? Showing that what you did had a positive outcome on the bottom line, or if it boosted efficiency in some way is key.
Could some places care more about the technologies you worked with? Sure, but like we said, we are focusing on the first job in any industry that you choose. If you are targeting a specific niche like iOS development, your path may vary.
For convenience, we have placed one of our resumes here back when we were in college. You will notice at times we had impactful items to list, and at other times, not so much.
Some notes based on what we have above
If you mention your GitHub account, make sure your projects are polished. It should be indicative of the type of work you would deliver for someone who hires you
Do not worry about listing too many languages, and HTML/CSS is not a language. Many list far too many languages and get torched during the interview since they do not know everything they list well enough
Be modest, it is good to list your achievements, but do not misrepresent your experience such that you invite technical questions you wouldn’t know the answer to
Do angle your resume towards what you want to do next. For example, if you want to work at a HF, try to do projects in your spare time that could be quantitative in nature
Cover letters did not come up for us. We focused on career fairs/networking. In our experience, we interviewed, received the offer (or didn’t), and HR came in towards the end to finalize the comp, onboarding, etc.
Based on this, we were still able to land interviews at different FAANG companies and specific Numeric/Software Developer roles that we were targeting. In the end, we landed the role in the niche that we wanted following this format.
Acing the Interview
At this point, you have everything in place, but you were probably practicing in isolation with maybe some interaction on forums like Stack Overflow or the Leetcode comments for a specific question. To crush the interview, we recommend doing mock interviews. There are many different avenues here. Here is what we liked:
Pramp (a free mock interview service where you team up with one person to do one question each)
Interviewing.io (a paid service with interviewers from top companies)
Start with pramp first to get comfortable with coding while someone is watching. Our suggestion still applies here. Spend 5 minutes figuring out a solution, 20 to implement, 5 to test (5/20/5). Some suggest to ask friends but we recommend practicing with strangers since your interviewer will be someone you do not know.
Some additional notes about the interview:
Now that you have been practicing, you should not feel nervous. This means do not be a robot. People hire people, not robots.
Keep the interview as a conversation, don’t make it so Q&A. Discuss ideas on how to solve the problem, indirectly show your mastery
If you have a specific target to nail an offer for, do not interview for them first. Instead, “warm up” by interviewing at other companies first. Nothing beats actual practice by going in for the real deal
Offer Negotiation
Congrats! Here is the fun part, always have competing offers. In our experience, do not try to bluff your numbers with the recruiters. It is easier to have competing offers and try to have each company beat the others’ offer. However, the company’s “quality” matters in the eyes of the recruiter. For example, if you have offers from FAANG #1 and FAANG #2, #1 will try to beat #2’s offer and vice versa. However, if you have an offer from FAANG #1 and an offer from an unknown company, this may not work in your favor.
Some are good at bluffing, but we prefer to avoid this. Do your best, work hard, keep improving, and build your network by adding value. As you get offers, you can negotiate more and more. Worst case scenario? They think you’re great and you can always keep in touch. Remember, USTT isn’t the end game.
Extras
Thanks for making it this far! Here are some extra tips and takeaways over the years that helped us, and hopefully they help you:
There are many paid services out there to help you with this process. In fact, there are entire businesses built around interview prep. If you want to sign up for a paid service beyond Leetcode Premium, that is up to you. Our opinion on this is that all you need is discipline
Behavioral portions of the interview process are not difficult, you can easily search for these. In our experience it has been more of the standard questions like handling conflict, specific situations around miscommunication, etc.
Make good first impressions early in the interview. Cannot tell you how many times that most of the decision is made in the first few minutes
Learn sales, it applies everywhere and especially here. You would be surprised at how bad your competition is at sales since everyone is focused on being as technical as they can be.
Think bigger, i.e. do not be a code monkey. Show that you can think about a larger product, end user experience, managing resources, and how to get things done with multiple teams
Communicate clearly, and speak slowly
Conclusion
Like we said earlier, there are many guides available and the process can appear to be daunting. Your mileage will vary depending on where you are at in school, and your personal experience. For us, we learned this the hard way; we did not even know there was a process to begin with back then! We went to competitive schools where the competition didn’t want to let out their “edge”. Luckily with the Jungle, we can change this for the better.
The overall idea no matter which path you choose is to create a system to prepare, and continue to follow the process. As James Clear says, “You do not rise to the level of your goals. You fall to the level of your systems”.
If there are any questions, comments, suggestions, drop them below!
How To Get Your First $100,000+ USTT Software Developer Job in 2021
If someone hasn't had exposure, I would recommend this rather than DDIA.
https://github.com/donnemartin/system-design-primer
DDIA is expansive and not fit for a beginner IMO.
Hey discovered the jungle on accident but want to take advantage of the information . I’m 24 and currently a truck driver. Would you recommend me switching careers (basically starting over). If so how would you go about it? College/no college, interns, entry level job, etc?
Thanks