Having been burned more than once, the questions I now ask are:
"Do you conduct regular peer reviews of code and documentation?"
"Do you have a bug tracking system?"
"Do you conduct regular peer reviews of code and documentation?"
"Do you have a bug tracking system?"
At one time I would argue that this is a fair question to ask. But in 2017? I'm appalled at the experience you must have had to deem this a valid question in an interview today. Today I'd just assume...and according to you, wrongly so.
Dare I even ask about whether they use source control?
1. Had no bug tracking
2. Had no source control (the official code was whatever was on one of the engineer's laptops)
3. Had no dedicated build machines (builds were done on that engineer's laptop)
4. Had no release process (build that went out was--you guessed it--copied from that engineer's laptop to a CD)
5. Had no formal QA
6. Had no documentation (either comments in the code, a spec, or a user manual)
7. Had no project management or roadmap planning (the CEO would just drop in and said we should do XYZ, and then a few weeks later "is it done yet?")
They thought their software problem was just that they didn't have enough smart engineers. Yea. You have to ask about these basic "hygiene" things.
If they were not open to change and improvement then you would be stuck burning CDs as well!
When I'm just working with my favorite designer and my favorite tester, and it's just us three, it's a lot of fun to just pass post-it notes around.
Even if you're on a multi-million / many-year project.
Dante missed several circles....