3 ms·

What I want to find out when conducting the interview is, are you really the awesome person your resume says you are? Or did you sit next to that awesome perso

What I want to find out when conducting the interview is, are you really the awesome person your resume says you are? Or did you sit next to that awesome person on a team at your last job and just goof off all day and now put everything that guy did on your resume? I'd love to have any means of better answering that question than going with "did you pay attention in class/last few jobs?" sorts of questions like "Can you work with this linked list on a white board" simple programming problems, but right now I don't know a better way. So I don't consider programming puzzles meaningless on the assumption that the guy who slacked off won't do well with them while the guy who paid attention and loves to program will know and demonstrate a thing or two. I know with some potential hires I can review a github repository, but that has similar problems. I've handed an interviewee code from his own github repo where he had fixed a defect and asked him to point out the defect he fixed on the page, and he couldn't find it. Does he just have a bad memory, or is he lying about that being his code? How can I tell?

chetanahuja 13y ago
I'll addressing two things from your post 1) is there a better way and 2) show me the defect that you fixed. 1) There definitely is a better way. It involves engaging with your potential long-term officemate for longer than a 45 minute face-to-face session. Have them write actual, working code (or whatever... depending on their intended role) -- maybe even pay them for the time they spend on this process with you, so they don't feel like you wasted their time if you decide not to hire them. Basically, approach this function with the same level seriousness and goodwill that you'd bring to any business dealing with people outside your company. What is that you say? You don't have time for that style of hiring process? Well you can either have a better process or a fast/simple process for judging people for long term compatibility. People generally don't get into long term relationships with other people after a 45 minute (mostly one-way) quiz. 2) Do you really expect a working professional to remember the details of each bug that they fixed in their career? Won't it have been better to simply concoct another piece of code with the bug they fixed and see if they can spot it with the familiarity of someone who's seen something like it before.
Sukotto 13y ago
One way to approach this is to say something like: "I have a selection of (simplified) problems we've faced recently. They're representative of the sorts of issues you would be taking care of if you join our team. Let me walk you through them one at a time and we can discuss. We'll start just by verbally going over them, then either move to a whiteboard or to a workstation to dig into them a little deeper. The goal here is to see how well we can communicate with each other as well as your ability to actually do the sort of work we need done." Imho, there are only three things you really need to know about the candidate: 1) Will this person fit into the current team with the minimum of fuss? 2) Can this person do the job professionally and in a timely way? 3) Is hiring this person a financial risk we're willing to take?

chetanahuja 13y ago

I'll addressing two things from your post 1) is there a better way and 2) show me the defect that you fixed. 1) There definitely is a better way. It involves engaging with your potential long-term officemate for longer than a 45 minute face-to-face session. Have them write actual, working code (or whatever... depending on their intended role) -- maybe even pay them for the time they spend on this process with you, so they don't feel like you wasted their time if you decide not to hire them. Basically, approach this function with the same level seriousness and goodwill that you'd bring to any business dealing with people outside your company. What is that you say? You don't have time for that style of hiring process? Well you can either have a better process or a fast/simple process for judging people for long term compatibility. People generally don't get into long term relationships with other people after a 45 minute (mostly one-way) quiz. 2) Do you really expect a working professional to remember the details of each bug that they fixed in their career? Won't it have been better to simply concoct another piece of code with the bug they fixed and see if they can spot it with the familiarity of someone who's seen something like it before.

Sukotto 13y ago

One way to approach this is to say something like: "I have a selection of (simplified) problems we've faced recently. They're representative of the sorts of issues you would be taking care of if you join our team. Let me walk you through them one at a time and we can discuss. We'll start just by verbally going over them, then either move to a whiteboard or to a workstation to dig into them a little deeper. The goal here is to see how well we can communicate with each other as well as your ability to actually do the sort of work we need done." Imho, there are only three things you really need to know about the candidate: 1) Will this person fit into the current team with the minimum of fuss? 2) Can this person do the job professionally and in a timely way? 3) Is hiring this person a financial risk we're willing to take?