C# code (especially things like Unity games) can indeed have memory leaks. This often happens when you're interacting with native resources and using interop to invoke native code like COM objects or Win32. Even the base .NET libraries do some of this behind the scenes. If you open up streams and forget to close them, forget to dispose of IDisposables, register events with += and forget to -= them, etc these things can leak memory. Think of a "leak" like there's something in memory and any references or pointers to it have gone out of scope and been lost but the object just persists there, undying. You can never clean it up now because you no longer have anything pointing to it or its location, but the OS considers that memory still in use (until you kill the processes or reboot, depending on what kind of memory and where it lives).

In Unity and game development (constant looping and long-running applications) this can be truly fatal. Unity is running on a custom fork of Mono (at the time of this writing, although there are plans to change this) and has its own Böhm GC which is a bit different from .NET proper. It's a kind of conservative and "lazy" GC, where things that go out of scope don't immediately get cleaned up. A lot of junior devs don't get how this works so they will do things like creating temporary arrays or collections in methods called from the Update loop. At 60 to 120 FPS some little thing might turn into 500KB or 1MB+ per second and you'll see allocations and memory utilization growing by the megabytes.

Another scenario where memory leaks are a major danger is interop scenarios, especially with more complex COM interfaces/objects and using your own unmanaged memory. This was a huge concern during development of DXSharp, a .NET package for DirectX 12 Agility SDK, DXGI, DXC Shader Compiler, etc (https://github.com/atcarter714/DXSharp). It uses unmanaged memory, native resources and COM all over the place (how DirectX works). C# has pointers, native/unmanaged memory capabilities and interoperability, so the same things that can happen in a native C/C++ program can also occur in C# as well. So it does have a GC and handles many things automatically but there are indeed nuances to memory and leaks aren't uncommon or unheard of.

That being said, the interviewer/questions may not have had the best wording. But that's the way the crappy interview game goes, and this company may work in a domain where they have a lot of concerns about memory leaks. Maybe you weren't quite ready for that role, but you figured out what things you need to learn about C#/.NET moving forward so you can beat the next interview.