I Am a Programmer — No, I Don't Want to Be a Team Player
Since the beginning of my software career, I was taught a slogan: TEAM means Together Everyone Achieves More.
However, for a long time, my idea of being a team player did not go quite far besides saying Yes to the “Are you a team player?” question.
Later in my career, I thought my interviewers deserved a more realistic answer. I decided to give deeper truth a try. And it hurt me.
During pandemics, I went through the most grueling serial-rejection phase of my career. The first rejection I faced at the very start of this period involved the so-called team-player skills.
How did I get rejected for being a bad team player?
The interview was techno-behavioral. They asked me about my CV bullets. Then, they progressed towards questions like projects I was proud about, programming language/libraries/frameworks I liked and my reasons for them, my opinions about software design and SDLC.
It all went quite smoothly until they asked me: “Do you work in a team, or do you like to work solo?”
I took the question at its face value and answered it truthfully, “As you can see in my CV, I have been an individual contributor. I need little assistance in programming tasks. Of course, I collaborate with other teammates for inputs such as functionality, UX, and UI design. But once I have them, I like to work in a silo and deliver what is expected.”
The next day, the hiring manager emailed me that they would not continue any further. I was shocked. Not that I had very high hopes attached to the position. At the same time, there was nothing that I did could possibly screw up the result.
When I asked what went wrong, he replied:
“Your team skills are not in line with our company values. We align more with programmers who collaborate continually with teammates and create the best that’s possible. As you mentioned, you work in your own silo, that’s a NO for our team, sorry 😞”
I read and re-read his reply. To me, it looked devoid of any substance. What was the tiniest amount of time period you had to visit your teammate to qualify as a team player? And what was that collaborative working to deliver the best product possible bullshit anyway? Aren’t you supposed to deliver the best regardless of whether you collaborate or not?
Besides, my answer didn’t say I was totally aloof. I just said I let myself alone till I got done with the feature.
After the initial anger cooled off, as I read it again, it dawned on me: It was the wordings. My “working in a silo” part triggered someone in the interview panel. Maybe that someone wasn’t a good listener, or he chose to ignore everything else that I had to offer.
A Great Programmer isn’t a Team Player:
Unless the evil forces in the software industry mold him/her into one — at which time he/she turns into a good programmer, or quits the company.
Don’t get me wrong. I have nothing against team players. But what team player traits are the true qualifiers of a collaborative programmer? When you ask someone whether he is a team player, what exactly are you expecting in return?
The very nature that drags you to an unromantic profession like programming is your ability to go into a cave for hours
If a programmer isn’t a team player, he would deliberately delay his deliveries, so as to let his peers’ work get delayed. Worse, he would make quick fixes that his teammates would have to spend sleepless nights fixing and refactoring, possibly also contributing to the bad balance sheets. A non-collaborative programmer wouldn’t update his work status in time, wouldn’t speak up when he is blocked, and wouldn’t communicate when something is asked of him.
None of these traits are part of the standard interview questions unless a candidate somehow manages to mention them proactively.
On the contrary: A team player isn’t someone who shies away from going into a silo. In fact, the very nature that drags you to an unromantic profession like programming is your ability to go into a cave for hours, and emerge victorious having nailed the problem, and/or designed the kickass solution. That victorious outcome takes months, sometimes years, yes. But it is core to the nature of work coders do. And unless they pass through that phase, their journeys aren’t complete.
If this ability is absent, someone is not doing his job right. A bloated codebase? A thousand unnecessary dependencies for mundane stuff like timestamp formatting or simple animation? That’s a clear sign the team isn’t spending time on development. Coders are not getting enough time to research, code, and test. Instead, they are spending way more time in meetings or unnecessary collaboration that the company culture enforces upon them.
Having lost the flow, they can do very little in the time that is left past it. I have observed that they waste it in hour-long coffee table chitchats. They waste hours deciding the venue for the next Friday outing that would last only an hour, and only a half of the teammates would attend. Though once in a while, such a waste of time is really fruitful in building the company culture, it mostly remains a box that is checked, with no tangible outcome.
A couple of interview affairs:
Back to my interview rejection stint, I faced yet more rejection for speaking out “I am not a Friday evening go out for beer kind of guy. Sometimes I attend them to bond, but the real bonding happens at work. ”
Rejection slip read: “Not a team player. Not for us, not at least now.” (That interview panel included 6 people from the same team, and I was the only one who spoke for most of the time)
To make myself employed, though, following that, I changed my perspective. In my forthcoming ones, I began to also describe how my silos attitude was beneficial to the colleagues and the company, without mentioning the exact word.
“I am kind of both: Collaborative in specs discussion, which shouldn’t take more time if you have done enough research beforehand. And I am an individualistic one once the specs are in stone. My objective is to minimize the time of my colleagues that I would waste if we go back and forth.”
I got success with that answer eventually. I have described my learnings in my latest eBook on senior developer interviews.
But what about pair programming?
I wrote extensively about pair programming — especially from the GitHub CoPilot perspective. My takeaway quote from that article is:
“Coding is very much like those midnight school assignments. If you are doing it with friends, you are not doing it at all.”
Besides, pair programming is an industry fad. Someone created a great tool to teach kids how to code, then decided to sell it to companies (because they got deeper pockets than schools and governments paying for kids' programming classes). Instead of selling just the tool (that possibly costs millions in licensing every year), they nowadays come up with a methodology (Agile, anyone?).
Next? Invent a peer pair-review tool that allows yet another pair to observe how the original pair codes. Optionally, check whether they are truly coding, or doing something more interesting (IoT making inroads into developers' desks finally😋) Create more meta-positions that measures and reports, all the while contributing to the team culture.
We are so productive in measuring productivity that we have forgotten the very thing we are supposed to produce.
In a nutshell:
Pair programming is disrupting the flow. It only works when both programmers have equivalent competencies, equal temperament, and know enough of each other to be willing to expose their typings to each other.
The last thing we need is bloated code reviews — they are doing fine in their current format.
Conclusion:
Every company thrives on the two most vital ingredients: Business objectives and company culture.
The entire idea of working in a team is to instill a sense of security and cultivate a will to contribute. Those goals are directed towards the business objective of the organization.
Company culture is a perfect lubricant that compliments the fuel which is the business objective. But it is not a goal that must be pursued as vehemently by programmers as it should be by managerial staff. Team building and collaboration fall under the company culture umbrella.
Attaining and exhibiting a perfect team-player personality isn’t a programmer’s most vital skill. Avoiding to be a shitty team player, realistically, is.
When your next hiring manager asks you about abstract team player skills, tell him exactly what you stand for, what you wouldn’t, and how you work. If your answer isn’t acceptable to him, it is for the better of both of you.
Pen Magnet is the author of the popular senior developer interview eBook that addresses the Amazon STAR interview format questions:
Comprehensive Approach to Senior Developer Interview (40+ example questions) (For the first 100 Medium readers, the discount is 50%)