Companies in my area use to grow rapidly, And, the more and more employers require the "team playing". What is the best reply? I just did well in my own rock band, and, i play fine on a remote but those are the place where evryone has own task, say, SW developer, or sysadm, or the musioc tool, like drums, and so on, but the team of developers doing almost the same stuff looks another deal to play in. Or not? While my carreer, i was the only S/W Dev. on the small or medium firm.
I'd say that they want the team to play the same tune even though everyone is working on different things.
Programming is never "the same stuff". There are unittest specialists, UI specialists, DB specialists, etc. etc.
On a big project, teaming is very important. A good team is comprised of members who know eachother well, and will fill in blanks for eachother. A good team has a clear common goal, and is made up of friends.
In my opinion, a good team has a maximum of 10 members, which are all physically in the same room, and share interests, preferably being or becomming good friends. Of all the projects I did in the past, the "10 friends in a room" approach is by far the best recipe for good quality code being delivered on time.
As you have been a solitary developer, there are some pitfalls. Your code is effectively your communication with your team. You can not write intricate hard to read code just for yourselves. You have to accept other people's code without refactoring it. You have to deal positively with criticism, and politely give positive criticism to your members.
Try to find that 10 people team, be part of it and see if you like it.
Today when rapid development of applications is needed it is crucial that you play with the team you get along with well. These are things project managers usually are looking for and usually are put in front of the great knowledge. After all if there are at least 4 or 5 developers with good knowledge in the team of 10, the others will follow as well.
I agree that team should be put up of approx 10 developers tops. And playing with the team means a lot of good communication - first of all understanding each task well and clearly is crucial. So it's better spending an hour discussing about task, than implementing it the wrong way whole day. Then the second thing is how you introduce your work to the other team members - introduce them the part they need to know well, and put aside your very special technical part of your "sub-team". You don't wan't to explain your algorithms to GUI specalist. And he doesn't want to hear it... The concept of black-box. So talk, understand, code. Be in the same room with other developers and have instant messaging software always open.
One approach to the interview question "Are you a team player?" could be along the lines of:
I've not had the chance to be a team player with other IT developer staff because I was the only IT developer on the staff. Of course, I worked as a team player with the other non-developer staff in the company, so my IT work was for the benefit of the corporate team, but one of the things I'm looking for in this job is the chance to be part of a team of IT developers, so I can share my experience and learn from other people.
The question "are you a team player" is not actually a question per se, it is a test of reflexes. Another similar one would be if you, as a tourist, visit the U.S.A. everyone will ask you "how do you like America?". THERE IS ONLY ONE CORRECT ANSWER TO THAT QUESTION. Moreover, if you take too long to think about it, you have failed the test.
If in an interview someone asks you if you are a team player, you should always say "yes", and quickly.
Only if they ask for examples of you being a team player should you think about it. But basically in that case, they just want to know either that you are easy to get along with, or that you can take orders.