absolutely all high-aptitude. my thinking there, fwiw, is that making something high-aptitude students like is the only way to build something that less-inclined students like.
their prior programming experience varied, though there's certainly bias in who would sign up for coding tutoring (free or paid.)
all were comfortable using computers, and they'd seen code before. about half had gone through a Girls Who Code summer program (http://girlswhocode.com/programs/), which is designed, i think, to overview technologies more than drill concepts. they all had computers had home (about 50-50 windows/mac) with new-ish chrome or safari.
i only had one student take the multiple choice questions; he would have gotten a 3 or 4 on that part. he's coming off SAT prep and is good at taking standardized tests; he was weakest on the test's particulars ("how many bytes in an int?") i spent very little time on those sorts of questions; my view is that a motivated student who can understands how computers think will learn those particulars if s/he wants a 5. and for those who don't, there's google and stackoverflow.
i asked students to answer old free-response questions in the editor that's shown in the fizzbuzz video. that worked really well; with the help of the compiler, they were able to ace those questions. (i know you don't get a compiler on test day, but it seems silly to cripple them when learning.)
sometimes i tutored in person; other times, i did so over google hangout. either way, i was working one-on-one with a student, and it was painfully clear when s/he was confused, whether it was over a CS concept or a tool i'd introduced. tutoring also meant it was my responsibility to "fix it", and i think that explains a lot of why i cut 160 classroom hours to 20 tutoring hours.