How to Decide if a New Hire Will Be a Team Player in the Interview | Hacker News Reader

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

linkedin.com

37 pointserinbryce53 comments

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 which case you probably want the uniformity.

If no one rocks the boat, it comfortably goes over the waterfall.

Hiring everyone with the same mindset is a great way to limit innovation and creativity. You also run the risk of being blindsided by upcoming challenges because everyone is so eagerly agreeing to the plan.

Great way to put it.

I think this is a part of a larger problem. A lot of IT interviews are based on a gigantic set of "ideal criteria" that no single person can realistically fulfill in its entirety. Because of that every hire is a compromise. Because of that who is hired in the end becomes a subject of subjective and irrational judgements.

In my opinion, having a realistic set of minimum requirements (which are actually needed to do the job) and looking for candidates to match every single one of them provides a much better and less biased approach. It can also help to design an interview process in a rational manner.

"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.

The OP purports to have a way of assessing teamwork-capability based on good interview questions (and I think his questions are spot-on)...but the anecdote he closes with is too pat:

> Many years ago a CFO of a fast-growing Southern California medical products company excluded a candidate I presented for a corporate cost accounting manager spot since he believed he lacked strong team skills and a sense of urgency. This was after a 20-minute “chat.” After I mentioned that the candidate was assigned to lead an international task force to implement a state-of-the-art cost system for a F50 company he quickly relented, re-interviewed the candidate, and hired him a few days later.

As the OP describes it, the overriding factor is: what is the candidate's claimed team-related achievement(s)? In this case, it was "being assigned to lead an international task force to implement a state-of-the-art cost system for a F50 company"...but that doesn't seem enough on its own...for example, was that project successful? seems to be an equally important question...and even the answer to that doesn't definitively quantify that person's ability to work on a team.

To be fair, the OP is describing a situation in which the hiring company apparently made a decision based on first impressions (i.e. mannerisms, appearance, etc.)...which of course is just bad. However, it'd be interesting to hear more in detail what factors were used to assess the candidate that were not found in that initial interview.

I wonder how my honest answers to that line of questioning would be interpreted?

">What were the biggest challenges the team faced?"

Struggling with a crony manager whose universal incompetence worked its way into every aspect of the project. This ultimately made a smoking wreck of the first public milestone.

">Walk me through the biggest team problems and how they were resolved. What was your role in this?

After the major public embarrassment described above I was sent before a panel of consultants to effectively interview for my job. I successfully convinced the consultants of my own my own plan to recover the project while laying provable blame for the project dysfunction on the problem manager.

The team was appointed a new manager who was happy to stay all but completely out of the way. I was made technical lead and given free reign to pull together a new team. Within six weeks we completed a new public milestone with 4x the scope of the previous failure without a hint of trouble.

---

Personally, I see "team player" often being confused with simply being subordinate to the established team.

I think there's definitely wisdom in a mentality of service, to the team or the job.

Thing is, the team may be best served by having part of it removed and the team function may be best served by a completely different team.

In my experience, people don't like to hear that.

Biggest challenge: A fake scrum system whose claim was "this will make us into great teams" when really all it was used for was micromanagement and scapegoating.

"Your velocity is off by ten percent. We're concerned."

"You're the most talked about person in the scrum-of-scrums."

Gahhh.

Are you a team player? Well now, that kinda depends on the team, doesn't it? You can't just slot people in and out like identical Lego blocks. "Ah, yes, I'll take a bag of 15 size-10 database programmers with 4 years experience please."

Charitably, I'd call this a complexity problem - it costs resources to look into individuals, and that's why you have an interview process rather than having the people who do the job talk to the person and see what they think.

Uncharitably, I'd say there are people seriously out of touch with their humanity. Who view people as components because they don't care about people. Perhaps because, if you do, it's emotionally draining to get to know so many people and then hurt them by turning them down.

Since it's hard to believe this is really an efficient long-term approach to recruitment, I suspect the truth lies somewhere in between.

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.

You can't do this with someone on a work visa in the US, so this could reduce your pool quite a bit (depending on where you are located).

> 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!

