Interviewing

When interviewing a candidate, it's very hard to know if you're asking the right questions. The distance between what you know and what the candidate knows can be huge (for either side) as can be to what she's supposed to know.

Also, interviewing is not only a matter of knowledge. It's not uncommon to find people with vast knowledge but little practical skills or with selfish behaviour that could jeopardize the whole team.

It's also not about giving the right answer but being consistent with her own policies with the company's. A good interview can identify those problems with a few simple questions.

• DOs
  • Smile.
  • Briefly explain the job and company first, it'll save a lot of time.
  • Do short interviews with few people in the room. Many eyes watching makes anyone nervous.
  • Ask other people to talk informally with the candidate. Attitude also counts.

• DONTs
  • Don't be arrogant. If you're not in the mood for an interview, ask someone else to do it for you.
  • Don't go deeper than the job will demand, it gives the wrong impressions of the job description.
  • Avoid default H.R. questions (such as “what are your best qualities/worst problems”) the answers are pre-formatted and add absolutely nothing.
  • Never apply I.Q. or psychology tests unless you have a psychologist to interpret the results.
  • Avoid written tests. Hackers have many ideas in parallel and only two hands.

• Basic skills
  • Problem Solving (algorithms & data structures, modularization, patterns, refactoring, programming languages)
  • Teamwork (projects, colleagues and DIY)
  • Bottleneck Analysis (new projects, slow code, network and hardware problems)
  • Object Oriented Skills (basic OO, language idiosyncrasy)
  • Thinking Parallel (splitting execution & data, threads and message passing)
  • Optimization

• Language skills
  • C++
  • Perl