TDD is more of an ideal state rather than a practical one. It is extremely rare that you can understand a problem space so thoroughly without having explored it first.
This is why most of the TDD examples online are for extremely easy to understand problem spaces. Yes, if I had to implement a calculator with TDD, it wouldn't be much of an inconvenience. But if I have to write a multithreaded file packing and compressing system that will be consumed by other programs, that's not going to be as easy for me to wrap my head around. My approach to building such a system might change multiple times as I get deeper into it, and it's very likely the tests I wrote initially made assumptions about the architecture that aren't true anymore.
Instead, we aim to do what u/Infinite-Eggs suggests and write the tests at the same time as the code. Basically, if you're writing some code and you wonder if it will work, already having a test project right there and being able to execute it is invaluable.
Keep in mind, though... It is usually much slower to write code that is easily testable. Easily testable code can be run in isolation, supports mocking dependencies and avoids side effects at all costs. Code that you write quickly probably isn't easily testable by this definition. Many experienced software developers also advise failing fast... if something isn't going to work architecturally, it is better to find out sooner so you can adjust the design. So this creates a dilemma. Do you sacrifice testability to get code working quickly? Or do you put project deadlines at risk if you guess incorrectly on an implementation?
My personal suggestion is balance the two as much as possible. I do this by doing Test-Driven Refactoring (this isn't an actual thing, but I like the name). You write code until it works and then you refactor it until it's testable. You don't check in until it is testable, but you don't let testing stop you from experimenting quickly.
If you get to the interview stage with this company, you should feel free to discuss with them their approach to TDD. Show you understand it and you don't have a built-in negative bias towards it as a lot of developers do... Your enthusiasm to learn more about this ahead of their interview will impress them, regardless.
Good luck!
Testing for mongo: https://github.com/Automattic/mongoose/tree/master/test
Otherwise use: mongodb-memory-server for something more complicated