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.
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.
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.
They are not going to be able to BS their way through an entire code base.
The problem is that a large number of coders out there simply do not have a project they can show an interviewer. This can be for a number of reasons such as only programming at work or not having much free time. The fact a coder has a project to walk someone through does not imply they are a good coder, so why would a company tailor their interview process to the minority of interview candidates out there who do have a sizable project they can demo?
When I sign up with a company I always get the stipulation that I can use the code for demonstration purposes, that the code will never leave my machine but that I can use it for demonstration purposes. Short of working on some top secret project I would not agree to anything else, not being able to show previous work in this industry is like an artist not being able to show commercial work as their portfolio.
The fact a coder has a project to walk someone through does not imply they are a good coder
No but it is an indication of their work, because it is sitting right there in front of you. Just because they have a project does not mean that it is good, but that is up to the interviewer to decide. If you can look at the code base, then the interviewer should be able to determine if it is well built or not. If they cannot, then I would question whether they should be the one conducting the interview.
so why would a company tailor their interview process to the minority of interview candidates out there who do have a sizable project they can demo
I personally feel that someone looking for a senior developer role should have something that they can demo, they have been in the business for 5 to 10 years, there should be something that they can run on their machine to demonstrate their abilities. Now for a junior developer, I agree they may not have something to demo, but for a junior role I assume a blank slate and look for totally different values. Specifically I look for passion and eagerness to learn, again a test is not going to tell me that.
Good point doing the fancy stuff is easy making it work 24/7 and do all the nasty fiddly little bits you gloss over is the hard stuff.
You want to be sure the figures add up when you do your first million pound month when the CTO (i think that Vint was his boss at the time) nudges you and says "this had better be right or we are both out of a job"
of course this was back 1983 so that is say $4,250,000 in today's money.
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".
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.
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".
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.
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.
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.
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).
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.
Thanks, I have dyslexia so that would be a great help, it is one of the reasons that I am hesitant to write articles and one of the reasons I post prolifically, writing is a challenge that I must always exercise to keep my ability to do so.
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.