Although the Joel Test is a good idea, I wouldn't pass up an opportunity just because it didn't fit into Joel's box. YMMV but I find it better to apply these to the situation rather than as a "by the book" technique of filtering out job opportunities. There are tons of great small startups that have yet to hit their stride yet. You could be the one to show them the folly of their ways and help them hit that stride.
If they don't have their SCM act together and won't let you fix that, I'd pass up such an "opportunity", you're going to have a lot of pain. That's items 1 and 2 and source code control is non-negotiable for me (unless that alternative is starvation).
Daily builds are an it depends, bug database is something you can probably do yourself at worst case, schedule and spec are also things that will make your life miserable if they don't have anything there.
If you don't have quiet working conditions, they don't care about your productivity or the quality of your work (so why should you???).
The rest except for the last are just damned good ideas: good tools shouldn't be a problem today, but your superiors might have funny ideas about what's good. EMACS is non-negotiable for me plus access to a Unix or cygwin on Windows.
If you don't have dedicated testers, more misery, but in a startup that can be finessed.
If they don't take care in hiring programmers (no writing code during interview test), they're going to hire plenty of duds, and getting rid if them is no fun ... assuming the company survives. A startup can't afford very many if any dud hires.
Let me close with one of PG's observations about dot.bomb failures: a whole lot of them were technical failures. Failing to do enough of the Joel Test items makes technical failure more likely and requires heroics to advert it.
