I’ve had a lot, and I mean, a lot, of interviews over the past year and a half. I was intermittently contracting and looking for the perfect job. So, in that process, I developed a few theories and opinions on how one should be interviewed.
At She’s Geeky 2011 last weekend, I attended a rather unsatisfactory session on just this topic. These were the gems of what was being shared- that rubbed me the wrong way.
1. Sit someone down for 1-1/2 hours, on the company’s computer, to test their basic Java skills
2. Despite all good interviews within the company, don’t hire them because “they don’t fit in”
3. Setting up all day meetings
4. Continual use of the word “he” for interviewee
5. Hiring right out of college, almost exclusively, by large companies (Google, MSFT)
6. Hiring only top 10 schools
(Answers to why these are bad, at the end.)
There were some good things folks were doing:
– Meeting with colleagues between interviews to quickly discuss the candidate
– Creating a scoring system before the interview, amongst colleagues, to use to rate candidates- great hire/ good hire/ ok hire/ bad hire/ really bad hire
– Using the same questions across candidates
These were largely interviewers, with only 1 or more companies in their dock. As someone who has been interviewed a lot, recently, I can pretty confidently tell you what’s going on in the field:
– quick screens on phone, single casual meetings, longer more in depth meetings
– high-up exec meetings first, then tech meetings last
– tech screens, and “fit” screens on phone
– quick ‘google tests,’ word questions, instead of sit-down-and-code
– very quick turnaround, and relatively good follow-up from someone at the team
I asked the facilitator- who had the 1 1/2 hr sit down Java test for her people- whether published code, that is used, popular, open source, negates the need for a sit-down test. We also discussed the lack of trust in hiring engineers- how there’s this undercurrent of the hirer being hoodwinked into hiring someone (man, or woman) who didn’t write their own code, or took three years to write one line. In other professions, having someone undergo a basic Excel test for a marketing job would seem insulting. She replied that she’s been tricked before, someone who “talked Java” quite well. Yes, it is on the onus of the interviewer to find out if what they know is what they know- it’s a risk we all take, and it goes both ways. The company could be vaporware, the investment not real, etc.
My favorite aspect of interviews lately: the Google question. Some interviewers look these up on Google, some make up their own. One company made up their own, and I was impressed with that, but when I told them it’s basically the game my mother taught me as a kid- Cribbage- they were perplexed. Now, I had to say that 3 times because I was called 3 times for a phone screen. And they didn’t talk to each other before hand. So this goes back to the other rule- talk to the interviewers, for just 5-10 minutes, beforehand. Don’t get conclusive, just talk about what you talked about. Leave the judgment for later on, when you can assess things together. They could have simply said, “I asked her that question we made up.” “Ok, I won’t.” The other thing is- don’t have 3 phone screens. A screen doesn’t go on and on. I took it as a sign of luke-warmness, which led me to not be as excited about the position, since they weren’t. And being asked the same question made me think they weren’t very organized. No matter how sexy and fun the work, developers especially hate disorganization (they’re disorganized enough).
The main problem with Google questions:
– you can find the answers on Google
– frequently they are testing bit-level processing, not iPhone development (or whatever specialty you are interviewing for). “there are 8 balls with on/off states” etc.
– many companies don’t care “how you think” they just want the answer they looked up on Google (because they are busy, tired, or didn’t arrive at it the hard way themselves.)
For many companies, it’s very hard to hire someone in a speciality that they don’t already have- and that is the source for most of the flustered, superior, “testy” atmospheres. There’s also the endemic feeling of superiority in “we have the job, you don’t,” especially in hard times. The desperation and hunger of the market, and the daunting task of hiring in something they don’t know, means that the worst side of companies come out- scared and defensive. And that becomes arrogance. Because 20 people will sit down and do these tests, and answer the same question 10 times, and “fit in” (more on that later), doesn’t mean that it’s the right way to go about it.
So what do we do?
Ask questions about the last hard problem that came up at work. These are great questions, if you can abstract it out a bit, because it deals with the daily job grind, and what kind of issues you come across. This may or may not be interesting to the developer- and beyond problem-solving, you should judge whether they seem interested in the problem. You can talk about what solution the current employees found, and what the candidate thinks of it.
Do your research. Look them up on LinkedIn, research companies, etc. Don’t stalk them, but find opinionated articles on technologies (+1 points if they have published opinionated articles!) and get into that. It will engage them, bring down the nervousness and be topically relevant.
Do read their code. Print it out, bring it. Or ask them for a sample of their favorite code beforehand. Talking about code, instead of making them write it on the spot, can be very revealing, and shows a portfolio way of displaying craft and skill, similar to other occupations. It’s respectful, and it’s important if they take pride in their work, etc. Points if they’ve published code on blogs, etc. or open source.
Don’t waste their time with multiple questions that are the same across interviewers. See what they think of the working environment, and don’t get defensive, just listen and store it away. Talk about the prospects of the company, realistically. Ask about their mentors or folks in the field they respect.
This is a parenting adage (from my sisters) if you treat a kid as a kid, they will act as a kid. If you treat a developer as an untrustworthy, unprofessionalbot, that is what you will get.
1. See almost all points above.
2. Here lurks many reasons for prejudice. If you can’t articulate it, be wary. Also- why homogeneity? Ask yourselves that. You’re making a choice to stay the same.
3. Waste of time
4. Sexist
5. Agist
6. Missing out on a lot of other folks.
Great reading:
Jean Hsu on her interviewing experiences, with this great quote:
My suspicion is that people who do well in interviews are generally fine, but that technical interviews may weed out candidates that don’t interview well but would actually do a good job.