Even as someone who enjoys side projects, the prospect of sharing a side project, and being criticized by a potential employer about the contents of it, turns it from "side project" to work.
From my experiences on both sides of the hiring game, side projects aren't really criticized in an interview but are rather used as a starting point for a conversation to explore the ways of thinking of the potential employee. "What was on of the most challenging parts about your project?" is probably one of the most common questions there, and I'd guess that long-running side projects (even if they have a lot of inactivity in them) contain challenges like any other project, maybe even more so.
If the applicant has side projects, it's often easier to talk about them instead of day-job code, since they usually are more passionate about that, and they can talk about it more freely because they don't have to be afraid to (accidentally) spill company secrets. Side projects are not a must and I've had good conversations with applicants about their work projects, though more confidence to talk about them is something that comes with seniority in my experience.
Nowadays you can share anything online (git or other) without fear of rejection, because unless you choose point select individuals to it, in today's deep oceans of "everyone sharing every random little bone they spewed up" it'll immediately drown and stay there forever undetected and unnoticed. Doubly so if you don't fill out repo description or tags.
(There's must be gazillions of solo hackers dumping their sources of the coolest little projects and experiments without any attention, simply because they don't go and spend the day yapping on about it everywhere --- they Just Keep On Hacking.)
The upside of doing so? If a code file that's way below your current skills is indeed many years old, this becomes clearly visible in the repo and there's no need to explain yourself --- if choosing to indeed point someone to your personal for-fun code-bases.
You should be able to take constructive criticism of your work regardless if it's a side project or not.
Yes, you basically answered the question your self. Tell the interviewer that you wrote that code ten years ago and while it works it's less then ideal, then explain why its not ideal and what a better solution would be.
Because they'll then try to make every part of the code perfect and with complete documentation for everything, probably spending more time trying to present it rather than working on it.
Almost all of the side projects would have undocumented constraints and requirements on which the design/engineering decisions were based. And I doubt the interviewer would take time to ask for design constraints beforehand and then go through the code enough to understand its design/architecture and have interesting criticisms that would bring something positive for the side project in the future.
You can't criticize design decisions without context. I would not be welcoming to someone criticizing my side projects without first asking for context/design constraints the work was based on.
I would not lash out or whatever. But I would not take the criticism without some sense of other person's care for the side project in question.
As an example, check the source on my homepage: http://jjcm.org
If nothing else, that was an entertaining read.
Glad you found it entertaining!