I would never think of asking this question since I have always just assumed that if you are building software, you are using version control. Apparently I was wrong...
... Yeah. I spent one job emailing code files back and forth (and verbally acquiring locks at the file-level). I spent most of the time there trying to convince the team to at least learn how to use a patch tool and mail patches instead.
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.
I once thought the same, and then I landed at a company where the source was contained across a mixture of svn, network drives and customer production servers.
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.
Yep - I worked at a company where our entire codebase was inside a folder in our web server. We actually copied things locally and had to paste in changes via FTP.
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.
