Hacker News Reader

Comment by dcw303 | Hacker News Reader

This is a good cheat sheet for those who don't have (or have forgotten) the knowledge but want to game an algorithm heavy interview. The problem I got with this is exactly the same as when I tried reading the "Cracking the Coding Interview" book:

I got through a few chapters and then the author mentions something off the cuff with an assumption that the reader will know what they mean. But of course, I don't, because these books are basically a collection of cheats and hacks. I get frustrated that I don't understand it, so I seek out something that starts with the fundamentals and expands from there.

What I'm trying to say is that I'd rather slog through 900 pages of Sedgewick and come out with a thorough understanding rather than try 20 quiz questions to be stumped by whatever the hell they were trying to get at with question 21 and then give up.

View on HN

CEO of Interview Cake here. We work really hard at trying to not do this.

Feedback on where folks get left behind is pure gold to us, because it lets us know what we need to smooth out next. We're not trying to be the /biggest/ resource out there--we're trying to be the /smoothest/.

For this article, do you remember where specifically you got left behind?

To be fair to your article, it actually reads quite well and has good detail for what's covered. I thought the big-o coverage was a bit sparse, but I also didn't see the expand link the first time.

Eep. Second person to say that in this thread.

We had it in one of those gray boxes in an earlier draft (so you didn't have to click anything to see it). We'll probably move it back out.

You might like "The algorithm design manual" by Skiena. (Second edition.)

It's one of the few dead-tree books I ended up buying this year, albeit after perusing a library copy.

i have the same feelings about "cracking the coding interview"

the day someone unironically asks me to "Write an algorithm to print all ways of arranging eight queens on a chess board so that none of them share the same row, column or diagonal" - I will jump off a bridge

I went to a CS high-school (not university) and we studied backtracking in the first or second year. Everyone was supposed to know how to solve this and similar problems for tests.

Sure, you'd know that right after a CS high-school - however, if after that school you go on to work on real problems for a decade or two, then you won't know that anymore, since outside of very specific domains you don't really write such things from scratch anymore; you'd always want to use existing, optimized&tested implementations of all the common and less common data structures and traversal algorithms instead of rewriting them.

You forget what you don't use, and this is stuff that you don't use.

IMHO the big problem is that they're missing the point on why we ask students do do these algorithm implementations - it's not so that they'd learn how to do that (though a bit of general programming practice is useful), we put them there as hands on exercises so that students would understand the usage of these algorithms better.

The implementations are just a learning aid, not a learning goal. Asking to reimplement a red-black tree is somewhat comparable to asking what was shown in a particular instructional video or what practice problems were assigned in that class - checking if you remember the details of a particular teaching instrument.

You can finish that algorithm and then ask for a *2 wage LOL

Or you can refuse to do that and then work on getting a position where you aren't treated like a monkey expected to do tricks on demand and also have a better wage and social status.

Of course your extra wage goes straight into maintaining that status with uncomfortable clothes, overpriced cars, a big house in the suburbs to support your trophy family who you then spend hours of unpaid overtime avoiding...

I mean you do you, but any job is going to involve a certain amount of doing stuff; personally I find CS algorithm puzzles a lot more fun than status games.

Status games? Hours of unpaid overtime? What are you talking about? The engineering managers (below the "C suite") everywhere I've worked have more or less kept the same hours as I have, dressed to the same standard, and used the same commute options as anyone else.

When you say things like "treated like a monkey expected to do tricks on demand", you're playing status games.

Ah, I see. You don't believe you're playing what you call a status game, even when you are.

The perspective that it's all a status game is legitimate in its own way, but not the only way to view things. I find there's a useful distinction to draw betwen trying to influence people's perceptions directly versus trying to do something valuable and trusting people to perceive it for themselves, and find the latter a lot more fun than the former.

See, the thing is that you keep calling it a "status game" when it's not really clear what you mean, other than to belittle work others do because it isn't solving algo puzzles.

Reply on news.ycombinator.com