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.

1. Code Complete, by Steve McConnell
2. System Design Interview, by Alex Xu
3. C++ Software Design, by Klaus Iglberger
4. Grokking Algorithms, by Aditya Y Bhargava
5. Coding Interview Patterns, by Alex Xu
6. Cracking the Code Interview, by Gayle Laakmann McDowell
7. Learn C++ By Example, by Frances Buontempo
8. 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!

In November 2023, I was part of a company-wide layoff that affected hundreds of employees. It was a layoff that nobody on my team saw coming, not even my own project manager, who was so irrationally angry for me when he heard I was the only one on our team getting let go. I had worked there for over 8 years, as my first and only job out of college. Needless to say, I had never experienced anything like this.

Nearly 20 months later, I finally got an offer! With that out of the way now, I’ve been thinking a lot about the journey I’ve been through over the past year half, with how much I’ve struggled, how much I’ve learned, and just thinking about how merciless the job market is today.

I had left the company completely underprepared. I thought I was learning a lot about software, especially from senior engineers above me whom I talked to and worked with every single day. I was getting comfortable with writing code the way my fellow engineers did. And I was seeing common patterns when debugging issues and navigating through hundreds of files of a codebase, especially in the scope of the domain I was working with. But after going through a couple of interviews, it showed that what I knew barely mattered.

I hadn’t interviewed for other companies throughout that time, as I was really enjoying my time working there and felt like I was learning something new every day, even 8 years later. I thought I would’ve been fine going into an interview with just a bit of prep here and there, some LeetCode for a few days, looking up common software engineering interview questions, and I’d be fine. I wasn’t planning on going for FAANG, and I had a pretty easy time interviewing for my previous employer. It should be fine!

Well, with the title of this post here… clearly I wasn’t fine.

I realized that majority of my technical knowledge, I had rarely if ever actually explained to another person before. It’s really weird to know something that you work with every day, yet you can barely put it into words because you’ve never actually had to after nearly a decade. Relatively simple things, like in threading explaining what a critical section is, or in networking explaining the difference between sockets and pipes – these are all pretty basic things from college. But I could barely articulate my thoughts. It was like trying to translate whatever foreign language was in my brain, into English. Even if I was able to explain it, my confidence in my answers were so low just because it wasn’t a question I expected (plot twist, I didn’t know what questions to expect because I hadn’t been interviewing). And confidence is EVERYTHING.

Then they started throwing questions about concepts I had never even heard of, but were expected of me as I applied to senior roles. I work primarily with C++, a language that gets updated with new features every 3 years since 2011. For any version of C++ starting that year, we call it Modern C++; older versions were called Classic C++. My workplace had really only worked with classic C++ (technically Modern C++ from 2014, or “C++14,” which our C++ framework was working on, but nobody on our team actually mentioned the term Modern C++ at all.) We’d casually use some Modern C++ features like the keyword “auto” and range loops – really just for convenience more than understanding why they’re preferred – but nothing more. However, interviewers started asking me questions, like what is RAII? What are “concepts” and “promises”? What’s an anonymous namespace? What about generics?

In hindsight, I feel like I deserved to not get hired because genuinely every C++ programmer in 2025 should know about these things – but I had simply never been introduced to them. This did expose one significant thing about my career however: admittedly I had paid very little attention to the tech world outside of work. I was one to think, oh because I’m learning so much on the job every single day (genuinely), for 40+ hours every week for so many years, I don’t need to keep up with what the rest of the world was doing. This was probably my biggest red flag honestly, and I sure was in for a rude awakening. It also showed how outdated a lot of our practices were at my last company (the average employee is fairly old for tech, maybe around their 40s.)

Some other questions they asked included things like design patterns: something I absolutely should be familiar with as a senior level engineer, but with 80% of the job being maintenance and debugging work, I wasn’t. Similarly, build processes and compilers: things that while we use every day, we barely work on it directly ever, especially when projects are all about improving legacy code.

Oh and don’t forget the LeetCode style questions! Where everyone says oh as long as you can solve medium difficulty questions you’ll be fine. Surprise, every other company is asking a hard difficulty now. And you don’t even solve these types of problems on the job, not even the medium difficulty ones. Converting binary trees into linked lists in an interview when your day-to-day job is mostly finding bugs and maintaining legacy code? I don’t even think I’ve used a tree a single time while employed. Relearning all that definitely took some time, on top of learning common interview algorithms like greedy, prefix sum, etc.

And lastly there’s those niche questions that you don’t need to truly understand the ins and outs of in your everyday work. Things like explaining the virtual table, the heap, garbage collectors, etc. I’m familiar with them and know when they’re being used, but fully explaining them like I’m a college professor… admittedly not so much.

I do think demonstrating a willingness to learn and a genuine curiosity can go a long way in interviews, and most people both interviewers and interviewees would agree. Whenever I did get such a question, I’d answer something like “I haven’t heard of that before, can you explain? I’d love to know more about it.” And more often than not, they’d be happy to explain (and this accumulation of answers helped me a LOT over the long term). But results wise, there was never another follow-up interview. Not in 2024 where competition is tougher than ever, that’s for sure. Some interviewers would just ignore my interest and say “no time, next question,” so I KNEW it was over.

Over the past year half, I knew I had to maintain a strict schedule in juggling books, interviews, job applications, LeetCode, actually building side projects, and catching up on the tech industry. I believe structure truly defines how far you’ll make it. ESPECIALLY when you’re unemployed, when it’s easy to go “okay let me just do that tomorrow” because you have all the time in the world.

To really get comfortable with these questions, especially with how broad and varied they can get, it felt like I had to prepare for a final exam. But instead of it being a final exam of a single course, it was the final exam of every single subject you took in college. I ended up resorting to flashcards – creating nearly a thousand of them, ensuring I could not just remember (and of course fully understand) the answer but also physically say the answer out loud while staring into my webcam. I started small and gradually added more and more, but it didn’t feel like it was helping for weeks. I think it was finally showing results however maybe four months in – admittedly however, I didn’t put as much effort in this compared to everything else.

Something else I had to work on steadily over the year – my actual speech and communication skills. Learning more about pacing, hand movement, smiling while talking, pauses before/while you talk, thinking out loud (this especially was a huge killer for me), constantly sitting up straight for confidence, etc. A lot of this feels SO awkward to me specifically when talking to strangers, especially people of authority. Practicing all this might have been harder than everything else mentioned honestly – it just felt so unnatural for me. Watching a video on speech (not just for interviews but in general too) on at minimum a weekly basis absolutely went a long way, but MAN was it SO uncomfortable. Pair this WITH actually answering the interview questions to the best of my ability, and it’s actually so much for my poor introverted brain to juggle. But it’s definitely gotten better over time!

All in all… it was a struggle… and I’m not excited for the next time I’m forced into the job market again. I feel like being able to maintain this knowledge, these skills, over the next couple of years for whenever I start interviewing again, is going to be key. And that’s going to require a lot of discipline as I go over all this material week after week, or maybe as month after month, for who knows how many years. But with the job market being tougher than ever, and layoffs still going on in current years, it’ll be a must if I want to go into the next job hunt prepared.

In future posts I plan on thought dumping on the books I studied, as well as the general interview process and job hunt. Stay tuned!