Every developer dreams of going greenfield. Ultimately, that's because it's harder and much more tedious to read code than to write it. If you start from scratch, you understand the whole stack/platform, everything is customized to your liking, and so on. That's great for you, but the company is usually stuck spinning its wheels for months while you push this rewrite down their throats.
It's also very easy to underestimate the depth of domain knowledge and accounted-for corner cases encoded in an old codebase. It looks easy at first, but it usually ends up taking at least months to reach feature parity with the old software, which usually also means that people will use both systems simultaneously, requiring data synchronization, etc.
The whole thing becomes messy, and by the time you're done, the "new system" usually isn't really all that improved over the old system. Systems get convoluted in the process of development, business needs demand quick shoehorning of something instead of thorough refactoring, etc.
Once in a while, a full rewrite is indeed justified, but it's much rarer than most people think.
Going in saying "Yes, my company needed a full rewrite" is an instant orange flag in my book, and thorough questioning would be needed to determine if this is an ongoing attitude problem where there's a reluctance/reticence to read other peoples' code. That portends laziness, a disrespect for colleagues, and a disrespect for the business's needs, which are rarely aligned with tying its developer labor up in a greenfield reimplementation.
