It's not about needing it in "the real world". It's about having fun. It's about the adrenalin rushing through your veins as the clock ticking down. It's about burst of joy when your brain just clicks and the invisible wall falls down, showing a path to the solution. I still do Putnam and IMO every year, I also occasionally take an hour or two during work and just solve Math problems. Solving problems is a hobby, just like video games. There's nothin really practical about it and there doesn't have to be.

What I'm saying is that aligning interviews to prefer candidates with this particular hobby (which is not related to the job) is not fair.

I think I agree with you, and I say this as someone who was probably a beneficiary of such an alignment, after college.

But the submission does not mention job interviews. The linked book (the author is “one of the organizers of the Finnish Olympiad in Informatics […] coached and led the Finnish team at several international programming contests, including the International Olympiad in Informatics”) is someone's labour of love, written for people interested in this hobby. It brings joy and satisfaction to many people, most of them young students. Why throw cold water on them, by reacting to mention of such a book with terms like “irritating”, based on something that others do in some other setting entirely? Or, even if bringing up job interviews is justified (no doubt your irritation is real), it would be nice IMO to at least preface the comment by clarifying that the comment is not about the hobby/competitive-programming world that are the subject and audience of this book, but about something else.

> What I'm saying is that aligning interviews to prefer candidates with this particular hobby (which is not related to the job) is not fair.

It's also detrimental to the business.

if we're going to take the video game comparison further, then there is something better you could be doing with your time.

For what? The man is happy doing his things. Who are you to judge him?

This is the case with anything you didn't discover it yourself but rather 'learned it', that's actually just a replaceable term for 'memorized it'.

People who discovered/invented these algorithms traversed several years of curiosity, blind alleys, dead ends, failures and successes. You can't possibly expect to get it all and make it up on memorization alone.

Algorithm learning is hard for the same reasons memorizing Math tables are hard.

As of today there is nothing novel about merely learning how a algorithm works and spitting it out in an interview, if anything it achieves the exact opposite goal of what it is supposed to.

This is true for lots of things though, right? Programming languages, spoken languages, mathematics, muscle mass...use it or lose it, but it gets easier to re-learn/re-gain everything each time. Plus you don't necessarily have to forget or lose it if you're able to set aside the time to maintain it.

Exactly. Having the experience of solving difficult algorithmic puzzles under time pressure makes parts of software engineering (writing working code, debugging) easier, so you can focus on the hard parts. Algorithmically, almost anything written in the real world is trivial in comparison.

If you really needed to remember it, you could employ spaced-repetition: https://en.wikipedia.org/wiki/Spaced_repetition

I use Spaced Repition for chess openings as I can't refer to a book while playing a tournament game. That's not the case for programming.

A lot of software developers are asked to code solutions to difficult problems using nothing other than a whiteboard. Given that under normal circumstances we use a computer, IDE, and the internet, I can see why some might opt to use spaced repetition to ensure employment.

If the interviewers aren't generous in offering corrections to small issues when you're at the whiteboard, you don't want to work for them. Whiteboard exercises are there to see how you think through a problem, not how much algo shit you crammed ahead of time.

You still often have to be familiar with approaches to problem solving and data structures. And you have to be practiced enough to know when to apply them.

In a high pressure situation like an interview, I personally find it difficult to think naturally through a problem. Familiarizing myself with different types of interview questions regularly helps a lot.

As convoluted Spaced Repetition sounds I am debating using it to brush up on algorithms.

10 years ago I was pretty handy with CLRS, but now I'd be hard pressed to implement quicksort without looking it up.

Kek - i employed this technique in learning starcraft 2 openings. Def. Seperated the top 10% from top 5%

The point is why people have to remember them ?

Why not look them up when necessary ?

I guess most of the problems are relatively small, but for Advent of Code¹, the "competitive" people are finishing most of their solutions in a minute or two.

1. http://adventofcode.com/

How will you look it up when necessary during a programming contest (like the IOI/ICPC mentioned in the book)? It's usually not allowed by the contest rules to look up an entire book's worth.

And if your teams algo and data structure knowledge isn't at the level where you know about these solutions or their applicability?

I have a checklist of possible interview topics and I think I might an esoteric data structure part to it (knowledge not code) and some implementation choice questions - given this situation and data, with these queries what would your data structures look like.

Maybe also a few quotations on the last paper they've read in CS or related topic.

Why test for anything in an interview? Why not assume anyone can learn everything on the job?

Why even have the interview? Why not just hire everyone who applies and assume they can do the job?

There are tests and interviews because not everyone can

I'm not sure I understand: the linked book is meant for high-school and college students, or anyone participating regularly in programming contests:

> The book is especially intended for students who want to learn algorithms and possibly participate in the International Olympiad in Informatics (IOI) or in the International Collegiate Programming Contest (ICPC). Of course, the book is also suitable for anybody else interested in competitive programming.

