In mathematics and computer science, an algorithm is a sequence of instructions, typically to solve a class of problems or perform a computation. Algorithms are unambiguous specifications for performing calculation, data processing, automated reasoning, and other tasks.
I've always felt as though I had a good intuitive grasp on algorithms.
I never took an explicit "Algorithms" course in my college days, but I did touch upon some traditional acedemic algorithm stuff in some of my classes. I learned the basics of Big-O notation, and did some things in a data-structures course with traversing tree-structures, etc...
Understanding, authoring, and applying algorithms is core to what we do as software developers. Mind you, in day-to-day work I have never personally had to do a breadth-first-search of a binary tree, but every now and again there is something which really exercises the algorithm muscles.
Job interviews for software development positions often put a strong emphasis on algorithms. Frequently there are code challenges, many of which are on the whiteboard.
Many people have the opinion that whiteboard algorithm interview questions are not representitive of real-world skills, and disproportionately select for those who put in time to memorize common algorithms or those who are just out of CS university programs.
Some complaints include:
- Whiteboarding code is just not realistic
- You can just look up algorithms -- no need to do from memory
- You won't need this kind of algorithm development on the job.
In defense of algorithm whiteboard questions:
- Whiteboarding in general is an important skill and used frequently in some organizations.
- Some jobs really are algorithm heavy
- Even if its not realistic for day-to-day jobs, it will give insight into how a developer works under pressure, and how they think about complex problems.
But when it comes down to it, regardless of whether you think having a candidate do algorithm challenges provides valuable information for whether or not to hire them, if you're interviewing for software development jobs, you better expect to have to do some of this stuff.
At the time of writing, that's the situation I'm in. I've been interviewing quite a bit this last several weeks. Not every interview has been algorithm heavy, but there have been a few. I've done OK at these. I definitely would not say I've excelled, but I've generally been able to arrive at a solution with minimal prodding, and can have a reasonably good conversation about the performance characteristics, etc.
But what I would like to excel at this type of interview question -- and impress the heck out of the person interviewing me. As such, I'm going to try to kick off a personal effort to actually study and practice this stuff.
Confession: I think studying algorithms is exceeding dry and boring. And I love nerdy programming stuff. Practicing algorithms can also be a slog, but its beeter.
I tend to talk a lot of crap about higher education CS programs. They're not super practical -- they're often outdated -- and the classes are hit or miss. But this kind of fundamental stuff is where it really shines. Not to mention the accountability of being forced to study it so you pass the class.
Here are couple good books that I own which talk about algorithms. I've read less than half of each of these, but vouch for their quality.
- Introduction to Algorithms: This is a traditional sort of textbook on algorithms
- Cracking the Coding Inverview: this is ostensibly a "coding interview" book, but the bulk of it is actual exercises and solutions with analyses.
Practice whiteboarding with a friend. Or find a meetup group. Or create your own. This is likely the best, most realistic practice for actual job interviews, since it mimicks the atmosphere. If you're in a big "tech hub" city there will undoubtedly be groups out there doing this already.
These sites are where I plan to focus my efforts. It should be relatively easy to set aside 30 minutes every day or two to tackle a problem.
Check back soon -- I'll likely have more thoughts on this topic.