tl;dr: Take fascinating classes while you have the chance. If that means that you take a graphics class instead of software design, learn software design fundamentals on the side and apply them to your graphics project work.
Longer answer:
Rebutting Uri's answer, here are points that I use when I am reviewing resumes and interviewing candidates:
Do you have a degree in anything? What level of education? What will we talk about in regards to this degree? B.S. is the basis, M.S. is desirable, Ph.D. leads to a different level of interview and the potential for the highest pay. So, from the point of view of the applicant, the Ph.D. has the highest value.
What experience do you have and what would that bring to my team? School experience can apply to a junior person as we can talk about a particular project and draw parallels between what we do.
I don't care at all about your school other than as a discussion point. Why did you choose that program? I chose my graduate school because they offered me full financial aid and a fellowship. That has certainly worked out for me in the long run.
I don't care about your GPA except for really crazy numbers. Lower than 2 would indicate something very strange. 4.0 would lead to the question of "why didn't you take any hard classes?"
Your ability to talk about the aspects of your work that map to industry software activities. Did you use version control? Did you work in teams? Have you ever written a spec for another person? Have you ever had to work from a spec?
Courses are critical. Do you have a fundamental understanding of data structures? Algorithmic complexity? Can you do math? Have you taken a compilers class? Why did you take the classes that you did? Can you talk about what was hard / important in your classes?
Here's the punchline to my resume evaluation process (which is going to sound a little mean):
If you tell me that you learned about software engineering in school, I am not going to believe you.
Technically, it's possible that you learned everything you need to know about working with a team on large scale, multi-year projects. If that's the case, you're going to have to convince me. Here are some of the questions that I'm going to ask:
- What is your practical experience (in school or out)? What have you made (see the fascinating courses recommendation at the top)?
- Why do you need a spec?
- What is feature creep?
- How would you estimate a software task?
- Did you allow for independent testing time in your estimate?
- What happens if a higher priority case appears on your list?
Point one above is the critical issue: if you can make it past that, we're going to have a great talk. If you've only learned the mechanics of software engineering rather than the practical aspects, our talk is going to be rough going.