If they say "no" or "RCS", politely say that you don't want to be a part of that dev team. Unless they hire you as the only developer, and you see real chances of introducing some sanity.
This is not just about the way they store code; it's about the attitude towards tools. If they aren't aware of source/version control, or are aware but don't care, experience shows that they will be a huge pain to work with. Know a perfectly fine, open source library that does 90% of that task? Have fun getting permission to use it!
At another job they just had a shared drive with a single copy of each project and mandated we use a particular editor because it had an in-built locking scheme. There were a few conditions (e.g. crashes) that required manual lock manipulation before you could accomplish anything. People would often manually release locks out of habit, open a file for writing but just leave it open all day in the background while the lock-holder worked, save the old copy when they were closing up at the end of the day, thereby reverting a day's progress. There was no backup strategy in place. This wasn't the 90s or anything, git and GitHub were already established.
However, I don't directly ask about VCS now, it seems overly focused for a question, instead I will ask how they produce builds, what the deploy pipeline is, and then track back if I find their answers alarming.
That's a good approach, noted!
I tried to make the team switch to something like Git or hell - even SVN - something to manage the code and not have it all in one point of failure but that fell on deaf ears.
Ultimately I create a private repository on Bitbucket and pushed the code there using Git and used that as my personal backup in case shit hit the fan.