Live data from Hacker News

Hiring Developers: You're Doing It Wrong

devinterviews.pen.io

71–80 of 230 posts

Re: Hiring Developers: You're Doing It Wrong

#71
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…

Try looking at it a different way - assume, you will have a full time job at either of these prospective employers. Do you want the one that makes FT offers immediately, or the one that makes them only after testing new people out for 3 months?

I'd take the one that makes full-time offers immediately in a heartbeat, because I wouldn't trust the company that does the 3-month, no-benefits contracting "test".

Going to work for a company with employees of varying skill is no big deal; every company above a certain size has people who probably shouldn't have been hired. Going to work for a company with shady management, however, is a deal-breaker.

Re: Hiring Developers: You're Doing It Wrong

#72
I get a really good insight in the candidate's programming skills by pair-programming a simple problem with them. For TDD, I write a test and ask him / her to write the code to make it pass (then repeat, refactor). That way, I can see how fluent they are in the programming language, at the same time evaluate their problem solving skills and see how they work in a team.

Re: Hiring Developers: You're Doing It Wrong

#73

When I hire a developer, I ask him about the scene in 'The Social Network' with the Winklevoss twins, and ask if he knew Armie Hammer's face was CG'ed to another actors body. Depending on his answer, I know right there whether to end the phone interview, or fly him to the Valley so I can see him write code on a whiteboard.

I guarantee with that hiring process, that you will not want to work with me. Given your interview process, the feeling is likely to be mutual.

(I don't watch TV or most movies, haven't seen The Social Network, and have no interest in doing so. If that is what you value, then I'm going to be a poor fit from both sides.)

Re: Hiring Developers: You're Doing It Wrong

#74

The only hiring process I have found to work for developers is to sit down and work on real code together. This gets to the heart of the matter, and you very quickly feel out someone's knowledge, ability, and most importantly, how well they collaborate on a problem. Because in a startup you will need collaboration, and likely under the highest stress moments you've seen in your life. I also feel like this gives appli…

I wonder if you could give them access to a custom subdomain of a test site and tell them to build a web app, anything they want, and upload it. Give a suitable time limit, a day to a week, depending on how much you want to see and whether they already are a full-time employee or student. Then screen based on what people came up with.

That's a bit more involved than the lighter-weight solution in the same vein - remote coding tests facilitated by a collaborative website. But it's something I haven't heard of yet.

Re: Hiring Developers: You're Doing It Wrong

#75

While at my last job I was tasked with being apart of the interview process. My favorite question was "how do you keep up with web technology and trends? (web development)" and I was surprised at how many people had no answer for that simple question. My response to my manager was "this dude wont work"

My answer to that one would be "I've found it's more efficient to not keep up with the latest fads."

Re: Hiring Developers: You're Doing It Wrong

#76
post #49
post #40

Earlier quoted context omitted.

I don't know if it's the same everywhere, but a 90-day "probationary" period is absolutely commonplace in the USA. Not sure I see much difference.

Out here in SV it is almost unheard of; if someone is not working out after 90 or 180 or 365 days you drop them and move on. It is definitely a sellers market for talent here and anyone who is worthwhile enough to make an offer to is not going to put with an explicit probationary period (since everyone is a at-will employee and general non-competes are worthless the concept is pretty much a moot point anyway...)

The advantage of the contract with a specific project is two fold:

1) It makes it very easy for either party to end the relationship in a natural and simple way. Minimal hurt feelings/embarrassment/harm to morale, etc.

2) The project is at least semi-isolated so it's very clear how skilled the person is. They don't get lost in some "training" mode as a new hire spending 6 months "ramping up" on the primary codebase. They (hopefully) get an early win and earn respect and confidence from the beginning.

Re: Hiring Developers: You're Doing It Wrong

#78
post #69
post #32

Earlier quoted context omitted.

Someone who opts-in to #3 is not necessarily desperate. In fact, to the contrary, they likely also want an opportunity to feel the company out and be more confident in their choice to stay/leave at the end of 3mo.

That "opportunity" is not worth having no company-provided health insurance, nor is it worth paying both halves of the FICA tax, except for the desperate.

Because it's impossible to pay someone at a higher hourly rate than they would be paid as a full-time employee?

Re: Hiring Developers: You're Doing It Wrong

#79

While at my last job I was tasked with being apart of the interview process. My favorite question was "how do you keep up with web technology and trends? (web development)" and I was surprised at how many people had no answer for that simple question. My response to my manager was "this dude wont work"

I don't know, I feel like I might be reticent about admitting exactly how much time I've wasted on HN and /r/programming.

Re: Hiring Developers: You're Doing It Wrong

#80

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.

Post reply on HN