Month: August 2020

First… the good

There is a lot of good in Cracking the Coding Interview (CTCI), especially if you’re coming from a nontechnical coding background, or making a career switch into software engineering.

That’s because going through CTCI is almost like going through a condensed ‘greatest hits’ session of undergraduate CS, and is arguably more comprehensive than many algorithm classes you may take in college.

If you haven’t gotten up to speed on most data structures and algorithms, this is a really good primer, with a lot more practice than you would probably get through interview courses.

My positive review ends here, not because I don’t think there is anything else good to say about the resources (there almost undoubtedly is, the 6th edition book is almost 700 pages!), but because it’s the best selling software engineering prep resource out there. Many people, including myself, have used it to prepare for interviews, so it hardly needs someone to sing its’ praises.

My Critique

My critique mainly falls into 4 categories:

1. A decent amount of ‘useless’ information
2. Not frequently updated enough
3. Specialized interviewing isn’t available
4. Architecture is pretty bare bones

‘Useless’ Information

There are a decent amount of chapters that are thrown into CTCI that don’t seem particularly relevant for engineering interviews in 2020 and beyond. Namely the ‘Math and Logic Puzzles’, C++ and Java sections. These all feel like afterthoughts and are placed rather randomly in the book.

Furthermore I have never seen any of these concepts tested in an actual live interview with FAANG type companies, larger funded startups or otherwise. These questions seem to focus on a smattering of concepts like primality and probability, but not thoroughly enough to be useful to someone like an actual Data Scientist or AI Researcher, and lord knows when you would get them as a general purpose SWE.

The same goes for these oddly language specific questions UNLESS your role / interview is highly language specific… in which case you likely need an entire other book dedicated to that. Interviewers these days will let you code in any language you’re comfortable in, so it seems strange to dedicate entire chapters to these concepts.

Not Frequently Updated Enough

Unfortunately there isn’t much that can be done about this when it comes to media like CTCI. It’s a book… that needs new editions every so often.

Unfortunately a lot of the content in CTCI needs to be updated frequently to change with the landscape. I mentioned that the book is a good primer, however I’ve noticed a significant uptick in the last few years in the difficulty of problems amongst large tech companies. Frequently companies are now asking ‘hard’ style dynamic programming questions even in technical screens as the bar has been raised. That means that ‘easy’ questions are borderline useless (except to teach a concept for the first time).

Furthermore, because many of the problems are ‘categorized’ (until you get to the moderate and hard sections) you have the initial hint of what the problem subject area is, which can give a false sense of confidence. One of the most important areas of practice is actually categorizing the ‘type’ of problem.

I have seen a bit of a deviation in some companies in terms of the style of interviews they give. While many of the largest companies still adhere to the straightforward white-boarding style interview, I have seen a significant uptick in pair programming / debugging in a codebase style of interview.

It would be great to at the very least touch on these other interview formats.

Specialized Interviewing Isn’t Available

This is the most nitpicky of these sections. CTCI in many ways is obviously aiming to be the one stop shop for ‘generic’ programming interviews. That means that it serves best as a primer and practice for things like Algorithms, Data Structures and the like.

It is curious then, that CTCI contains sections on things like Java and C++ specific knowledge. Most engineering interviews at top companies now let you choose any language of your choice: C++, Java, Javascript, Python… you name it (unless the language in question can’t handle a particular style of question, ie Javascript for multithreading questions).

I find these sections to be almost wholly useless as it should be fairly apparent whether or not this knowledge will be tested… in which case there are far better in depth resources on languages out there than CTCI. These sections of the book would be better filled with additional content (see my next point on architecture) or omitted altogether. Along with the brain teasers and math section they feel like filler.

The solution to this might be to add more specialized sections to CTCI that focused on subject areas (as opposed to language specific questions). We are now living in a time where things like specialized questions for Front End, Mobile and Machine Learning engineers exist. Primers for these subjects would be wholly useful depending on which specialized interview loop you enter into.

In the case of Front End interviews the knowledge of CS concepts is VERY tightly coupled with knowledge of Data Structures as they relate to the DOM, and Javascript language questions. As a result questions found in CTCI very superficially resemble anything you would receive on such an interview.

