It's not unacceptable. But your internet's down today (or alternatively, nobody has solved this problem before). Now what?

Well without cheating and googling it, my first thought would be to have a list of overriding methods for each virtual method which could then be chosen from based on the type of the object that contains the method.

Okay, that's a reasonable start. How do you know the type of the object? If we have a pointer P in our script (which points to some valid object), and we're calling, I dunno, P->DoSomething(), how do we know what type P actually is? And how do we know where in this list to look for DoSomething?

(I hope by now you get the idea I'm going for, so you don't have to keep answering these follow-up questions unless you want me to keep asking them, but you can expect that these of things will be the kind of things you are asked, in an in-person interview. And when you take the test, you can apply the same structure to the question they ask you: if you don't actually know the answer, say that, and start thinking of how you'd solve the problem or try to approach some answer based on what you *do* know. Not everybody will care about giving you "points for trying" on a written test, but it's almost always going to be better than leaving the question blank if you don't know it).

Yea, thanks a lot for that, it was actually quite helpful to get in the right sort of mindset. Apparently the test and the interview is somewhat interlinked, so I'm guessing that I can expect followup questions like these to answers that I might not have gotten completely right.

I had to take a written test a long while back for a company, they basically had me take the written first thing upon arriving, then go to lunch while they 'graded' it. I guess if you do poorly, you get to just leave after lunch =) I did well enough that I was called back in to meet the developers, and then they went over all my answers, both the correct and incorrect ones, to check why I answered them in the way I did. So rote memorization isn't super helpful, though some places I recall written tests with some fairly trivial questions, and if you haven't been actively using a language, it can be nice to do a once over and brush up on it's more unique features, so you can quickly get past the trivial stuff and onto the more difficult and interesting ones. (Though the folks at the company that I interviewed for, it was a C# position and the test was all in C++, go figure)

I'd probably also brush up on your math, if you haven't been actively using it. It's good to have most of the basics of 3d math down cold, because it's a timed test after all. Though you can relax a little here, I don't think anyone cares if you get it done early, they aren't going to rank you on it, but it's nice to be able to get through all the questions.

I hope Petrie's line of questioning shows what a good interviewer will do to pick the interviewee's brain to see if they are capable of thinking about a problem or question. Basically, it's okay and a good idea to go, "I don't know", and then try to offer a reasoned guess about how to solve something.

As others pointed out, cramming for the test part isn't too valuable.

Practicing for the interview questions, however, can be extremely valuable.

You KNOW they will ask a bunch of questions: "Tell me about yourself?" will be among the first question you hear. When they ask, "Why do you want to work for us?" or "Why do you want the job?", you better not reply with a quip about paychecks. "What do you know about the company?", "What are your strengths and weaknesses?", "Tell me about a conflict you faced and how you dealt with it.", "Why are you leaving/Why did you leave your past job?". Google can find you other common questions. Just the practice of answering, having anybody (even a child or neighbor or complete stranger) ask you questions about yourself and your history can be useful practice.

You also know they'll be asking you to solve a bunch of logic problems. It can be fun to have people give you quirky questions that they find online. It can be useful to get into answering questions in an interview-friendly style. Explain as you think, describe your reasoning, and avoid too many references to looking up answers on Google.

And of course, be prepared with an answer to the request, "What are your salary requirements?" Salary negotiation is an enormous topic so read up. I've seen people who took initial low-ball offers, and people who negotiated far beyond what the company owner originally planned on offering. Always at least attempt to negotiate your pay and be prepared with numbers specific to the company you are applying for.

For me it's a simple one; be sure to read and understand the question or problem they ask you to work on. So many times I've seen candidates talk themselves into committing to solutions where the problem is asking something totally different. Being able to analyse a written or verbal set of instructions is a required skill, just like the programming itself. If in doubt, ask the assessor. Don't be afraid to ask for clarification if there's ambiguity or you don't understand what is being asked.

And of course, be prepared with an answer to the request, "What are your salary requirements?" Salary negotiation is an enormous topic so read up. I've seen people who took initial low-ball offers, and people who negotiated far beyond what the company owner originally planned on offering. Always at least attempt to negotiate your pay and be prepared with numbers specific to the company you are applying for.

The other things I think I've got somewhat of a handle on, but this bit kinda stumps me. As this branch of Ubisoft is in bulgaria, I have literally no idea what sort of salary is common there. This question was actually part of the application form and I believe I simply put "An entry level salary" or something similar. I tried looking for figures for bulgarian game devs, but as you might imagine, there is not a whole lot of information out there.

Yeah, that's a tough one, I think the main thing for a junior programmer/starting position, is to ensure they pay you a livable wage. Look at the taxes, cost of living (rent, food, etc), and try to make sure that you have enough to live and get some savings on. I had a friend take a job that was in another state from where he lived, and he vastly underestimated the expenses involved, and also took a pretty terrible salary. He had no money for a refrigerator and was eating basically just peanut butter and jelly sandwiches for a few months until he could save up enough to rent one.

Even at the entry level most game programmers can demand far more than "a livable wage".

Game programming often pays less than other programming fields, but that "less than other programmers" is generally professional-level pay and significantly more than regional average wages. Everywhere I've looked the entry level game programmers earn at least double the regional average pay. When I graduated decades ago my entry level pay was roughly on par with my father's pay as a 30-year-tenured CPA, and slightly more than double the state's published average wages.

Hi I worked in game development for about 15 years. I know things have changed since I switched to another, better paid industry but one thing I can tell you is, nobody in the game development will ignore you just because you don't know what a vtable is, or a pointer to member, or C++ 11 last news or whatever. If you're a programmer, you will learn any of this in a few days/weeks and you'll be on your way for the real part of the job which is, as somebody else pointed out, problem solving.

I did some interviews in the past for recruiting programmers, I was never, ever asking them for technical details but rather trying to guess their potential, their wish and ability to learn, their intuition facing a problem. Did they program stuff at home after school? What quantity of environments, libraries, languages did they get an interest into by themselves?

Technical details and syncrasies, nearly anybody can learn them. The really important point for the interviewer is to get a feeling of your problem solving style, how do you use your brain.

Be yourself, nothing else. This is the guy the interviewer wants to hire.

As of the salary, well, honnestly you will probably be offered less than you hope, like everybody! Don't bother asking for too much, just tell what you "hope" and the interviewer will tell you how near from it is possible. You should know that most of the time, the possible salary is decided before interviewing candidates because it fits in a budget plan.

As far as I know, nobody will reject you just because you ask a little too much, they will just tell you it's a little too much, and consider your applying anyway.