Live data from Hacker News

How to Decide if a New Hire Will Be a Team Player in the Interview

linkedin.com

41–50 of 57 posts

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#41
post #27

Earlier quoted context omitted.

Or how about those potentially-excellent candidates who don't have children but just have a life? I love my job. I love writing code. I am passionate about it. The time I spend at work I mostly enjoy, but 40 hours a week is enough for me. I would rather spend the rest of my time with the people I love or on other ventures that don't involve sitting in front of a screen. If you don't want to hire me because my job isn…

Never seen that. All people I know who love programming even find time to do their own stuff on a 60 hour schedule.

I love programming, but I love my hobbies (e.g., film and video preservation) A LOT more.

I don't love programming enough to devote time outside of my 40 hours/week to it.

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#42

If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire. Anything less is a guess. Every team is different, every need is different and every candidate's experience is different. Assuming you can ask a magical question or two and know is the realm of psychics.

> If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire The difficulty here is that no one who is even mediocre would ever do a "contract to hire". If they are good they have options and there just isn't any upside to doing a contract for hire when you can take another full time job. Contract for hire is a big red flag!

Not necessarily true, automattic (makers of wordpress) does this[1]

[1] http://automattic.com/work-with-us/

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#43

If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire. Anything less is a guess. Every team is different, every need is different and every candidate's experience is different. Assuming you can ask a magical question or two and know is the realm of psychics.

> If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire The difficulty here is that no one who is even mediocre would ever do a "contract to hire". If they are good they have options and there just isn't any upside to doing a contract for hire when you can take another full time job. Contract for hire is a big red flag!

Maybe in SV it is, but out here in the regular world it's not the uncommon. My current job was contract to hire at a slightly higher rate. I was converted after 4 months. This way both sides were happy with the work environment. In SV there are too many jobs and not enough people so it might be harder to get anyone to do this. But contract works both ways - the prospective employee gets to see if they like the team too. I've taken jobs before direct where the team turned out to be completely evil but it wasn't obvious in the interview.

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#44

Earlier quoted context omitted.

> The difficulty here is that no one who is even mediocre would ever do a "contract to hire". this is absolutely not true. good people will simply demand a high hourly billing rate during the contract phase to compensate for the opportunity cost, which you have to be prepared to pay. sure if you're dicking around with $20/hr "contracts" everyone decent will tell you to kick rocks. have you ever worked with people who…

I think we're going to have to disagree here. > have you ever worked with people who are used to getting paid $100+/hr? i.e. top people? it doesn't sound like it. I saw this and wondered if you were trolling. It's certainly a rude and undeserved comment, but I'll be charitable and bite:) My main point is that "good" developers, always have options. My assumptions: 1) the developer wants full time work, otherwise they…

Done right, contract-to-hire seems like a great solution to me. It's actually a chance for the employer and employee to get to know each other and make sure their mutual expectations match.

Assuming the position were to be salaried at $104k, a sensible agreement might be: - The employee is hired temporarily for a period of one to three months. - Their wage is paid weekly, at a rate of $2k per week (i.e. 1/52 of their expected salary) - The contract may be cancelled by either party with seven days' notice. - At its end, the contract automatically converts to a permanent position.

If a signing bonus is called for, it should be due early during the probationary period. A separate bonus for the transition from temporary to permanent employment may not be a great idea as it may incentivize the employer to terminate the agreement.

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#45

If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire. Anything less is a guess. Every team is different, every need is different and every candidate's experience is different. Assuming you can ask a magical question or two and know is the realm of psychics.

> If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire The difficulty here is that no one who is even mediocre would ever do a "contract to hire". If they are good they have options and there just isn't any upside to doing a contract for hire when you can take another full time job. Contract for hire is a big red flag!

The difficulty here is that no one who is even mediocre would ever do a "contract to hire".

I would, but at a real consulting rate (over $150 per hour) and not at a salary rate, since it comes with none of the benefits of being salaried.

That kind of arrangement is going to lead to adverse selection in the end. At typical tech salaries, you'd be asking me to take a 50% pay cut for (not much) additional job security. The main upshot of being FT (aside from benefits but those don't merit a 50% pay cut) is that it takes ~30-60 days to fire someone without severance. For contractors, they don't have to do that PIP bullshit. But I prefer to plan my career based on upside, not job security/what happens if I'm fired.

The rate at which I'd take a contract-to-hire gig is one at which I wouldn't happily convert to full-time, unless there were a huge promotion in the mix. The people who would convert without a big promotion are the ones you don't want, because they plan on coasting.

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#46
post #44

Earlier quoted context omitted.

I think we're going to have to disagree here. > have you ever worked with people who are used to getting paid $100+/hr? i.e. top people? it doesn't sound like it. I saw this and wondered if you were trolling. It's certainly a rude and undeserved comment, but I'll be charitable and bite:) My main point is that "good" developers, always have options. My assumptions: 1) the developer wants full time work, otherwise they…

