Interviewing
May. 18th, 2017 10:44 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
tensegrityYesterday I got to conduct my first technical interview and there are two more to do today. It was interesting to be on the other side of the table and I'm finding that I have strong opinions about technical interviews.
Yesterday's happened with very little notice. I only had about an hour to prep for it and we didn't have a standard set of interview questions ready. (Our team used to have a list, but it hadn't been updated in several years and has disappeared in a reorg at some point.) And just to make it interesting, we really would like to get a mobile unicorn, someone with strong skills in both iOS and Android, even though we don't expect to find one. Oh, and preferably they can work in a specific cross platform tool and have some experience with hybrid apps that incorporate web content.
Of the three interviews this week, one candidate has iOS experience, one comes from an Android background, and one is mostly a .Net developer. We only get to hire one person for now, so how do you structure a technical interview in this case? I've had to come up with four sets of questions; iOS development, Android development, mobile development, and a general set of personality/working style questions. With ten to fifteen questions in each set, I should be able to pick and choose appropriate questions for any given candidate. I'm most of the way there but I'll be doing some refining of the list over the next week.
Opinion time. I hate trick questions. I hate them. I also think that deep in the weeds technical questions are bullshit for most interviews. I also dislike questions that ask people to regurgitate bullet point lists or interface details that can be easily looked up; they tend to be lazy questions that don't tell you much about a candidate. I like questions that tell me whether a candidate understands the jargon of a field and has an understanding of the shape of the problems to be solved. I like questions that give a chance for the candidate to express themselves because communication skills are critical. If you've worked in more than one language and more than one toolset over the course of a few years, then you've probably mastered the skill of learning new languages and toolsets. If you don't know the ones we're working with, you'll learn them. But if you can't communicate effectively, that's a deal breaker.
Ideally, the questions should never be phrased in such a way that they encourage a yes or no answer. But how do you get useful information about someone's skill at estimating the time required for a project? How can you evaluate debugging skills in a phone interview? I'm working on it. In the meantime, I am also leaning one heck of a lot about writing resumes.
Yesterday's happened with very little notice. I only had about an hour to prep for it and we didn't have a standard set of interview questions ready. (Our team used to have a list, but it hadn't been updated in several years and has disappeared in a reorg at some point.) And just to make it interesting, we really would like to get a mobile unicorn, someone with strong skills in both iOS and Android, even though we don't expect to find one. Oh, and preferably they can work in a specific cross platform tool and have some experience with hybrid apps that incorporate web content.
Of the three interviews this week, one candidate has iOS experience, one comes from an Android background, and one is mostly a .Net developer. We only get to hire one person for now, so how do you structure a technical interview in this case? I've had to come up with four sets of questions; iOS development, Android development, mobile development, and a general set of personality/working style questions. With ten to fifteen questions in each set, I should be able to pick and choose appropriate questions for any given candidate. I'm most of the way there but I'll be doing some refining of the list over the next week.
Opinion time. I hate trick questions. I hate them. I also think that deep in the weeds technical questions are bullshit for most interviews. I also dislike questions that ask people to regurgitate bullet point lists or interface details that can be easily looked up; they tend to be lazy questions that don't tell you much about a candidate. I like questions that tell me whether a candidate understands the jargon of a field and has an understanding of the shape of the problems to be solved. I like questions that give a chance for the candidate to express themselves because communication skills are critical. If you've worked in more than one language and more than one toolset over the course of a few years, then you've probably mastered the skill of learning new languages and toolsets. If you don't know the ones we're working with, you'll learn them. But if you can't communicate effectively, that's a deal breaker.
Ideally, the questions should never be phrased in such a way that they encourage a yes or no answer. But how do you get useful information about someone's skill at estimating the time required for a project? How can you evaluate debugging skills in a phone interview? I'm working on it. In the meantime, I am also leaning one heck of a lot about writing resumes.
