Applying for Programming Jobs

[Chrisb3]

Thank you very much
I have something like this for openGL which is what I've been concentrating on really because my degree was more focused on games.
Anyway this is just what I was looking for!

+Internets have been handed out thanks guys.

[Fog]

Read TAOCP -- no, really, read it, and do the exercises, too. I assume you enjoy programming if you're interviewing for programming jobs. If you do enjoy programming, it should be tremendously rewarding for you, as well as do a great job sharpening (re-sharpening?) your logical mind.

(I apologize for proselytizing you if you have worked through it -- I usually try to give people the benefit of doubt on being well-read, but too many of my CS friends have never bothered. It seems like for a lot of people it's kind of a programmer's Ulysses.)

For lighter CS reading, I recommend Jon Bentley's Programming Pearls (more.) Besides having a lot of fascinating puzzles, anecdotes, and pieces of code, it contains a lot of interesting insight into some pretty general programming and software issues like profiling and debugging. This book, Beautiful Code, is a similar one to Programming Pearls that was highly recommended to me by a friend, but I haven't gotten around to it yet - it's much thicker!

(This is getting a little off-topic, so I'll leave it at that.)

[Zehn - Vhex]

Also, be prepared to be their bitch if you work for a gaming company.

[Tripamang]

Question for people in the industry, I basically got handed my current job after a stint as a code reviewer/documenter (so boring, you have no idea). Do a lot of companies ask stupid niche/trick questions during interviews?

I've sat through a few interviews post hiring for me, we're pretty good about just testing someone to make sure they're actually capable of writing code and developing ideas into actual programs. I'm kind of curious as to what the average company expects from someone they hire, my situation was a rather large exception I'd say.

[Zehn - Vhex]

Originally Posted by Tripamang

Question for people in the industry, I basically got handed my current job after a stint as a code reviewer/documenter (so boring, you have no idea). Do a lot of companies ask stupid niche/trick questions during interviews?

I've sat through a few interviews post hiring for me, we're pretty good about just testing someone to make sure they're actually capable of writing code and developing ideas into actual programs. I'm kind of curious as to what the average company expects from someone they hire, my situation was a rather large exception I'd say.

Most are willing to sit back and let you give out a good spiel about yourself. You should honestly go in with the intention of selling yourself. Not answering inane questions about what flavor of car you'd want to be if you had been born in India.

I've applied for several (non-gaming related) tech positions and it's usually more or less the same 4 things over and over again in a variety of ways.

1) Tell us about yourself
2) What have you done in the past
3) What will you bring to the company
4) What do you want

Honestly the only time I've been asked the off-the-wall questions were from inexperienced interviewers.

[Tenks]

I'll try and give out some advice.

Pre-face: I just graduated (last week!) from college. 5yr degree in Information Technology / Software Devlopment & Database administration. I was an intern at an insurance company for 4 years duing school working as a console-based Java programmer.

I recently started my new job (though I interviewed & was offered months ago) to be a Groovy programmer.

