Regarding Interviews and the Recruitment Process

Everyone looks for new employment opportunities at some point in their lives. Those who work in the technology sector are no different. After recently undergoing a number of interviews and interview related tasks, I thought that I'd take the time to share my experiences: the good; the bad; and complete time wasters. For a bit of background, I'm a Software Engineer living in Sydney. Some of the companies I've recently interviewed with include Atlassian, Google, Ning, and ThoughtWorks. I'd like to say up front, that despite any negative spin that I put on the interview process, I still enjoyed them all (to some degree at least). Quite clearly, I was not successful with all of them, else I would not have interviewed at the other companies.

When it comes to interview tasks:

• Ask questions that you seriously expect the applicant to know. If you do not expect me to know, or don't know why the question is there, then why are you asking it?
• Non-technical people should not ask technical questions. This is a complete waste of my time and yours. I expect the person asking the questions to understand the questions they are asking. Going off a template is no excuse.
• As the hiring process often involves a number of different interview steps, calling me in for a face-to-face interview, knowing nothing about me apart from my resume is a waste of everyone's time. Telephone interviews serve a purpose.
• Providing feedback is critical. Expecting me to offer hours of my time, then offering no feedback will do nothing but annoy me.
• Timely follow-ups. Yes, there may be multiple interview steps. Yes, people are busy. That is no excuse for taking three or four weeks to provide feedback. In the meantime, you run the risk of losing me to another company.
• Coding tasks are great. They can give great insight into the applicant. This approach opens opportunities for paired programming as a follow up interview.
• Throwing problems at an applicant to solve on their own on whiteboard is a waste of time. Yes, you may gain insight into their problem solving skills, however this is not an indication of real world problem solving.
• If you want to see examples of my code, ask me to code a solution to a problem. Code written for another company is copyrighted, so I cannot show you it. Likewise, as coding is a group exercise, where multiple people work on a single piece of code over time, is does not indicate a particular coder's experience or skill.
• Do not ask me to come into your office to take a pen and paper test, unless I'm also doing a face-to-face interview. Find a way to get the test to me.
• Do not ask me textbook questions. If you want a walking talking textbook, hire a recent graduate. There's a good chance that I once knew the textbook answer, but too much time has passed. Instead, ask a lead in question that provides more context or offers a real world example.
• At some stage in the interview process, someone needs to site down and give me an information dump in regards to just what the job is about. Sure, I'll ask questions along the way, however, as I do not know necessarily about the company and job beforehand, please do not assume that at some point I would have asked the correct question.

What can I say about particular companies:

Google

• The questions were interesting, and required careful thought and consideration in order to provide an efficient solution. Explaining code over the phone is not straightforward however.
• For me, the difficulty in answering Google's questions, was not in not knowing what to do. I believe that the key point in answering the question is to quickly recognise the category of the question. If you do this, the answer will be much easier.
• In each Google interview task, I was given one question that was significantly more complex than all the others. This question was the clear crux of the interview. These questions were all really quite interesting and challenging to solve. At the same time, they were also a lot of fun.
• I don't care that you are Google. You shouldn't take three to four weeks to get back to me.

Atlassian

• Spending nearly half an hour discussing the obscure fallacies of Java's HashMap implementation seems a little unusual. Sure, you may use a lot of HashMaps, but this seems a bit overboard.
• I've taken the time to write sample code for you. I've taken the time to answer questions (in short essay form). The least you can do is provide feedback more than, "nothing in particular".

ThoughtWorks

• Lots of interview tasks (I went through nine in total).
• Tasks were a lot of fun ('The Logic' in particular rocked!).
• The results to my tests were lost??? I'm glad that the results were positive, but even so...
• Waiting three weeks for feedback is not good.
• Cancelling an interview when I was already onsite. Whilst this may be unavoidable in some circumstances, it was nevertheless not appreciated.