Anyone in the target audience of the book will encounter most of this frequently enough; I definitely didn't have the experience (when I was in college and doing competitive programming, over a decade ago) that I was forgetting most of it.

Of course, if someone is not interested in competitive programming and never uses any of the knowledge they're likely to eventually forget it; it's just like learning a bit of French or group theory (say) and not touching it again for years — it's possible to forget. But not sure why that's irritating; it's just the nature of learning, at least after a certain age or below a certain threshold of practice.

Not the intended audience but now, technical interviews now have a lot of competitive programming in them so this book can help you.

Same goes for most of your theoretical computer science education...

Arguably competitive programming helps with this problem by letting you drill the concepts you've learned.

Exactly

Just like sql and regular expressions. You work hard to get it to work and then forget about it.

That’s the entire point of those kinds of interviews. It’s a strong filter for “recent graduate” while maintaining plausible deniability for ageism. It has a secondary effect of filtering for “willing to do unpaid overtime”.

I do wonder how many 40+ programmers are able to keep up with "young ones" in these contests.

I fear it is like chess, the cognitive decline starts to become noticable in the mid 40s and only gets worse from then on.

There are a few exceptions like Korchnoi was in chess so there must be Fabrice Bellards and Bill Joys who would be able to keep up.

Still looking at completion times for Advent of Code made me feel old.

I think also the interviewer gets to feel smart. Always nice to have the answers.

Yeah, right. Clearly they have nothing better to do and are all egomaniacs.

I think its more of aptitude test in a domain common to all programmers.

The problem with this thinking is this "aptitude" is something which comes naturally. I was drilled with this "aptitude" nonsense when I was a student where the teachers would say that if a person "gets" a problem and finds a solution then he is a natural for the subject.

In my practical experience I find that to get the "aptitude" requires a lot of effort put in it. It definitely would vary depending on the person and his experiences but practicing it is very important to go forward.

Yeah right. Tell me the last time you built your own red-black tree in real actual code at work. Or did a sort by any other means than tacking “order by” on the end of a query.

They are a test of how recently you crammed for your CS finals, that’s all.

Or how much effort you're willing to put into prepping for interviewing and getting a new job. It definitely filters against the casual looker.

Which, to some extent, makes sense. You're basically filtering out people who won't put in the effort to get the job. Whether or not those who put in the extra effort are actually going to be better employees is a different decision.

There are languages - C and Go, and to a lesser extent, C++ - in which re-implementation of data structures and algorithms is not uncommon.

To your larger point, data structures and algorithms are popular in interviews for the same reason Project Euler is popular - it is very easy to ask a well defined, but interesting question about core CS or math.

Would be legit if the job required tasks like implementing red-black trees or sorts.

As is, it's more like advertising for python, then surprise java.

Indeed. If the job was implementing algorithms on bare metal then bring it on! That job sounds like a lot of fun!

But those kinds of questions make zero sense and have zero value if the job is actually implementing CRUD apps in a high level language. You might as well quiz candidates on their assembly language skills too, for a Python job...

So there is obviously an ulterior motive.

Tell me a better standardized question set for programmers that measures intelligence efficiently.

Do you think that that’s what that does? Interesting.

It's not ok to comment like this here, regardless of how wrong someone else is or you feel they are. Please post civilly and substantively, or not at all.

https://news.ycombinator.com/newsguidelines.html

Sorry, it was indeed an off-the-cuff remark in poor taste.

That's enlightening. Never thought of it that way.

Maybe it's just a way to provide a fair test that anyone with ability can pass with a little practice?

I wouldn't call it "a little practice". There are people who are "into" competitive programming and there are people who aren't, and those "fair" tests are skewed towards the former group. The worst thing is that the actual job has nothing to do with the competitive programming at all.

Another filter for age is that 20-something’s are more likely to have time for this whereas older people may have more time commitments already

People in their 20s and 30s now will regret not stamping out ageism when they hit their 40s and 50s, as they inevitably will

> People in their 20s and 30s now will regret not stamping out ageism when they hit their 40s and 50s, as they inevitably will

The problem is, everyone in their 20s and 30s assumes they'll be gazillionaires by the time they're 40, because of course they're brilliant and hard work always pays off! Ageism is only a factor if you're not smart enough to make a billion by the time you're facing it.

Hard work does pay off. Believe in karma.

Karma goes both ways. Those that practiced ageism will find that out themselves eventually.

Unfortunately then the victims of ageism now will find that cold comfort in the future.

Rote leaning and getting a piece of paper is not a good way to interview for candidates who can when given a task that wasn't on the test research and implement a solution under their own power.

Memorising derivations of algorithms and solutions to puzzles from a book like Cracking The Coding Interview surely is just rote learning. There should be a high correlation between the content of the interview and the actual job, or what is the interview really for?

That's not a popular viewpoint around here. :D