Now, if you were signalling to them that googling a solution is the extent of your programming ability, then perhaps you were doing them a favor.
Now, if you were signalling to them that googling a solution is the extent of your programming ability, then perhaps you were doing them a favor.
And if I follow your trail of thought, then I hope you're not using stackoverflow when you do your job, because that means you are relying on others to solve a problem for you. Does your boss know about this?
I wonder how many times you copy-pasted anything.
And just for your information I still provided a second solution for them after they frown back the first one.
But hey, sorry if I think solving a problem doesn't mean I have to write everything from scratch.
I was wrong, I moved on, so did they.
If I would have a similar test today I wouldn't go down the same route, because I know what they would expect.
Maybe it was my sysadmin past talking back then. Trying to find a good existing solution for the problem.
And there is the part 'may be a cool job'. Sometimes that part is a lie.
Yes come to us and you will be working with the newest tech and learn new things...
Oh did we forgot to mention we use CVS, Java 1.6 and Expoler 8? You want to use something else? No can't do sweety.
Mechanic: gets out the yellow pages and calls a real mechanic.
Me: ok I'll hire that guy you just called
They're not hiring someone to search. They're hiring someone to code. You proved you could search but not that you could code
Mechanic: "Yes, of course!" - he gets up and collects loads of bits and pieces, metal bars and stuff, then starts to hammer away to create a car part.
Me: "What the hell are you doing?"
Mechanic: "I'm building the part for your car."
Me: "Don't you have a spare or something?"
Mechanic: "Well I don't, but there are spares I could order."
Me: "Then do it man, order one."
Mechanic: "Nah, I like to build everything by myself."
Anyway, using an API doesn't mean you don't have to code.
I was wrong, I learned, next time will be different.
At work we've stopped doing take away tests in part for just this reason. We do have a small pair programming test (fix some SOLID code smells in a small 10 line program) and we also don't expect folks to fix all of the problems within that code.
As a pair programming exercise you can almost walk someone through the first problem with the code (there are two big problems[2] plus four minor issues that you could find) and also you can guide the scale of the response they have to the issues (For example I might prompt them and say if you use mocking frameworks in your current job lets use that and you can talk me through how to use it)
We've had pretty good success with this and does seem to avoid some of talks a good talk but can't do developers.
[1] Getting the library onto the interviewers machine might be a really big issue their firewall might block access / maybe I can't send binaries to you due to your AV
[2] Since it's only 10 lines of code the issues are the sort of thing in the "real" world you might ignore but repeated across a code base would be a problem.
When hiring someone with "fabrication skills" into a machine shop, you certainly don't expect them to order a part during the interview when you just asked them to make a part on the lathe. Which position are you interviewing for, machinist or administrator/purchasing?
This is a common interview tactic: trying to figure out if someone belongs to a group known to have particular skills by their choice of words or similar.