Done right, contract-to-hire seems like a great solution to me. It's actually a chance for the employer and employee to get to know each other and make sure their mutual expectations match. Assuming the position were to be salaried at $104k, a sensible agreement might be: - The employee is hired temporarily for a period of one to three months. - Their wage is paid weekly, at a rate of $2k per week (i.e. 1/52 of their…

That's the issue. A job explicitly labeled "contract to hire" is never done right. No good developer is going to do contract to hire at 1/52 of the salary, because they already either make an equivalent salary or far more as a contractor. The company isn't going to pay an actual contracting rate, because they are either cheap or can't afford it. Contract to hire is almost exclusively done in places where it's hard for a developer to find a good job and it's used to take advantage of this situation.

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#47
post #23

Why do they have to be? Just because a person isn't 100% 'team player' material doesn't mean they are not capable of massive step-change contributions to a team activity. If you hire all 'team players' or all PhDs or all men or all people who have been successful in their lives you are likely to have a team that has less capability than one that has some diversity. Unless you're just building a production line - in w…

"Team player" is code for the middling level of ambition (MacLeod Clueless). Not a disengaged doesn't-give-a-shit clock-puncher, but not attuned/savvy enough to focus only on projects conferring personal career benefit.

It has little to do with whether one actually works well in a team. It's just a codeword for something that's hard to describe and somewhat socially unacceptable (a middling level of ambition that only exists in fresh college grads who haven't figured out who they are yet) to want.

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#48

Earlier quoted context omitted.

> If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire The difficulty here is that no one who is even mediocre would ever do a "contract to hire". If they are good they have options and there just isn't any upside to doing a contract for hire when you can take another full time job. Contract for hire is a big red flag!

The difficulty here is that no one who is even mediocre would ever do a "contract to hire". I would, but at a real consulting rate (over $150 per hour) and not at a salary rate, since it comes with none of the benefits of being salaried. That kind of arrangement is going to lead to adverse selection in the end. At typical tech salaries, you'd be asking me to take a 50% pay cut for (not much) additional job security.…

I was skeptical of contract-to-hire situations until I did one myself. I got a significant increase my salary in the contract phase (even including what I paid for benefits) and got an increase on top of that at the time of hire (not counting benefits).

I was toward the top end of what I could make being traditionally employed locally (Helena, Montana). The remote contract-to-hire opportunity put me on par with folks living in cities, save places like NY and SF, or those working for huge companies.

Definitely a good deal for some of us that don't have professional networks that would support consulting. And whatever you might think, I'm not a coaster or I wouldn't have been offered full-time employment.

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#49

Earlier quoted context omitted.

> The difficulty here is that no one who is even mediocre would ever do a "contract to hire". this is absolutely not true. good people will simply demand a high hourly billing rate during the contract phase to compensate for the opportunity cost, which you have to be prepared to pay. sure if you're dicking around with $20/hr "contracts" everyone decent will tell you to kick rocks. have you ever worked with people who…

I think we're going to have to disagree here. > have you ever worked with people who are used to getting paid $100+/hr? i.e. top people? it doesn't sound like it. I saw this and wondered if you were trolling. It's certainly a rude and undeserved comment, but I'll be charitable and bite:) My main point is that "good" developers, always have options. My assumptions: 1) the developer wants full time work, otherwise they…

what i'm saying is my actual real life experience contradicts pretty much everything you're stating.

your position is falsifiable by a single example. it's not reality. it's just your opinion. you're saying "that's impossible", when it clearly is NOT impossible.

Re: How to Decide if a New Hire Will Be a Team Player in the Interview

#50
post #46
post #44

Earlier quoted context omitted.

Done right, contract-to-hire seems like a great solution to me. It's actually a chance for the employer and employee to get to know each other and make sure their mutual expectations match. Assuming the position were to be salaried at $104k, a sensible agreement might be: - The employee is hired temporarily for a period of one to three months. - Their wage is paid weekly, at a rate of $2k per week (i.e. 1/52 of their…

That's the issue. A job explicitly labeled "contract to hire" is never done right. No good developer is going to do contract to hire at 1/52 of the salary, because they already either make an equivalent salary or far more as a contractor. The company isn't going to pay an actual contracting rate, because they are either cheap or can't afford it. Contract to hire is almost exclusively done in places where it's hard fo…

> A job explicitly labeled "contract to hire" is never done right

i don't understand how you and the other guy can make these blanket black and white statements like this. have you guys ever had to hire people based on advertised solicitation only?

contract to hire is mainly done in situations where a new employee can not be vouched for by an existing one, or a large number of new employees must be brought on at once.

the reason why it's so rare among elite silicon valley firms is because everyone knows each other and recruiting is usually a personal process between existing employees and prospective ones. THIS IS NOT HOW IT IS EVERYWHERE.

outside of the echo chamber it's very common and good people can be hired this way.

Post reply on HN