
This book provides efficient code solutions in several programming languages that you can easily adapt to a specific project. Each major algorithm is presented in the style of a design pattern that includes information to help you understand why and when the algorithm is appropriate
I didn't find SICP to be that fantastic as I already learned a lot of the principles from the masses of books I've read and software systems I've taken apart to understand.
I can also recommend taking Coursera courses on compilers, ML, architecture, anything interesting from a good US university. At least if they're still a thing :-)
I work at Google and do interviews (though I don't enjoy them). We do ask questions around domain expertise, software design, etc. It's not all just coding and algorithms.
A good question:
1. Has a low enough floor that a poor candidate can still make some progress and not feel like they are doing poorly and get stressed out.
2. Has a high enough ceiling that a strong candidate doesn't blow through it in five minutes.
3. Has a smooth ramp between those points.
4. Doesn't rely on too much domain-specific knowledge so that a candidate who happens to have a random gap in their background that leaves them totally hosed.
5. Is concrete enough that the interviewer can capture that feedback in a way that the hiring committee can easily understand.
6. Isn't well-known outside of Google as stock interview question so that candidates can game us by just learning the answer.
7. Isn't asked by any of the other interviewers the candidates sees.
8. Can be explained and worked through in about twenty minutes.
In case it isn't obvious, it is really really hard to find good questions that pass that gauntlet. Questions do tend to skew towards smaller-scale algorithm coding questions because I think those tend to survive that gauntlet better than most other questions.
> unusually good at algorithm puzzles
Interviewers are trained to not ask "puzzle" or "trick" questions. Not only are trick questions a shitty experience for the candidate, they are a shitty experience for the interviewer too. My job in an interview is to get as much data as I can about a candidate in order to provide information to the hiring committee. If I ask you a trick question, I get about one bit—in the binary sense—of data from you: did you find the trick or not?I don't think you have to be unusually good at algorithms. I basically read some Wikipedia articles and spent a few hours in the hotel cramming Algorithms in a Nutshell, and I managed to squeak through.
That time was incredibly well-spent. Since then, I have relied on that algorithm knowledge way more than I expected too, and have since spent more time learning algorithms and data structures because I can clearly see it's made me a better programmer.
> on whiteboards,
That part is hard. We allow candidates to use a laptop too, if they prefer, or both. My experience is that candidates who use the whiteboard, at least for the earlier "design" parts of the question tend to do better than the ones that go straight to typing.We need to learn how you think, and putting a screen in front of people tends to make them clam up. If all I see is the code you write and you don't explain your thinking behind it, I don't get much data.
> under time pressure.
That part is really hard too. The reality is that interviewers and candidates have a limited amount of time they can put into this process. Keep in mind that most candidates are currently employed and don't want their job to know they are interviewing. Many of them travel to interview. There are only so many hours.Basically beginner programmers can acquire a broad understanding of the foundation the programs you're building are built on by reading this book. It reads more like a non-fiction expose than a programming language tutorial book, which is to say, given its subject, it's an easy read you can do on the couch. Depending on your skill and knowledge level, there may be a few sections you have to re-read several times until you understand it, but you won't feel as though you need to go over to your computer chair and try something to fully grasp it.
If you can do basic arithmetic, you can get through this book. That seems to be the hidden premise. That computers are easy and should be easy to understand. This book is a testament of that. Though I'm sure some will find this doesn't go deep enough. But the point is: learning so generally will create many entry points for you to follow up on in your journey into programming and computer science. It will clear up many things and essentially make the path seem less scary and out of reach. This book achieves that really well. High level programmers will come away feeling far less insecure about their lack of knowledge of the underpinnings of whatever it is they are developing. I know I did. I can't say enough about this book. It's the real deal. I'm sure those with a computer science degree might have more to say (that is they likely think it's a cursory overview), but I think for everyone else it's a computer science degree in a book you can read in one or two weeks. At least half the degree. For the second half, I recommend Algorithms In A Nutshell. And done! Go back to programming your high level JavaScript react app and get on with your life.
On a side note: it's my opinion that theory first is the wrong way. Application first, theory as needed is the right approach. Otherwise it's like learning music theory before u know u even like to play music. U might not even like being a programmer or be natural at it. And if u spend 4 years studying theory first, u will have spent a lot of time to discover what u could have in like a month. In addition, it can suck the joy and fun out of the exploration of programming and computer science. It's natural and fun to learn as u dive into real problems. Everything u can learn is on the internet. It's very rewarding and often faster to learn things when you are learning it to attain a specific goal. The theory u do learn seems to make much more sense in the face of some goal you are trying to apply it to. In short over ur computing career u can learn the same stuff far faster and far more enjoyably if you do so paired with actual problems.
But that said sometimes u do gotta step back and allocate time for fundamentals, even if u have no specific problem they are related to. However you will know when it's time to brush up on algorithms, or finally learn how the computer works below your day to day level of abstraction. Just know that a larger and larger percentage of us programmers went the applied route, rather than the computer science theory first + formal education route. It's probably the majority of programmers at this point in time. In short u r not alone learning this as u go. Learn to enjoy that early on and save yourself from the pain of insecurity of not knowing everything. This is an exploration and investigation, and perhaps you will make some discoveries nobody else has been able to make, and far before u have mastered and understood everything there is to know about he computer. Perhaps that's it's biggest selling point--you don't have to know everything before you can contribute to the computer world! So enjoy your pursuits in programming, knowing in your unique exploration at any time u may come up with something highly novel and valuable.