Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Dave Weinstein

Member Since 08 Mar 2006
Offline Last Active Mar 01 2015 11:28 PM

#5213584 Epic List of Interview Questions

Posted by Dave Weinstein on 28 February 2015 - 10:44 PM

I tend to like more open questions. One of my favorites is "Write an Elevator".




#5212722 Getting Destroyed in Programmer Screeners

Posted by Dave Weinstein on 24 February 2015 - 10:41 AM

The reason you don't advance to the next round can have nothing to do with how you answered the question.

 

The Game Industry has a talent oversupply, especially at entry level. This is further exacerbated by the instability of the industry; at any given point in time layoffs are putting experienced developers back into the labor pool.

 

So you could literally be the perfect entry level candidate, cream of the applicant pool, but if two days before they decide who to bring in for in-person interviews they get applications from experienced devs, you are going to fall out of the list.




#5212048 Getting Destroyed in Programmer Screeners

Posted by Dave Weinstein on 20 February 2015 - 09:58 PM

Not one of them will improve my ability to "create a queue structure that has manual alloc and dealloc methods that do not use heap, but instead, a provided 2048 char/byte array as storage" I couldn't even force a scenario like that if I wanted to into an indie game. Why would I?

 

So, that sounds very much like they are looking to see how comfortable you are with actually implementing and understanding data structures, rather than just using libraries. Yes, you probably won't be writing your own systems (and arguably, most of the time, you shouldn't be), but making sure you know how to as an open-book question seems reasonable to me.

 



#5211111 how to know most hack possiblities and find best way to handle them

Posted by Dave Weinstein on 16 February 2015 - 10:06 PM

Encryption of network traffic has really only one purpose -- to prevent a third party from seeing the contents of the message traffic. 

 

That's it.

 

It doesn't even prevent a third party from tampering with the data (that would be message authentication), it just is supposed to prevent them from reading it.

 

Someone cheating is not a third party, they are a hostile endpoint, and that's another problem completely.




#5210602 I this going to be ok as a Network message class

Posted by Dave Weinstein on 13 February 2015 - 11:39 PM

If you were going to make a custom packet in binary. you need to add a packet header in case data is corrupted, or hacked.

Usually the header includes

1. Message ID

2. Message type or class

3. Checksum

4. Actual data size

 

The checksum is likely wasted data. It isn't necessary assuming that your transport layer is TCP or UDP, since those are already doing those checks. And a checksum is useless against an actual attacker.




#5206340 Game college: Cheaper school or better school?

Posted by Dave Weinstein on 23 January 2015 - 11:29 PM

Avoid debt if you can possibly help it.

 

College debt cannot be discharged in bankruptcy -- if you were disabled they would garnish your social security to pay back your college loans.

 

Debt denies opportunities. You have payments that must be made, and that limits your ability to pursue lower paying options with long term payout, or to get access to credit that you might need for future purposes.




#5197992 best way to send an receive multivarible data by socket

Posted by Dave Weinstein on 13 December 2014 - 09:45 AM

Is there a reason you want to use text for transmission?




#5195314 IOCP critical section design problem

Posted by Dave Weinstein on 28 November 2014 - 11:03 PM

Threading is one of the hardest things to do well in programming. Period.

 

Locks are both prone to hard but complex failures (deadlocks) on the one hand, and extreme performance hits on the other (limited number of locks to prevent deadlocks).

 

I'm personally fond of option 3 (above) in the case of network code, for a couple of reasons. First, you are spending as little time in the lock as possible, so you might be able to get away with a single "I am about to create a message" lock. Second, you have a single inter-thread communications system. The first one makes it less likely you will have programmer error, and the second gives you a single high-risk component to test the everliving-hell out of.




#5165165 I've got problems with interviews

Posted by Dave Weinstein on 06 July 2014 - 07:45 PM

I cannot imagine ever hiring for a programmer position without having the candidate white board one or more programming problems.

 

I say this, because I've been the "technical interview" for people being hired in as programmers who really were not at all qualified. The resume looked great, they absolutely nailed the "let's talk about process, and how we work together" process interviews, as well as the "let's talk about programming without actually doing any" interviews. And then I asked them to whiteboard, and they absolutely cratered.

 

One of the questions I used to use when looking at candidates who listed on their resume a proficiency with C/C++ was a simple opener. 

 

Please implement this function:

/* Implement a simplified version of integer to ascii, supporting only base 10, and assuming a 32 bit value on a 2s-Complement architecture */
char * itoa(Int32 value)
{
}

This is not a hard question per se (as with most of my interview questions, I stole it from questions I was asked in an interview). There are a couple of ways to approach it, and while there is a corner case, I don't hold missing it against the candidate. Getting it on the other hand is a bonus. Mostly, I want to see you approach the problem.

 

