How does a non team player answer questions about team playing [closed]

Question

I am asking a question for my friend; he is searching for a position in the corporate world.

Let's call him "Joe". This Joe guy does not think working in a team necessarily means the best product will be delivered, and this is his dilemma.

Before I duck him expressing his innate nature and say, hey be a team player, allow me to express his side.

In his experience, he has always shined while performing individually. Teams, in his opinion, are required only when gigantic software projects are being developed or maintained. With teams come additional responsibilities of making sure everybody is in sync with each other and the product they are engineering. You gotta conduct yourself all the time to everyone's satisfaction. Even if some guy in a team is a jerk, you have to tolerate him and work with him, even if he is slowing down the entire team. Individual work, on the other hand, means it is only him who is responsible for anything that goes wrong or anything that shines.

The problem is, this kind of a work ethic is not encouraged by many firms, and this average Joe is losing out on many lucrative job opportunities because he doesn't like to lie and openly says he does not perform at his maximum when working in a team, which is true.

How does a non-team player answer questions about team playing in an interview?

Answer 1

When I was a younger developer I thought much the same way as your friend so let my give you my insight.

I am inclined to the personality trait that I feel everything I do personally and every system that I am involved in should be operating at peak performance and optimum efficiency. I am also naturally something of a control freak and am prone to anxiety problems because of this.

My first jobs were on very large projects and the only thing I noticed is that we have this big clunky inefficient software team revolved around new features that might have taken me and one other developer a couple weeks to complete on our own. Project managers would spend days laboring over schedules and resource conflicts, developers would work on technical documentation that most of the time nobody would read, business analysts tinkered with and put attention to requirements documents and QA analysts would talk to BA's and Devs about strategies for their test cases.

This of course slowed me down and all I could focus on was that the system was inefficient and that I could do all of this in good quality in a shorter amount of time.

I was looking at the world through Developer colored glasses. My entire mindset was that process efficiency was the primary goal, and that implementation is all that was important because that was the only thing of tangible value to the customer.

This is of course incorrect and I only came to understand this once I began to understand that the only thing that is important is the needs of the stakeholders, tangible or intagible, fake or real, founded or baseless.

Your friend very well may be an All-Star software developer, but riding your plans on the shoulders of a hero is terribly risky, especially when a lot of money is on the line. One of the primary concerns of all stakeholders is the inherent risk of a complicated project. The process and extra people may slow down the All-Star or even delay the project more than giving it to only a few people but this inherently lowers the perceivable risk to have project managers and project plans, clearly laid out requirements, quality assurance seal of approval, etc...

Answer 2

I hate working with people like this guy (whether in software or engineering or any field).

For example, he generally:

• Makes more work for me by not documenting anything
• Causes a million communication issues
• Never maintains any process or code or anything he does
• Cannot hand off projects
• Thinks his idea is always best
• Causes this problem in everything he does

My interview advice for him would be to tell the truth, that he doesn't work with teams and thinks they are a waste, so he doesn't get hired into my company and make my life miserable.

My career advice would be for him to become an independent developer and release his own apps and live/die by his own philosophy. He'll especially learn how important someone being able to do marketing type work (whether advertising or market research, etc) is unless he can do it himself. He's going to hate working on teams and make all his coworkers miserable so he might as well just find jobs which fit what he wants to do. Or seek out contract work which is suited to one person.

Is this unfair? Absolutely not - a company offers a lot of $$$$$ to employees and part of this work involves working on teams. If he doesn't want to do this, then he has no right to feel upset about companies turning him down.

Answer 3

I'll start with - he's right.

The bigger the team, department or company, the more of a "tax" it pays on communication overhead. From a communication perspective a team of 1 is absolutely the most efficient.

It is also constrained to the pace of a single person - if the problem is small enough, that is absolutely doable.

Problem is - the market doesn't support a whole lot of those positions. Most of the major products made today involve a scope and complexity that are bigger than 1 person. They take diverse skills that 1 person alone cannot hope to learn in a life time. They involve shifting requirements and a pace to development that requires massive hours, but in a short time frame.

