Nerd Pub Trivia @ ITA

Every year ITA Software sends us all out on a boat to eat, drink and make merry, and this year I thought it would be fun to host a Nerd Pub Trivia. The idea came when, while playing regular pub trivia, the picture round category was “Famous Nerds”. My friends and I thought we were a lock for a perfect picture round score, but instead of pictures of Turing Award winners we got pictures of movie and TV nerds. We joked about how awesome it would be if there was real nerd pub trivia, so that’s what I made happen on ITA’s booze cruise.

The format was a shortened pub trivia, with songs played after reading each question:

  • 1 round of 4 questions with each question being worth either 1, 3, 5 or 7 points (you decide, you can only use each value once)
  • 1 special picture round (2 points for each item correctly identified)
  • 1 round of 4 questions with each question being worth 2, 4, 6 or 8 points (akin to the first round)
  • 2 final questions on which you wager up to 10 points each (win or lose what you wager)

Without further ado, here are the questions:

Famous Nerds: Who wrote in a famous RFC, “be conservative in what you do, be liberal in what you accept from others”?

Databases: What does ACID stand for?

Networking: How many bytes are there in an Ethernet address?

Systems Programming: What is the only UNIX syscall that returns twice?

Data Structures: This colorful binary tree is self-balancing and contains no data in the tree’s leaf nodes – what is it?

Operating Systems: Which process typically has the PID of 1 on a UNIX system?

Computing History: Which of these technologies was not invented at XEROX PARC: Ethernet, The Mouse, The Windowing GUI, laser printer?

SciFi/Fantasy: Who is the Kwistaz Haderach?

Video Games: What item must you retrieve from the Dungeons Of Doom in Nethack?

Role Playing Games: What does THAC0 stand for?

And of course, we had a picture round: ID The Programming Language & ID Carrier/GDS By IATA Code (hey, we’re an airline software company, I have to have some airline trivia).

I won’t post the answers here but feel free to post your answers in the comments (and be aware there’s a few correct answers to some of these questions).

Also, if you’re a nerd looking for a job at a cool place to work, check out ITA’s current job offerings. Not to spam my readers but it really is fun to work at a place where you can host a nerd pub trivia and 10 teams join the fun.

Learning From My Hiring Mistakes

The last 8 or 9 years of my career have been spent managing operations groups at various organizations. I think one of the most difficult tasks for any manager is hiring the right people. Many blog posts have been written about how to hire developers and operations people, and I won’t rehash what they’ve said here, but I will add to the conversations with some of my own experiences and some of the lessons I’ve learned from my mistakes.

I’ve mostly hired “DevOps” people

Almost all of my hires have been for teams that are either too small to have defined boundaries or for teams that have charters that involve problems that don’t fit into traditional operations roles (“System Engineer II”). I’m much more interested in building a team of people that will own problems and find solutions regardless of their job description and have therefore tried to avoid creating jobs that rely on a specific skill. I want people who will go outside their role boundaries and marshal the technical resources needed to solve a problem correctly.

I want to hire people to do people work and let computers do computer work. People are good at creative problem solving; they’re good at understanding subtlety and context and intention. Computers are very good at doing the same thing over and over again very quickly. In other words, if it can be automated, I want to hire the people who will automate it and move on to harder, more human problems. I want to hire smart people who can learn a particular tool if necessary, not hire people just because they’ve used that tool before.

That is not to say I like to hire purely creative people with no thought to their technical ability, but rather that I don’t hire based on knowledge of a specific technology. For example, I may run postfix on my mail servers but I’d still hire someone with sendmail experience if that candidate understood internet mail routing really well.

On the other hand, there’s a baseline level of technical ability you need to do your job well. I’m not hiring people to teach them Linux. You need to be experienced with the basics so that you can get to work building better tools and solving hard problems for the company that hired you. We’ve got work to do, after all.

I’ve made a lot of mistakes in hiring

Here are just a few of the many mistakes I’ve made, and some of the lessons I’ve learned from those mistakes:

Rushing a hire because of a current need (a specific project, a needed skill on a team, a work overload).

Your best admin is quitting work to become a piano tuner and he’s taking his storage management expertise with him. You need a replacement stat. What you should not do is rush to hire the first admin with storage experience on his or her resume, because it is inevitable that the hire will work on a diverse set of technologies in their career at your company. Spend the time to hire an admin who you’ll later think of as your best admin.

Some tips for speeding up hiring without sacrificing quality:

  • Fast track your internal references, especially from your most valued employees. Smart people are friends with other smart people.
  • Use phone screens to test candidates for the requisite technical ability; phone screens should have questions with specific answers on topics the candidate simply must know. You’ll weed out a lot of unqualified people in a 30 minute phone call.
  • If they pass the first phone, do a 45 minute phone interview; discuss an interesting topic from their resume.
  • Don’t be afraid to walk someone out early; it’ll save you time and they probably already know the interview isn’t going well.
  • ITA is well known for our pre-interview programming puzzles, and there’s legitimate debate about this process, but if you don’t require a puzzle at least ask for a code sample or equivalent. Like the technical phone screen, this process can help identify candidates for in-person interviews.

Not interviewing thoroughly enough.

This is especially important in a small company where the success or failure of a hire can have a drastic effect on the health of the company. Have the candidate talk to at least 5 people, and make sure most of them are technical people. It’s also important to discuss who will talk about what in each interview before the interview. Otherwise, you’ll all talk to the candidate about the same interesting bit on his or her resume. Don’t hesitate to bring the candidate back for another round of interviews if you think it is warranted.

Compromising on ability.

I made this mistake at a previous job after being unable to find the correct person for the job for months. I eventually hired a person simply to get a body in, and I knew the person wasn’t good enough for the job. Sure enough we had to part ways after a few months. Firing someone is expensive and time consuming, and you’re left back where you started. Part of the problem with this hire was that my budget wasn’t correct for the skill set I wanted, but in the end it was me compromising that led to the failure.

Some lessons from this mistake:

  • Fight for the correct budget for the skills you need.
  • Make sure everyone agrees the person is correct for the job.
  • If you haven’t hired for a position you’ve had open for a long time, perhaps you need to re-evaluate what you are looking for and if you really need the hire.

Thinking I’ll have the time to train someone in skills fundamental to the job.

I feel worst about this mistake because I should have known better; I was already overloaded at work, so what made me think I could train someone in my zero free time? Even if you think you have the free time it is inevitable that work will take back that free time.

What didn’t work for me may work for you…

… but it also may not, so be careful. Hopefully you’ll learn from my mistakes in any future hiring you do.