"Best algorithms book" is an unanswerable question until you say why you are asking. Passing interviews, building genuine intuition, and having a reference on the shelf demand different books, and picking the wrong one is how people bounce off the subject entirely.
Grokking Algorithms (2nd Edition)
Start here if the subject has ever intimidated you. Illustrated, friendly, and honest about scope — it covers the core ideas with pictures instead of proofs and takes a weekend.
The Algorithm Design Manual (3rd Edition)
My default recommendation for practitioners. Part one builds intuition, part two is a catalogue of problems and which algorithm applies. The war stories from real consulting work are what make it stick.
Algorithms (4th Edition)
The best balance of rigour and readability, with genuinely good implementations and visualizations. Pair it with the free Coursera course from the same authors.
Introduction to Algorithms (CLRS, 4th Edition)
The reference. Comprehensive, precise, mathematically serious — and a poor first read. Own it, consult it when you need the exact analysis, do not attempt it cover to cover as a beginner.
Cracking the Coding Interview
Aimed squarely at interviews, and good at that job. Use it for the patterns and the behavioural framing, not as a way to learn algorithms in the first place.
Elements of Programming Interviews
Harder and more thorough than CtCI, with solutions that explain the reasoning rather than just the answer. The better choice if you are targeting a demanding interview loop.
Competitive Programming (4th Edition)
For contests and for anyone who wants speed under pressure. Dense, exhaustive, and full of techniques you will not meet elsewhere.
Algorithm Design
The best book on how to design an algorithm rather than memorize one. Superb chapters on network flow and NP-completeness, and the strongest treatment of greedy-versus-dynamic-programming reasoning.
Reading is not the practice
Algorithms are a motor skill. Solve problems with the book closed, on a schedule — a few a week for a long time beats a hundred in a panicked fortnight. Work by pattern (two pointers, sliding window, binary search on the answer, graph traversal, dynamic programming over subsets) rather than by random problem list, and after every solved problem read someone else's solution and ask what they saw that you did not.
Complexity analysis is the transferable part. Most engineers will never implement a red-black tree, but every engineer should notice when their loop just became quadratic.