So - the market for products or solutions that can provided by 1 guy who isn't willing to invest the overhead in communication skills is a very limited market. While a multi-person work unit is inefficient, it's a fair bet that those who have spent time getting good at communication in all its varieties are going be able to handle this "tax" much more efficiently than those who are "not team players" - in other words, those with little to no interest in practicing team communication.

If he's dead set on not improving in this area, I'd suggest that he:

• Develop a skill set that makes him an absolute wizard. They are becoming rarer and rarer, but there are still niche areas where the One Perfect Guy may be able to land a position working alone and doing specialty work that negates the high barrier of his inefficient communication.

• Figure out what other parts of work/life he's willing to sacrifice - job options are simply going to be more limited than for a "team player" - so be aware of what barriers are OK - salary? work hours? company stability? education benefits? location? exciting work? I'm not saying that non-team players are going to get the absolute worst jobs on the planet - but I'm saying that the demand for this skill set is more limited so when the right job comes along, he should be clear on what he's willing to put up with.

• Consider expanding into a least one communication skill area - in particular - writing. If you are a wizard at a state of the art technology, can do great one-man work in it, and write well enough to explain it to others, you can balance the limited "I make solutions for a living" work with also writing about how to do what you do for others. It increases the expert's fame and increases future potential opportunities as well. And writing is one of the more solitary-compatible communication arts.

This is the radical answer. I'd tell this answer to a friend who I knew would simply miserable if he had to work in a team. I wouldn't tell this answer to a guy who'd had experience in a few teams with a few of the more ... unique... personalities that make even a great team a very unfun place to work.

If I thought that the guy was a typical sort of computer geek who is actually a fine team player with people who are similarly decent to work with - I'd also offer the advice to refocus the question. Team work is not about liking everyone or never being annoyed. It's about being socially adaptable enough to get a big project done in tandem with other people - helping and teaching across skill sets, buffering others weaknesses with your strengths and being helped in turn. If your friend can think of situations where the team experience has been a positive one (in or out of work), I'd ask that instead of accepting limited job options, he concentrate on the parts of team work that he likes, and say that that's the sort of team experience he's looking for.

"Independent" and "team player" don't have to be opposites. But for a strongly independent personality, it takes the right team to make it work.

Answer 4

That kind of work ethic is not encouraged because it is not the most effective for the organization. Your friend needs to learn to work with others, to deal with the people he doesn't like and to stop thinking he is so much better than everyone else that he doesn't have to play the game. Why would he want to handicap himself to small one-person projects when the big projects are often far more challenging and interesting? Why would he want to stay at a junior person's salarly (Senior people have to be able to work with others) for the rest of his life? Team work is simply a requirement most places and it should be. He needs to fix his problem and then he will know what to say in interviews.

Answer 5

So, this is probably so obvious it doesn't bear saying, but put yourself in the shoes of the interviewer: I have a team, and your "friend" doesn't want to be on a team and can't work effectively on one. What do I do?

Note that it's cumbersome always saying "your friend," so for brevity I will just say "you."

So, what to do?

1. As enderland says, you could start your own company, and never have to deal with anyone else again, except clients, accountants, designers, etc. (All of whom can make other developers look incredibly easy to work with).
2. Get so good, working on your own, that there will always be companies that will hire you and stick you away in a room somewhere, just to feast on your brilliance. The problem with this is that there are a lot of skills you probably need to have to get to that level that you're unlikely to have a chance to achieve working on your own, such as using version control and architecting so that less-skilled developers can build on your code. There's also the issue that there are so many good developers out there that even if you get to that level, you won't get the opportunities unless you can get your name out there--by speaking at conferences or writing a book or something. These both require you to deal well with people.
3. Look at people-skills as similar to any other skills, and work at them. Note that it is very difficult to change your basic character, so you will probably always have "issues." But you have to start somewhere--just as you did with your programming skills. You will have the opportunity to learn the technical skills that come from working on teams, and you might even learn something from the ideas of those you have the opportunity to work with. I think you should be honest that this is not your strong suit, but that you're willing to work on it. Maybe someone will take a chance on you. In the meantime, maybe working on an open-source project would give you the opportunity to practice while not asking someone to take that chance with you.

Answer 6

