Hiring Developers: You're Doing It Wrong

Post by ericd » Wed, Mar 30, 2011, 7:44 AM UTC

georgieporgie wrote: post #96

tptacek wrote: post #48

Earlier quoted context omitted.

Virtually all employment in the US is at will, meaning you are continually on "probation". The difference between a contractor and an FT is that the contractor is 1099'd, pays both halves of FICA taxes, and isn't provided health insurance; more importantly, when the employer is as overt about the issue as "not hiring you full time", there's no implied social contract or norm ensuring you'll even end up getting the jo…

Contractors make significantly more money than full time devs partly for this reason I've always heard that, yet when I look for contract work, it's always at equivalent or less than my hourly equivalent as a full-time dev. Full time was $100k - $115k/yr, contract was $40 - $50/hr, in the SF Bay Area.

Post by mavelikara » Wed, Mar 30, 2011, 7:55 AM UTC

zlopid wrote: post #47

michaelchisari wrote: post #27

Despite having written tens of thousands of lines of open source code, I have yet to have an interviewer who has looked at that code and asked me about it.

Whenever I see a resume with open source code, I always visit and try to read some of their code. I rarely ask them about it (there's little time), but it does inform which questions I want to ask in the interview and my overall impression of their skills.

Post by mavelikara » Wed, Mar 30, 2011, 8:10 AM UTC

swampthing wrote: post #63

tptacek wrote: post #59

Earlier quoted context omitted.

I want the one that makes FT offers, because I don't believe that the best programmers, who can write their own ticket in this business climate, would put up with this contracting bullshit. This approach to hiring is a cop-out. It says, "we don't know how to hire properly, so we're going to push the risk onto the candidates".

I've seen the contracts with my own eyes. But I guess I can't prove that the developers in question were good without divulging names. Anyways, I don't see why this is a cop-out any more than any other hiring procedure. No company has anywhere near a 100% success rate - this procedure acknowledges the shortcomings of a traditional interview process (namely that succeeding on an interview and succeeding as a developer…

Post by ulrich » Wed, Mar 30, 2011, 8:14 AM UTC

sp_ wrote: post #22

I worked for a German startup too and our main problem was not vetting interviewees but finding people who want to interview at all. In the five year history of the company I think only one single person was hired who was not already friends with someone at the company. Other people just never applied. I remember manning the booth at one of those college campus events and it was very lonely. I probably talked to thre…

Post by adrianN » Wed, Mar 30, 2011, 8:28 AM UTC

bugsy wrote: post #80

MichaelGG wrote: post #33

Writing code is just another type of conversation. Sure, you're going to ask many questions. Having a candidate code a bit in front of you, going back and forth, provides a lot of info. As far as "CS puzzles" - binary search, trees, linked lists, hashtables, etc: None of those should be puzzles. If you're giving interviews that people can "memorize" an answer to, then the problem is how you're doing the interview. A…

Do you actually find people that expect candidates to implement quicksort? I've certainly implemented it, but there's no way I have it memorized, it's not an obvious algorithm at all. I'd be flabbergasted to be asked to implement it from memory with no warning. It seems clear to me that one would be testing for if the person happened to have looked at the algorithm recently, not if they were competent.