The original version of this question specified "lists" as the target of the operation of helper methods. That is a very critical fact here, but I will cover two scenarios.
The first scenario is one where you have a generic operation that you perform on an object of a class you wrote. That absolutely should be part of the class. Sometimes it is difficult to fit it into an existing class: object-oriented design can be difficult at times, for sure. If you are debating putting such a utility function in a separate module because you are not sure where it fits, that may be an indication (some people call it a "code smell") that the design of your class or module is not ideal. I would like to point you to an answer I wrote for a different question that covers one aspect of refactoring code to remove temporal coupling (call method A before method B). Sometimes when a module does too much it can be difficult to reason about it and understand where methods go and how to use them together. It may help to break it up into pieces. That can make the answer to your question more clear.
The second scenario is an unfortunate one. Let us say you need a new general-purpose list operation, where "list" is a class provided by your language's core framework and said framework is not modifiable by you (typically the case, but not always). There really is no best solution here. Long story short, the software community long ago came to a consensus that the least bad option is to create classes with static methods that manipulate the core data structures. If you look at Apache Commons, for example, there are StringUtils and CollectionUtils classes where each class has utility methods for a single core Java class. Each utils class corresponds to a single core Java class, containing utility methods someone found useful when working with it but the Java interface and implementations lacked the necessary functionality.
One option you might consider is decorating an object if you need to alter its behavior. For example, let us assume you have an unsorted list of integers. However, you want to iterate the list in ascending order defined by the integers' natural ordering (i.e. the way we count up). Rather than modifying the list, you could wrap or decorate the object. Most of the methods simply pass through to the underlying list, however, methods used for iteration alter their behavior. Then when you want to iterate in a different order, you wrap the list in this new object and call whatever method your language uses to get an iterator.
There are options here, and there is not necessarily a "right" or "wrong" answer. There is no "best practice." Being relatively new to the profession, your takeaway should be that software design is an inherently complex process involving tradeoffs. You need to decide which positive and negative tradeoffs are acceptable for the program you are writing. We (here on this site) can help you identify options and maybe even pare some of them down, but ultimately, it is your call how to proceed.