Being able to work with people you aren't necessarily going to be friends with is the sign of a professional attitude. You have to have the social skills to bridge the gap in order to play the game. Your friend simply isn't willing to play the game, either because of his own feelings of superiority or social ineptness in professional terms.

In my opinion, your friend might be a good programmer, but he is a lousy professional. He lacks the skill set that is necessary to be one. You may have arguments about how to get things done, but those are normal. The ability to deal with these situations in a way that, in the end, everyone agrees on the way to go forward is a professional skill and a condition for good team work. From what you describe, your friend needs to learn how to do this.

Luckily, both can be addressed through either self-help, or better yet, the help of a workplace coach.

As an illustration, I'll provide you with some situations I've been in and compare them.

In one situation we worked in a team where we developed a mid sized product in the vacation home rental business. This team was very diverse, and we had great interaction. This wasn't because we were friends, but we had respect for each others' skills. This lead to a great attitude that was reflected in the standards of workmanship and in the way we supported each other. All in all I'd say these guys were a great team to be with. I was only an intern, but I would have loved to go back there. (unfortunately, they folded in the crisis) If anyone got sick, the fact that we all had done our bit to contribute to the big picture helped to cover for each other. the discussions we had left no stone unturned, but at the end we had a good understanding why we made the choices we did, and we all knew how to progress from there.

In another company I worked for, the situation was pretty much what your friend was looking for: Developing e-commerce websites for small and medium sized businesses. (and a few big ones) These developers for the most part had developers work on their own projects, with one or two teams maintaining the sites of the very big customers. From what I can tell the programmers were either skilled people who wanted a break due to other life issues or they started out as unskilled people who grew into the job. The skilled workers were the team workers. But as teams were few in number, overall it could be said that team work was abysmal. The parts that were done together by non team regulars didn't fare well because work was unstructured and often team members were not communicating. If someone became ill, that would usually be a major problem. Nobody was there to fill in the gaps and it would cause costly overruns for someone to fix what was left open, or because of the damage clauses for time overruns. The lack of team work would leave the replacements guessing as to what they should to to finish these projects within their deadlines.

Is there a drawback to working in teams? Yes, working in teams creates overhead in planning and execution because you need to communicate. Are there advantages to working in teams? Most definitely! Good team players can cover for each other, meaning continuity and a better overall product. One of the main reasons being that you have someone that is watching your back. Although this might create some peer pressure (something that isn't half bad in my opinion) it also provides for much easier problem solving. Nobody is god in the workplace, nor is anyone that inept that they can't contribute. (assuming he/she has an educational background in software engineering as part of their history)

The answer to the question isn't one he's going to like: There is no way around it. He needs to learn how to be a social professional before he'll get a good job. There's no fool proof way to trick the interviewer. The interviewer will probably punch through the facade with a follow up, whatever his answer is going to be.

Answer 7

It's possible the real problem is that his previous experience is on mediocre teams. It's no fun cleaning up after people doing negative work. He might find that he enjoys working on a strong team.

I recommend that instead of saying he's not a team player, that instead he select his future employers more carefully. If he's really good, then he could be happy and grow a lot as a member of a strong team.

Answer 8

Your friend has to decide what is more important, a better paying job or working independently?

There are many companies that have several developers on their staff, but rarely have any projects large enough for more than one dev.

Maybe your friend should focus on finding a job that has other programmers that are better than he/she is. This is how you really step up your game. A willingness to learn more is the sign of a great developer. Those that think they know everything are delusional.

Edit: Good programmers are also the ones who can: make sound arguements and pursuade others to follow their suggestions and work with code written by others.

Answer 9

Your friend should be flexible about what he regards as a "team". A software developer working in a team does not necessarily mean being part of a group working on the same technical thing. The team is also your fellow software developers who work on different components, but report to the same manager. They are the people whom you can ask to review a piece of code. Furthermore, your team are the people who support the customers in relation to parts of the software you're responsible for. Product managers who guide the direction of the product and the scope of the milestones are part of your team. Software testers who look for ways to break what you've written are your team. People looking after builds, bug trackers and version control, and their integration and automations, are your team. If your friend thinks about "team" more broadly, he will probably realize that he's worked with and relied upon teams all along.