4 ms·

A lot of developers, myself included, do not perform well under a microscope. They almost can't even type when someone is watching them, making stupid mistakes

A lot of developers, myself included, do not perform well under a microscope. They almost can't even type when someone is watching them, making stupid mistakes and blanking on simple concepts. Luckily, the vast majority of programmers don't have to code under this kind of pressure on a daily basis. I find the most effective way to get a good sense of how someone can code is to give them homework to do that they can bring to the interview and discuss. That way they can take their time, put their best foot forward, and it won't weed out introverts or people with test or social anxiety.

lawl 12y ago
I think I usually noticed when someone felt uneasy, so I left the room for a few minutes. Test anxiety might be really bad for some people, I know. But if it's that bad that they can't explain to me how to check if "n mod m == 0" then I think there are usually deeper underlying problems in their programming ability. And if it was really just anxiety, I'm sorry I'd rather have a false negative than hiring them. I tried homework, it didn't really work that well for me, people would google and copy paste stuff and invest way too much time, in the end they couldn't explain what they did and it was just a waste of time for both parties. The other problem is that I usually let people work with whatever language/frameworks their familiar with. I ended up beeing not familiar with some C# stuff they used and couldn't really judge their code. Fizzbuzz is simple enough that you can see if it looks right in pretty much any language And it's done in 5 minutes even if that means accepting a few false positives. Oh and, we had I few people where I noticed that they were really nervous and I thought maybe that's why they failed Fizzbuzz, so I invited them in for half a day and gave them a toy project to implement. Usually something really simple like, fetch this RSS Feed, parse it, save it somewhere, make sure that if you fetch it multiple times it doesn't save duplicate entries, and spit out the titles and URL's to stdout or a webpage or anything. A relatively real world exercise I think, nobody was constantly watching them, it was just a "get it done" job, they had internet, their own IDE, their language of choice and everything (a few people complained that they can't implement FizzBuzz without an IDE). And all of them failed. Hard. So I ended up not doing that anymore and treat a failed FizzBuzz as a K.O. criteria.
j2bax 12y ago
This is precisely what we do when hiring at our web dev/game/app agency. We have a somewhat casual meeting to first determine if the candidate is the type of person we'd want to work with every day and then we give them a challenge to take home with them. We provide a direct line to one of our developers that fulfills a similar role to what we are hiring for and encourage them to ask questions as they are completing the challenge. It's a very telling process. We are a very collaborative team and expect people to ask questions and grow together. When candidates ask questions that would be really easily answered by a quick Google search, or take far longer to complete the challenge than it should take someone who even sort of knows what they are doing, these are major red flags. At the end we review their code and see if their solutions are well thought out and up to basic standards. I should mention the challenge is typically extremely simple... Some candidates don't make it a priority and make excuses for days or weeks on end why they aren't finished. These don't tend to be the type of people we like to hire.

lawl 12y ago

I think I usually noticed when someone felt uneasy, so I left the room for a few minutes. Test anxiety might be really bad for some people, I know. But if it's that bad that they can't explain to me how to check if "n mod m == 0" then I think there are usually deeper underlying problems in their programming ability. And if it was really just anxiety, I'm sorry I'd rather have a false negative than hiring them. I tried homework, it didn't really work that well for me, people would google and copy paste stuff and invest way too much time, in the end they couldn't explain what they did and it was just a waste of time for both parties. The other problem is that I usually let people work with whatever language/frameworks their familiar with. I ended up beeing not familiar with some C# stuff they used and couldn't really judge their code. Fizzbuzz is simple enough that you can see if it looks right in pretty much any language And it's done in 5 minutes even if that means accepting a few false positives. Oh and, we had I few people where I noticed that they were really nervous and I thought maybe that's why they failed Fizzbuzz, so I invited them in for half a day and gave them a toy project to implement. Usually something really simple like, fetch this RSS Feed, parse it, save it somewhere, make sure that if you fetch it multiple times it doesn't save duplicate entries, and spit out the titles and URL's to stdout or a webpage or anything. A relatively real world exercise I think, nobody was constantly watching them, it was just a "get it done" job, they had internet, their own IDE, their language of choice and everything (a few people complained that they can't implement FizzBuzz without an IDE). And all of them failed. Hard. So I ended up not doing that anymore and treat a failed FizzBuzz as a K.O. criteria.

j2bax 12y ago

This is precisely what we do when hiring at our web dev/game/app agency. We have a somewhat casual meeting to first determine if the candidate is the type of person we'd want to work with every day and then we give them a challenge to take home with them. We provide a direct line to one of our developers that fulfills a similar role to what we are hiring for and encourage them to ask questions as they are completing the challenge. It's a very telling process. We are a very collaborative team and expect people to ask questions and grow together. When candidates ask questions that would be really easily answered by a quick Google search, or take far longer to complete the challenge than it should take someone who even sort of knows what they are doing, these are major red flags. At the end we review their code and see if their solutions are well thought out and up to basic standards. I should mention the challenge is typically extremely simple... Some candidates don't make it a priority and make excuses for days or weeks on end why they aren't finished. These don't tend to be the type of people we like to hire.