Firstly since this was entry level they seemed to have very low-bar expectations. I know OOD Patterns are now becoming a relative buzz-word anymore these days but they seemed blown away that I had a code portfolio (~3000 lines spread across 4 projects [2 Java 2 C#]) and furthermore that I had various Strategy, Facade and Factory classes sprinkled throughout. They seemed to have no desire to hire an hack n' slash programmer who would write unmanageable code. So you need to sell the fact that you're a manageable programmer. Not just someone who can write it and it "works" but someone who can write it and it is "elegant."

Next, honestly, I'd study up on industry buzz words. Find out what the hot topics are these days in game design. I know for corporate jobs it is in fact OOD pattern implementation and various Web 2.0 skills (AJAX, Hibernate, Rails.) Maybe it is not the same for game programmers. However, every single game company demands a love for gaming. No, this does not mean you tell them "I sat in my mom's basement for 8hrs a day playing games!" it means that you took the initiative to learn about game design, to learn about proper 3D engine programming and show you have a passion to design games. Not just play them.

I'm starting to get long winded but I'll leave with a few more words. Firstly, I know people who have been game designers. They are the elite level programmers. If you want logic problems and challenges it is certainly a field to investigate. Do no think it is all glam. These guys put in 16 hour shifts when need be. A 10 hour day is a 'light' day for them. It is not for the feint. This is why they demand passion for the industry. If you just want to look at them because you think it will be "cool" to be a game designer they don't want you.

Furthermore if you can't name off at least 10 GoF patterns off the top of your head then you may not be ready for an elite level programmer position yet. It is easy to write hack n' slash code but it takes forward thinking to write manageable code.


-edit-

And Zehn is right about the questions. You can find out these little nook and cranny questions on the google machine but you can't easily google how to transform your code into being readable or solve business logic problems.

[Vehn]

why don't you just join a modification team for a game (like a half life 2 or Crysis mod) and write code for them in your spare time? It adds to your portfolio, and will especially be good if the mod is succesful and they see what you've contributed to it. Could be the foot in the door for many companies

[Vinen]

Originally Posted by Tripamang

Question for people in the industry, I basically got handed my current job after a stint as a code reviewer/documenter (so boring, you have no idea). Do a lot of companies ask stupid niche/trick questions during interviews?

I've sat through a few interviews post hiring for me, we're pretty good about just testing someone to make sure they're actually capable of writing code and developing ideas into actual programs. I'm kind of curious as to what the average company expects from someone they hire, my situation was a rather large exception I'd say.

Honestly, I think the qualifications required to enter the gaming industry as a developer are far higher then those of other industries.

I just got hired by a Defense Contractor as a Software Engineer and the questions I got asked surprised me... not in their difficulty... but in how damn easy they were.

[x1hundredregrets]

Originally Posted by Vinen

Honestly, I think the qualifications required to enter the gaming industry as a developer are far higher then those of other industries.

I just got hired by a Defense Contractor as a Software Engineer and the questions I got asked surprised me... not in their difficulty... but in how damn easy they were.

I think its not so much the requirements to get into the gaming industry, its the raw skill required. You have to be a damn good programmer to make cutting edge games. Whereas if you're dicking around making office software, you probably are not attempting to squeeze every extra CPU cycle you can out of the code.

[Tenks]

Originally Posted by x1hundredregrets

I think its not so much the requirements to get into the gaming industry, its the raw skill required. You have to be a damn good programmer to make cutting edge games. Whereas if you're dicking around making office software, you probably are not attempting to squeeze every extra CPU cycle you can out of the code.

This is exactly true. No one in any job I've had cared about how efficient the code was. They simply cared that it: #1) worked #2) maintainable. I wrote a very elegant solution to a problem using multiple threading and wide spread use of patterns and was asked to re-write it "easier to understand." The code was good as hell and I hated every second of rewriting it but thats the politics you have to put up with in companies I suppose.

As I said above. Game programmers are the elite. Mostly anyone can write corporate software as long as you have a grasp on logic controllers (which you should have after 1 programming course~).

[Tripamang]

Originally Posted by x1hundredregrets

I think its not so much the requirements to get into the gaming industry, its the raw skill required. You have to be a damn good programmer to make cutting edge games. Whereas if you're dicking around making office software, you probably are not attempting to squeeze every extra CPU cycle you can out of the code.

I think you'd be surprised how many businesses are performance obessed. Oracle for example, puts a massive internal emphasis on performance because their success is performance dependent. The company I work for dedicates a great deal of resources to improving the performance of our software. Though threading etc are less emphasized (we work in a web based ISAPI environment with an oracle backend it comes pre-threaded). We need to always be more efficient because the responsiveness of our app is so crucial to productivity in our market.

I think you'd be surprised how much work does go into making efficient business code, but on that same note a lot of business programming lacks this necessity which breeds lazy programmers.

I feel for Tenks though I consistently bring up issues during our design meetings about how important scalability and how modifiable our implementations need to be. I get shot down quite frequently due to what people feel is my over complication of implementations. In the end we end up wasting time on future builds adding features I wanted to add from the get go all because the simplest and easiest to implement is what we went with.

[Tenks]

Well if you're referring to Oracle then you're talking about your DBA's doing query performance. Naturally you are going to want to quickest possible query as this is a much larger bottleneck than CPU cycles.

Personally, I've found that most programmers just are not good. I've had my fair share of 'A ha!' moments that involve programming. First it was 'A ha!' logic! Then 'A Ha!' classes! Then 'A Ha!' interfaces! Then 'A Ha!' MVC/Subscriber-Publisher! Then 'A Ha!' Threading! Then 'A Ha!' OOD patterns! They just need to come in time. Generally via practice and self-study I've found work for me personally. It seems like a lot of programmers (both academic and professional) kind of learn about classes and call OOD a day. There is so much more to it than learning about class coupling and cohesion. Personally, I think it is because very few students of CS/IT have a real passion for technology. They see a comfortable, stable, lasting and profitable profession and choose it. Very few programmers I meet seem to have the job because they have a passion for problem solving and programming in general.

I'm not saying its a terrible thing people do that anyways. The world needs software developers, elite or otherwise. I do not classify myself as an elite level programmer. Just a better-than-average programmer. I have no knowledge of advanced physics, AI or 3d programming. Then again, I have no interest in being a game engine programmer. Though a job programming AI interests the hell out of me. I digress.

What really irritates me, however, is it feels sometimes I must "talk down" to fellow co-workers. Further irritates me if I bring up some suggestions that get shot down very quickly. Being a Groovy programmer I try to make my stuff very Groovy. There are still people in the team trying to transition from Java POJO/J2EE to Groovy and a lot of code is written that is very un-Groovy. When I suggest a change, I get a lot of "It is easier to read this way" talk. I'm just fairly convinced it is people who don't fully understand the language and its power.

Regardless, back somewhat to the OP and less ranting about standard-issue software developers. Show you have the passion for technology. If you got into programming because you looked up the salary and saw it was consistantly a top-10 job on all charts then you are not cut out for a game programmer. Try to convey to these interviewers you are in programming for passion, not pay.

[Kallian]

Originally Posted by Tenks

This is exactly true. No one in any job I've had cared about how efficient the code was. They simply cared that it: #1) worked #2) maintainable. I wrote a very elegant solution to a problem using multiple threading and wide spread use of patterns and was asked to re-write it "easier to understand." The code was good as hell and I hated every second of rewriting it but thats the politics you have to put up with in companies I suppose.

As I said above. Game programmers are the elite. Mostly anyone can write corporate software as long as you have a grasp on logic controllers (which you should have after 1 programming course~).

Funny about the re-write, although I'm curious as to why they would be opposed to you teaching them about your solution. Have to move on at some point.

I imagine game programmers are good, but as to whether or not anyone with 1 programming course can write corporate software... false. Lots of folks out there (with development jobs) do not "get it."

[Maleficence]

Originally Posted by Kallian

Funny about the re-write, although I'm curious as to why they would be opposed to you teaching them about your solution. Have to move on at some point.

I've run into this scenario as well while working on corporate apps.

The gist of it is that maintenance of an application is one of the more important factors, and the longevity of applications tends to exceed the average stay of programmers in a given company. Hence, it is a reality that new guys will be working with old code. If the code is not easy to understand then the new guys might introduce bugs or waste time trying to understand the elegant solution. And for most companies, time lost and errors in a process are bigger risks than wasting cycles on a processor.

As a manager which sounds more appealing? A billing system that's less prone to errors and is easily fixed or one that runs more efficiently on a given piece of hardware? For most successful companies, buying better hardware is a non-issue, but having some bug in billing could spell a PR/CS disaster and affect the company's bottom line.

Of course, this is all based on the assumption that "simpler code" leads to less bugs. Which can be debatable.

[Fog]

It's meaningless to say that "corporate software" or "business software" doesn't need performance, or that it's easy to write. What are you talking about? The label of "corporate software" covers half the software that has ever been written. It covers applications with ten thousand lines of code and ten million. It covers applications running on top-of-the-line PCs and tiny, slow embedded devices. It covers desktop applications and web applications, written in every language ever conceived. There is no generalization you can make about it.

Addendum: On the quality of programmers - I just graduated from a big state university undergrad CS program, and watched the sort of people who got bachelor's degrees along with me. A fair amount of them definitely "got it." I've been programming since I was very young and have a lot of experience and theory under my belt, and I met folks who were as good as me or better and a real pleasure to work with.

However, I'd say that a solid minority of 30% or 40% didn't, at all. Mostly they were the sort of people who did just a little bit of recreational programming when they were teenagers, writing stuff on their calculators or making webpages, and they enjoyed it. Although they kept enjoying it, at some point they stopped understanding it!

One of the first big roadblocks for a lot of people was pointers and references (most of our courses were in C and C++.) That made it really difficult for them to do Win32 programming, as you can imagine. Another was non-trivial recursion. A later really big one was lambda calculus and functional programming. (Maybe a Scheme course would have made things easier for people?)

On topics like this, these sort of folks would have absolutely no understanding, and just try to skate by that part of the class, except it didn't work so well, because these sort of things build on each other. The result was rarely catastrophic for them, though. Usually they would work really really really hard with someone who "got it," finally get their projects running and get a C for the semester but still not understand what the hell was going on. I never discovered why some abstract topics which objectively aren't that complicated seemed like insurmountable roadblocks for people in this way.

So these guys graduated, but without a fair amount of what I would consider fundamental concepts of stuff like memory management and algorithms. (They're going all over the place, now; I have a few friends in those shoes specifically interested in pursuing game development, for what that's worth.) The majority of them also only know C++, and maybe Java. Now, here's the million-dollar-question: Does it matter?

I don't know if it makes any difference to understand these things, because I'm just now starting my own career as a programmer. After all, if you're using Java or C#, a lot of the things that were "roadblocks" for people are abstracted away from you, and I do agree that there is lots of simple software to be written that doesn't require difficult algorithms, strange data structures, or lambda expressions.

However, I can say without reservation that a bachelor's degree doesn't mean you're a good programmer, and I guarantee there are courses much worse than mine in this regard -- I gather that some schools teach completely with Java now, which seems like a complete recipe for disaster.