Programming Interview Advice

[Anonymous]

Hi guys,

I have an interview next week for a junior programmer position over in England. The interview will last 3 hours, and will consist of a face-to-face with 3 programmers there, a written theory test, and a practical test.

I’m looking for some advice to allow me prepare for it the best I can. Any tips (or hilariously embarassing anecdotes) are welcome. Thanks guys :)

[Anonymous]

Who’re you interviewing with?
I’m assuming this will be for a junior role, yes? I’ve been an interviewer a couple of times now, so here’s my take on it.
Written test will probably mainly test your C++ knowledge and figure out how much maths / physics / graphics / other knowledge you have. People want to know that a) you can code well, b) understand the process of coding a full project and c) understand what to expect with game coding.
I’m guessing the practical test will be a piece of broken code, debug it and make it work…should be easy, but you have to figure out other people’s coding style in the process.
Interview…be yourself, don’t stress too much. Some places will verbally go through your test with you, so you get to fix the mistakes you made in it and explain what you were thinking. Some people can make decisions based on first impressions, so make a good one.

[Anonymous]

I had 3 programming tests for the job I’m now in, had to do one of them remotely which would normally be face-to-face which is similar to what I’m presuming you’ll have.

I got six or seven pieces of code and had to spot errors in the code. Was some buffer overruns, virtual functions definitions missing, invalid macro definitions and invalid pointer returning/input to functions.

Lets just say I didn’t think I had done well. I was encouraged to talk through my thought process (which I’d definitely recommend you to do too) as they wanted to see what my train of thought was like. I think I got one of the questions right, the rest I got there eventually with help from one of the programmers. I ended the testing thinking I messed it all up but was offered the job a couple of days after. So I’d reiterate Omen’s point to not get too stressed and just try and answer each question, forgetting any problems you’ve had in previous questions. You don’t have to get everything 100% right to do well in the test.

My test may have been different to regular Game Dev tests as the BGS don’t really have much 3D stuff so my maths/physics weren’t tested.

[Anonymous]

Tests vary alot from game studio to game studio. Depends on the guys setting up the test, often their interest areas and the area your applying for. If you applying for a networking role, questions about shader tech etc would be lost on ya ;) and really tell them nothing about your ability for networking etc.

Typically, a C++/C test of some broken code and fix it up to work correctly works pretty decent. Then discuss the questions with the candidate afterwards to get an idea of their thought process and maybe drill abit deeper on the code to see where their knowledge ends and bullshiting starts :) Stuff like statics, constness etc.

Best advice for an interview, dont bullshit something you dont know just because you feel you should know it. Best to say i dont know, it portrays a much better image of you to the interviewers.

well my 2 cents anyway

[Anonymous]

Hey,

Just found this http://gamedeveloper.texterity.com/gamedeveloper/2008careerguide/

Theres a good 4 page list of questions and how to answer them – scroll to page 31

Hope it helps.

[Anonymous]

Best advice for an interview, dont bullshit something you dont know just because you feel you should know it. Best to say i dont know, it portrays a much better image of you to the interviewers.
[/quote:2aed7e031f]
Seconded, crucial advice for interview.

People tend to chance their arm in interviews in general when they get a question they didn’t expect – don’t do this in a programming interview; be frank and up front and say you don’t know. By all means clarification on the question (interviewers might deliberately provide you with less information than you need to answer, as a test), or offer to take a shot at the answer, if they want, but be clear that you are just taking a shot.

This is very important, because in a technical interview people will be able to tell when you are winging it – they will know the answer to the question they asked – and no one wants to hire a programmer that pretends they know something they don’t, and gives bad information.

[Anonymous]

Hey Adrian, best of luck with the interview!

[Anonymous]

Hey guys,

Thanks so much for your help, that has given me great food for thought :D
I’ll make sure to post back after and let you know how it goes

[Author]

Posts