|
I love this; it's a good insight into what a hiring company wants to know about a potential employee. So how do you get there? Here's my suggestion: There are 2 very distinct (in my mind) kinds of skills in question. For the "soft skills", a manager-type could and maybe should do that part of the interview. A trusted tech person should do the technical part. I'd go so far to say to that every technical person on the staff should be trained / groomed to help with interviews. So maybe you have 1 tech person do the tech interview, and a 2nd is learning how to interview. For the interview itself, the process I'd use is to ask a lot of questions. For the soft interview, things like: - "Tell me about a difficult customer you've had." Let them explain a while, and ask lots of probing questions: "Why didn't you do X instead?", etc. - "Tell me about a difficult problem you had with a former employer." Same drill. For the tech part, bring some code to the interview, ask the interviewee to bring some code to discuss. Another option would be to just throw them into a source code tree and say something like "Here's a tree of one of our projects. Talk to me about it." Maybe I'm wrong, but I think I could tell a lot about a tech person just from how they approached being thrown into a mess with no prior information. After all, that's a large part of being a good developer IMO. As they start to figure things out, look at code, etc., ask them questions about what they're seeing. Let them ask too. If you run into something interesting, like a specialized algorithm, ask them about it: "Why do you think it was done this way? What would some other options be?" Then let them do these things for code they have previously written. For example, I wrote a Prime minicomputer emulator. I'd love an interview where they asked me about why I did this project, what problems I ran into, what were some alternative designs for tricky problems, what were the tricky problems, what did I learn from doing this, what tools did I use to do it, etc. |
"Its in perl, I don't know perl, and especially not your internally modified version of custom-magic perl that Steve wrote 7 years ago."
Not to mention that you are now either showing source code trees to random potential hires, or you have to audit/create/otherwise use some potential set of source code. Maybe you prescreen by asking them their favorite language, and you come in with an open source project, in their language of choice, but now you have to have one of your devs spend time familiarizing themselves with Redis or the Python interpreter or Hibernate Core or Angular or whatever, and what happens when they ask to do the interview in Haskell?
FWIW, I know some companies that do the interviews you're describing, but they're all relatively small (<100 employees), and they all do that kind of interview only after a technical phone screen with your conventional questions, because the time investment required by the company is so great.