Defrag

After graduating, I spent about 6 months grinding away trying to get a job. Curiously enough, a little over 18 months later, I've been fortunate enough to be helping out on the other side of the interview table (albiet probably only because I do a fairly uncommon programming job, so I only have one person in my department who is senior to me). It's interesting to see both sides. Unsurprisingly, my advice mirrors Carmack's (even though I am but a peon in comparison). What follows is more programmer related than art, but someone may find some use from it.

Use your time wisely
Remember that when in full time education, you have a shitload of time to burn. I reckon I spent only 10-15% of my waking hours engaged in university work; the rest of my time was free time. I could do whatever I wanted with it. Now, you can spend it playing games, getting drunk, watching daytime TV etc... or you could spend it improving your skills. Remember that, at the end of your college/university period, there will be scores of graduates just like you with the same coursework deliverables and accreditations, so what do you have to offer that distinguishes you?

Learn through doing
Make lots of stuff. It doesn't matter what it is, who it's for or why you're making it; just make it. You learn so much more when actually making stuff compared to theorising about it. Theory is definitely important and it's worth doing a degree etc., but you only cement and further your understanding through doing. In my first year of commercial programming (9 'til 5 every day) versus 6 years of sometime coding (maybe a couple of hours every other day), it felt like I learned just as much again. Code that I had considered to be good a year ago suddenly appeared, in hindsight, to be a pile of steaming shit. And long may it continue.

To further underline why 'doing' is important:


I.e. the more time you spend doing something, the better your chances are of becoming good at it. Practice makes you better. If you want the job badly, then you can improve your chances by always creating new works. You could set yourself a goal of "implement small feature x in my program this week" or "create, unwrap and texture a new mesh this week". I personally got the most out of my learning when I was setting repeated, incremental goals each week.

Finish what you start
Don't worry about perfectionism. It's easy to start thinking that everything you do and show to prospective employees must be perfect. That's not the case. You should endeavour to finish what you started; even a rough, finished version is better than a polished fragment. Companies understand that you are young, raw and will require support, mentoring and encouragement. The code I submitted that helped secure an interview should have by all rights been set on fire, detonated and then buried in a lead-lined mine shaft. It was pretty horribly designed, but it demonstrated that I could finish a project. In my opinion, the most important thing is that you can demonstrate that you get things done. Junior members of staff are not hired as read-made geniuses who slot into the production machine firing on all cylinders. Yes, these people exist, but they are few and far between. As long as you demonstrate that you're a decent person, you have potential and that you will find a way to achieve your goals, you have a chance.

The reason I say this is that, in the modding scene in particular, I encountered way too many people who had portfolios full of half-finished levels, models, texture sets etc. The moment I see this I automatically think "flake". The hardest part is finishing something; pulling things apart and optimising them, then rebuilding them. Reducing the texture memory usage, fixing alignment and clipping issues etc. There is little creative fulfilment involved in this step, there is no artistic merit or craft in fiddling with it and there will be nobody to offer you a compliment on your collision and clip optimisations. It takes guts, pure and simple. Any time I saw scores of "cool looking room in never finished level" or "half an awesome gun model" images on websites, I just closed the page. Do not want. If you can't even finish your own personal work, work that involves a subject matter that is of your own choosing, then why would a company have any faith in you finishing something you may not have a particularly strong affinity for? Chances are you won't be working on Rage or Bioshock 2...

If you can't find a way to finish to a standard you're happy with then limit the scope. Remove functionality from the program, cut out areas of the level or reduce the complexity of a scene. Remember that once you finish the first version, you are now in a good position to iteratively improve it Finish version 1 and go from there. The sense of achievement from finishing something is also a great feeling! It's much better than leaving the work to languish in "C:\work\wip\", never to be viewed again.

Keep up with new technology and techniques
Read a new book. Learn a new language. Read blogs. Write a blog. Write articles. Discuss stuff with like minded folk. I've learned a lot of really interesting and cool ideas from blogs; my google reader has about 50 entries in it, including programming, art, modelling and technology blogs + podcasts. Most only get updated once every week and a lot of them are sporadic or inactive, but you get the odd gem now and then. If you spend a few hours a week reading, it will be a few hours well spent.

MOD MOD MOD
Yeah. I've already talked about this at length before, so I'll spare you the rant again. Mods are basically smaller versions of real companies. You have the same people issues, conflicts of opinion, fun times, hard stretches etc. You can make mistakes in mods and then learn from them. You also make a shitload of contacts if you're a decent guy. Contacts and string pulling can be instrumental in landing an interview, so don't pass on modding. My modding with FF was instrumental in getting an interview; it distinguished me from a lot of my peers by the way of proving that I have the passion to make something in my spare time. I guess different companies view modding in a different light, but it was great for me.

Create a non-generic CV
CVs should be grounded in what you've actually done. Don't smother it in buzzwords or over-egg the pudding. Don't oversell or overcomplicate something you've finished to try and make it look better than it is. Don't pad your CV with terminology and 'skill' bullet points that add nothing. My first attempts at CVs both suffered from these problems -- I was simply spamming phrases, technologies and buzzwords instead of talking about what I'd actually achieved with my most important skills. Bullet point-driven skill-heavy CVs tend to be impersonal and anonymous. There is nothing to distinguish one from another.

E.g. "Fluent grasp of C++, Direct3D, OpenGL, TDD, OpenAL, LINQ" = noise. Compare that to, "In my spare time, I developed a small C++ game featuring ; the rendering was implemented using D3D using features, including to drive a particle system".

I.e. give your skills with plenty of context, not as some detached list of headless bullet points. Luke Halliwell has some really good articles on CVs, so I'll redirect you to his post rather than ape it.

Don't talk a load of balls
This is more for programmers, but when it comes to interviews, less is often more.

Be prepared to have your CV grilled. If you talk a good game on your CV, be prepared to be called out on any and every detail (this is why you should never embellish your CV with skills you don't have...). You should think about your decisions and be able to justify them. E.g. if someone asks you why you used language x for assignment y, you should be able to say why. "Since the application wasn't required to be fast, I used Java as it freed me from having to track memory allocation, meaning I had more time to concentrate on feature development" is better than "because I always use Java". If you cannot justify yourself due to making a poor decision and you learned something from the process, this is the ideal time to talk about it. It's not the ideal time to defensively trot out excuses. Self-awareness and the ability to reflect on projects (successful or otherwise) are very important things.

If an answer should be explainable in 3 sentences, use 3 sentences. Don't keep on talking until your course is gently steered on to the next topic. There's nothing wrong with being nervous, but try not to ramble because it just gives the impression that you're vainly groping for the right phrase. If you don't know the answer or you're unsure as to whether your point was understood, just say so. It's much better to say "does that answer your question?" than to talk for 3 minutes solid, hoping you ticked some box.

Finally, have faith in your own opinions. Don't flip flop based on what you think the interviewer wants to hear. Bosses aren't interested in hearing their own opinion parroted back at them -- they want to hear what you think.

If at first you don't suceed
Try try try again. If you attended an interview but didn't make it, politely ask if the company can offer you any feedback on your application. Then, work like crazy for months and re-apply when you feel it is appropriate. It took me many months to get my foot in the door, but if you genuinely want it, you can most likely beat the door down through sheer persistence.

After graduating, I spent about 6 months grinding away trying to get a job. Curiously enough, a little over 18 months later, I've been fortunate enough to be helping out on the other side of the interview table (albiet probably only because I do a fairly uncommon programming job, so I only have one person in my department who is senior to me). It's interesting to see both sides. Unsurprisingly, my advice mirrors Carmack's (even though I am but a peon in comparison). What follows is more programmer related than art, but someone may find some use from it.

Use your time wisely
Remember that when in full time education, you have a shitload of time to burn. I reckon I spent only 10-15% of my waking hours engaged in university work; the rest of my time was free time. I could do whatever I wanted with it. Now, you can spend it playing games, getting drunk, watching daytime TV etc... or you could spend it improving your skills. Remember that, at the end of your college/university period, there will be scores of graduates just like you with the same coursework deliverables and accreditations, so what do you have to offer that distinguishes you?

Learn through doing
Make lots of stuff. It doesn't matter what it is, who it's for or why you're making it; just make it. You learn so much more when actually making stuff compared to theorising about it. Theory is definitely important and it's worth doing a degree etc., but you only cement and further your understanding through doing. In my first year of commercial programming (9 'til 5 every day) versus 6 years of sometime coding (maybe a couple of hours every other day), it felt like I learned just as much again. Code that I had considered to be good a year ago suddenly appeared, in hindsight, to be a pile of steaming shit. And long may it continue.

To further underline why 'doing' is important:


I.e. the more time you spend doing something, the better your chances are of becoming good at it. Practice makes you better. If you want the job badly, then you can improve your chances by always creating new works. You could set yourself a goal of "implement small feature x in my program this week" or "create, unwrap and texture a new mesh this week". I personally got the most out of my learning when I was setting repeated, incremental goals each week.

Finish what you start
Don't worry about perfectionism. It's easy to start thinking that everything you do and show to prospective employees must be perfect. That's not the case. You should endeavour to finish what you started; even a rough, finished version is better than a polished fragment. Companies understand that you are young, raw and will require support, mentoring and encouragement. The code I submitted that helped secure an interview should have by all rights been set on fire, detonated and then buried in a lead-lined mine shaft. It was pretty horribly designed, but it demonstrated that I could finish a project. In my opinion, the most important thing is that you can demonstrate that you get things done. Junior members of staff are not hired as read-made geniuses who slot into the production machine firing on all cylinders. Yes, these people exist, but they are few and far between. As long as you demonstrate that you're a decent person, you have potential and that you will find a way to achieve your goals, you have a chance.

The reason I say this is that, in the modding scene in particular, I encountered way too many people who had portfolios full of half-finished levels, models, texture sets etc. The moment I see this I automatically think "flake". The hardest part is finishing something; pulling things apart and optimising them, then rebuilding them. Reducing the texture memory usage, fixing alignment and clipping issues etc. There is little creative fulfilment involved in this step, there is no artistic merit or craft in fiddling with it and there will be nobody to offer you a compliment on your collision and clip optimisations. It takes guts, pure and simple. Any time I saw scores of "cool looking room in never finished level" or "half an awesome gun model" images on websites, I just closed the page. Do not want. If you can't even finish your own personal work, work that involves a subject matter that is of your own choosing, then why would a company have any faith in you finishing something you may not have a particularly strong affinity for? Chances are you won't be working on Rage or Bioshock 2...

If you can't find a way to finish to a standard you're happy with then limit the scope. Remove functionality from the program, cut out areas of the level or reduce the complexity of a scene. Remember that once you finish the first version, you are now in a good position to iteratively improve it Finish version 1 and go from there. The sense of achievement from finishing something is also a great feeling! It's much better than leaving the work to languish in "C:\work\wip\", never to be viewed again.

Keep up with new technology and techniques
Read a new book. Learn a new language. Read blogs. Write a blog. Write articles. Discuss stuff with like minded folk. I've learned a lot of really interesting and cool ideas from blogs; my google reader has about 50 entries in it, including programming, art, modelling and technology blogs + podcasts. Most only get updated once every week and a lot of them are sporadic or inactive, but you get the odd gem now and then. If you spend a few hours a week reading, it will be a few hours well spent.

MOD MOD MOD
Yeah. I've already talked about this at length before, so I'll spare you the rant again. Mods are basically smaller versions of real companies. You have the same people issues, conflicts of opinion, fun times, hard stretches etc. You can make mistakes in mods and then learn from them. You also make a shitload of contacts if you're a decent guy. Contacts and string pulling can be instrumental in landing an interview, so don't pass on modding. My modding with FF was instrumental in getting an interview; it distinguished me from a lot of my peers by the way of proving that I have the passion to make something in my spare time. I guess different companies view modding in a different light, but it was great for me.

Create a non-generic CV
CVs should be grounded in what you've actually done. Don't smother it in buzzwords or over-egg the pudding. Don't oversell or overcomplicate something you've finished to try and make it look better than it is. Don't pad your CV with terminology and 'skill' bullet points that add nothing. My first attempts at CVs both suffered from these problems -- I was simply spamming phrases, technologies and buzzwords instead of talking about what I'd actually achieved with my most important skills. Bullet point-driven skill-heavy CVs tend to be impersonal and anonymous. There is nothing to distinguish one from another.

E.g. "Fluent grasp of C++, Direct3D, OpenGL, TDD, OpenAL, LINQ" = noise. Compare that to, "In my spare time, I developed a small C++ game featuring ; the rendering was implemented using D3D using features, including to drive a particle system".

I.e. give your skills with plenty of context, not as some detached list of headless bullet points. Luke Halliwell has some really good articles on CVs, so I'll redirect you to his post rather than ape it.

Don't talk a load of balls
This is more for programmers, but when it comes to interviews, less is often more.

Be prepared to have your CV grilled. If you talk a good game on your CV, be prepared to be called out on any and every detail (this is why you should never embellish your CV with skills you don't have...). You should think about your decisions and be able to justify them. E.g. if someone asks you why you used language x for assignment y, you should be able to say why. "Since the application wasn't required to be fast, I used Java as it freed me from having to track memory allocation, meaning I had more time to concentrate on feature development" is better than "because I always use Java". If you cannot justify yourself due to making a poor decision and you learned something from the process, this is the ideal time to talk about it. It's not the ideal time to defensively trot out excuses. Self-awareness and the ability to reflect on projects (successful or otherwise) are very important things.

If an answer should be explainable in 3 sentences, use 3 sentences. Don't keep on talking until your course is gently steered on to the next topic. There's nothing wrong with being nervous, but try not to ramble because it just gives the impression that you're vainly groping for the right phrase. If you don't know the answer or you're unsure as to whether your point was understood, just say so. It's much better to say "does that answer your question?" than to talk for 3 minutes solid, hoping you ticked some box.

Finally, have faith in your own opinions. Don't flip flop based on what you think the interviewer wants to hear. Bosses aren't interested in hearing their own opinion parroted back at them -- they want to hear what you think.

If at first you don't suceed
Try try try again. If you attended an interview but didn't make it, politely ask if the company can offer you any feedback on your application. Then, work like crazy for months and re-apply when you feel it is appropriate. It took me many months to get my foot in the door, but if you genuinely want it, you can most likely beat the door down through sheer persistence.

After graduating, I spent about 6 months grinding away trying to get a job. Curiously enough, a little over 18 months later, I've been fortunate enough to be helping out on the other side of the interview table (albiet probably only because I do a fairly uncommon programming job, so I only have one person in my department who is senior to me). It's interesting to see both sides. Unsurprisingly, my advice mirrors Carmack's (even though I am but a peon in comparison). What follows is more programmer related than art, but someone may find some use from it.

Use your time wisely
Remember that when in full time education, you have a shitload of time to burn. I reckon I spent only 10-15% of my waking hours engaged in university work; the rest of my time was free time. I could do whatever I wanted with it. Now, you can spend it playing games, getting drunk, watching daytime TV etc... or you could spend it improving your skills. Remember that, at the end of your college/university period, there will be scores of graduates just like you with the same coursework deliverables and accreditations, so what do you have to offer that distinguishes you?

Learn through doing
Make lots of stuff. It doesn't matter what it is, who it's for or why you're making it; just make it. You learn so much more when actually making stuff compared to theorising about it. Theory is definitely important and it's worth doing a degree etc., but you only cement and further your understanding through doing. In my first year of commercial programming (9 'til 5 every day) versus 6 years of sometime coding (maybe a couple of hours every other day), it felt like I learned just as much again. Code that I had considered to be good a year ago suddenly appeared, in hindsight, to be a pile of steaming shit. And long may it continue.

To further underline why 'doing' is important:


I.e. the more time you spend doing something, the better your chances are of becoming good at it. Practice makes you better. If you want the job badly, then you can improve your chances by always creating new works. You could set yourself a goal of "implement small feature x in my program this week" or "create, unwrap and texture a new mesh this week". I personally got the most out of my learning when I was setting repeated, incremental goals each week.

Finish what you start
Don't worry about perfectionism. It's easy to start thinking that everything you do and show to prospective employees must be perfect. That's not the case. You should endeavour to finish what you started; even a rough, finished version is better than a polished fragment. Companies understand that you are young, raw and will require support, mentoring and encouragement. The code I submitted that helped secure an interview should have by all rights been set on fire, detonated and then buried in a lead-lined mine shaft. It was pretty horribly designed, but it demonstrated that I could finish a project. In my opinion, the most important thing is that you can demonstrate that you get things done. Junior members of staff are not hired as read-made geniuses who slot into the production machine firing on all cylinders. Yes, these people exist, but they are few and far between. As long as you demonstrate that you're a decent person, you have potential and that you will find a way to achieve your goals, you have a chance.

The reason I say this is that, in the modding scene in particular, I encountered way too many people who had portfolios full of half-finished levels, models, texture sets etc. The moment I see this I automatically think "flake". The hardest part is finishing something; pulling things apart and optimising them, then rebuilding them. Reducing the texture memory usage, fixing alignment and clipping issues etc. There is little creative fulfilment involved in this step, there is no artistic merit or craft in fiddling with it and there will be nobody to offer you a compliment on your collision and clip optimisations. It takes guts, pure and simple. Any time I saw scores of "cool looking room in never finished level" or "half an awesome gun model" images on websites, I just closed the page. Do not want. If you can't even finish your own personal work, work that involves a subject matter that is of your own choosing, then why would a company have any faith in you finishing something you may not have a particularly strong affinity for? Chances are you won't be working on Rage or Bioshock 2...

If you can't find a way to finish to a standard you're happy with then limit the scope. Remove functionality from the program, cut out areas of the level or reduce the complexity of a scene. Remember that once you finish the first version, you are now in a good position to iteratively improve it Finish version 1 and go from there. The sense of achievement from finishing something is also a great feeling! It's much better than leaving the work to languish in "C:\work\wip\", never to be viewed again.

Keep up with new technology and techniques
Read a new book. Learn a new language. Read blogs. Write a blog. Write articles. Discuss stuff with like minded folk. I've learned a lot of really interesting and cool ideas from blogs; my google reader has about 50 entries in it, including programming, art, modelling and technology blogs + podcasts. Most only get updated once every week and a lot of them are sporadic or inactive, but you get the odd gem now and then. If you spend a few hours a week reading, it will be a few hours well spent.

MOD MOD MOD
Yeah. I've already talked about this at length before, so I'll spare you the rant again. Mods are basically smaller versions of real companies. You have the same people issues, conflicts of opinion, fun times, hard stretches etc. You can make mistakes in mods and then learn from them. You also make a shitload of contacts if you're a decent guy. Contacts and string pulling can be instrumental in landing an interview, so don't pass on modding. My modding with FF was instrumental in getting an interview; it distinguished me from a lot of my peers by the way of proving that I have the passion to make something in my spare time. I guess different companies view modding in a different light, but it was great for me.

Create a non-generic CV
CVs should be grounded in what you've actually done. Don't smother it in buzzwords or over-egg the pudding. Don't oversell or overcomplicate something you've finished to try and make it look better than it is. Don't pad your CV with terminology and 'skill' bullet points that add nothing. My first attempts at CVs both suffered from these problems -- I was simply spamming phrases, technologies and buzzwords instead of talking about what I'd actually achieved with my most important skills. Bullet point-driven skill-heavy CVs tend to be impersonal and anonymous. There is nothing to distinguish one from another.

E.g. "Fluent grasp of C++, Direct3D, OpenGL, TDD, OpenAL, LINQ" = noise. Compare that to, "In my spare time, I developed a small C++ game featuring ; the rendering was implemented using D3D using features, including to drive a particle system".

I.e. give your skills with plenty of context, not as some detached list of headless bullet points. Luke Halliwell has some really good articles on CVs, so I'll redirect you to his post rather than ape it.

Don't talk a load of balls
This is more for programmers, but when it comes to interviews, less is often more.

Be prepared to have your CV grilled. If you talk a good game on your CV, be prepared to be called out on any and every detail (this is why you should never embellish your CV with skills you don't have...). You should think about your decisions and be able to justify them. E.g. if someone asks you why you used language x for assignment y, you should be able to say why. "Since the application wasn't required to be fast, I used Java as it freed me from having to track memory allocation, meaning I had more time to concentrate on feature development" is better than "because I always use Java". If you cannot justify yourself due to making a poor decision and you learned something from the process, this is the ideal time to talk about it. It's not the ideal time to defensively trot out excuses. Self-awareness and the ability to reflect on projects (successful or otherwise) are very important things.

If an answer should be explainable in 3 sentences, use 3 sentences. Don't keep on talking until your course is gently steered on to the next topic. There's nothing wrong with being nervous, but try not to ramble because it just gives the impression that you're vainly groping for the right phrase. If you don't know the answer or you're unsure as to whether your point was understood, just say so. It's much better to say "does that answer your question?" than to talk for 3 minutes solid, hoping you ticked some box.

Finally, have faith in your own opinions. Don't flip flop based on what you think the interviewer wants to hear. Bosses aren't interested in hearing their own opinion parroted back at them -- they want to hear what you think.

If at first you don't suceed
Try try try again. If you attended an interview but didn't make it, politely ask if the company can offer you any feedback on your application. Then, work like crazy for months and re-apply when you feel it is appropriate. It took me many months to get my foot in the door, but if you genuinely want it, you can most likely beat the door down through sheer persistence.

After graduating, I spent about 6 months grinding away trying to get a job. Curiously enough, a little over 18 months later, I've been fortunate enough to be helping out on the other side of the interview table (albiet probably only because I do a fairly uncommon programming job, so I only have one person in my department who is senior to me). It's interesting to see both sides. Unsurprisingly, my advice mirrors Carmack's (even though I am but a peon in comparison). What follows is more programmer related than art, but someone may find some use from it.

Use your time wisely
Remember that when in full time education, you have a shitload of time to burn. I reckon I spent only 10-15% of my waking hours engaged in university work; the rest of my time was free time. I could do whatever I wanted with it. Now, you can spend it playing games, getting drunk, watching daytime TV etc... or you could spend it improving your skills. Remember that, at the end of your college/university period, there will be scores of graduates just like you with the same coursework deliverables and accreditations, so what do you have to offer that distinguishes you?

Learn through doing
Make lots of stuff. It doesn't matter what it is, who it's for or why you're making it; just make it. You learn so much more when actually making stuff compared to theorising about it. Theory is definitely important and it's worth doing a degree etc., but you only cement and further your understanding through doing. In my first year of commercial programming (9 'til 5 every day) versus 6 years of sometime coding (maybe a couple of hours every other day), it felt like I learned just as much again. Code that I had considered to be good a year ago suddenly appeared, in hindsight, to be a pile of steaming shit. And long may it continue.

To further underline why 'doing' is important:


I.e. the more time you spend doing something, the better your chances are of becoming good at it. Practice makes you better. If you want the job badly, then you can improve your chances by always creating new works. You could set yourself a goal of "implement small feature x in my program this week" or "create, unwrap and texture a new mesh this week". I personally got the most out of my learning when I was setting repeated, incremental goals each week.

Finish what you start
Don't worry about perfectionism. It's easy to start thinking that everything you do and show to prospective employees must be perfect. That's not the case. You should endeavour to finish what you started; even a rough, finished version is better than a polished fragment. Companies understand that you are young, raw and will require support, mentoring and encouragement. The code I submitted that helped secure an interview should have by all rights been set on fire, detonated and then buried in a lead-lined mine shaft. It was pretty horribly designed, but it demonstrated that I could finish a project. In my opinion, the most important thing is that you can demonstrate that you get things done. Junior members of staff are not hired as read-made geniuses who slot into the production machine firing on all cylinders. Yes, these people exist, but they are few and far between. As long as you demonstrate that you're a decent person, you have potential and that you will find a way to achieve your goals, you have a chance.

The reason I say this is that, in the modding scene in particular, I encountered way too many people who had portfolios full of half-finished levels, models, texture sets etc. The moment I see this I automatically think "flake". The hardest part is finishing something; pulling things apart and optimising them, then rebuilding them. Reducing the texture memory usage, fixing alignment and clipping issues etc. There is little creative fulfilment involved in this step, there is no artistic merit or craft in fiddling with it and there will be nobody to offer you a compliment on your collision and clip optimisations. It takes guts, pure and simple. Any time I saw scores of "cool looking room in never finished level" or "half an awesome gun model" images on websites, I just closed the page. Do not want. If you can't even finish your own personal work, work that involves a subject matter that is of your own choosing, then why would a company have any faith in you finishing something you may not have a particularly strong affinity for? Chances are you won't be working on Rage or Bioshock 2...

If you can't find a way to finish to a standard you're happy with then limit the scope. Remove functionality from the program, cut out areas of the level or reduce the complexity of a scene. Remember that once you finish the first version, you are now in a good position to iteratively improve it Finish version 1 and go from there. The sense of achievement from finishing something is also a great feeling! It's much better than leaving the work to languish in "C:\work\wip\", never to be viewed again.

Keep up with new technology and techniques
Read a new book. Learn a new language. Read blogs. Write a blog. Write articles. Discuss stuff with like minded folk. I've learned a lot of really interesting and cool ideas from blogs; my google reader has about 50 entries in it, including programming, art, modelling and technology blogs + podcasts. Most only get updated once every week and a lot of them are sporadic or inactive, but you get the odd gem now and then. If you spend a few hours a week reading, it will be a few hours well spent.

MOD MOD MOD
Yeah. I've already talked about this at length before, so I'll spare you the rant again. Mods are basically smaller versions of real companies. You have the same people issues, conflicts of opinion, fun times, hard stretches etc. You can make mistakes in mods and then learn from them. You also make a shitload of contacts if you're a decent guy. Contacts and string pulling can be instrumental in landing an interview, so don't pass on modding. My modding with FF was instrumental in getting an interview; it distinguished me from a lot of my peers by the way of proving that I have the passion to make something in my spare time. I guess different companies view modding in a different light, but it was great for me.

Create a non-generic CV
CVs should be grounded in what you've actually done. Don't smother it in buzzwords or over-egg the pudding. Don't oversell or overcomplicate something you've finished to try and make it look better than it is. Don't pad your CV with terminology and 'skill' bullet points that add nothing. My first attempts at CVs both suffered from these problems -- I was simply spamming phrases, technologies and buzzwords instead of talking about what I'd actually achieved with my most important skills. Bullet point-driven skill-heavy CVs tend to be impersonal and anonymous. There is nothing to distinguish one from another.

E.g. "Fluent grasp of C++, Direct3D, OpenGL, TDD, OpenAL, LINQ" = noise. Compare that to, "In my spare time, I developed a small C++ game featuring ; the rendering was implemented using D3D using features, including to drive a particle system".

I.e. give your skills with plenty of context, not as some detached list of headless bullet points. Luke Halliwell has some really good articles on CVs, so I'll redirect you to his post rather than ape it.

Don't talk a load of balls
This is more for programmers, but when it comes to interviews, less is often more.

Be prepared to have your CV grilled. If you talk a good game on your CV, be prepared to be called out on any and every detail (this is why you should never embellish your CV with skills you don't have...). You should think about your decisions and be able to justify them. E.g. if someone asks you why you used language x for assignment y, you should be able to say why. "Since the application wasn't required to be fast, I used Java as it freed me from having to track memory allocation, meaning I had more time to concentrate on feature development" is better than "because I always use Java". If you cannot justify yourself due to making a poor decision and you learned something from the process, this is the ideal time to talk about it. It's not the ideal time to defensively trot out excuses. Self-awareness and the ability to reflect on projects (successful or otherwise) are very important things.

If an answer should be explainable in 3 sentences, use 3 sentences. Don't keep on talking until your course is gently steered on to the next topic. There's nothing wrong with being nervous, but try not to ramble because it just gives the impression that you're vainly groping for the right phrase. If you don't know the answer or you're unsure as to whether your point was understood, just say so. It's much better to say "does that answer your question?" than to talk for 3 minutes solid, hoping you ticked some box.

Finally, have faith in your own opinions. Don't flip flop based on what you think the interviewer wants to hear. Bosses aren't interested in hearing their own opinion parroted back at them -- they want to hear what you think.

If at first you don't suceed
Try try try again. If you attended an interview but didn't make it, politely ask if the company can offer you any feedback on your application. Then, work like crazy for months and re-apply when you feel it is appropriate. It took me many months to get my foot in the door, but if you genuinely want it, you can most likely beat the door down through sheer persistence.

After graduating, I spent about 6 months grinding away trying to get a job. Curiously enough, a little over 18 months later, I've been fortunate enough to be helping out on the other side of the interview table (albiet probably only because I do a fairly uncommon programming job, so I only have one person in my department who is senior to me). It's interesting to see both sides. Unsurprisingly, my advice mirrors Carmack's (even though I am but a peon in comparison). What follows is more programmer related than art, but someone may find some use from it.

Use your time wisely
Remember that when in full time education, you have a shitload of time to burn. I reckon I spent only 10-15% of my waking hours engaged in university work; the rest of my time was free time. I could do whatever I wanted with it. Now, you can spend it playing games, getting drunk, watching daytime TV etc... or you could spend it improving your skills. Remember that, at the end of your college/university period, there will be scores of graduates just like you with the same coursework deliverables and accreditations, so what do you have to offer that distinguishes you?

Learn through doing
Make lots of stuff. It doesn't matter what it is, who it's for or why you're making it; just make it. You learn so much more when actually making stuff compared to theorising about it. Theory is definitely important and it's worth doing a degree etc., but you only cement and further your understanding through doing. In my first year of commercial programming (9 'til 5 every day) versus 6 years of sometime coding (maybe a couple of hours every other day), it felt like I learned just as much again. Code that I had considered to be good a year ago suddenly appeared, in hindsight, to be a pile of steaming shit. And long may it continue.

To further underline why 'doing' is important:


I.e. the more time you spend doing something, the better your chances are of becoming good at it. Practice makes you better. If you want the job badly, then you can improve your chances by always creating new works. You could set yourself a goal of "implement small feature x in my program this week" or "create, unwrap and texture a new mesh this week". I personally got the most out of my learning when I was setting repeated, incremental goals each week.

Finish what you start
Don't worry about perfectionism. It's easy to start thinking that everything you do and show to prospective employees must be perfect. That's not the case. You should endeavour to finish what you started; even a rough, finished version is better than a polished fragment. Companies understand that you are young, raw and will require support, mentoring and encouragement. The code I submitted that helped secure an interview should have by all rights been set on fire, detonated and then buried in a lead-lined mine shaft. It was pretty horribly designed, but it demonstrated that I could finish a project. In my opinion, the most important thing is that you can demonstrate that you get things done. Junior members of staff are not hired as read-made geniuses who slot into the production machine firing on all cylinders. Yes, these people exist, but they are few and far between. As long as you demonstrate that you're a decent person, you have potential and that you will find a way to achieve your goals, you have a chance.

The reason I say this is that, in the modding scene in particular, I encountered way too many people who had portfolios full of half-finished levels, models, texture sets etc. The moment I see this I automatically think "flake". The hardest part is finishing something; pulling things apart and optimising them, then rebuilding them. Reducing the texture memory usage, fixing alignment and clipping issues etc. There is little creative fulfilment involved in this step, there is no artistic merit or craft in fiddling with it and there will be nobody to offer you a compliment on your collision and clip optimisations. It takes guts, pure and simple. Any time I saw scores of "cool looking room in never finished level" or "half an awesome gun model" images on websites, I just closed the page. Do not want. If you can't even finish your own personal work, work that involves a subject matter that is of your own choosing, then why would a company have any faith in you finishing something you may not have a particularly strong affinity for? Chances are you won't be working on Rage or Bioshock 2...

If you can't find a way to finish to a standard you're happy with then limit the scope. Remove functionality from the program, cut out areas of the level or reduce the complexity of a scene. Remember that once you finish the first version, you are now in a good position to iteratively improve it Finish version 1 and go from there. The sense of achievement from finishing something is also a great feeling! It's much better than leaving the work to languish in "C:\work\wip\", never to be viewed again.

Keep up with new technology and techniques
Read a new book. Learn a new language. Read blogs. Write a blog. Write articles. Discuss stuff with like minded folk. I've learned a lot of really interesting and cool ideas from blogs; my google reader has about 50 entries in it, including programming, art, modelling and technology blogs + podcasts. Most only get updated once every week and a lot of them are sporadic or inactive, but you get the odd gem now and then. If you spend a few hours a week reading, it will be a few hours well spent.

MOD MOD MOD
Yeah. I've already talked about this at length before, so I'll spare you the rant again. Mods are basically smaller versions of real companies. You have the same people issues, conflicts of opinion, fun times, hard stretches etc. You can make mistakes in mods and then learn from them. You also make a shitload of contacts if you're a decent guy. Contacts and string pulling can be instrumental in landing an interview, so don't pass on modding. My modding with FF was instrumental in getting an interview; it distinguished me from a lot of my peers by the way of proving that I have the passion to make something in my spare time. I guess different companies view modding in a different light, but it was great for me.

Create a non-generic CV
CVs should be grounded in what you've actually done. Don't smother it in buzzwords or over-egg the pudding. Don't oversell or overcomplicate something you've finished to try and make it look better than it is. Don't pad your CV with terminology and 'skill' bullet points that add nothing. My first attempts at CVs both suffered from these problems -- I was simply spamming phrases, technologies and buzzwords instead of talking about what I'd actually achieved with my most important skills. Bullet point-driven skill-heavy CVs tend to be impersonal and anonymous. There is nothing to distinguish one from another.

E.g. "Fluent grasp of C++, Direct3D, OpenGL, TDD, OpenAL, LINQ" = noise. Compare that to, "In my spare time, I developed a small C++ game featuring ; the rendering was implemented using D3D using features, including to drive a particle system".

I.e. give your skills with plenty of context, not as some detached list of headless bullet points. Luke Halliwell has some really good articles on CVs, so I'll redirect you to his post rather than ape it.

Don't talk a load of balls
This is more for programmers, but when it comes to interviews, less is often more.

Be prepared to have your CV grilled. If you talk a good game on your CV, be prepared to be called out on any and every detail (this is why you should never embellish your CV with skills you don't have...). You should think about your decisions and be able to justify them. E.g. if someone asks you why you used language x for assignment y, you should be able to say why. "Since the application wasn't required to be fast, I used Java as it freed me from having to track memory allocation, meaning I had more time to concentrate on feature development" is better than "because I always use Java". If you cannot justify yourself due to making a poor decision and you learned something from the process, this is the ideal time to talk about it. It's not the ideal time to defensively trot out excuses. Self-awareness and the ability to reflect on projects (successful or otherwise) are very important things.

If an answer should be explainable in 3 sentences, use 3 sentences. Don't keep on talking until your course is gently steered on to the next topic. There's nothing wrong with being nervous, but try not to ramble because it just gives the impression that you're vainly groping for the right phrase. If you don't know the answer or you're unsure as to whether your point was understood, just say so. It's much better to say "does that answer your question?" than to talk for 3 minutes solid, hoping you ticked some box.

Finally, have faith in your own opinions. Don't flip flop based on what you think the interviewer wants to hear. Bosses aren't interested in hearing their own opinion parroted back at them -- they want to hear what you think.

If at first you don't suceed
Try try try again. If you attended an interview but didn't make it, politely ask if the company can offer you any feedback on your application. Then, work like crazy for months and re-apply when you feel it is appropriate. It took me many months to get my foot in the door, but if you genuinely want it, you can most likely beat the door down through sheer persistence.

After graduating, I spent about 6 months grinding away trying to get a job. Curiously enough, a little over 18 months later, I've been fortunate enough to be helping out on the other side of the interview table (albiet probably only because I do a fairly uncommon programming job, so I only have one person in my department who is senior to me). It's interesting to see both sides. Unsurprisingly, my advice mirrors Carmack's (even though I am but a peon in comparison). What follows is more programmer related than art, but someone may find some use from it.

Use your time wisely
Remember that when in full time education, you have a shitload of time to burn. I reckon I spent only 10-15% of my waking hours engaged in university work; the rest of my time was free time. I could do whatever I wanted with it. Now, you can spend it playing games, getting drunk, watching daytime TV etc... or you could spend it improving your skills. Remember that, at the end of your college/university period, there will be scores of graduates just like you with the same coursework deliverables and accreditations, so what do you have to offer that distinguishes you?

Learn through doing
Make lots of stuff. It doesn't matter what it is, who it's for or why you're making it; just make it. You learn so much more when actually making stuff compared to theorising about it. Theory is definitely important and it's worth doing a degree etc., but you only cement and further your understanding through doing. In my first year of commercial programming (9 'til 5 every day) versus 6 years of sometime coding (maybe a couple of hours every other day), it felt like I learned just as much again. Code that I had considered to be good a year ago suddenly appeared, in hindsight, to be a pile of steaming shit. And long may it continue.

To further underline why 'doing' is important:


I.e. the more time you spend doing something, the better your chances are of becoming good at it. Practice makes you better. If you want the job badly, then you can improve your chances by always creating new works. You could set yourself a goal of "implement small feature x in my program this week" or "create, unwrap and texture a new mesh this week". I personally got the most out of my learning when I was setting repeated, incremental goals each week.

Finish what you start
Don't worry about perfectionism. It's easy to start thinking that everything you do and show to prospective employees must be perfect. That's not the case. You should endeavour to finish what you started; even a rough, finished version is better than a polished fragment. Companies understand that you are young, raw and will require support, mentoring and encouragement. The code I submitted that helped secure an interview should have by all rights been set on fire, detonated and then buried in a lead-lined mine shaft. It was pretty horribly designed, but it demonstrated that I could finish a project. In my opinion, the most important thing is that you can demonstrate that you get things done. Junior members of staff are not hired as read-made geniuses who slot into the production machine firing on all cylinders. Yes, these people exist, but they are few and far between. As long as you demonstrate that you're a decent person, you have potential and that you will find a way to achieve your goals, you have a chance.

The reason I say this is that, in the modding scene in particular, I encountered way too many people who had portfolios full of half-finished levels, models, texture sets etc. The moment I see this I automatically think "flake". The hardest part is finishing something; pulling things apart and optimising them, then rebuilding them. Reducing the texture memory usage, fixing alignment and clipping issues etc. There is little creative fulfilment involved in this step, there is no artistic merit or craft in fiddling with it and there will be nobody to offer you a compliment on your collision and clip optimisations. It takes guts, pure and simple. Any time I saw scores of "cool looking room in never finished level" or "half an awesome gun model" images on websites, I just closed the page. Do not want. If you can't even finish your own personal work, work that involves a subject matter that is of your own choosing, then why would a company have any faith in you finishing something you may not have a particularly strong affinity for? Chances are you won't be working on Rage or Bioshock 2...

If you can't find a way to finish to a standard you're happy with then limit the scope. Remove functionality from the program, cut out areas of the level or reduce the complexity of a scene. Remember that once you finish the first version, you are now in a good position to iteratively improve it Finish version 1 and go from there. The sense of achievement from finishing something is also a great feeling! It's much better than leaving the work to languish in "C:\work\wip\", never to be viewed again.

Keep up with new technology and techniques
Read a new book. Learn a new language. Read blogs. Write a blog. Write articles. Discuss stuff with like minded folk. I've learned a lot of really interesting and cool ideas from blogs; my google reader has about 50 entries in it, including programming, art, modelling and technology blogs + podcasts. Most only get updated once every week and a lot of them are sporadic or inactive, but you get the odd gem now and then. If you spend a few hours a week reading, it will be a few hours well spent.

MOD MOD MOD
Yeah. I've already talked about this at length before, so I'll spare you the rant again. Mods are basically smaller versions of real companies. You have the same people issues, conflicts of opinion, fun times, hard stretches etc. You can make mistakes in mods and then learn from them. You also make a shitload of contacts if you're a decent guy. Contacts and string pulling can be instrumental in landing an interview, so don't pass on modding. My modding with FF was instrumental in getting an interview; it distinguished me from a lot of my peers by the way of proving that I have the passion to make something in my spare time. I guess different companies view modding in a different light, but it was great for me.

Create a non-generic CV
CVs should be grounded in what you've actually done. Don't smother it in buzzwords or over-egg the pudding. Don't oversell or overcomplicate something you've finished to try and make it look better than it is. Don't pad your CV with terminology and 'skill' bullet points that add nothing. My first attempts at CVs both suffered from these problems -- I was simply spamming phrases, technologies and buzzwords instead of talking about what I'd actually achieved with my most important skills. Bullet point-driven skill-heavy CVs tend to be impersonal and anonymous. There is nothing to distinguish one from another.

E.g. "Fluent grasp of C++, Direct3D, OpenGL, TDD, OpenAL, LINQ" = noise. Compare that to, "In my spare time, I developed a small C++ game featuring ; the rendering was implemented using D3D using features, including to drive a particle system".

I.e. give your skills with plenty of context, not as some detached list of headless bullet points. Luke Halliwell has some really good articles on CVs, so I'll redirect you to his post rather than ape it.

Don't talk a load of balls
This is more for programmers, but when it comes to interviews, less is often more.

Be prepared to have your CV grilled. If you talk a good game on your CV, be prepared to be called out on any and every detail (this is why you should never embellish your CV with skills you don't have...). You should think about your decisions and be able to justify them. E.g. if someone asks you why you used language x for assignment y, you should be able to say why. "Since the application wasn't required to be fast, I used Java as it freed me from having to track memory allocation, meaning I had more time to concentrate on feature development" is better than "because I always use Java". If you cannot justify yourself due to making a poor decision and you learned something from the process, this is the ideal time to talk about it. It's not the ideal time to defensively trot out excuses. Self-awareness and the ability to reflect on projects (successful or otherwise) are very important things.

If an answer should be explainable in 3 sentences, use 3 sentences. Don't keep on talking until your course is gently steered on to the next topic. There's nothing wrong with being nervous, but try not to ramble because it just gives the impression that you're vainly groping for the right phrase. If you don't know the answer or you're unsure as to whether your point was understood, just say so. It's much better to say "does that answer your question?" than to talk for 3 minutes solid, hoping you ticked some box.

Finally, have faith in your own opinions. Don't flip flop based on what you think the interviewer wants to hear. Bosses aren't interested in hearing their own opinion parroted back at them -- they want to hear what you think.

If at first you don't suceed
Try try try again. If you attended an interview but didn't make it, politely ask if the company can offer you any feedback on your application. Then, work like crazy for months and re-apply when you feel it is appropriate. It took me many months to get my foot in the door, but if you genuinely want it, you can most likely beat the door down through sheer persistence.

After graduating, I spent about 6 months grinding away trying to get a job. Curiously enough, a little over 18 months later, I've been fortunate enough to be helping out on the other side of the interview table (albiet probably only because I do a fairly uncommon programming job, so I only have one person in my department who is senior to me). It's interesting to see both sides. Unsurprisingly, my advice mirrors Carmack's (even though I am but a peon in comparison). What follows is more programmer related than art, but someone may find some use from it.

Use your time wisely
Remember that when in full time education, you have a shitload of time to burn. I reckon I spent only 10-15% of my waking hours engaged in university work; the rest of my time was free time. I could do whatever I wanted with it. Now, you can spend it playing games, getting drunk, watching daytime TV etc... or you could spend it improving your skills. Remember that, at the end of your college/university period, there will be scores of graduates just like you with the same coursework deliverables and accreditations, so what do you have to offer that distinguishes you?

Learn through doing
Make lots of stuff. It doesn't matter what it is, who it's for or why you're making it; just make it. You learn so much more when actually making stuff compared to theorising about it. Theory is definitely important and it's worth doing a degree etc., but you only cement and further your understanding through doing. In my first year of commercial programming (9 'til 5 every day) versus 6 years of sometime coding (maybe a couple of hours every other day), it felt like I learned just as much again. Code that I had considered to be good a year ago suddenly appeared, in hindsight, to be a pile of steaming shit. And long may it continue.

To further underline why 'doing' is important:


I.e. the more time you spend doing something, the better your chances are of becoming good at it. Practice makes you better. If you want the job badly, then you can improve your chances by always creating new works. You could set yourself a goal of "implement small feature x in my program this week" or "create, unwrap and texture a new mesh this week". I personally got the most out of my learning when I was setting repeated, incremental goals each week.

Finish what you start
Don't worry about perfectionism. It's easy to start thinking that everything you do and show to prospective employees must be perfect. That's not the case. You should endeavour to finish what you started; even a rough, finished version is better than a polished fragment. Companies understand that you are young, raw and will require support, mentoring and encouragement. The code I submitted that helped secure an interview should have by all rights been set on fire, detonated and then buried in a lead-lined mine shaft. It was pretty horribly designed, but it demonstrated that I could finish a project. In my opinion, the most important thing is that you can demonstrate that you get things done. Junior members of staff are not hired as read-made geniuses who slot into the production machine firing on all cylinders. Yes, these people exist, but they are few and far between. As long as you demonstrate that you're a decent person, you have potential and that you will find a way to achieve your goals, you have a chance.

The reason I say this is that, in the modding scene in particular, I encountered way too many people who had portfolios full of half-finished levels, models, texture sets etc. The moment I see this I automatically think "flake". The hardest part is finishing something; pulling things apart and optimising them, then rebuilding them. Reducing the texture memory usage, fixing alignment and clipping issues etc. There is little creative fulfilment involved in this step, there is no artistic merit or craft in fiddling with it and there will be nobody to offer you a compliment on your collision and clip optimisations. It takes guts, pure and simple. Any time I saw scores of "cool looking room in never finished level" or "half an awesome gun model" images on websites, I just closed the page. Do not want. If you can't even finish your own personal work, work that involves a subject matter that is of your own choosing, then why would a company have any faith in you finishing something you may not have a particularly strong affinity for? Chances are you won't be working on Rage or Bioshock 2...

If you can't find a way to finish to a standard you're happy with then limit the scope. Remove functionality from the program, cut out areas of the level or reduce the complexity of a scene. Remember that once you finish the first version, you are now in a good position to iteratively improve it Finish version 1 and go from there. The sense of achievement from finishing something is also a great feeling! It's much better than leaving the work to languish in "C:\work\wip\", never to be viewed again.

Keep up with new technology and techniques
Read a new book. Learn a new language. Read blogs. Write a blog. Write articles. Discuss stuff with like minded folk. I've learned a lot of really interesting and cool ideas from blogs; my google reader has about 50 entries in it, including programming, art, modelling and technology blogs + podcasts. Most only get updated once every week and a lot of them are sporadic or inactive, but you get the odd gem now and then. If you spend a few hours a week reading, it will be a few hours well spent.

MOD MOD MOD
Yeah. I've already talked about this at length before, so I'll spare you the rant again. Mods are basically smaller versions of real companies. You have the same people issues, conflicts of opinion, fun times, hard stretches etc. You can make mistakes in mods and then learn from them. You also make a shitload of contacts if you're a decent guy. Contacts and string pulling can be instrumental in landing an interview, so don't pass on modding. My modding with FF was instrumental in getting an interview; it distinguished me from a lot of my peers by the way of proving that I have the passion to make something in my spare time. I guess different companies view modding in a different light, but it was great for me.

Create a non-generic CV
CVs should be grounded in what you've actually done. Don't smother it in buzzwords or over-egg the pudding. Don't oversell or overcomplicate something you've finished to try and make it look better than it is. Don't pad your CV with terminology and 'skill' bullet points that add nothing. My first attempts at CVs both suffered from these problems -- I was simply spamming phrases, technologies and buzzwords instead of talking about what I'd actually achieved with my most important skills. Bullet point-driven skill-heavy CVs tend to be impersonal and anonymous. There is nothing to distinguish one from another.

E.g. "Fluent grasp of C++, Direct3D, OpenGL, TDD, OpenAL, LINQ" = noise. Compare that to, "In my spare time, I developed a small C++ game featuring ; the rendering was implemented using D3D using features, including to drive a particle system".

I.e. give your skills with plenty of context, not as some detached list of headless bullet points. Luke Halliwell has some really good articles on CVs, so I'll redirect you to his post rather than ape it.

Don't talk a load of balls
This is more for programmers, but when it comes to interviews, less is often more.

Be prepared to have your CV grilled. If you talk a good game on your CV, be prepared to be called out on any and every detail (this is why you should never embellish your CV with skills you don't have...). You should think about your decisions and be able to justify them. E.g. if someone asks you why you used language x for assignment y, you should be able to say why. "Since the application wasn't required to be fast, I used Java as it freed me from having to track memory allocation, meaning I had more time to concentrate on feature development" is better than "because I always use Java". If you cannot justify yourself due to making a poor decision and you learned something from the process, this is the ideal time to talk about it. It's not the ideal time to defensively trot out excuses. Self-awareness and the ability to reflect on projects (successful or otherwise) are very important things.

If an answer should be explainable in 3 sentences, use 3 sentences. Don't keep on talking until your course is gently steered on to the next topic. There's nothing wrong with being nervous, but try not to ramble because it just gives the impression that you're vainly groping for the right phrase. If you don't know the answer or you're unsure as to whether your point was understood, just say so. It's much better to say "does that answer your question?" than to talk for 3 minutes solid, hoping you ticked some box.

Finally, have faith in your own opinions. Don't flip flop based on what you think the interviewer wants to hear. Bosses aren't interested in hearing their own opinion parroted back at them -- they want to hear what you think.

If at first you don't suceed
Try try try again. If you attended an interview but didn't make it, politely ask if the company can offer you any feedback on your application. Then, work like crazy for months and re-apply when you feel it is appropriate. It took me many months to get my foot in the door, but if you genuinely want it, you can most likely beat the door down through sheer persistence.