Hi, I'm Max! I am a programmer for Electronic Arts and I develop compilers and systems/concurrency related libraries for games. Outside of work I dabble in XNA, Lisp, and C with my side projects revolving around rendering, web apps, and whatever else I find shiny. I'm also on Twitter.
Posts by Max Burke
  1. The Value of Valgrind ( Counting comments... )
  2. Revisiting the Technical Interview ( Counting comments... )
  3. The Problem of a Lifetime ( Counting comments... )
  4. On Builds ( Counting comments... )
  5. Handy Developer Tools: The Sandbox ( Counting comments... )
  6. C for C++ programmers ( Counting comments... )
  7. Tips and Tricks for Debugging Optimized Code ( Counting comments... )

The choices of who to employ are some of the most important decisions a company will make. Obviously picking your CEO, if it's not the person who formed the company, will have a huge impact on how the company does but the ripples can be felt even at the leaves of the org chart. There are many costs involved in picking the wrong person, including the obvious (salary), the unfortunately-sometimes-necessary (termination costs), and the insidious indirect (draining the productivity of others).

The candidate's responsibility is to show that they can make the company better with them on board and the company's responsibility is to find out that they will be better with the candidate in their ranks.

I think the way most companies conduct technical interviews is borderline pathological. Programmers are herded into a small room, given a glass of water and a whiteboard marker, and are expected to recite a bug-free quicksort or work through demented problems like determining the weight of a Boeing 747.

Technical interviews are about seeing if the candidate has the chops to make the team significantly better. It's not about grilling them with tricky questions, it's about seeing if they're capable enough to do the job and if they get along well with the existing team in the process.

One of my new favorite screening techniques is to take a body of work done by the candidate, either some sort of code portfolio (like an open source project they've contributed to) or an assignment we've given them ahead of time, and use this as a basis for discussion. Topics like API design, or use, are incredibly important but don't fit well into a 1-hour interview segment because it's not enough time to ask about the consequences of such decisions.

This offline work allows them to produce code in an environment similar to their day-to-day job, working at a computer in the comfort of their preferred development environment, rather than on a whiteboard under the watchful eye of a person who may or may not control thir destiny and oh my god I just forgot a semicolon CRAP I NEED A CAST HERE OH GOD THIS DOESN'T WORK WHEN i IS 0 I'M NEVER GOING TO GET THIS JOB I'M GOING TO DIE PENNILESS--... ahem.

Since our interviewing volume has been pretty high and we don't really have the number of people on the team to permit doing day long interviews with everyone who passes through recruiting we've also split up our interviews -- instead of having two people talk to a candidate for an hour, we're having each person have a separate session with the candidate.

Overall these changes have worked quite well for us and have helped get a better handle on the people we're interviewing, such as where they're at technically now and where they need improvement, and I think it's helped us hire better people.