4 ms·
This ignores a lot of the details of the real world: > Because you should have enough public examples of your work avalaible for your potential employer to eva
by pbiggar 14y ago
This ignores a lot of the details of the real world:
> Because you should have enough public examples of your work avalaible for your potential employer to evaluate. If you don’t, for whatever reason, then take yourself a little more seriously and get some public stuff out there.
Many people don't have this. And why would they: it's hard to evaluate a candidate via bits of random code and half finished projects which took their fancy, that they worked on on their own.
> Employers … you ask for spec work when you are incapable of evaluating a candidate based on interviews and existing work.
That's right. It's fucking impossible to evaluate someone based on an interview (there have been hundreds of posts to HN on this topic in the last few years). Existing work is hit-and-miss.
I personally feel that spec work is the only way to seriously evaluate people, with the caveat that _we pay for it_. If you're serious about interviewing this person, paying their day rate for a day of their time is a reasonable way to ask people to do this.
- stevoyoung 14y ago>"Many people don't have this. And why would they: it's hard to evaluate a candidate via bits of random code and half finished projects which took their fancy, that they worked on on their own." I do agree with everything here except "why would they". I have tons of old, unfinished, half baked code /designs lying around. I wouldn't show any of it to a future employer. What I would show them is something that I took real time and effort to do. Often time that's something for my self, an open source contribution or refactoring a side project to make it "usable". This takes a lot of time. But if you ever want to be in the position of choosing who you work for this is needed. That's all that I'm suggesting. The alternative is 6+ hours of spec work for every job you want to get. Which is mostly not reusable because it's company specific. >"That's right. It's fucking impossible to evaluate someone based on an interview (there have been hundreds of posts to HN on this topic in the last few years). Existing work is hit-and-miss." I mostly agree. I think multiple interviews with multiple people and talking through problems and design/development problems can greatly reduce the gap of it being hit-and-miss. I'm also not suggesting this is cheap to do (for both employee and employer). But hiring someone or starting a new job should require a lot of investment on both sides. > " ...with the caveat that _we pay for it_. If you're serious about interviewing this person, paying their day rate for a day of their time is a reasonable way to ask people to do this." I wish more folks did this. You obviously take hiring seriously. I bet you have many sold folks at your place.
- pbiggar 14y ago> You obviously take hiring seriously. I bet you have many sold folks at your place. Very much. It's easy to get burned. We're young so we just have one employee, but we paid him 8 hours work to do a small project, because we wanted to see what he could do in 8 hours. It was great so we hired him. > Often time that's something for my self, an open source contribution or refactoring a side project to make it "usable". I don't find this to be terribly valuable, personally. Its great to see that you can pick up a strange project and quickly make a valuable contribution, but it says very little about whether you're a good coder. > if you ever want to be in the position of choosing who you work for this is needed I disagree. To do this you need to be a great coder/designer, and there are many ways to demonstrate this. Lots of open source is a good way, but a small amount of open source, or just a couple of side projects you worked alone on, isn't a great way, IMO.