Buy a cactus, get hired

Interviewing people at Apple was something I always enjoyed. It was a way to have a small, but important part of building the company.

I had a number of interview topics I liked to deploy. One of the most important to me was learning what software projects the candidate had accomplished that were not part of a class at school or a job. It was a big red flag if a candidate has no side projects, and learning about any side projects could reveal a tremendous amount about them.

In 2001, when I was on the Mail team, I interviewed a candidate, who I will call Felix, for a QA position on Address Book (now Contacts). In addition to testing experience, we wanted someone with excellent scripting ability.

We found people that were strong scripters, but lacked testing experience. Felix was the opposite: rather weak on scripting, but solid everywhere else.

The candidate put a link to his website on the résumé. Before the interview I poked around and found a page of scripts that he had written. They were mostly simple work-related geeky scripts.

One script caught my eye: cactus_watering.pl. It would connect to a weather server and get the daily rain forecast for Tuscon, AZ. If rain was expected, it would email anyone on the happy-cactus mailing list to tell them to water their cactus.

It’s always a positive sign for me when people post code they’ve written, no matter how impressive or unimpressive it is.

I loved it for so many reasons.

1. I appreciate when people are not shy about publishing code they’ve written, even if they are not exactly revolutionary. They are allowing criticism as well as helping others learn things.
2. Choosing a portable language like perl or python rather than a shell scripting language shows good programming choices.
3. The script was nicely written and documented. It’s one thing to write a quick-and-dirty script; it’s another thing to write something for public consumption.
4. I like when people see a need and try to find a software way to solve it. Felix could have easily just done a Google search and called it a day.
5. Even though it was a fairly simple script, it did involve networking, text parsing, sending email to a mailing list, and daily scheduling for running the script.
6. It showed a genuine sense of humor and an enjoyment for writing code.
7. One of the best way to enhance your testing skills is to write code that you and others will use. This gives you insight into those that are writing the code you are testing.
8. I felt like it gave an insight into his personality and helped determine whether he’d fit in well with the team.

Oh, and we ended up hiring Felix. He stayed for more than 15 years.