4 ms·

If the candidate has enough free time try to do a trial project. There are also more procedural things that can be useful like code tests (although they need to

by kls 15y ago

If the candidate has enough free time try to do a trial project. There are also more procedural things that can be useful like code tests (although they need to be done in a respectful way and they are more about getting to know how each side thinks than actually testing whether the candidate knows how to program (hopefully you know that by this stage)). I have come to the point where I respectfully decline to take tests and will generally end the interview at that point, because it tells me that the interviewer and the company has no way of knowing what constitutes a good developer. Figuring out if a developers is good is actually pretty simple, have them show you something they built and then ask them to show you the routine they are most proud of, this way you can start an organic conversation about something they know, testing only devolves into trick questions, unrealistic pressure, and testing candidates for what you think they should know, as such I start looking for the exit as soon as I see them. Not to be a jerk but, it tells me that either the company does not know how to spot talent or that they think they are elite, which tells me they will have a scalability problem in recruiting should they take off.

Timothee 15y ago
You make a good point about the way a code test can change the "atmosphere" of an interview. Showing what you've built and explaining how you did it is also probably much closer to how you would collaborate if you were hired. Some might say that it would be too easy for someone to discuss code they haven't actually written, but it's also easy (as demonstrated recently on HN) to just practice common coding tests and pass. I haven't done many interviews for development jobs, so I don't know how common (if at all) it is to get "please bring with you something you've built to discuss it".
- kls 15y ago
  I always bring my laptop with me and try to steer the interview in that direction. The first thing I do is ask them if they would like to see something that I have built and offer to walk them through the code and the architecture. If someone does this on an interview, they would be hard pressed to BS their way through an entire application. There is just a level of detail that they will go into that, someone that is faking it cannot, generally you will get storied about the code, stuff like oh yeah, this routine was a pain because in IE when you add and remove an element from the DOM it destroys it in memory. That kind of battlefield cometary shows that they lived through the code and it comes out organically when you talk to someone about something that they have been part of.
  - Timothee 15y ago
    I totally agree. I'm just imagining that one easy argument against that would be "well, we want to see them code, otherwise, how can we be sure?". To this, I answer that it may be true, but coding tests are no better in that regard, because they can be gamed very easily too. And, as you're saying, I would expect that showing and explaining what you've built would actually be much more useful and a much better proof of competence and culture fit.
ericHosick 15y ago
This is actually a really good interviewing technique. If you ask someone to talk about projects they have worked on and they don't talk your ear off then the person is probably not someone you would want to hire. Having to force a person to answer questions on projects they've worked on before is a hint that something is wrong. Many times, when this happens, their final answer is something like "Well, actually, I didn't code that. I just reported on it".
- kls 15y ago
  Right you get to their passion immediately and can figure out if they are just slinging code or if they really love what they are doing. If I have to choose between passion and skill, I will chose passion every time, due to the fact that unless they are completely incompetent they can pick up skills.
aaronblohowiak 15y ago
An afternoon pairing is a much richer test than bringing pre-made work to the table, as it more accurately simulates the fit.
- kls 15y ago
  While I think paring has some value, someone is not going to be productive in an environment that they just came into, tribal knowledge such as business intelligence has not set in and there are acronyms, business realities and other common knowledge elements that this person will be just exposed to and have to deal with. Some of that information is garnered over the course of months so depending on the problem domain, a single afternoon could tell you very little about the candidate. I contend that with today's reality (2.7% tech unemployment) that it is more expensive to accidentally pass on a good developer due to bad interviewing techniques than it is to hire a bad developer. A bad developer is spotted within a week on the job, a good developer can easily be passed over in an interview, it may be a long time before another good developer comes through the door. Especially considering that good developers usually have groups of peers, that probably will not interview with a company if they pass on one a peer that they respect.
  - gruseom 15y ago
    You've made at least a half dozen good points in this thread. I wish you'd write a longer piece on the topic and post it. This stuff is important, and you seem to be a bit ahead of the curve (or maybe it's just that I agree with you).
    - kls 15y ago
      I am passionate about the subject because, I used to be really bad at interviewing people. I took a lot of reflection on what I was doing wrong and to be honest some ego issues on my own part, when I was younger. When I started evaluation what I was doing wrong and what other people where doing right I started to see a common trends among those that are effective at hiring and a common trend among those that where complaining about talent. Once I started doing what the effective hiring managers where doing, I began to be able to spot true talent. I don't think I have misidentified talent since that realization, nor have I had a false positive. I thank you for the encouragement, and I have thought about putting together an article on the subject. I think the information is valuable and could be of use to a lot of people. I will see if I can free up some time to put one together.
greenEggsNHam 15y ago
I'm confident you're a solid coder, which is the same benefit of the doubt I give any interviewee I meet with. However, if you dismiss any opportunity that asks you to perform a test to exhibits your skills, then your process is fraught with false positives. Has it occurred to you that perhaps you might like the company/opportunity even though you're given an exam? You took the time to research the company and show up. It's too narrow at that point to give up simply b/c the interviewer wants to make sure that you truly are capable of performing the way you represent yourself on paper. Further, figuring out if a developers is good is actually not that simple. Again, perhaps finding out that YOU'RE a good coder is pretty simple b/c hey - you're a good coder and you can articulate your work well. But what if you weren't a good coder, and only a good talker? What about those who simply don't communicate as well due to language barriers? Coding tests are important from both perspectives. All I'm saying is that you have the right to decline any coding test you want, but you're painting too broad a stroke to determine that they're so terrible, and further you may be limiting your own opportunities.
- kls 15y ago
  then your process is fraught with false positives I contend that if you test me you will get a false negative. Becase you are testing me on what you think I should know which is a reflection of your strengths not mine. Has it occurred to you that perhaps you might like the company/opportunity even though you're given an exam? Yes it has, the problem is that I now belive that they don't know how to hire and I will be working with a group of people that know trivia but may not know how to deliver. As such it will fall on me to deliver becase their hiring process has not shown an ephisis on selecting people that can deliver. the interviewer wants to make sure that you truly are capable of performing the way you represent yourself on paper. I feel that, my and others capibilities are best reflected in what I have already done. We don't ask a other professionals to take test we look at their history and accomplishments. But what if you weren't a good coder, and only a good talker? A good talker can BS someone with no knowledge of the field. They are not going to be able to BS their way through an entire code base. A skilled technical person will catch on. I don't think companies that do test are terrible I just think their interview process is lacking as such it can leave me holding the bag with long hours becase they cannot identify other good talent. It's from experience that I have come to the conclusion that hireing via test is a useless filter, because at one point in time I was the worst offender. I used to use elite code trick questions, abstract questions and code tests and I found not only where they ineffective but I was actually driving the best individuals away, due to what they perceived as arrogance on the part of my orginizarion. Developers have little tolarance for things that seem inefficient and pointless. It took me a while to learn that lesson.

by kls 15y ago

Timothee 15y ago

You make a good point about the way a code test can change the "atmosphere" of an interview. Showing what you've built and explaining how you did it is also probably much closer to how you would collaborate if you were hired. Some might say that it would be too easy for someone to discuss code they haven't actually written, but it's also easy (as demonstrated recently on HN) to just practice common coding tests and pass. I haven't done many interviews for development jobs, so I don't know how common (if at all) it is to get "please bring with you something you've built to discuss it".

kls 15y ago
I always bring my laptop with me and try to steer the interview in that direction. The first thing I do is ask them if they would like to see something that I have built and offer to walk them through the code and the architecture. If someone does this on an interview, they would be hard pressed to BS their way through an entire application. There is just a level of detail that they will go into that, someone that is faking it cannot, generally you will get storied about the code, stuff like oh yeah, this routine was a pain because in IE when you add and remove an element from the DOM it destroys it in memory. That kind of battlefield cometary shows that they lived through the code and it comes out organically when you talk to someone about something that they have been part of.
- Timothee 15y ago
  I totally agree. I'm just imagining that one easy argument against that would be "well, we want to see them code, otherwise, how can we be sure?". To this, I answer that it may be true, but coding tests are no better in that regard, because they can be gamed very easily too. And, as you're saying, I would expect that showing and explaining what you've built would actually be much more useful and a much better proof of competence and culture fit.

ericHosick 15y ago

This is actually a really good interviewing technique. If you ask someone to talk about projects they have worked on and they don't talk your ear off then the person is probably not someone you would want to hire. Having to force a person to answer questions on projects they've worked on before is a hint that something is wrong. Many times, when this happens, their final answer is something like "Well, actually, I didn't code that. I just reported on it".

kls 15y ago
Right you get to their passion immediately and can figure out if they are just slinging code or if they really love what they are doing. If I have to choose between passion and skill, I will chose passion every time, due to the fact that unless they are completely incompetent they can pick up skills.

aaronblohowiak 15y ago

An afternoon pairing is a much richer test than bringing pre-made work to the table, as it more accurately simulates the fit.

kls 15y ago
While I think paring has some value, someone is not going to be productive in an environment that they just came into, tribal knowledge such as business intelligence has not set in and there are acronyms, business realities and other common knowledge elements that this person will be just exposed to and have to deal with. Some of that information is garnered over the course of months so depending on the problem domain, a single afternoon could tell you very little about the candidate. I contend that with today's reality (2.7% tech unemployment) that it is more expensive to accidentally pass on a good developer due to bad interviewing techniques than it is to hire a bad developer. A bad developer is spotted within a week on the job, a good developer can easily be passed over in an interview, it may be a long time before another good developer comes through the door. Especially considering that good developers usually have groups of peers, that probably will not interview with a company if they pass on one a peer that they respect.
- gruseom 15y ago
  You've made at least a half dozen good points in this thread. I wish you'd write a longer piece on the topic and post it. This stuff is important, and you seem to be a bit ahead of the curve (or maybe it's just that I agree with you).
  - kls 15y ago
    I am passionate about the subject because, I used to be really bad at interviewing people. I took a lot of reflection on what I was doing wrong and to be honest some ego issues on my own part, when I was younger. When I started evaluation what I was doing wrong and what other people where doing right I started to see a common trends among those that are effective at hiring and a common trend among those that where complaining about talent. Once I started doing what the effective hiring managers where doing, I began to be able to spot true talent. I don't think I have misidentified talent since that realization, nor have I had a false positive. I thank you for the encouragement, and I have thought about putting together an article on the subject. I think the information is valuable and could be of use to a lot of people. I will see if I can free up some time to put one together.

greenEggsNHam 15y ago

I'm confident you're a solid coder, which is the same benefit of the doubt I give any interviewee I meet with. However, if you dismiss any opportunity that asks you to perform a test to exhibits your skills, then your process is fraught with false positives. Has it occurred to you that perhaps you might like the company/opportunity even though you're given an exam? You took the time to research the company and show up. It's too narrow at that point to give up simply b/c the interviewer wants to make sure that you truly are capable of performing the way you represent yourself on paper. Further, figuring out if a developers is good is actually not that simple. Again, perhaps finding out that YOU'RE a good coder is pretty simple b/c hey - you're a good coder and you can articulate your work well. But what if you weren't a good coder, and only a good talker? What about those who simply don't communicate as well due to language barriers? Coding tests are important from both perspectives. All I'm saying is that you have the right to decline any coding test you want, but you're painting too broad a stroke to determine that they're so terrible, and further you may be limiting your own opportunities.

kls 15y ago
then your process is fraught with false positives I contend that if you test me you will get a false negative. Becase you are testing me on what you think I should know which is a reflection of your strengths not mine. Has it occurred to you that perhaps you might like the company/opportunity even though you're given an exam? Yes it has, the problem is that I now belive that they don't know how to hire and I will be working with a group of people that know trivia but may not know how to deliver. As such it will fall on me to deliver becase their hiring process has not shown an ephisis on selecting people that can deliver. the interviewer wants to make sure that you truly are capable of performing the way you represent yourself on paper. I feel that, my and others capibilities are best reflected in what I have already done. We don't ask a other professionals to take test we look at their history and accomplishments. But what if you weren't a good coder, and only a good talker? A good talker can BS someone with no knowledge of the field. They are not going to be able to BS their way through an entire code base. A skilled technical person will catch on. I don't think companies that do test are terrible I just think their interview process is lacking as such it can leave me holding the bag with long hours becase they cannot identify other good talent. It's from experience that I have come to the conclusion that hireing via test is a useless filter, because at one point in time I was the worst offender. I used to use elite code trick questions, abstract questions and code tests and I found not only where they ineffective but I was actually driving the best individuals away, due to what they perceived as arrogance on the part of my orginizarion. Developers have little tolarance for things that seem inefficient and pointless. It took me a while to learn that lesson.