A few months ago I blogged about the fact that IBM was looking for two interns to fill a longterm (paid) internship. The good news is that after an extensive selection process and a hearty dose of governmental bureaucracy (which is not unusual when relocating countries), two students have finally been able to join our DB2 team at the lab.
In case you are curious about who the students are, they’re Marius Butuc from Romania, and Henrique Zambon from Brazil. They’re good guys, feel free to follow them on Twitter (even though Henrique’s stream may be more interesting to you if you speak Portuguese).
The selection process
I received about 100 resumes from students around the globe who wanted to apply for the internship. Of those, I invited the 50 most promising applicants to have an initial phone interview, as I wanted to give a fair chance to everyone (yet at the same time, I didn’t want get the hopes up of those who clearly didn’t have a shot, and thus the remaining applicants were informed that they hadn’t made the initial cut).
Before their first interviews took place, I assigned the 50 preselected candidates a coding project. They could either develop a CSV to HTML converter, a search client using Twitter’s API, or an S3 uploader.
While none of these exercises were rocket science, they were intended to provide us with an general idea of the students’ ability to code. Most candidates went for the CSV to HTML converter. Some chose the Twitter client, and a tiny handful opted for the S3 uploader (one ambitious candidate delivered all three).
After carefully reviewing their code, I held the technical interviews with all of the candidates who had sent in their assignments. During the first interview I asked each person a series of very technical questions, and in some instances we also discussed their assignments. In most cases each interview lasted for an hour.
After the initial round of interviews had wrapped up, I selected the 10 most promising candidates for a second phone call and informed the others that they wouldn’t be continuing on with the interview process.
For the second round of interviews I was joined by my manager, and together we conducted phone calls with each candidate that were based less on the each person’s technical skills. This second interview was meant to test their soft skills, to get a feel for their interests, and to assess their overall attitude.
There were important interviews because they helped us get to know the candidates a bit better. Our aim was to learn about what excited these eager applicants, to see their level of passion for programming, and to observe other skills that were not strictly related to coding. We also discussed the project they’d be working on if they were selected, our team approach (we are more of an Agile startup than the stereotypical image you may have of IBM), and discussed details of the next steps with each of these ten candidates.
At this point Leon (my manager) and I discussed at length which two applicants we wanted to select. All ten students were top notch candidates, so the choice wasn’t an easy one for us. We ended up considering every single bit of information at our disposal about the students, from their their resumes and past experiences to their performance with the technical assignment, what (human and programming) languages they knew, and how they’d faired with both of the interviews.
After a lot of consideration, we ended up selecting Marius and Henrique. (In case you’re wondering, the student who did all three assignment was also from Romania and he was ultimately our third choice, had either Marius or Henrique been unable to accept the internship position.)
What I learned from reviewing so many candidates
When you receive 100 resumes from very good students from around the world, you quickly come to realize that it’s surprisingly hard to determine someone’s real ability. Just about everyone looked pretty darn good on paper! That’s why I had to extrapolate what made each person unique via specific elements that weren’t based on coursework or grades (more on this later).
The coding assignment was a huge asset in determining people’s real abilities. Some of the nicest assignments came from those with academically weaker performances. You could clearly see who the hackers and potential future computer science professors were. Without the assignment, the selection process would have been much harder, so I’m glad that it was something we required the applicants to do.
With just a few exceptions, even good students seemed to struggle with relatively straightforward algorithmic questions, more than any other type of question. Sample questions included: What’s a Red-Black Tree and what would you use it for? Can you explain the P versus NP problem to me? (Note that these were rather open-ended questions, which I would generally follow up with more specific questions to assess the applicants’ theoretical backgrounds — as well as their way of thinking about these kinds of problems.)
Most students didn’t know much about programming in the real world. In particular, they didn’t seem to be very up-to-date, most having never heard of things like SVN, GIT, MVC, ORM, Agile programming, or NoSQL.
In general, the qualifications listed on the resumes we saw were greatly exaggerated by mediocre candidates, and somewhat downplayed by the great ones. (It looked like some form of Dunning–Kruger effect was at work.)
Some candidates, taking advantage of the long distance telephone interview, tried to Google their answers and I could literally hear them typing as I presented them with questions that they weren’t familiar with. Replies such as, “Hmmm…well…”, followed by a 20 second pause and then the all but cut and paste Wikipedia definition. This was very easy to spot and didn’t end up boding well for those candidates who opted for this less than honest route.
Recruiting is hard. It takes a lot of time and energy; rational decisions are challenging to make because in most cases you really are comparing apple to oranges.
What made a resume stick out to me
Open Source contributions (a GitHub link would immediately arouse my interest in that candidate).
A concise but detailed description of practical projects that had been implemented by the student for companies outside of their coursework (whether on the side or through internships).
Social media involvement in the programming community. Did they have a StackOverflow profile? A Twitter account related to programming? Perhaps a a blog dedicated to the subject? While these points alone certainly don’t mean someone is a good programmer, they are a decent indicator that a person is at least passionate about the subject. Attendance of industry conferences (which some had) was also a strong indicator of interest in the field.
Knowledge of unusual programming languages. Virtually everyone had Java on their resume, however that alone wasn’t good enough to catch my eye as an interviewer. (Heck, even Python is starting to be pretty common.) When candidates claimed knowledge of Haskell, Scala, Clojure, OCaml, Scheme, Factor, Io, J, etc… that definitely grabbed my attention. Again, this is no guarantee that someone is a good programmer, but chances are that they have an above average interest in our profession or have attended a university where these languages were taught (both positive signs).
While I’m not sure what you’ll get out of this article, I thought it was worth sharing as I found the whole process described above to be a fascinating one. Perhaps if you’re a student in a similar position you’ll find tips on what to do when applying for an internship with a company such as IBM. If you’ve ever found yourself in a similar interviewer’s position, you’ll likely find numerous relatable points in this post.
中文版本参见：http://www.aqee.net/2010/10/12/things-i%E2%80%99ve-learned-from-hiring-interns-for-ibm/
Jobs Digg 是一个实验性的招聘求职互助协作平台. 覆盖工作相关信息: 招聘、求职、就业、面试、裁员、感悟......
Tips: 发布信息请点击上面的提交内容.
Tips: 发布信息请点击上面的提交内容.