Bluntly, you want a degree with the maximal value for what you can afford.
So, certificate programs are effectively useless. No one cares about a certificate in game development, except the community colleges which want students.
Associates degrees, again, the degree isn't going to open any doors for you.
When looking at a Bachelor's degree, you want a degree with regional (that is to say, traditional higher education) accreditation, not national (that is to say, normally associated with trade schools) accreditation. The dedicated game development schools (DigiPen, Full Sail) are, as far as I know, still both nationally accredited. What that means for a prospective student is that if you wanted to go to graduate school, you would discover that you would need to get *another* Bachelor's degree first, because they won't count the one you have in game development.
Finally, I should caution you. The average career in game development is still quite short. Skilled programmers should have no trouble moving outside the industry (and getting a nice pay bump in the process). Artists? Well, everyone and their goat has a web site now, and the demand for art content is quite high. Producers? Producer maps straight over to Program Manager in the rest of technology, and again, will likely get a pay bump. Designers? The only people who need game designers are game companies.
I have been threatening for years to pitch a "How to Break Out of the Game Industry" panel for GDC.
When I decided (because, bluntly, the continual crunch burned me out) that it was time to leave the game industry, my path out was actually the fact that I had built a lot of tools for game development over the years. Look for points of congruence between what another part of high tech needs and what you have done in games, and take advantage of the halo effect that "professional game developer" has in the eyes of some people looking to hire, and find your way out.
Do you need to stay in your local area, or are you willing to relocate? Who do you know outside of games but inside of high tech? What sounds *interesting* to you as a career path to take? Where would you ideally like to live? What sounds like the most interesting thing to work on? Big company or small company, you ideally want someone you know and who knows your skills to be walking that resume in the door.
Start looking now. Write a resume for outside the game industry, and tune it and the cover letter for every job you are looking for. You just need to find the right position, it is going to be out there.
I will disagree with Tom, I would not have this discussion with your employer. When you have your next position lined up, give them two weeks notice. Having a discussion with them about it is far more likely to have your employment ending on their timetable rather than yours.
The reason you don't advance to the next round can have nothing to do with how you answered the question.
The Game Industry has a talent oversupply, especially at entry level. This is further exacerbated by the instability of the industry; at any given point in time layoffs are putting experienced developers back into the labor pool.
So you could literally be the perfect entry level candidate, cream of the applicant pool, but if two days before they decide who to bring in for in-person interviews they get applications from experienced devs, you are going to fall out of the list.
So, that sounds very much like they are looking to see how comfortable you are with actually implementing and understanding data structures, rather than just using libraries. Yes, you probably won't be writing your own systems (and arguably, most of the time, you shouldn't be), but making sure you know how to as an open-book question seems reasonable to me.
If you were going to make a custom packet in binary. you need to add a packet header in case data is corrupted, or hacked.
Usually the header includes
1. Message ID
2. Message type or class
4. Actual data size
The checksum is likely wasted data. It isn't necessary assuming that your transport layer is TCP or UDP, since those are already doing those checks. And a checksum is useless against an actual attacker.
College debt cannot be discharged in bankruptcy -- if you were disabled they would garnish your social security to pay back your college loans.
Debt denies opportunities. You have payments that must be made, and that limits your ability to pursue lower paying options with long term payout, or to get access to credit that you might need for future purposes.
Threading is one of the hardest things to do well in programming. Period.
Locks are both prone to hard but complex failures (deadlocks) on the one hand, and extreme performance hits on the other (limited number of locks to prevent deadlocks).
I'm personally fond of option 3 (above) in the case of network code, for a couple of reasons. First, you are spending as little time in the lock as possible, so you might be able to get away with a single "I am about to create a message" lock. Second, you have a single inter-thread communications system. The first one makes it less likely you will have programmer error, and the second gives you a single high-risk component to test the everliving-hell out of.
I cannot imagine ever hiring for a programmer position without having the candidate white board one or more programming problems.
I say this, because I've been the "technical interview" for people being hired in as programmers who really were not at all qualified. The resume looked great, they absolutely nailed the "let's talk about process, and how we work together" process interviews, as well as the "let's talk about programming without actually doing any" interviews. And then I asked them to whiteboard, and they absolutely cratered.
One of the questions I used to use when looking at candidates who listed on their resume a proficiency with C/C++ was a simple opener.
Please implement this function:
/* Implement a simplified version of integer to ascii, supporting only base 10, and assuming a 32 bit value on a 2s-Complement architecture */
char * itoa(Int32 value)
This is not a hard question per se (as with most of my interview questions, I stole it from questions I was asked in an interview). There are a couple of ways to approach it, and while there is a corner case, I don't hold missing it against the candidate. Getting it on the other hand is a bonus. Mostly, I want to see you approach the problem.
Not only did he confidently write it, it took a fair bit to convince him he was wrong. Even with a lot of prompting, what was supposed to be the first 15 minutes of the interview took the whole hour, and he never did get the problem solved.
And that is why I'll always want anyone being hired for a development role to actually write code as part of the interview. Because I've *seen* people with the right resume say all the right things, and flunk the ability to actually write anything. I no longer assume "basic coding competence".
[As a side note, having been on both sides of whiteboarding questions, it is *always* easier to spot the bug while you are sitting there watching them write. That's why the interviewer always seems to have a laser focus on the bug when you haven't seen it. As a candidate, as soon as you finish writing it down (and you should talk about what you are doing and why as you go), say something to the effect of "Now to step through this and look for bugs", and out loud start debugging what you wrote with example cases.]