Last week there was an interesting thread going on Twitter regarding job interviews. The range of responses went from helpful, to just plain blackmailing, and everything in between. Obviously this is a very sensitive topic since it involves different people (different backgrounds and biases) with different roles (candidate/interviewer/recruiter) with conflicting requirements (need to find the right people / provide opportunities to new comers in the industry / grow the company).
So here I’m going to make an attempt to boil down my own personal experience and opinion on the subject just as bullet points. If you want me to elaborate further in anything specific let me know.
- I have taken many interviews. Some of them for full time positions, some to get hired as consultant, many to show that the outsourcing company I was working for was good enough for the client on staff augmentation type of projects.
- The split of telephone vs personal interviews I have taken is pretty close to 50/50.
- I have even taken internal interviews before being presented to a potential client.
- As a funny example, I was interviewed internally for a client that had rejected at least 10 other candidates. The internal interview went horrible and management thought that I would be rejected by the client. Instead I was asked to join by the client in less than an hour.
- Programming tests
- Usually fairly simple coding tests.
- Tasks such as:
- Implement itoa.
- Implement factorial of a number.
- Detect errors or pitfalls in a piece of code.
- Free-form tasks are also good.
- I remember I was once asked to implement a simple and fast function to move a tank in the direction of an enemy if it was in the field of view.
- No right or wrong, and very good for conversion.
- Most of the good interviews used the programming test answers to spark conversation.
- In one case I remember doing a programming test when I was younger where I took it upon myself to even rewrite the code the interviewer provided. That became a big red flag for them since it seemed like I wouldn’t respect existing standards or legacy code. Being the young cocky programmer that I was I told them that I would change whatever necessary to have “optimal code”. A job offer wasn’t made to me. They knew I wouldn’t fit in that culture.
- Questionnaires
- Specific short questions that can be answered in bullet points.
- Very concrete questions or with lots of details. The good questionnaires I have taken in the past never left any room for ambiguity.
- Whiteboarding
- Very helpful for problems that are visual in nature.
- Common to me since my focus is on rendering.
- Useful when I was encouraged by the interviewer to use it as a canvas to explain whatever I need.
- Very helpful for problems that are visual in nature.
- Programming tests
- Tasks completely unrelated to the actual job.
- String parsing, etc.
- Write a gameplay system when applying for a work as a rendering engineer.
- Live or supervised programming tests.
- Hardly ever do you ever need to write code while someone that is evaluating you is breathing on your neck.
- The idea of an interview, from the point of view of the potential employer, is to find if the candidate can do the work that he or she needs to do under normal conditions.
- Use of a specific IDEs to write the code and not allow the candidate the tool he/she is more comfortable with.
- Web based tools are usually terrible and almost never used on the actual job.
- You are trying to assess the knowledge of the candidate and not his/her ability to endure terrible development environments.
- Codility comes to mind.
- Tests that ask too much of the candidate in terms of time investment.
- The assumption that the candidate has all the free time to do a proper job could be completely wrong.
- I remember being asked to write a small path-tracer in a week.
- Fix, optimize, and parallelize a software sphere rasterizer. At that time, I was a technical leader of a distributed project, barely had the time for some personal life and the potential employer asked me to do that in a few days. Needless to say I did a pretty poor job.
- The assumption that the candidate has all the free time to do a proper job could be completely wrong.
- Tasks completely unrelated to the actual job.
- Questionnaires
- Riddles and trick questions in general.
- Multiple choice tests that don’t allow for comments.
- I have had many cases where I know what the "expected answer" was but I didn’t agree with that and I couldn’t explain why.
- For example, being asked about multiple inheritance. I avoid it as much as I can yet there is only one “right” answer if there isn't any comments section.
- Whiteboarding
- Coding on whiteboard.
- Just as bad as supervised or live programming.
- It puts stress on the candidate on irrelevant details.
- Can the interviewer read my horrible writing?
- Did I forget a semicolon somewhere?
- I have yet to ever write code in a whiteboard in a real job. Completely useless practice.
- Coding on whiteboard.
- General discussion
- Terribly biased interviewers.
- I had one interviewer waste at least 15 minutes trying to find out how I was supposed to have done work with PS3 and Xbox 360 devkits from Argentina. His probing included asking questions about peripherals and ports on the devkits, how the closed development networks looked like and bullshit like that. Needless to say I was pretty insulted and the interviewer did notice so eventually moved on. After the interview I wrote to the recruiter saying that I wouldn't even consider an offer due to the terrible interview.
- Terribly biased interviewers.
- I have interviewed at list 40 people for very different positions.
- I have done more personal interviews than remote ones, but not by a huge margin.
- Never had the responsibility of choosing whether a candidate should be hired or not, I could only recommend to hire or not hire.
- I have interviewed people for my own team as well as people for different projects or clients.
- In very few cases did I interview a candidate together with someone else.
- I have never defined the contents of any of the programming tests taken by the candidate before I had to interview them.
- I was a terrible interviewer back in 2007, I'm doing much better now but I certainly have a ton to learn.
- Programming tests
- Used the programming test as a possibility to talk with the candidate, but not as a chance to grade the test in front of him or her.
- The programming tests that I found useful even though I didn't write them.
- The common characterstic they had was that they focused on tasks that are related to the open position, rather than complex in areas that are unrelated to the actual job.