And yet, one candidate confidently wrote this:

char *itoa(Int32 value)
{
   return (char *) value;
}
 

Not only did he confidently write it, it took a fair bit to convince him he was wrong. Even with a lot of prompting, what was supposed to be the first 15 minutes of the interview took the whole hour, and he never did get the problem solved.

 

And that is why I'll always want anyone being hired for a development role to actually write code as part of the interview. Because I've *seen* people with the right resume say all the right things, and flunk the ability to actually write anything. I no longer assume "basic coding competence".

 

[As a side note, having been on both sides of whiteboarding questions, it is *always* easier to spot the bug while you are sitting there watching them write. That's why the interviewer always seems to have a laser focus on the bug when you haven't seen it. As a candidate, as soon as you finish writing it down (and you should talk about what you are doing and why as you go), say something to the effect of "Now to step through this and look for bugs", and out loud start debugging what you wrote with example cases.] 




#5089058 Data compression/optimization strategies

Posted by Dave Weinstein on 25 August 2013 - 09:40 PM

The most compact data is the data that you do not send.

Work very hard on not sending data.

 

This, this, a thousand times this.

 

The art of multiplayer game development is knowing what not to send, and how often to not send it. That is where the craftsmanship comes in.

 

Connecting machines together with well defined APIs is not a difficult task. Basic housekeeping tasks like matching up network ports and game identity are not hard things to master.

 

There are two arts to master. One is how to hide or design around latency (since if you have a work-around for the speed of light, you have bigger fish to fry). The other is how to maximize the efficient use of bandwidth. The former is fundamentally a design issue (although technological mistakes can make it worse). The latter is fundamentally an engineering issue (although design mistakes can make it worse).

 

If you aren't making sure your networking and game architecture makes it easy for the network developers to easily route traffic such that nothing unnecessary hits the wire, all of your bit packing efforts are fundamentally just optimizing a bubble sort.




#5083411 Game server DoS / DDoS mitigation strategies?

Posted by Dave Weinstein on 05 August 2013 - 08:28 PM

 


 I've dug deep into cryptography to design a protocol which I feel fairly confident in. Mostly because it's basically an implementation combining two well known protocols. Still, I know it's a risk.

 

No.

 

Don't do this.

 

Seriously, this is a bad idea.

 

Either use a well known cryptographic solution, which has been subject to peer review, or, if you are a cryptographer, and you see a need for a new approach, publish a paper on it, and if the paper holds up after a few years, then use it.

 

But rolling your own cryptography almost inevitably leads to a much much worse outcome than using something that has actually been subject to peer review.




#5075159 More of a security type question.

Posted by Dave Weinstein on 03 July 2013 - 07:34 PM

That's a really really bad idea.

 

If you want to download executables off the network for updating, you're going to need to strongly sign them, and then have the installer (and auto-updater) verify the signature of the executable on download.

 

Copying it off of a random network share is just unwise.




#5074060 Unity Network.Destoy problem.

Posted by Dave Weinstein on 29 June 2013 - 10:16 PM

So I guess Unitys built in networking is completely useless for any serious project? Guess I'll have to switch to Lidgren.

 

Every networking scheme has exactly the same vulnerability.

 

If the Client isn't supposed to be able to destroy an object, you need to block that functionality at the Server.




#5073388 Client/server movement when to update?

Posted by Dave Weinstein on 27 June 2013 - 04:54 PM

Send MoveStart and MoveStop the frame they happen. Limit MoveUpdate to a 10hz frequency. Combine all movement updates sent in a given frame into one packet.

 

That should give you decent baseline performance, and you can tune from there.




#5068261 Scalability issues (UDP)

Posted by Dave Weinstein on 08 June 2013 - 11:43 AM

The art of the network engineer is knowing what not to send, and how often to not send it.

 

So, first, look for everything that can be inferred by another piece of information. If a specific gun firing always generates the same sound, and you know what gun the actor has, then you don't send both a FireGun message and a PlaySound message, the one is inferred from the other.

 

Next, measure. What packets are you sending the most often. Optimize these down to as compact a form as you can.

 

Next, throttle. If you send a change of direction packet for the player every time their vector changes slightly then human mouse interactions are going to generate a lot of unneeded traffic. So for an FPS, you want to send an updated movement packet (here is my facing, position, speed) at a throttled rate, with exceptions for things like starting and stopping which will be really obvious if held.

 

Then, affinity filtering. Send information based on what they need to know. In the original Rainbow Six, every actor in the game had its position updated in the game over a reliable channel to all players on a 1 hz strobe. However, if another actor was in the same room, in an adjacent room, or there was a line of sight relationship (these were cached by the engine anyway), you would get unreliable updates (throttled as above) for them as movement changed.






PARTNERS