Jump to content

  • Log In with Google      Sign In   
  • Create Account


Dave Weinstein

Member Since 08 Mar 2006
Offline Last Active Yesterday, 07:49 AM

Posts I've Made

In Topic: I've got problems with interviews

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.] 


In Topic: identifying UDP sockets, using winsock

30 November 2013 - 11:45 AM

One other thing to always keep in mind with recvfrom is that the sender data is actually provided by the remote machine; it isn't trustworthy. It is trivial to spoof UDP packets as coming from any address and port.


In Topic: sending the same data to different computers

02 November 2013 - 09:33 AM

For all practical purposes, you can't do it.


In Topic: Data compression/optimization strategies

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.


In Topic: UDP network layer must-haves?

09 August 2013 - 10:51 PM


And, given that you provide the server, and manage the server, how could another service be squatting on the same port? The only reason that could happen would be if some third-party user accidentally puts in the wrong hostname/port information in some other program. Or they did it maliciously -- this is known as a "fuzz DDoS attack."

 

It is more of an issue for LAN play, where broadcast packets become problematic if multiple applications are using the same port. But I've seen lots of cases where companies (including large companies) decide to use a port that is already registered by someone else for some completely different purpose and just set up shop.

 

As to your first question, if you go look at the IANA list, you'll see that I registered a set of ports for all the Red Storm games back in the '90s.


PARTNERS