On a related note, when hiring, I often get candidates describe themselves as very motivated, love learning new things, give out their 100% on every task, etc.. Most of them never bother to finish and reply on a simple coding task I send as an initial screening.
So yeah, filler BS goes both ways.
(PS. Coding tasks in prescreening are contentunous topic. My
POV: if you don't have open source "portfolio" I can look at, and if you can't be bothered to spend an hour to potentially save both of us from a couple hours on an interview day, I don't want to talk to you anyway).
If the coding task wouldn't take longer than a preliminary interview, I can't see what's controversial about it? If you want to make sure, that no poor slob is putting in days, just make it a timed task. I.e. hand in whatever you have an hour after you've got the problem.
I can see that being asked to code for days is a no-no for prescreening.
Some people do take the piss a little with their coding task requests, but an hour isn't too bad. I do appreciate when someone is willing to look at code I've written beforehand, though - at the end of the day, even if you're being quite focused with your job hunt, if every application took an hour it'd really limit how many you could do.
When I was looking for my last job I rejected a company based on the simplicity of it's code task. A company's code task should interest and challenge. View helpers satisfy neither requirement (for me).
I disagree, and cite fizzbuzz. There are so many programming candidates who can't even answer a simple problem like fizzbuzz that it prunes out a good number of candidates by asking a simple question like that. Not every step in an interview is intended to meet the same goals, e.g. your coding question could have easily been a quick pruning method versus saying anything about what sort of work is being done there.
Comments
On a related note, when hiring, I often get candidates describe themselves as very motivated, love learning new things, give out their 100% on every task, etc.. Most of them never bother to finish and reply on a simple coding task I send as an initial screening.
So yeah, filler BS goes both ways.
(PS. Coding tasks in prescreening are contentunous topic. My POV: if you don't have open source "portfolio" I can look at, and if you can't be bothered to spend an hour to potentially save both of us from a couple hours on an interview day, I don't want to talk to you anyway).
If the coding task wouldn't take longer than a preliminary interview, I can't see what's controversial about it? If you want to make sure, that no poor slob is putting in days, just make it a timed task. I.e. hand in whatever you have an hour after you've got the problem.
I can see that being asked to code for days is a no-no for prescreening.
Some people do take the piss a little with their coding task requests, but an hour isn't too bad. I do appreciate when someone is willing to look at code I've written beforehand, though - at the end of the day, even if you're being quite focused with your job hunt, if every application took an hour it'd really limit how many you could do.
When I was looking for my last job I rejected a company based on the simplicity of it's code task. A company's code task should interest and challenge. View helpers satisfy neither requirement (for me).
I disagree, and cite fizzbuzz. There are so many programming candidates who can't even answer a simple problem like fizzbuzz that it prunes out a good number of candidates by asking a simple question like that. Not every step in an interview is intended to meet the same goals, e.g. your coding question could have easily been a quick pruning method versus saying anything about what sort of work is being done there.