What's In A Server Name?

In the beginning, the admins named the servers. So the servers got geek-culture names like gandalf and sauron, or enterprise and voyager. And it worked pretty well. People remembered the names, and they remembered that gandalf was the development box, and sauron was the production Oracle database.

Then some suit decided that the geek-culture names were unprofessional (whatever that means), so IT management stepped in. They came up with server naming conventions that embedded all sorts of useful information: data center, run-time environment, software configuration, server number, etc. And out came monstrous server names like NYCP3STDZ09. Which is a challenge to say out loud, and hard to remember, and doesn't connote much of anything unless you know the original conventions. Which hardly anyone does after a few years of turnover.

And NYCP3STDZ09 is a hard name to get right in a phone call, and an easy name to mistype in an email, and that's just so much extra fun in the middle of a production problem.

Meanwhile, sauron comes across clearly in phone calls and emails, even when you're frazzled because your boss's boss's boss wants to know when the fuck the system will be back up, even when your data center is offshore and your admin's accent is very different from yours, and you're on a conference call that sounds like a cell phone in a hurricane. It's a great server name when people need to communicate.

But it's unprofessional, and disorderly, and doesn't tell us anything about the server's role in the organization. So we have a winner: NYCP3STDZ09. Just be careful what you type. Don't want to get the wrong box rebooted again!

Interviews 2.0

I've been doing some J2EE screening interviews for my company, over the phone. Some trends:

• Candidates google as they go, so feature questions like What's the difference between a HashMap and a HashTable? have almost no value. All you're testing is how quickly and quietly the candidate can type.


• Candidates have found a quasi-ethical way to embellish their resumes: describe a project in detail, but don't say which pieces you worked on. List every tool/technology used in the project, whether or not you were the one using it.
  
  Of course, this is pretty easy to blow apart. I've gotten some amusing explanations of Ajax from people who maybe used it once to clean a sink. Which brings us to...


• Don't just ask people to explain a technology. Ask them how they've used it on a project. Any candidate who answers with an accurate general description of the technology probably hasn't used it much. A candidate who can tell you what he's done with the technology, the problems he ran into, how he worked around them - he's telling you the truth. Bonus points if he gets animated while he's talking about it.
  

Experience is hard to fake, even over the phone with a browser open.