It is actually a good way for some employees to go from proven track record with tech X to building a proven track record with tech Y. Especially for those that don't dedicate a lot of free time to building demos/products.

> 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 are used to getting paid $100+/hr? i.e. top people? it doesn't sound like it.

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 would just do contracting and not contract for hire.

2) jobs are plentiful for good developers.

Why would the developer assume all the risk with contract for hire, unless they had no other options? Why not just take the full time job instead?

Basically my point boils down to two points...

1) How would a company convince me to do contract for hire work when I can work somewhere else without that risk? What's my upside to doing this?

2) As long as most companies don't' do contract for hire, a company is putting themselves in a position that excludes most talented developers. ie if you aren't facebook, twitter, dropbox, etc. my contention is that the top developers will laugh at your contract to hire request.

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.

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.

> 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.

I'm not sure what I said contradicts what you're saying. I've been involved with hiring over 100 people in Boston, San Francisco and NYC. Everyone does not really know everyone but that's a different story. Contract to hire is very popular in the part of the Midwest where I'm originally from because of no particular reason other than the hiring firm can and the person being hired doesn't have many options. At one place I worked in Boston everyone was theoretically "contract to hire" but it was atypical as the rate paid was so high that nobody ever took the full time job.

i see you deleted your anecdote, which to me basically exemplifies my theory that the opposing opinion on this matter is simply just a way of validating ego.

"I would never do that, so therefore, no other good developer would either. Ever."

I deleted my anecdote because I didn't feel it was appropriate to leave details up about my friend's company as he's still my friend and they still need to fill the position.

I guess I don't get what you're saying. Who does contract to hire where it's good a good deal for someone other than the employer?

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.

Ok, I'll try to restate my opinion as clearly as I can as it looks like we're talking past each other:)

A developer has a job, they are looking for a new job. They have a full time offer and a contract for hire offer. All other things being equal.....

Why would the developer ever consider taking a contract for hire offer when they have other alternatives?

This just seems like they are taking all the risk here. If they take a full time offer and find out the culture isn't a good fit then they can leave, just like in contract for hire.

What is the upside to the developer here over taking a full time position?

I don't agree. This is an opportunity for both parties to check each other out, a top dev might want to check the employers claims, too. Too often they are just lying, especially if the market is drained.

Totally agree, I never even touch job openings that are looking for contract to hire. Some companies just want you for a short time and this is a way to get better talent without having to keep them, and I definitely don't want to relocate with the risk they won't need me in six months.

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

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

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.

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.

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.

I strongly agree that something like that is the best approach. I'm developing a process I'll call YRR (for Yes, Real and Reciprocal) to define one particular take on this idea. I'm going to try to enforce using it on others, as much as I can, going forward. So tired of people making guesses. So tired of "tell me your life story", so tired of being told I'm under-qualified or over-qualified for things I know I can do and clearly have a track record of doing, etc. So much time wasted on meta instead of doing the real things itself we want. And too many formal/bureaucratic hoops, unpaid, people expect you to jump through. The traditional recruiting/applying/hiring process, at least as its done in the more formal parts of the software development field is badly broken, almost a circus not to be taken seriously. Can it work sometimes? Of course. Could it be done much much better? Hell yes.

Throw a dice: if it's a 6 then he'll be a good team player. No, serious, it's really hard to know that beforehand, an interview with the right questions can help but luck is still involved.

I think this is better: http://en.wikipedia.org/wiki/Waiter_Rule

I hear this a lot, especially with regard to dating advice, but I don't think I've ever eaten with someone who was rude to the waiter. Have I just been lucky?

Maybe you're rude too so you can't tell how the waiter should be treated. /joke

I've never eaten with someone who was rude to a waiter, but there are some things that you can learn from a person by looking at how he behaves with other people.

For example, if someone is putting food on your table, try to not be in his way and maybe tone down the conversation a little bit. Saying thanks is also a nice thing to do... looking at you, study team member.

Very similar approach as this article by Tucker Max.

http://tuckermax.me/dont-look-for-talent-find-people-who-do-...

I really like asking questions about what a person has done (especially as personal / home projects), also to a lesser degree what tech blogs they frequent (if they only mention aggregators, thats half a demerit).

