A company I contacted for a game programming position is asking me for code samples, in order to see my "coding style and efficiency". What should I send them? Should it be a big 5,000-line project, or would a nice pretty 200-line function suffice? Do they need a complete working program, or can I just send them a couple classes and/or files?

If I was asked to do something like this, I would quite possibly send them this.

Wow, that's some clean code!

Is it very important for the code to be so polished and well-documented?

Generally, I'm the type of programmer that just gets things done, even if I have to use an occasional goto. I suppose that's not what they want to see, is it?

Quote: Original post by Halma
Is it very important for the code to be so polished and well-documented?

It's pretty much the least they can expect...

Quote: Generally, I'm the type of programmer that just gets things done, even if I have to use an occasional goto. I suppose that's not what they want to see, is it?

This is exactly the kind of programmer who you don't want on your team. Team programming requires the ability to write code which can be understood by your teammates even if you have to spend more time writing it.

I see what you mean. But I could be a "horrible goto-using programmer", but still manage to clean up and polish one of my messy codes. So what's the big deal?

By the way, is it a good idea to send them something that isn't open source? Couldn't the company steal my code?

Quote: But I could be a "horrible goto-using programmer", but still manage to clean up and polish one of my messy codes.

In my experience, if ya do something just to get it to work, and not write cleanly... it'll be a snowball's chance in hell to go back and clean it up.

Also poorly written code builds up and makes it harder on yourself, since you have to go back and modify it later to make it do different things or fix bugs. Once you go back to fix a bug or add something to it, it'll be so hard to work on because of all of the hacks.

Trust me, if ya do it write it nicely the first time you save yourself a whole heck of a lot of trouble.

P.S dont use goto.

It's not so bad. Say I have 2 goto's in my code. At worst, I can just rewrite the 2 offending functions.

Besides, I'm not saying that it's good programming practice to write goto's and have to fix them later. What I'm saying is, if the company sees your code and it looks clean, how can they know that you're not a sloppy programmer that just managed to clean up one project?

They won't know that you're not a sloppy programmer who cleaned up one project, but it's all they've got to go on.

And I would send them a kitten. Everyone loves kittens.

For everyone's enjoyment...

I always ask what they're looking for, exactly. If they want to see one method/class you can go through and polish it a bit. If they want to see a whole project just pick something you wrote recently.

Quote: Original post by Halma
Besides, I'm not saying that it's good programming practice to write goto's and have to fix them later. What I'm saying is, if the company sees your code and it looks clean, how can they know that you're not a sloppy programmer that just managed to clean up one project?

Because they're likely to also give you a programming exam. They'll compare the submitted code to the exam code in terms of style, and they WILL notice discrepancies. Habits are a lot harder to hide than you may think.

Oh, and for everyone's sake, become a better programmer. This "hack it through" mentality is something you should adopt in worst-case scenarios, not as a matter of standard practice.