2 ms·
There's no value in memorizing algorithms. There is, however, a lot of value in the ability to solve algorithmic tasks. I don't think anybody is intentionally s
by baobabKoodaa 7y ago
There's no value in memorizing algorithms. There is, however, a lot of value in the ability to solve algorithmic tasks. I don't think anybody is intentionally structuring interviews to measure how many algorithms a candidate has memorized... interviewers are looking for the ability to solve problems, they just... fail at doing that.
- jerf 7y agoIn principle, my interviews, which tend to be a lot more about "take this text from a DB and process it in this way and display it on a web page" are algorithmic too. I mean, if anyone's writing code, they're writing algorithms. But there's day-by-day algorithms where you're basically gluing lots of things together, and there's Project Euler problems. In my 20+ years of software engineering, I've personally encountered maybe 3 or 4 Project Euler-type problems in my real job. (And even those weren't as clean as those problems; I still had to integrate them back into some other real-world code base.) Expecting your candidates to be good at inverting red-black trees recursively when you want them to hook databases to web pages without massive security vulnerabilities or performance issues is silly. "Gluing lots of things together" is a descriptive term, not a derogatory one. There's a ton of things you need to know to be a good gluer nowadays; security, performance characteristics of all the pieces, we're adding more and more distribution into our systems, higher level stuff like integrating with teams, documentation of your code, how your workflow goes... there's more than enough to interview all day on these issues without ever having to quiz the candidate on puzzles from the back of a Knuth book. (This is agreement with you, not disagreement.)