The most irritating thing with these competitive/algo stuff is that no matter how many times you master it - eventually you always forget it, because you don't need it on a daily (or more like yearly) basis in the real world.
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.
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.
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.
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.
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.
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.
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.
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”.
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.
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...
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.
> 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.
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?