In my previous post, I talked about how I was in the job market for over a year and a half, going over my interview prep and thinking about all the types of questions they would ask. This post is a response to those questions, preparing for those interviews by really studying up and hitting the textbooks as if I were back in college.
- Code Complete, by Steve McConnell
- System Design Interview, by Alex Xu
- C++ Software Design, by Klaus Iglberger
- Grokking Algorithms, by Aditya Y Bhargava
- Coding Interview Patterns, by Alex Xu
- Cracking the Code Interview, by Gayle Laakmann McDowell
- Learn C++ By Example, by Frances Buontempo
- The Software Engineer’s Guidebook, by Gergely Orosz
Code Complete, by Steve McConnell
An absolutely massive book of 900 pages… this was kind of a… weird? read, honestly, despite how popular it is. The text shows its age, having published in 2004. The book feels like it leans towards more theory, more about the processes of software development. While it may appear comprehensive with how fat this book is, it really is just an overview of dozens of subjects. There’s a lot of sections that I feel are more geared toward junior developers (I had actually bought this book during my first year out of college, and while I hadn’t gone through the entire book at that time, I did feel like it was more helpful then). Overall it felt like everything was a nice refresher, but nothing really felt new to me, nor did it feel too helpful in regards to interview prep.
The book starts with software construction and high quality code. Focus on construction, requirements, design. Define your coding conventions as a team. Write code for humans first. Code defensively, but not too defensively. Lay out your code structure starting with pseudocode. These are pretty important, but pretty general concepts overall. As a senior engineer you’ll know about all these, but it’s nice to go over how you can improve on this. As a junior engineer, these might not be as relevant since you’re often not the one making the initial design, requirements, etc. In regards to interview prep, this helps a bit in focusing more on the bigger picture, like double checking your requirements before diving into a interview question.
Then there’s the basics of actual programming, variables and statements. Variable names (make sure they’re clear and make sense), data types (avoid overflow, magic numbers, check for potential off-by-one errors in arrays), if-else statements (is the nominal path clear), and loops (are you using the right loop) – these are really quick skims, probably even for junior devs. I could’ve skipped these chapters entirely, but skimmed through it in case they had random useful tidbits of info (I don’t think they did).
Then it goes into concepts of code improvement and craftsmanship like quality assurance, pair programming, testing, debugging, refactoring, using programming tools, layout and style, writing self-documenting code. All nice to know, and again pretty broad subjects in general. But nothing really in terms of interview prep.
Overall a book I could have passed, but at the same time I’m glad I had time to churn through such a book that everyone has praised so much about. Unfortunately that praise was from over 10 years ago. I still picked up some random tidbits of info here and there. But man, 900 pages haha.
System Design Interview, by Alex Xu
This was a book that every senior engineer seemed to recommend – however, it didn’t seem too useful for me who’s more in embedded development. Majority of software engineering jobs are web-based, with a significant need for scaling to handle millions of users. But this isn’t the case for embedded software where only one user, if not a few, will be using it at a time. It also doesn’t help that literally every content creator in tech works for web (including all of FAANG), so there was a HUGE emphasis on studying system design.
Either way, I thought this was something I should prepare for, as I was looking for senior positions after all. Maybe it was just something I missed out on while with my last company. It turns out however that my skillset actually barely carries over to web services, where you also need to know databases, cloud platforms, distributed systems, and more. Even if they used the same languages that I knew (primarily C++ and C#), it didn’t matter if I was missing everything else. Because of this, I ended up not having to answer any system design questions after all.
Regardless, I felt like preparing for this felt really beneficial in general senior level thinking. Understanding the scope and requirements of a problem, start answering the problem at a high / broad level, then really honing in (deep dive) on a module. Knowing what kinds of questions you should ask the interview regarding clarifying assumptions, and understanding how to make assumptions given a lack of info.
C++ Software Design, by Klaus Iglberger
This was my favorite out of all the books I went through. I learned a ton about software design and architecture, SOLID principles, and design patterns. The author made the book a pretty fun read as well, e.g. with some poor dad jokes here and there, and things like “…your favorite programming book, like this one!”
Regarding SOLID principles, this was something that I only kind of knew about, but never truly understood at a fundamental level. This is actually a HUGE red flag for a senior level engineer. But in my first project out of college, majority of my coworkers were similar new grads, and the senior devs never brought SOLID up at all. Similarly with my second project, majority of my coworkers had about the same amount of experience as me, barring one coworker who had over double. The second project was however more about improving upon a legacy system, not so much designing a new system from scratch. Overall, the lack of exposure to SOLID principles over the years might’ve been the most detrimental part of my growth as a software engineer.
Iglberger however breaks down each principle super clearly, teaching us how code that doesn’t adhere to the principle is bad, and how the principle makes everything so much nicer and easier. Majority of it comes down to preferring composition over inheritance, using interfaces and passing them in to classes. Prefer how things are done, rather than what is done. Abstraction over implementation. All of these concepts complement each other so well, especially in the way the author presented them.
Then he breaks down design patterns, explaining how they can be really useful (and also how they can be detrimental). Majority of design patterns make maintainability and readability easier, at the cost of a bit of performance. They also make collaboration among teams easier, assuming the team is aware of those design patterns (and if not, it makes a great learning experience for them). Similar to my experience with SOLID, it was rarely brought up by coworkers, and it doesn’t help that the second project was on improving legacy systems.
These concepts were ubiquitous across interviews, and rightfully so. No wonder I was zero luck when starting out on my interviews! Fortunately this was one of the first books I read after getting laid off – and even more fortunate in how I even encountered this book in the first place (I don’t even remember). After this book, as I interviewed more and more, I got more comfortable answering these questions. Maybe half of them asked about SOLID, and a quarter asked about design patterns.
My first time making it to the final round of an interview process happened before reading this book – I think I would’ve gotten the job if I read it sooner. They asked about my familiarity with design patterns, in which I said I barely had any. I asked that interviewer for examples, hoping to learning more about them in that moment (and presenting my curiosity and desire to learn – they noticed this as well and were more than willing to cooperate), but it was still the weakest part of my interview that day. Everything else went extremely well that day.
Knowing that design patterns were a major gap in my knowledge, I went out to seek a book on them, which was how I found this book. I went through it, and then had a second opportunity where I made it to the final round. They asked about design patterns as well, and I was able to explain several patterns (I think I broke down Strategy and Bridge) as if I had used them my entire career. My interviewer only had one response…
Unfortunately I still didn’t get that offer, and I wasn’t sure at what I was lacking that day. It was a pretty easy interview overall and answered everything correctly, so I think it could’ve been a matter of just answering the questions more confident and/or quickly compared to the other interviewees. Regardless, seeing this improvement thanks to going through this one book was an amazing feeling, and I knew I was on the right track.
Grokking Algorithms, by Aditya Y Bhargava
This was another book that was brought up everywhere online, so naturally I had to take on this book as well. However, I felt like I could’ve passed on this one as well. Majority of the concepts felt like they were made for junior engineers. On top of that, the book overall felt like it was written for non-programmers (so that algorithms become less intimidating), so the author didn’t really go too in-depth into them.
The first half went over simple algorithms like sorting, recursion, and hash tables. I was already super confident in these concepts, and with how the book was designed and written, I didn’t learn anything from this personally.
The latter half involved way more complicated algorithms however, including Dijkstra’s algorithm, dynamic programming, and greedy. Despite how complicated those are, they didn’t go too in-depth, instead just going over them as an introduction. I also didn’t expect interviews to go over such complicated algorithms (besides greedy) unless if I was going for a FAANG-esque company, which I wasn’t. I went through these chapters regardless and felt a bit (just a bit) more comfortable, though I knew I needed to practice them later on. Either way, I was never asked these types of questions in any interview.
Coding Interview Patterns, by Alex Xu
This was written by the same author who wrote the book on system design. Coincidentally, I had just finished that book around the same time that this book just got published, in November 2024. Despite how new this book is, thus with no reviews, I gave it a shot. After all, his book on system design was really helpful, and so was his content on ByteByteGo which I started skimming through after discovering the former.
This book is basically LeetCode in book form. Each chapter covers a specific algorithm, ones that aren’t covered in school but are common in interviews. Examples include 2-pointer, sliding window, prefix sums, backtracking, and more. I actually needed a nice, structured introduction to these concepts, and having them in this neatly packaged book was perfect for my needs. They didn’t cover over basic data structures – it assumes you already know enough of that, especially since there’s hundreds of books covering those already.
Each chapter starts with a general explanation of the algorithm and how one would solve the problem. Then after the introduction, they provide several LeetCode problems, with a solution written out exactly like the Editorial tab on LeetCode. You could argue that you could just go to LeetCode itself and practice those problems (I of course did while/after finishing this book), but I really appreciated the structure of this book – I think that really helped a lot in retention personally.
Cracking the Code Interview, by Gayle Laakmann McDowell
The classic… I had gone through this book while looking for my first job, and so I might as well go through it again since I already have it on my bookshelf. Turns out it wasn’t that helpful for me actually. This book focuses more so on data structures, with interview questions focusing on how to best use them. I think this is more for junior level roles – more senior level questions would be algorithm and pattern-based like what Alex Xu covers.
Alternatively, it could be that the overall difficulty of interviews have just gotten harder since this book was published back in 2008. Regardless, I gave this a quick skim, and it was a nice refresher as I started getting back into interviews.
Learn C++ By Example, by Frances Buontempo
I had mentioned in my previous post that interviewers asked a lot of questions regarding Modern C++ – this book was the solution, breaking down each new feature from C++11 to C++23. I had just discovered this book around a month after it was published in April 2024, and it looked like it presented itself to me just in time. I hadn’t actually been asked of any Modern C++ questions yet, but I did notice a lot of job listings requiring Modern C++ experience, so I decided to give this book a shot. I think this ended up being either my 2nd or 3rd most helpful book – it offered a LOT that I was missing out on.
The book starts off with pretty basic features, such as auto and ranges. I learned how “auto” is more than just convenience – in fact, convenience is literally the weakest reason as to why you use it. It’s a lot more than that; a lot of it comes down to abstraction. I also learned the rule of AAA, or “Almost Always Auto”, and was so surprised on how I nor any of my coworkers had never heard of this rule. But alas it’s actually omnipresent in any project that uses Modern C++. Ranges then go over iterating through for loops without an indexer variable, i.e. basically a “for each” in C#, or “for” in Python (without using range()), and why they’re preferred over the classic for loop.
They then went over optional, equivalent to a C# nullable type (e.g. “int?” type, which can be assigned to null). Ratios, suffix literals, and variants (also with visit). All these little things add up.
Lambdas were described in great detail as well. I had used them a little bit on the job previously, but never actually looked too deep into this subject. Learning how lambdas make implementation more flexible and more loosely coupled was the biggest takeaway here; practicing the actual execution of writing up lambda functions was extremely helpful as well.
Requirements and concepts introduced the idea of generic programming, making templates more restrictive, thus more readable and actually more flexible. The compiler is able to catch more errors when using templates, which is preferred over runtime errors that are much harder to catch and debug. Generics make a SIGNIFICANT part of Modern C++, so much that I feel like I need to go through an entire book dedicated to this subject. (I was looking into the book “C++ Templates: The Complete Guide” by David Vandevoorde, but this is a fat 800+ page book, plus interviewers had never actually asked me on generic programming, so this wasn’t high on my priority list. I really want to get to this soon though!)
Smart pointers (and RAII) were probably the biggest thing for me. Before reading through this section, I had been asked about smart pointers a few times in interviews… and it was clearly a red flag that I didn’t know about them. After reading about them… it was clearly a red flag in my last workplace in how it was never brought up there. There’s almost no reason not to use them either. I think it was just legitimately nobody on the team knew about them.
They also introduced new data structures, unordered maps and sets. These are basically optimized maps and sets, since majority of times you actually don’t need the data in these structures to be sorted. I had indirectly learned about these earlier on as I churned through LeetCode and saw how every solution used the unordered version. Regardless it was nice to read through an official lecture on these new data structures.
Coroutines were really complicated for me; I definitely need to revisit this concept soon. This basically allows multitasking within a single thread, using co_await, co_yield, co_return, and promises. This section was definitely a loaded one, but fortunately I hadn’t had any interviewers ask about this.
Parameter packs (using “…” in function parameters) seemed like a nice-to-know more than anything – a template parameter that accepts zero or more arguments. This replaces having to write multiple overloaded functions, making code more flexible and reusable. Just a neat way to improve your code, not a must unlike most of the above concepts.
All in all, this book was extremely helpful! This was also before I discovered “Effective Modern C++” by Scott Myers, which seems to be the book for Modern C++. I plan to go through this book soon too later this year.
The Software Engineer’s Guidebook, by Gergely Orosz
This book isn’t so much for interviews, but more so on what makes a software engineer a senior level one over a junior. It felt like a book I actually should’ve read as soon as I got an offer, knowing how to best tackle the new role. Nonetheless, now that I do have an offer!, there are some nice takeaways for me to try when I start work in just a few days.
It breaks down different career paths and different types of tech organizations, and how you can thrive in each unique environment, so I’d be prepared for whatever company I’d end up in. Similarly, it breaks these down even further, depending on your level of experience. It goes over tech lead and staff positions, but I’m not at those levels yet so I skipped on that. Basically it presents a roadmap for your future career, which I really appreciate.
The book also emphasizes heavily on recording the work you’ve done, week after week. He calls this a brag log, which helps for promotions as you show them to your supervisor in performance reviews to objectively list everything that you’ve done (including times when you’ve helped coworkers, when this may not be covered in JIRA tickets). This was my biggest takeaway from this book, as it’s definitely something I wish I had so I could better present myself in interviews and really hone in on specific problems and solutions.
And that’s everything! With over 2000 pages worth of knowledge… it’s been quite a year. I learned way more about software than any other year in my life, including college (since it’s usually combined with non-software classes) and employment (small nuggets of wisdom here and there accumulated over the years, coupled with raw experience). As I interviewed more and more, I learned what knowledge I was missing and what exactly I needed to learn to even stand a chance. And now that I have… I can’t believe I missed out on all this over the years. It makes me feel almost embarrassed, to be quite honest.
That said, that shows just how important it is to continue learning outside of work. I really need to dedicate time outside of work hours just learning what the rest of the tech world up to, watching videos and reading Substacks to see what I’m missing. And from there I can see what books I could find to fill in what I’m lacking. I never gave any priority to this outside of work, but now that I’ve been… traumatized, by how much I was missing, now I know haha. Better late than never at least!
Kevin Who 