HN Books @HNBooksMonth

Cracking The Coding Interview

https://www.amazon.com/Cracking-Coding-Interview-Programming...

Have been writing code since the mid '70s. But, that has been mostly with startups. YMMV

Two years ago, I ran out of money. So, I started interviewing. One example was interviewing for the Apple Watch team. My experience included the design and code lead of an Apple Watch product, which was featured by Apple. But, I failed the Coderpad. Why? The interviewer wanted me to use a new Swift generic syntax, which I had never seen before. With an unfamiliar code editor. In under 10 minutes. Did it matter that I had an Apple Watch product, which he could download from the AppStore and ran super fast on a Series 0? Nope. Did it matter that he could download a 29K Swift based functional ontology that I wrote? Nope.

The point is that there are two skills: writing code and getting past the interview. The latter is often conducted by a 20-something, just out of college. So, there is more emphasis on tacit knowledge of the tools and techniques. It feels more like passing a finals exam.

A few years ago my CEO hired Gayle Laakman to prep the team for an acquisition by a FAANG. I loved the puzzles and read her book [1] cover to cover. But, I hated the premise of avoiding "false positives". A famous false negative is Max Howell [2] (who went on to write Apple's Swift Package Manager)

So, how did I get a gig? I kept trying. Learned new frameworks. Focused on jobs interviews which had a take home. During the on-site, I insisted on using my own laptop. An often overlooked factor in achieving a coding flow-state is muscle memory.

I've been told that some companies are shifting from whiteboard to take-home -- particularly during covid. Post covid, if the option is available to you, try moving to the Bay Area or Austin and attend every single hackathon that looks interesting. If you don't want to leave HI, maybe contribute to an open source project in some way.

Or perhaps, start a company. Maybe there's an opportunity in refactoring Aerospace code? I dunno. Now, I'm guessing ...

[1] https://www.amazon.com/Cracking-Coding-Interview-Programming...

[2] https://news.ycombinator.com/item?id=9695102

⬐ ac2022

> So, how did I get a gig? I kept trying. Learned new frameworks. Focused on jobs interviews which had a take home. During the on-site, I insisted on using my own laptop. An often overlooked factor in achieving a coding flow-state is muscle memory.

This is so inspiring. I am stuck in dead-end job. It is not bad but it doesn't excite me. I had a few interviews in last few months. I spend several hours on take home tests, I did Leetcode at some companies. None of them hired me. Felt like such a waste of time. I feel like giving up but maybe I should continue to try.

⬐ therealdavesky

great observation wrt using your own keyboard to enter stuff...

it has to be remote for me for now because i am stuck in hawaii due to $$ probs

they bay area would be a great place to live, but its hard to get there and i know about the networking prospects when you "just show up", i was in berkeley for a few years back in the 80s: you never know who you will run into over there.

big island? welpers, larry ellison has a huge house over here but he doesnt show up at the supermarket very often...

Maybe grab a copy of Cracking The Coding Interview[1] and work through that?

And as cliched as it sounds, as a fairly targeted, short-term thing, you might consider jumping on leetcode and grind through some of the exercises there. How useful that would be depends a lot on the nature of the company(s) you wind up interviewing with, of course. Some companies are really big on these kinds of exercises, others less so.

Also, depending on what language(s) you currently know and work with, you might find value in spending some time learning another "trendy" language. Given the next 3 months to work on it, you could probably make real progress on learning a given language to a usable level. For example, if you don't use Go today, maybe spend some time learning it, since it's very popular and seen as "modern" and "trendy".

Or if not a whole new language, maybe just a "trendy" library/framework (for example, React if you're a Javascript person, but don't currently do React).

(Note: Go and React are just examples I picked to make a point. Please don't take this as saying specifically "learn Go" or "learn React".)

[1]: https://www.amazon.com/Cracking-Coding-Interview-Programming...

⬐ jwally

This is helpful, thanks! Just purchased the book.

I have a pretty solid background in relational db's (SQLServer, MySQL, SQLite), used MongoDB a lot 5 years ago, but kind of let it go. I've built several web-apps via Node.js / Express, and PHP. Most of the front-end work I've done has involved Bootstrap and a templating library (Hogan - a derivative of mustache)

Anecdotally, it seems like API integration is big (???) and I've worked with Google's, Twitter's, JIRA's, SAP's, Square's, Stripe's, etc...

I get the general use case of Git, and use it; but have to google anything out of "Git add *.whatever" or "git commit -m ..."

I've thought about learning React; but didn't know if my time would best be spent there or something like getting a feel for Kubernetes or Jenkins or whatever.

Again, this helps. Thanks!

⬐ mindcrime

Yeah, Kubernetes is another of those things that is really "hot" right now. It's not a bad thing to have at least a basic working knowledge of, in today's IT world.

Of course, the issue you have right now is how to prioritize what to do in a fixed amount of time. There are a billion things (more or less) you could do. The challenge is how to pick the ones that maximize your likelihood of finding suitable employment in your desired time-frame after your current gig ends. And it's hard to know for 100% sure how to do that, since different employers value different things. That's why my best advice is kinda generically "focus on things that you know are hot/trendy in kind of a general sense."

Now if you knew you were targeting a particular company that you wanted to work for, you could make your preparations more focused. But it doesn't sound like that's the case here.

If it were me, I'd probably consult Cracking The Coding Interview[1], and the Robert Sedgewick Algorithms in C++ [2][3] books. That and maybe spend some time practicing on Leetcode, Hacker Rank, Project Euler, etc. Skiena's Algorithm Design Manual[4] could also be good.

[1]: https://www.amazon.com/Cracking-Coding-Interview-Programming...

[2]: https://www.amazon.com/Algorithms-Parts-1-4-Fundamentals-Str...

[3]: https://www.amazon.com/Algorithms-Part-Graph-3rd-Pt-5/dp/020...

[4]: https://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena...

Facebook recruiter (and people I know who worked there) literally tell you to buy and study “cracking the coding interview.” I did buy the book but I’ve never moved forward with the interview because I really didn’t like to commute south when did it for a year and I like pairing too much.

Cracking the Coding Interview: 189 Programming Questions and Solutions

https://www.amazon.com/dp/0984782850/ref=cm_sw_r_cp_api_OiRw...

⬐ tom_mellior

When I was contacted by a Google recruiter a while ago, he also sent me a PDF copy of Cracking the Coding Interview and said I should use it to prepare.

The actual questions I got at the interview were nothing like what was in the book. They weren't questions like "how does algorithm X work?" but "how would you model/implement as system that does X?".

So, shrug. My one data point says that this book is a mostly useless distraction.

Gainlo (http://www.gainlo.co/) does mock interviews with actual Big N / unicorn developers for a price.

Triplebyte (https://triplebyte.com/iv/afyYdFu/cp , referral link), if you can make it to their final video interview, will also give you full feedback whether or not you pass, for free. They don't do whiteboarding but they do live coding and debugging.

There are a few general tips though... the biggest of which is to talk out loud. They're not necessarily wanting a full solution to the problem (although it helps); the interviewer wants to know how you think, whether or not you can code decently, and if you test. (You prove the last part by running an example through your code while talking about it to find and fix any bugs.)

Check out Cracking the Coding Interview (https://www.amazon.com/Cracking-Coding-Interview-Programming...) for more of this. It's a very good book. Pairing its problems with an actual whiteboard and a timer is a close approximation to a real interview.

I have found three different categories for tech-related interviews:

1. Algorithm and data structures trivia: which includes the classic CtCI [1],

2. In-house problems: where you have to analyze and propose multiple solutions to a problem that has been faced by the current development team in the company that is executing the interview,

3. Homework-like projects: which usually take 3-7 days to finish.

After an exhausting 2016 full of interviews I do not know which one is worse.

On one hand, having a common set of problems like the ones proposed in CtCI is good because you just prepare once (kind of) and can apply to multiple companies at the same time. On the other hand, in-house problems are good if you really want to work for a specific company and want to know what are the problems that your future co-workers are facing, the problem is that you have to be well versed in a wide range of concepts to give at least one answer that pleases the lead developer. And finally, the take-home projects, I think they are the worse in comparison, you are expected to work for free for at least one day in a problem that is either very basic or too complicated but they always expect you to have a perfect solution just by yourself. How many times have you done this in your own job? Do you start working in a solution to a problem without asking questions? Without a discussion with your colleagues? Without full specifications? Without multiple attempts? Take-home projects are really not suitable for an interview.

I understand the point of these tweets but I doubt they will change anything. Much of the craziness of nowadays interviews comes from the recruiters who have no idea about these problems, they don't know algorithms and/or data structures, they don't know what are the problems that the company is facing, they only care about the money that the company will give them if the candidate is hired. Now you know why websites like Hackerrank [2] are so popular, recruiters love to have a standard set of questions and if your answer is not the exact same that is in their sheets you lose.

From now on I will just resort to colleague's referral. With this I know that at least one member of the team will vouch for me to join the company and make the interview process as painless as possible because they already have an idea of how good of an engineer I am.

[1] https://www.amazon.com/dp/0984782850

[2] https://www.hackerrank.com/

⬐ FullMtlAlcoholc

> And finally, the take-home projects, I think they are the worse in comparison, you are expected to work for free for at least one day in a problem that is either very basic or too complicated

One of the solutions my team has come across for this (also mentioned in previous HN threads) is to pay the interviewee for a day's work or give them an Amazon gift card for an equivalent amount. And we aren't looking for a perfectly crafted solution. We're just trying to get a handle on their general coding style, maintainability, coherence from variable naming and/or comments, DRY, whether they bother with edge cases in their solution, robustness/anticipate other types of errors or bugs that may pop up, etc.

Indeed, I have no degree but have been working for +7 years in the field. Recently I decided to start searching for new challenges but thanks to ATS [1] my resume has been rejected 90% of the time, the other 10% has been invested in interviews in fairly popular companies including Amazon and Booking.com. After having studied CtCI [2] and practiced on LeetCode [3] for two weeks (yes, just two weeks) I was able to pass most of the technical interviews, so I can testify that using this repository as a way to improve your skills actually works.

PS: Just to clarify, I haven't been hired by any of the "Big 4" yet, but that is because — again — I have been studying for only two weeks, if I invest more time on this, maybe in 5-6 months I can guarantee an offer in one of those popular companies that appear featured on HN all the time. And as the parent comment says, even if you have no intention to work for Google or any other of the big corporations, this still is a good list of resources to improve your skillset.

[1] https://en.wikipedia.org/wiki/Applicant_tracking_system

[2] https://www.amazon.com/a/dp/0984782850

[3] https://leetcode.com/

Personally I think you would learn more from solving algorithm puzzle problems independently than taking algorithms and analysis courses.

A couple that come to mind are Project Euler [1] and CodeKata [2].

The problem with most courses is that they teach the very basic types of data structures, a couple search algorithms, etc but not enough. They didn't give me the intuition I was looking for.

Alternatively, the most recommended books I've seen for your use case are _Programming Interviews Exposed_ (PIE) [3] and _Cracking the Coding Interview_ [4].

[1]: https://projecteuler.net/

[2]: http://codekata.com/

[3]: https://www.amazon.com/Programming-Interviews-Exposed-Secret...

[4]: https://www.amazon.com/Cracking-Coding-Interview-Programming...

[1] 4.5 stars (227 reviews) $28 https://amzn.com/dp/1479274836

[2] 4.5 stars (216 reviews) $27 https://amzn.com/dp/0984782850

[3] 4.5 stars (94 reviews) $16 https://amzn.com/dp/B008SGNJOW

These problems aren't that hard, although they do not say anything about the person that solves them. One can prepare for a Google interview in 1-3 months and I'm sure there's a pretty high chance they would pass it.

I've seen tens if not more people from my unknown middle EU university nail the interviews, ending up with jobs at Google, Facebook, Microsoft etc. and I've cooperated with some of them, knowing that their programming skills and knowledge, teamwork are lacking. But they can solve some simple dynamic programming problems, or maybe a silly breadth-first-search, and they'll get the job.

I, personally, wouldn't like to be hired at a firm that evaluates me that ridiculously. Yes, I'm a fresh graduate but thinking that knowing Dijkstra's algorithm evaluates my abilities makes me believe the whole culture is entirely deformed and I do not want to be fascinated by these ridiculous puzzles when I'm working with others.

Give them a week to implement something of larger complexity and they are drowned by so many concepts they decided to skip to earn an internship/full-time position at their beloved giants.

But I guess giants can afford having engineers that aren't that productive, or aren't doing projects that matter. I wouldn't like to be one of these engineers.

So, the real question is do you want that, or is the cash blinding you? :D

Books like these below can increase your chances significantly:

http://www.amazon.com/Elements-Programming-Interviews-Inside...

http://www.amazon.com/Competitive-Programming-3rd-Steven-Hal...

http://www.amazon.com/Cracking-Coding-Interview-6th-Edition/...