Jump to content

  • Log In with Google      Sign In   
  • Create Account

Programming Assignment - what's important?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 dominik81   Members   -  Reputation: 120

Like
0Likes
Like

Posted 23 November 2012 - 02:57 PM

Hello there!

Short version:
What in particular is a company looking for when they send out programming assignments. What should I optimize my code for? Readability? Code style? Efficiency?

Long version:
After a long history of private and open source game projects and with a M.Sc. in CS in the bag, I am currently trying to break into the industry.

Some companies hand out programming assignments to be solved by the applicant. I recently had one of those and my application was turned down without further information. I even followed up with another email asking for feedback, which they ignored.

This time I'm awaiting a programming assignment from another company. It's a highly reputable studio, one where I really, really wanna work. Had a phone interview conference with three of their senior programmers which went extremly well. But next up is a one day programming task. And I'm really uneasy about it. What do you think I should focus on? Finding an optimal solution? Or writing pretty and readable code? Anthing else?

Thanks for any input!

Sponsor:

#2 frob   Moderators   -  Reputation: 22710

Like
1Likes
Like

Posted 23 November 2012 - 07:27 PM

First, breaking in is hard. You are non in a vacuum. It is entirely possible that you did everything right and they still chose not to hire you.

I would just do a normal code review: Does it work? If it doesn't work then nothing else matters. Next, what kind of problems are there with the code? Does it potentially follow null pointers? Does it potentially divide by zero? Does it potentially break numeric limits? Did you use magic numbers or named constants? Is everything initialized to sane values? Are any resources leaked? Etc., etc.

If you have to focus on anything, that one thing should be maintainability. Can someone else come in and tinker with the code safely? The answer should be yes.

Don't let the first interview get you down. You will probably need to interview at multiple companies before you eventually land the job. That is normal.

Good luck on the job hunt.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#3 dominik81   Members   -  Reputation: 120

Like
0Likes
Like

Posted 26 November 2012 - 03:58 PM

Thanks for your advice! I mean, most of it is common (programmer's) sense, but under pressure it could be easily neglected...

#4 Ravyne   GDNet+   -  Reputation: 8102

Like
0Likes
Like

Posted 26 November 2012 - 06:04 PM

The very first thing you should focus on is making sure you understand the requirements -- it's all too easy, under pressure, to either miss a key detail, or fill in details left unclear based on our own experience. Read the requirements clearly and ask if anything is unclear to you (explaining what you understand, and asking specific questions based on that). The requirements may be functional, engineering (solution structure), algorithmic (time and space), or otherwise.

How you approach the solution is largely based on your own style -- but you want to think about simplicity, maintainability, extensibility, and performance, to name a few.
Its acceptable to prototype and throw away code too, providing you can do it and complete the assignment in the allotted time. As Frob said, maintainability is probably the one key thing if there were only one; alas, its always a balance, so a solution that achieves great maintainability at great cost to simplicity or performance is probably not the solution they are looking for. In the end, their judgement is going to be subjective, so don't get so caught up on any one aspect that it begins to cost you time.

And don't forget to reserve time to test your solution.

If you should find yourself with extra time, go back and make sure you've commented correctly and thoroughly, and perhaps provide some light documentation -- outline the approach, discuss your design options and decisions, talk about performance and storage requirements. Even if they don't ask for this last step, it will be valuable as an orientation for reviewers and demonstrate how you communicate technically, so do it anyways, time permitted. Keep it brief, but no briefer than need be. If you can give the impression that you can communicate technical information in impromptu meetings around the water-cooler, its a very desirable quality.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS