When you use someone else's algorithm, you still need to understand the tradeoffs. For example, in Java, the sort()
method provided by the Collections class uses a modified mergesort that guarantees n log(n) performance. However, it also states that it dumps the collection into an array, sorts the array, and iterates over the list. This use of an array requires more memory consumption.
The question becomes: Is this good enough for your needs? If you don't understand algorithms, time complexity, and space complexity, you can't really answer that. You don't need to know as much about the underlying mathematics and theory as someone who develops new algorithms, but you do need to be able to compare multiple algorithms and determine which one best allows you to meet the requirements of the system.
Note that the exact same thing applies to data structures. Understanding the characteristics of your data and the insert and retrieval from the data structure will allow you to choose the most appropriate structure for your needs.
Now, all of this happens at a lower level than design patterns. Design patterns say nothing about what data structure or algorithm that you need, but rather that you need to have some kind of relationship between modules of your application. When talking about design, you might say "we need to sort the data", or perhaps even "we need to provide multiple sorting algorithms" (Strategy pattern, perhaps?), but you wouldn't be talking about merge sort or quick sort or any particular sorting algorithms.