I originally created this as a short to-do list of study topics for becoming a software engineer,
but it grew to the large list you see today. After going through this study plan, I got hired
as a Software Development Engineer at Amazon!
You probably won't have to study as much as I did. Anyway, everything you need is here.
The items listed here will prepare you well for a technical interview at just about any software company,
including the giants: Amazon, Facebook, Google, and Microsoft.
This is my multi-month study plan for going from web developer (self-taught, no CS degree) to software engineer for a large company.
This is meant for new software engineers or those switching from
software/web development to software engineering (where computer science knowledge is required). If you have
many years of experience and are claiming many years of software engineering experience, expect a harder interview.
If you have many years of software/web development experience, note that large software companies like Google, Amazon,
Facebook and Microsoft view software engineering as different from software/web development, and they require computer science knowledge.
If you want to be a reliability engineer or operations engineer, study more from the optional list (networking, security).
When I started this project, I didn't know a stack from a heap, didn't know Big-O anything, anything about trees, or how to
traverse a graph. If I had to code a sorting algorithm, I can tell ya it wouldn't have been very good.
Every data structure I've ever used was built into the language, and I didn't know how they worked
under the hood at all. I've never had to manage memory unless a process I was running would give an "out of
memory" error, and then I'd have to find a workaround. I've used a few multidimensional arrays in my life and
thousands of associative arrays, but I've never created data structures from scratch.
It's a long plan. It may take you months. If you are familiar with a lot of this already it will take you a lot less time.
How to use it
Everything below is an outline, and you should tackle the items in order from top to bottom.
I'm using GitHub's special markdown flavor, including tasks lists to track progress.
Create a new branch so you can check items like this, just put an x in the brackets: [x]
Some videos are available only by enrolling in a Coursera or EdX class. These are called MOOCs.
Sometimes the classes are not in session so you have to wait a couple of months, so you have no access.
I'd appreciate your help to add free and always-available public sources, such as YouTube videos to accompany the online course videos.
I like using university lectures.
Get hands-on practice with over 100 data structures and algorithm exercises and guidance from a dedicated mentor to help prepare you for interviews and on-the-job scenarios.
You need to choose a language for the interview (see above).
Here are my recommendations by language. I don't have resources for all languages. I welcome additions.
If you read through one of these, you should have all the data structures and algorithms knowledge you'll need to start doing coding problems.
You can skip all the video lectures in this project, unless you'd like a review.
This list grew over many months, and yes, it kind of got out of hand.
Here are some mistakes I made so you'll have a better experience.
1. You Won't Remember it All
I watched hours of videos and took copious notes, and months later there was much I didn't remember. I spent 3 days going
through my notes and making flashcards, so I could review.
Keep in mind I went overboard and have cards covering everything from assembly language and Python trivia to machine learning and statistics. It's way too much for what's required.
Note on flashcards: The first time you recognize you know the answer, don't mark it as known. You have to see the
same card and answer it several times correctly before you really know it. Repetition will put that knowledge deeper in
your brain.
An alternative to using my flashcard site is Anki, which has been recommended to me numerous times. It uses a repetition system to help you remember.
It's user-friendly, available on all platforms and has a cloud sync system. It costs $25 on iOS but is free on other platforms.
3. Start doing coding interview questions while you're learning data structures and algorithms
You need to apply what you're learning to solving problems, or you'll forget. I made this mistake. Once you've learned a topic,
and feel comfortable with it, like linked lists, open one of the coding interview books and do a couple of questions regarding
linked lists. Then move on to the next learning topic. Then later, go back and do another linked list problem,
or recursion problem, or whatever. But keep doing problems while you're learning. You're not being hired for knowledge,
but how you apply the knowledge. There are several books and sites I recommend.
See here for more: Coding Question Practice.
4. Review, review, review
I keep a set of cheat sheets on ASCII, OSI stack, Big-O notations, and more. I study them when I have some spare time.
Take a break from programming problems for a half hour and go through your flashcards.
5. Focus
There are a lot of distractions that can take up valuable time. Focus and concentration are hard. Turn on some music
without lyrics and you'll be able to focus pretty well.
What you won't see covered
These are prevalent technologies but not part of this study plan:
SQL
Javascript
HTML, CSS, and other front-end technologies
The Daily Plan
Some subjects take one day, and some will take multiple days. Some are just learning with nothing to implement.
Each day I take one subject from the list below, watch videos about that subject, and write an implementation in:
C - using structs and functions that take a struct * and something else as args
C++ - without using built-in types
C++ - using built-in types, like STL's std::list for a linked list
Python - using built-in types (to keep practicing Python)
and write tests to ensure I'm doing it right, sometimes just using simple assert() statements
You may do Java or something else, this is just my thing
Practice, practice, practice, until I'm sick of it, and can do it with no problem (some have many edge cases and bookkeeping details to remember)
Work within the raw constraints (allocating/freeing memory without help of garbage collection (except Python or Java))
Make use of built-in types, so I have experience using the built-in tools for real-world use (not going to write my own linked list implementation in production)
I may not have time to do all of these for every subject, but I'll try.
This is a short book, but it will give you a great handle on the C language and if you practice it a little
you'll quickly get proficient. Understanding C helps you understand how programs and memory work
Gotcha: you need pointer to pointer knowledge:
(for when you pass a pointer to a function that may change the address where that pointer points)
This page is just to get a grasp on ptr to ptr. I don't recommend this list traversal style. Readability and maintainability suffer due to cleverness.
dequeue() - returns value and removes least recently added element (front)
empty()
Implement using fixed-sized array:
enqueue(value) - adds item at end of available storage
dequeue() - returns value and removes least recently added element
empty()
full()
Cost:
a bad implementation using linked list where you enqueue at head and dequeue at tail would be O(n)
because you'd need the next to last element, causing a full traversal each dequeue
enqueue: O(1) (amortized, linked list and array [probing])
You probably won't see any dynamic programming problems in your interview, but it's worth being able to recognize a problem as being a candidate for dynamic programming.
This subject can be pretty difficult, as each DP soluble problem must be defined as a recursion relation, and coming up with it can be tricky.
I suggest looking at many examples of DP problems until you have a solid understanding of the pattern involved.
Videos:
the Skiena videos can be hard to follow since he sometimes uses the whiteboard, which is too small to see
Know about the most famous classes of NP-complete problems, such as traveling salesman and the knapsack problem,
and be able to recognize them when an interviewer asks you them in disguise.
You can expect system design questions if you have 4+ years of experience.
Scalability and System Design are very large topics with many topics and resources, since
there is a lot to consider when designing a software/hardware system that can scale.
Expect to spend quite a bit of time on this
For even more, see "Mining Massive Datasets" video series in the Video Series section
Practicing the system design process: Here are some ideas to try working through on paper, each with some documentation on how it was handled in the real world:
This section will have shorter videos that you can watch pretty quickly to review most of the important concepts.
It's nice if you want a refresher often.
Series of 2-3 minutes short subject videos (23 videos)
Now that you know all the computer science topics above, it's time to practice answering coding problems.
Coding question practice is not about memorizing answers to programming problems.
Why you need to practice doing programming problems:
Problem recognition, and where the right data structures and algorithms fit in
Gathering requirements for the problem
Talking your way through the problem like you will in the interview
Coding on a whiteboard or paper, not a computer
Coming up with time and space complexity for your solutions
Testing your solutions
There is a great intro for methodical, communicative problem solving in an interview. You'll get this from the programming
interview books, too, but I found this outstanding:
Algorithm design canvas
No whiteboard at home? That makes sense. I'm a weirdo and have a big whiteboard. Instead of a whiteboard, pick up a
large drawing pad from an art store. You can sit on the couch and practice. This is my "sofa whiteboard".
I added the pen in the photo for scale. If you use a pen, you'll wish you could erase. Gets messy quick. I use a pencil
and eraser.
Think of about 20 interview questions you'll get, along with the lines of the items below. Have 2-3 answers for each.
Have a story, not just data, about something you accomplished.
Why do you want this job?
What's a tough problem you've solved?
Biggest challenges faced?
Best/worst designs seen?
Ideas for improving an existing product
How do you work best, as an individual and as part of a team?
Which of your skills or experiences would be assets in the role and why?
What did you most enjoy at [job x / project y]?
What was the biggest challenge you faced at [job x / project y]?
What was the hardest bug you faced at [job x / project y]?
What did you learn at [job x / project y]?
What would you have done better at [job x / project y]?
Have questions for the interviewer
Some of mine (I already may know answer to but want their opinion or team perspective):
How large is your team?
What does your dev cycle look like? Do you do waterfall/sprints/agile?
Are rushes to deadlines common? Or is there flexibility?
How are decisions made in your team?
How many meetings do you have per week?
Do you feel your work environment helps you concentrate?
What are you working on?
What do you like about it?
What is the work life like?
How is work/life balance?
Once You've Got The Job
Congratulations!
Keep learning.
You're never really done.
*****************************************************************************************************
*****************************************************************************************************
Everything below this point is optional.
By studying these, you'll get greater exposure to more CS concepts, and will be better prepared for
any software engineering job. You'll be a much more well-rounded software engineer.
*****************************************************************************************************
*****************************************************************************************************
Additional Books
These are here so you can dive into a topic you find interesting.
Important: Reading this book will only have limited value. This book is a great review of algorithms and data structures, but won't teach you how to write good code. You have to be able to code a decent solution efficiently
AKA CLR, sometimes CLRS, because Stein was late to the game
The first couple of chapters present clever solutions to programming problems (some very old using data tape) but
that is just an intro. This a guidebook on program design and architecture
Additional Learning
I added them to help you become a well-rounded software engineer, and to be aware of certain
technologies and algorithms, so you'll have a bigger toolbox.
Know at least one type of balanced binary tree (and know how it's implemented):
"Among balanced search trees, AVL and 2/3 trees are now passé, and red-black trees seem to be more popular.
A particularly interesting self-organizing data structure is the splay tree, which uses rotations
to move any accessed key to the root." - Skiena
Of these, I chose to implement a splay tree. From what I've read, you won't implement a
balanced search tree in your interview. But I wanted exposure to coding one up
and let's face it, splay trees are the bee's knees. I did read a lot of red-black tree code
Splay tree: insert, search, delete functions
If you end up implementing red/black tree try just these:
Search and insertion functions, skipping delete
I want to learn more about B-Tree since it's used so widely with very large data sets
In practice:
From what I can tell, these aren't used much in practice, but I could see where they would be:
The AVL tree is another structure supporting O(log n) search, insertion, and removal. It is more rigidly
balanced than red–black trees, leading to slower insertion and removal but faster retrieval. This makes it
attractive for data structures that may be built once and loaded without reconstruction, such as language
dictionaries (or program dictionaries, such as the opcodes of an assembler or interpreter)
In practice:
Splay trees are typically used in the implementation of caches, memory allocators, routers, garbage collectors,
data compression, ropes (replacement of string used for long text strings), in Windows NT (in the virtual memory,
networking and file system code) etc
These are a translation of a 2-3 tree (see below).
In practice:
Red–black trees offer worst-case guarantees for insertion time, deletion time, and search time.
Not only does this make them valuable in time-sensitive applications such as real-time applications,
but it makes them valuable building blocks in other data structures which provide worst-case guarantees;
for example, many data structures used in computational geometry can be based on red–black trees, and
the Completely Fair Scheduler used in current Linux kernels uses red–black trees. In the version 8 of Java,
the Collection HashMap has been modified such that instead of using a LinkedList to store identical elements with poor
hashcodes, a Red-Black tree is used
In practice:
For every 2-4 tree, there are corresponding red–black trees with data elements in the same order. The insertion and deletion
operations on 2-4 trees are also equivalent to color-flipping and rotations in red–black trees. This makes 2-4 trees an
important tool for understanding the logic behind red–black trees, and this is why many introductory algorithm texts introduce
2-4 trees just before red–black trees, even though 2-4 trees are not often used in practice.
Fun fact: it's a mystery, but the B could stand for Boeing, Balanced, or Bayer (co-inventor).
In Practice:
B-Trees are widely used in databases. Most modern filesystems use B-trees (or Variants). In addition to
its use in databases, the B-tree is also used in filesystems to allow quick random access to an arbitrary
block in a particular file. The basic problem is turning the file block i address into a disk block
(or perhaps to a cylinder-head-sector) address
MIT 6.851 - Memory Hierarchy Models (video)
- covers cache-oblivious B-Trees, very interesting data structures
- the first 37 minutes are very technical, may be skipped (B is block size, cache line size)
k-D Trees
Great for finding number of points in a rectangle or higher dimension object
I added these to reinforce some ideas already presented above, but didn't want to include them
above because it's just too much. It's easy to overdo it on a subject.
You want to get hired in this century, right?