If you’re going to be a developer, you need to understand algorithms.

At its most basic definition, an algorithm is just a program. “print(“Hello, World!”)” is an algorithm, albeit a very boring one. As a software developer, your job boils down to reading and writing algorithms, or figuring out why and how some algorithms are wrong in certain circumstances. These algorithms are almost never the “fundamental algorithms” that pertain to sorting, searching, and graphs. However, the fundamental algorithms contain the language with which you can talk about algorithms.

The Two Things You Need to Know
At Atomic, we don’t expect developers to have a huge array of algorithms in their mental utility belts, ready to whip out and implement. But we do expect them to recognize when complexity requires a broad category of algorithmic approach, and then find and implement an appropriate (and cost-effective!) solution.

The way to prepare for this is to get experience in learning and applying fundamental algorithms to real problems. Conversely, you need to see how some algorithms will fail with certain kinds of problems.

Some types of problems can only be solved in reasonable amounts of time with very specific and sophisticated algorithms. We sometimes encounter these problems when solving business problems for our clients. Learning about time complexity will help you understand whether your program will finish executing before or after the earth is engulfed by the sun.

How to Get Good at Algorithms
You need to take an algorithms & data structures course. You could use Coursera’s algorithms course or some other online course (or one at a local college!). Work through the course while using the following resources:

*Cracking the Coding Interview*by Gayle Laakman McDowell

This is geared toward helping you pass an interview, but I find McDowell’s writing really helpful for understanding how to categorize and talk about CS concepts.*Introduction to Algorithms*by Cormen, Leiserson, Rivest, and Stein: This is a very abstract and math-based approach, but it is the definitive algorithms book. It’s sometimes called CLRS, because of the authors’ names.*Algorithm Design Manual*by Steven Skiena: There are a lot of practical C implementations and good advice in this book. It is a helpful counterbalance to CLRS’s abstraction.

**Mostly ignore the object-oriented bits of CS algorithms courses.**When I started looking at syllabi for this post, I was surprised to see a focus on object-oriented programming techniques. This is likely because algorithms courses should ask you to implement a data structure, and an object-oriented approach is the easiest way to do that. For instance, you might write your own hash table class and implement its hashing algorithm. Very basic knowledge of OO techniques is required. Just make sure you don’t dally too long in OO land.**Use whatever language you are comfortable with (or that the curriculum endorses).**If there is room for choice, use a dynamically typed language like Python. Using a statically-typed language (like C or Java) as a student forces you to learn how data is stored in memory*, which is great, but not especially helpful when you’re learning a high-level algorithm.

Learning algorithms is less fun than solving problems with them. In your quest to learn about algorithms, I recommend using my two favorite problem sets: Project Euler and Kattis.

Kattis is more accessible for fundamental algorithm problems, and there are a lot of online materials (like algo.is and blogs here) that can help you understand which problems correspond to which sorts of algorithms.

Aside from algo.is, you’ll need to look up which programming competition a particular problem is from, then see if the people who ran that competition published any commentary about the problem set. For example, here’s a problem set on Kattis (from the 2017 Mid-Atlantic) and an accompanying discussion that describes the time complexity of different solutions. You will need to learn to handle input from stdin in the programming language of your choice, since Kattis is going to run your code against a series of tests.

Project Euler is nice because each problem essentially takes the approach of, “Here’s a description of a really weird big number. Find it!” This gives you the freedom to not worry about i/o. There isn’t as much writing on the internet about Project Euler’s problem set, which is by design.

You are trying to do a hard thing, and you will need someone to get you unstuck. Especially if you’re in the Ann Arbor or Grand Rapids area, get in touch, and I will either be your mentor or find you one. If not, use Stephanie Hurlburt’s list of engineers willing to mentor you to find one in your area.

*Strictly speaking, static typing has nothing to do with how things are stored in memory. It happens to be true that two of the most common languages students use (C and Java) are both statically typed, and many of their types correspond with managing memory allocation. TypeScript is a great example of a statically typed language that couldn’t care two hoots about memory management, since it compiles to a dynamically-typed language (JavaScript).

This is part 2 of our Beyond Bootcamp series. Come back next weekend for the rest of the series.

- A Roadmap
- Understanding Algorithms
- Learning to Think Like a Programmer (next Friday)
- Expanding Your Skills into Other Domains (next Saturday)
- Finding a Community (next Sunday)

The post Beyond Coding Bootcamp, Part 2 – Understanding Algorithms appeared first on Atomic Spin.

- Beyond Coding Bootcamp, Part 1 – Learning Software Development without College
- How to Present Your Portfolio at a Software Design Job Interview
- Three Habits That Will Slowly Make You a Better Developer