In my experience, packet loss does not happen too often. When it does, it seems to happen in bursts. Reordering seems to be much more frequent.
However, most important is that it can happen. For a simple game state this is not an issue (simply drop the old state and interpolate), but you really need to be prepared issues with game events (e.g. chat messages, kill events).
Most net-libs (DirectPlay, ENet, RakNet) implement a way to mark packets as 'reliable and ordered', thereby ensuring that packets arrive and are sent to the application in the correct order.
I would say it really depends on what you'd define as 'roll through'. From the few I looked at, I think many candidates would have their answers be marked as incorrect. They're quite full of small gotchas, instead of really testing someone's programming skills.
(But hey, that may just be my disappointment speaking )
That said, I'd be much more interested in why the candidate gave that answer. If a candidate knows what a reference, copy constructor, initialization list, etc. is, but just overlooked some small issue, I'd still would want to hire them.
Example: one of the tests checks if you know what happens if a local functor has the same name as a function and you call f(..). I don't care: anyone who programs something like that will be close to be fired on the spot or at least have a good talking to...
So as a test, I don't think these are particularly good. As a starting point for a technical discussion, they're quite nice.
Well, in short I would deem nothing 'unhackable'. Most people would have considered OpenSSL to be safe, and the Heartbleed-bug showed that in certain cases this was unsafe as well. A cynical answer would therefore be: nothing is unhackable.
The other part of this is that everything that will be decrypted on your user's client side will be accessible to him/her. So, by asking for something unhackable, who is not allowed to have the information? Is it your user that cannot see the information? Or is it just the data as it is in transit?
In the encryption debate, I think it is important to strike a balance between 'unhackability' and 'impact if hacked'. If the consequences of an intercepted message would be that one player would know the location of another, and would be cheating, it would probably be more efficient to implement a good banning system, instead of trying to create a really secure system.
If you have an Android-device (phone or tablet), I found it quite satifying to create my own Android game. Although mobile development may not be the first thing that comes to mind for making an FPS, it does help you learn Java and have something to show for it quite quickly. The Android developer pages (http://developer.android.com/training/index.html) contain loads of good documentation and tutorials.
From there, you have picked up enough programming skills and knowledge to transition to a more FPS-minded environment or even C++/Unity/etc...
You have given us little information to go on. Debugging is a bit like police work: you need to get a lot of clues and from that distill what happened.
As far as I see the runtime error occurs in the DX11 Effects-framework. Since you say 'it just goes there', I'm suspecting your debugger stopped execution there because of a crash, or an exception. Could it be pResource is just NULL? You can check in the debugger (or by checking in the code).
You already deduced that the error only occurs in the last 15 meshes. How many meshes are there (i.e. is at least one mesh actually succesfully loaded?). Can you pinpoint which exact meshes fail to load? Oh also, there's lots of versions of the Sponza model. It may help to know which one you're using.
Please try to dig a little deeper. That way, either you figure it out yourself, or are able to provide us with some information to help you better.
As mark ds says, the geometry shader runs after the vertex shader.
If I understand correctly you want to do some checking before running them through an expensive vertex shader, am I right?
I think you'd have to use a trivial vertex shader, use your geometry shader to check which triangles should be culled, and store the triangles that pass the test in the transform feedback buffer. You can then use that buffer as input to your expensive vertex shader and run the rest of the pipeline.
In a game (or actually a simulation) I worked on, we abused the networking system for this. We made a special kind of 'client' that would not connect through the network, but ran on the server locally. It would store all the game state updates sent to the clients in a file. Periodically, the whole game state (say, your save game) would be stored as well, serving as a kind of keyframe.
Then, at a later time, that file could be used as a replay.
Is it ideal? No.
In a large game, you'd selectively send updates to clients. So if units are not near the player, you'd not (or more sparsely) send updates. Also, it requires you to have networking code in place, which not everybody does, of course.
But for us, it was the quickest way to get things working.
Splendid idea to try and read other people's code. There's so much to learn from that.
First and foremost I'd try to give myself a task, something to go and find out. For example, find out how he handles collisions. This way, you can focus on your task and ignore anything that doesn't seem related. Otherwise, I can imagine you'd be overwhelmed fast.
Next, I tend to pinpoint some classes that seem relevant to me (just from their names, often) and try to sketch their relationship. If you know UML that's cool, but some simple rectangles for the classes and lines for relationships will do.
Now that you have the structure of the code, it may be interesting to compare it to what you would have done. How is this different, can you think up why it was done this way? Maybe yours is actually better?
When reading code, you may well encounter some syntax you never used before. Hopefully that is something you can google, or otherwise ask here. Most often, this is 'syntactic sugar' and can be written in another way. E.g., x += 2 is the same as x = x + 2.
As of your points 3) and 5): the source code of Notch's Mario is quite heavy on the magic numbers. I think that's the most difficult kind of code to read, because you cannot simply google magic numbers, like you can do with unknown syntax. Maybe you'd be off better trying to read some other game's source?
I really don't agree with this trend to call GameStop's business model 'stealing'. I thinks it really says more about the game development-business than of Gamestop.
Because, seriously, how is what they do different than a second hand furniture shop? Do we see carpenters parading the streets how criminal it is that people sell of their furniture, allowing other people to buy them so they won't get new assignments? Are they devising ways to have their chairs break as soon as they are placed into a different home?
Good furniture lasts years. Really good furniture becomes antique and gets passed from generation to generation. Video games that end up at Gamestop apparently have lost their charm after a few days, or maybe even hours of play. That's where your problem is. Development budgets skyrocket, but they yield products that do not generate equally bigger sales/profits. I think it's not fair to blame others for that problem, and especially not implying they're 'criminal' like what's happening now.
So, developers: make products I want to keep. Let me have that game I'll pop back in now and again (and not fail because the DRM-server is down).