What are the weaknesses of these questions?

The problem with rating a candidate on the basis of his personal/home projects is that it excludes potentially-excellent candidates who are __unable__ to work on anything at home due to, e.g., having several young children and half-dead parents to care for.

(Also, don't try to retort with "so ask them about the personal/home projects they did before having kids", as that wouldn't be sufficient to cover the people who have had children at a young age; e.g., before turning 20 years-old.)

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't my entire life, than I don't want to work for you. Nobody should be penalized career-wise for enjoying their free time.

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.

And just to avoid misunderstandings: I don't think that 60 hour schedules are good! Personally, I prefer a 25 hour week of coding only on my own stuff and 0 hours of coding for other people :-)

>if they only mention aggregators, thats half a demerit

This is silly. Aggregators let the quality articles rise to the top. It's a much more efficient use of your time (assuming you don't become addicted). These are exactly the type of totally arbitrary, no signal producing filters that people need to get away from.

Don't usually turn to this guy for advice but I 100% agree with this. I am going through the same old interview template right now that everyone has copied from google/facebook and I think while it applies some places, for early startups, its ridiculous to use that as a marker.

You should hire for a developers ability to execute, not their ability to solve problem about bowling balls and skyscrapers, and not their ability to reverse() a string without using reverse(). I get that they are testing your overall data structure knowledge and your algorithmic thinking, but those are also things that one can find on google, things that one can educate one's self on when they need to. Early stage companies want to look for those people who will do that, people who encounter a problem and then just go out and solve it.

(.....now I will stop ranting and go back to memorizing stupid puzzle/data structure interview questions, for my next phone screen in a few hours)

I find this is very hard to screen for by looking at resumes, and almost as hard to detect in interviews. Even with an interview, sometimes people just talk a good game. The only reliable methods I've seen are "Hiring people you already know to be good team workers" and "Watch them over a 10 week internship."

The Airplane test: imagine sitting next to this person for 8 hours on an airplane. If your first reaction is "No thank you!" then your team will feel the same about working with them.

In 1683, Prince Eugene of Savoy applied to Louis XIV for a commission in the French army. Louis XIV turned him down flat; whether as not a team player or just as ugly, unprepossessing, etc. I don't know. Prince Eugene turned to Vienna, and spend the beginning of the 1700s winning campaigns and battles against the French marshals, often in cooperation with John Churchill, eventually Duke of Marlborough.

Wikipedia has the dates etc.

"Personally, I see "team player" often being confused with simply being subordinate to the established team."

Some of the best team players are those who would do anything, for anyone, at the drop of a hat. They are the people who show up early, bust their ass, never complain, and wouldn't think twice about lending a hand whenever you ask. I have no idea how to determine that from an interview.

Didn't read. But why does all this "Management" experts seems to love awful stock-photos? And why are these Management/HR people always obsessed to come up with rules and guides, as if they ironically are to incompetent to handle people so they need a manual...

> rules and guides

Repeatability would be one reason. Asking the same questions to different candidates will help you make better and comparable decisions. The usual "casual chat" interview is heavily biased towards people who are good looking and interview well.

That was my whole point...all these NLP, coloring personalities and all other bullshit HR and management people are into is only due to their lack of ability to read and sense people. If they don't come up with all this bullshit, they'd be completely lost (just to fall back on looks).

I'll tell you why. It's because this line of corporate work isn't about work or passion. It's about filling your day with tasks so you can justify your paycheck. I'm not saying this as a negative thing. It's just how the corporate world works.

Nobody is enthusiastic. I haven't talked to anyone at my work who is truly stoked about what they're doing, as in they'll go home and keep working on what they're doing.

There are no hackers here. It's just corporate culture.

These people are so deep into the corporate culture that they forget how to interact with people without an underlying guide or goal.

Wait, people still use "team player" non-ironically?

"♪ The dream of the oh-ohs is alive on Linkedin... ♪"

You'd think they'd look for cultural fit, but instead they're looking for "growth in terms of the size and importance of the teams the person has been assigned". Feels bigco-oriented to me.

Reply on news.ycombinator.com