I am completely against written tests or questions that ask abstract questions and ask you to write algorithms. Unless you're going for a position that requires a PhD in computer science and your job will be writing algorithms and solving overly complex problems, the pen and whiteboard approach just doesn't work in 2013.
Hiring a developer shouldn't be as complicated as some companies make it out to be. Maybe for the likes of Google it has to be a lot more complex than others because they have an image and large workforce that depends on people being excellent self-managers and workers that require minimal management.
For smaller companies you are wasting your time and my time asking me questions that test my ability to remember things more-so than they do to search and find answers. Lets face it, most developers these days are hackers. I've never met a developer who knows the answer to everything, I've seen the best of the best using Stackoverflow to find an answer to their question.
The difference between a good developer and a great developer is knowing a little and for the stuff you don't know, knowing exactly what to Google when you encounter a problem you can't solve off of the top of your head. As Albert Einstein famously said, "Never Memorize What You Can Look Up in a Book" — that doesn't mean don't learn anything, but get the basics down and eventually you'll know what to Google when you don't know something.
The real test of any developer is if they're a good fit for your team, have good work ethic and can get the job done. You can find the smartest developer in the world but they might not be a good fit for your team. Culture matters as does a good work environment with compatible people.
The best way to test a developer anywhere in the world is to give them access to a computer, an IDE and their environment of choice. Then ask them to build you something. Don't ask them to write binary search code if they're being interviewed for a front-end position, ask them to build something.
Welcome to your interview; build us a blog, build us a todo app, write a simple Wordpress plugin, write a jQuery plugin or what my current employer did: they brought me in for a trial for a couple of days (paid) and asked me to get my hands dirty on a real project they were currently working on. Just threw me in the deep end and after two days they had a good idea how I worked and if I was a fit.
> they brought me in for a trial for a couple of days (paid)
How does this work? Did you not have a job at the time? If you did, there are more often than not legal issues involved, depending on the terms of your current employment. This comes up a lot, but I don't understand how it works from a legal standpoint.
The other issue, of course, is that a good developer doesn't have to put up with that, so why would they? I did it once, looking for a job out of college, but never again. If the "interview" is going to cost me more than a couple of hours, then I will work somewhere that knows how to make a decision.
I never had a job at the time when I took the trial. I had just finished a contract position with a media company and was looking for a permanent position with a smaller studio.
> Don't ask them to write binary search code if they're being interviewed for a front-end position, ask them to build something.
+1!
Thanks for the thoughtful response; I really love the way you worded this.
I agree with what you're saying; the best, most fun, challenging and fair interviews I've had have been at small companies coding side by side with somone. I wonder if it's possible to scale the "build-it" interview up to a google sized org.
Another idea I've been mulling around is hiring people for an N month contract position where you get to work with them. If at the end, both parties agree its a good fit, then proceed. I can see a lot of pit falls to this approach, but it might work really well for people with strong referrals.
Definitely. Seeing how someone handles a real project, a real challenge with real consequences and timelines is arguably the better way to do it. To find the good candidates you still need to weed out the bad ones, but it's not hard to see who is the real deal by just sitting down and having a chat with them.
When I worked for the ABC here in Australia for a short contract position there was a room of about 10 people from different teams (designers, journalists, developers, managers) and each of them had a copy of my resume. They asked questions based off of what I put on my C.V to see if my answers matched. I thought that was brilliant, ask questions to see if your answers matched and if you were the real deal.
I reckon a spoken interview where you get to know the person and ask them a bit about their experience (not ask them to solve problems) will get you 85% of the way and the other 15% is if they can handle the pressure of the workplace and work well with the team. A few trial hours (unpaid) where you bring in your candidates, sit them down with your team and see how they handle things would definitely go a long way and cost nothing.
Seems I have struck a chord with someone who down-voted me. Would that person care to elaborate?
I bet you whoever downvoted you did so because you suggested candidates should work unpaid hours
That's ridiculous, and kind of offensive
And it's a great way to scare away the best candidates who will have several offers lined up and skip working for free
I think it's more than fair to ask someone to come in for a couple of hours and see how they work. How is it any different from companies that sit you down and give you tests that can go on for hours unpaid anyway? Think of it as an interview, two hours is not unreasonable unless you're afraid you won't be good enough.
Once again some people on HN take things to heart way too easily. You can't voice an opinion on something without someone taking it the wrong way or personally.
> .... if they're a good fit for your team, have good work ethic and can get the job done.
I'd modify that last to "and can get the job done well". Most of my co-workers have been fantastic, but there have been one or two who absolutely got the job done... in ways that eventually cost so much dev time (on maintenance / refactoring) that it would have been better to have someone else build the thing in the first place.
(Which is also presumably easier to discover from sample work than from a whiteboard interview. :)
Hiring a developer shouldn't be as complicated as some companies make it out to be. Maybe for the likes of Google it has to be a lot more complex than others because they have an image and large workforce that depends on people being excellent self-managers and workers that require minimal management.
For smaller companies you are wasting your time and my time asking me questions that test my ability to remember things more-so than they do to search and find answers. Lets face it, most developers these days are hackers. I've never met a developer who knows the answer to everything, I've seen the best of the best using Stackoverflow to find an answer to their question.
The difference between a good developer and a great developer is knowing a little and for the stuff you don't know, knowing exactly what to Google when you encounter a problem you can't solve off of the top of your head. As Albert Einstein famously said, "Never Memorize What You Can Look Up in a Book" — that doesn't mean don't learn anything, but get the basics down and eventually you'll know what to Google when you don't know something.
The real test of any developer is if they're a good fit for your team, have good work ethic and can get the job done. You can find the smartest developer in the world but they might not be a good fit for your team. Culture matters as does a good work environment with compatible people.
The best way to test a developer anywhere in the world is to give them access to a computer, an IDE and their environment of choice. Then ask them to build you something. Don't ask them to write binary search code if they're being interviewed for a front-end position, ask them to build something.
Welcome to your interview; build us a blog, build us a todo app, write a simple Wordpress plugin, write a jQuery plugin or what my current employer did: they brought me in for a trial for a couple of days (paid) and asked me to get my hands dirty on a real project they were currently working on. Just threw me in the deep end and after two days they had a good idea how I worked and if I was a fit.