Similarly an ML interview will have questions on statistics, probability, tuning models, and optimization (math will actually show up during an interview).

I understand that it may be out of scope for this book, but then so are the sections on brain teasers and languages.

Architecture is Pretty Bare Bones

The architecture section of CTCI is… well it just isn’t very good.

All of the superfluous sections mentioned above should be ripped out for a far more thorough review of this section. There is a very low likelihood that studying this section will help you ‘crack’ anything.

In CTCI’s defense: architecture is hard… really hard. A lot of knowledge in this domain is built up through years of experience or by supplementing experience with a deep understanding of systems. However the suggestions here are VERY high level (with only passing mention of something like MapReduce, which would be beneficial to know about on a deep level).

I highly recommend that someone studying for this portion of the interview do their study in 3 main ways:

1. Pick up a copy of Designing Data Intensive Applications
2. Watch architecture videos of ACTUAL important systems on a place like InfoQ
3. Try and design a system (preferably one that has a detailed blog post) and compare… how did you do? Did you think of all the edge cases? Did you make the same tradeoffs? How robust was your system. I’ve found this to be the most illuminating.
4. Revisit your own career and think about the systems YOU made and the tradeoffs that were taken

This post will cover some of my favorite resources for problem solving. There will be a software bent to the suggested books, however my intent is not to simply provide the “best interview prep resources” but rather those which will help make you a more effective thinker in the field.

How to Solve It

I’ve saved the best for first. This book is the most ‘general’ problem solving centric book of the group. “How to Solve It” is a classic, written by legendary mathematician George Polya.

While there is a mathematical bent to the book (especially in the examples given), the math is rudimentary. It is mostly a stand in for general problem solving techniques.

Some of the general ideas in this book involve looking for smaller problems to solve (that are similar to the one at hand), knowing whether you have seen similar problems before, thinking of a corollary to a problem and solving that… etc. The topics are too numerous to list here, and Polya does an exhaustive job of listing all the possible ways one could try and digest a problem.

What stands out to me about this book is not its place as a problem solving manual, but Polya’s love for problem solving as a path to deeper discovery. Polya advocates for deconstructing and revisiting a problem even after you’ve solved it for deeper insight. This in turn will lead to a deeper toolkit.

Indeed, where you might be able to, for example, pass a programming interview through sheer brute force of solving A LOT of problems, Polya reminds us that some of the joy of problem solving is not always about results. He instead reminds us to treat problem as an art.

The Algorithm Design Manual

As is the case with Polya’s “How to Solve It”, “The Algorithm Design Manual” is fun. If you had to choose a well rounded but descriptive book on Algorithms, I would recommend this one above all others. While the famous Cormen “Introduction to Algorithms” is more thorough (giving detailed mathematical analysis of all algorithms presented in this book) it is often dense and unwieldy for the budding computer science student.

Where Skiena’s book shines is in its depth of content (covering all major topics you would expect in an Algorithms textbook), engaging writing, and the inclusion of “War Stories”, and practice problems.

The “War Stories” sections in particular stand out because they highlight real world practical use cases for many of the presented algorithms. Somehow, with this book, Skienna managed to find some perfect intersection of academic textbook, interview prep book, and technical blog post without losing much of anything in the process.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Ok, so this one isn’t a ‘problem solving’ book per se. But, it’s the first book that comes to mind when someone asks me how to ‘learn’ about application architecture.

The truth is, this is a domain where there is no shortcut. Unlike algorithms there often are no ‘best’ solutions to the infinite variations of architecture problems you may encounter. Worse yet, I often find example prep problems to be shallow in their solutions.

Algorithmic problems are neat little packages which contain many small techniques strung together. Even when solutions to these problems becomes ambiguous it is because there is a time / space tradeoff. These tradeoffs are the precipice of architecture problems.

Therefor, the best I feel I can provide in this domain is to give the best / most concise resource of possible solutions, which are contained in this book.
The truth is answering canned architecture interview questions well usually depends on: – how much depth of experience you have at work- how well you know what the possible options are (where this book comes in)- Conference talks (think infoQ) or in depth technical blog posts by some of your favorite engineering teams