Do you know that? $44-$49 average hourly rates for freelancers with less than five years of experience next

Do array subscripts always start with zero?

Yes. If you have an array a[MAX] (in which MAX is some value known at compile time), the first element is  a[0], and the last element is a[MAX-1]. This arrangement is different from what you would find in some other languages. In some languages, such as some versions of BASIC, the elements would be a[1] through  a[MAX], and in other languages, such as Pascal, you can have it either way.

This variance can lead to some confusion. The "first element" in non-technical terms is the "zero'th" element according to its array index. If you're using spoken words, use "first" as the opposite of "last." If that's not precise enough, use pseudo-C. You might say, "The elements  a sub one through a sub eight," or, "The second through ninth elements of a."

There's something you can do to try to fake array subscripts that start with one. Don't do it. The technique is described here only so that you'll know why not to use it.

Because pointers and arrays are almost identical, you might consider creating a pointer that would refer to the same elements as an array but would use indices that start with one. For example:

/* don't do this!!! */
int     a0[ MAX ];
int     *a1 = a0 - 1;   /* & a[ -1 ] */

Thus, the first element of a0 (if this worked, which it might not) would be the same as a1[1]. The last element
of a0, a0[MAX-1], would be the same as a1[MAX]. There are two reasons why you shouldn't do this.

The first reason is that it might not work. According to the ANSI/ISO standard, it's undefined (which is a
Bad Thing). The problem is that &a[-1] might not be a valid address; Your program might
work all the time with some compilers, and some of the time with all compilers. Is that good enough?

The second reason not to do this is that it's not C-like. Part of learning C is to learn how array indices work.
Part of reading (and maintaining) someone else's C code is being able to recognize common C idioms. If you
do weird stuff like this, it'll be harder for people to understand your code. (It'll be harder for you to understand
your own code, six months later.)