3 ms·

"That guy didn't have 20 years of experience with db2... He had 2 years of experience, 10 times." One of my mentors said that about an interview he conducted a

"That guy didn't have 20 years of experience with db2... He had 2 years of experience, 10 times." One of my mentors said that about an interview he conducted a while back. I found a lot of truth in that line. I run my tech interviews by starting very green and let the candidate dictate how fast I ramp it up. I've gotten pushback from managers before that you can't start with basic questions, but I've equally gotten positive feedback from candidates (even one's who've been failed the interview). In the end, programmers want to see an algorithm that allows them to judge an interviewee. I don't believe one exists.

mywittyname 8y ago
This is a brilliant approach because everyone has more context, meaning answers can be more pointed and exact. When the questions start small and build incrementally the next topic of conversation becomes much more natural. The candidate knows that they can use a technique because it's already been discussed and the interviewer is has more control over the flow because there are fewer tangential topics.
- pfarrell 8y ago
  I don't claim to have solved the problem of interviews, but I do think I and the candidate get more out of it when we leave it a bit more free-form. I'll cover architecture of our system, API design stuff, debugging, testing, security, problems we're currently having, etc. I'm looking for passion so if the candidate starts riffing on any area, I'll let the conversation flow into that area and go as deep as we can. I usually play dumb as we talk, asking the candidate to explain why and ask what does that mean if they throw an acronym or design pattern into the conversation. A plus of that Socratic method is that if we get into an area that I don't know much about, the candidate doesn't know the difference :)

3 ms·

"That guy didn't have 20 years of experience with db2... He had 2 years of experience, 10 times." One of my mentors said that about an interview he conducted a

by pfarrell 8y ago

mywittyname 8y ago
This is a brilliant approach because everyone has more context, meaning answers can be more pointed and exact. When the questions start small and build incrementally the next topic of conversation becomes much more natural. The candidate knows that they can use a technique because it's already been discussed and the interviewer is has more control over the flow because there are fewer tangential topics.
- pfarrell 8y ago
  I don't claim to have solved the problem of interviews, but I do think I and the candidate get more out of it when we leave it a bit more free-form. I'll cover architecture of our system, API design stuff, debugging, testing, security, problems we're currently having, etc. I'm looking for passion so if the candidate starts riffing on any area, I'll let the conversation flow into that area and go as deep as we can. I usually play dumb as we talk, asking the candidate to explain why and ask what does that mean if they throw an acronym or design pattern into the conversation. A plus of that Socratic method is that if we get into an area that I don't know much about, the candidate doesn't know the difference :)