The two questions I ask every interviewer
The best interview I had (for a lead games programmer position) was a written test, I can&#x27;t remember the exact details but perhaps 24 pages and 45 minutes to complete it. Before starting I flicked through the entire test to get a feel for what was being asked of me, and then for a little while debated just getting up and leaving the room. It felt a bit crazy, a test on all sorts of disciplines of games programming that I wasn&#x27;t an expert in, and I didn&#x27;t intend to become an expert in (and the job I was applying for didn&#x27;t require me to be an expert in). But I calmed down, tackled the test in the best way I could, answered the questions in an order where my most confident answers (and quick to complete) answers were done first, then moving onto ones I had a pretty good idea of, then ones I knew less well, etc.<p>40 minutes in, the CEO of the company came in, it is a ~300 man company, so it was interested in itself that he came in. Anyway, he wanted to go through the test, I said I hadn&#x27;t finished yet, and had made a note of the start time, and still had 5 minutes remaining. He said it doesn&#x27;t matter, lets have a look. And he flicked through the test and didn&#x27;t look at my answers and instead found a section of the test which I had completely ignored (it was to do with AI and path finding, both topics I have done almost nothing on during my entire education and career). Of course, this was the question he wanted me to answer, I explained the reasons I hadn&#x27;t answered it, and said if they wanted me to do things like this it really wouldn&#x27;t be a suitable job for me. But he persisted, stop worrying about all of these things, just answer the question now. Again I had that slight feeling of wanting to just leave, but again I overcame in.<p>I started talking him through the things I did know about the question, pointing out areas which could cause problems, then started listing what I could do to limit the question to avoid some of these issues (it had a picture of a top down level, the question was inside a box, I said lets initially forget about the box for example). Then I started just talking about an initial algorithm which could route AI around the level - I said it would obviously be really bad (basically AI just walking into things, then working out where to go next, and then a bit later saying oh I could keep track of where I have been in case I end up at the same point, etc.) we talked more about it, he asked some questions, and bit by bit I came up with a solution.<p>He said that&#x27;s interesting, because during this process you have described parts of various algorithms which someone who has studied AI would know about, but you are going from a brute force perspective, not having any way points in the level, no extra level knowledge. I said I didn&#x27;t realize I was allowed to do that, if I could do that, I could potentially come up with some nodes in the level, and rather than bumping into objects, go between nodes, work out the distance between nodes, build up a graph so you know the best way to get between points. Again he was happy, I was describing, or partially describing an actual solution. His next question was but how would I work out where to put the way point nodes, and again I just starting looking at the image, thinking about good positions for the way points, looking at the normals from each wall face, and started to see that putting way points as far away as possible from all normals had some advantages, and bit by bit came up with some sort of solution about how to do this.<p>By the end of it, there was a solution which involved preprocessing the level data offline, when the game runs using this data to move around the level, being able to handle paths becoming blocked (or new paths being opened), strategies for running this on a separate thread or CPU, asynchronous to the main game. It was demonstrating knowledge of the full pipeline for making a game from artist making levels to game running at 60Hz on a PC&#x2F;console, and also taking into account human resource, i.e. we could do things this way, which would give us a slight edge, but it would make the designers life a lot harder, so I&#x27;d probably not do that, take the performance hit, which is small and can probably be won back by the level designerse having extra time to optimize anyway.<p>I was offered the job, ultimately I had a better offer elsewhere so I didn&#x27;t take it, but for me the test made a lot of sense. My day to day job (Tech Director of a 12 man games development studio) is constantly having to solve problems which initially do not appear to have an answer. The ability to break down an issue, not panic, look from various different perspectives, build up a solution, have a good feeling for what parts of the solution are weak and need further research etc. to me makes a huge difference between an &#x27;ok&#x27; programmer&#x2F;developer and an exceptional one. I haven&#x27;t used the same test approach, but have certainly learned a lot from it when hiring people, never trying to trick interviewees, quite the opposite, trying to give them as many options as possible, and just urging them show me how they would be able to deal with day to day issues and come out on top. I certainly worry that whilst I got through, some people really would have just walked out, and in some cases you could argue those people wouldn&#x27;t work well when faced with tough problems and lots of pressure, but on the other hand, but outside of the testing environment they&#x27;d be fine. Anyway, I personally wouldn&#x27;t want to create quite as much stress&#x2F;pressure if I were to use these technique in future.