IService or defining IProductService, ICustomerService As per tutorial here, I have the following classes:
(In reference to this tutorial's section)
namespace Supermarket.API.Domain.Services
{
    public interface ICategoryService
    {
         Task&lt;IEnumerable&lt;Category&gt;&gt; ListAsync();
    }
}

IProductService.cs
namespace Supermarket.API.Domain.Services
{
    public interface IProductService
    {
         Task&lt;IEnumerable&lt;Product&gt;&gt; ListAsync();
    }
}

ICustomerService.cs
namespace Supermarket.API.Domain.Services
{
    public interface ICustomerService
    {
         Task&lt;IEnumerable&lt;Customer&gt;&gt; ListAsync();
    }
}

I have about 10 Domains that I want to have the same interface as above (i.e. the service ability to GET items for e.g. Customer / Product / OrderItem / Order)
In view of the DRY principle, I am thinking of changing to the below:
public interface IService&lt;T&gt;
{
    /// &lt;summary&gt;
    /// Gets a collection of entities
    /// &lt;/summary&gt;
    /// &lt;returns&gt;&lt;/returns&gt;
    Task&lt;IEnumerable&lt;T&gt;&gt; ListAsync();
}

Whereby at implementation time, it looks like the below:
public class CustomerService : IService&lt;Customer&gt;
{
    public async Task&lt;IEnumerable&lt;Customer&gt;&gt; ListAsync()
    {
        var entities =  await // Imeplementation of DAL to follow

        return entities;
    }
}

None of the tutorials that I have read so far does anything similar to keep the interface DRY. Is this a good idea? Thanks.
It makes perfect sense to define such generic interface as long as there is a generic consumer that can do some useful work with any of the implementations.
And I suppose there is in this case.
If I were to guess, I'd say the tutorial did not include generics just because that is a feature that might not be familiar to the audience that the tutorial was pointing at.
As @Hayden already mentioned, IService&lt;T&gt; is not a very useful name. Let me call it IEntityListProvider&lt;T&gt; instead.
I can imagine the common consumer could be a single route controller.
Let me first a define a simple routing framework to provide some context:
// IRequest and IResponse are models of HTTP request resp. response
interface IRequestHandler
{
  public Task&lt;IResponse&gt; HandleAsync(IRequest request);
}

interface IRouterBuilder
{
  // register a GET route handler
  public void Get(string path, IRequestHandler handler);

  // build the router instance
  public IRequestHandler Build();
}

now we can implement the generic consumer like this:
class EntityListRouteHandler&lt;T&gt; : IRequestHandler
{
  private IEntityListProvider&lt;T&gt; Provider;

  // add constructor to take the dependency

  Task&lt;IResponse&gt; HandleAsync(IRequest request)
  {
    // get the list from provider
    // and convert the list to a response in a way
    // that's going to be the same for all entities
  }
}

and somewhere in router factory you would do somethig like this:
RouterBuilder.Get('/categories', new EntityListRouteHandler&lt;Category&gt;(categoriesProvider));
RouterBuilder.Get('/products', new EntityListRouteHandler&lt;Product&gt;(productProvider));
RouterBuilder.Get('/customers', new EntityListRouteHandler&lt;Customer&gt;(customersProvider));

Now I would like to expand on @Hayden's answer.
Ad 1) he mentions that if a PasswordService were to exist, it would probably not need a ListAsync method. Well, that's true, but it's misleading because it is irrelevant. Such a service would simply not implement the IEntityListProvider&lt;T&gt; interface.
Ad 2) if some service needs some more methods, then I would ask mayself is there someone who needs those methods at the same time? If yes just create a new interface extending the base one. If not, just define a new separate interface. Whether the concrete class implements two interfaces or you simply provide two different classes to implement each of the two interfaces is up to you. But a separate class for each interface feels like it better follows SRP.
I would add one more note regarding pagination. It is not very wise to provide the lists of entities without any limit. The momory consumption of such program is then out of control unless there is some logic that prevents too many entities to exist in the first place. Your ListAsync method should have arguments for pagination and possibly filtering and sorting as those are very common things to do with list resources. The type of these arguments may as well be generic arguments of the interface. I.e. Task&lt;IEnumerable&lt;T&gt;&gt; IEntityListProvider&lt;T, F, S, P&gt;::ListAsync(F filter, S sort, P page) or so...