In software engineering, what exactly is meant by collaborative tone?

Question

For all of my web/software development career, I have worked alone and with a very small team. I have just interviewed with a larger company. There were several interviews - technical and behavioral.

The behavioral part asked me some questions on how I deal with stress, conflict, and personal/professional development. As usual, I gave accounts on listening, reaching out to my colleagues, and my willingness and efforts to solve problems with colleagues, supervisors, and clients. I think that those kinds of accounts should cover the topic of "collaborative tone".

In the technical interviews, the questions were focused on knowledge of software architecture, data structures and algorithms, and other technical matters. There were also some coding exercises where they posed a problem, and they watched me code and talk through my process of solving it.

Long story short - I did not get the position. The recruiter offered to discuss the decision with me in greater detail than in that rejection email, so I took it. They told me that while I demonstrated solid programming skills and solved the problems, I lacked the "collaborative tone" in those technical interviews, which was actually a huge factor. They said that the fact that I have been working alone most of my career showed that I have little to no team experience (fair enough). They said that I did not mention or discuss certain things that they were looking for that demonstrated the "collaborative tone". When I asked about that specifically, the recruiter told me that they do not have further details for legal reasons.

So, my question is, what exactly is "collaborative tone" in software development? What kinds of things should I have said while working through the programming exercises and speaking with the engineers who could have been my colleagues? What kinds of questions should have I asked? I did ask about what it was like working in a team in their environment, but apparently, that wasn't enough.

Answer 1

"Collaborative tone" is not well-defined, true... but anyone who has worked on a team and alone can tell you there are vastly different approaches that make one successful at each.

Consider working solo. You're forced to solve problems on your own through research and become the expert that your organization needs (or close enough to get the job done). You don't have code reviews, and you may not even have to follow any standards besides the conventions you set for yourself or you get from your direct supervisor.

Teams must avoid stepping on each others' toes, collaborate for solutions, and ask for help when you're stuck so the timeline doesn't slip. Standards need to be agreed upon and followed, because the person working on a product in a few months may not be the same person that did it last time. Documentation, consistency, and communication are much more important.

"Collaborative tone" may have been a red herring to distract you, but if they were being somewhat helpful as it sounds to me like they were, this phrase is how I would summarize the difference between "works alone" and "team player." If they're looking for someone with extremely strong teamwork, it sounds like you didn't exhibit (in their eyes, anyway) those skills that make one a good team asset.

Don't overthink this; just try to get better at teamwork and thinking in a team mindset, if you think that'll be important to other employers. The best way to get team experience is to work on a team, but if your work style is already well-suited to solo, you might prefer that.

Answer 2

What kinds of things should I have said

The truth.

The purpose of a job interview is to determine whether you are a good fit for the position, and whether the position is a good fit for you. It's not a game of dropping the correct buzzwords to get your foot in, giving little thought about what comes after the interview - after all, if you take the job, it's not buzzwords that will be needed, but the ability and willingness to do what the position requires.

Different positions come with different needs. Apparently, this position came with a need for a "collaborative tone" that wasn't second nature to you since you've never worked in a team, and another candidate fit this need better.

It's immaterial what they meant by that. They realized you wouldn't fit this need of theirs, and decided to go with somebody else. It's unknown whether other companies need a "collaborative tone", too, and it is most definitely unknown whether they'd mean the same thing by that.

There is only so much we can learn from two words. Therefore, I'd only be concerned if I were hearing such feedback often. Then, the multitude of different perspectives would help clarify the meaning.

I should also point out that your feedback was from a recruiter. Not all recruiters are good at accurately understanding and relaying feedback, which can result in a game of Chinese whispers. I'd put more weight on feedback from people directly involved in the interview process.

Answer 3

In software engineering, what exactly is meant by collaborative tone?

To me this translates to an estimate of a person's reception of feedback and willingness to change course when working with people. This is universal and not specific to software engineering.

I wasn't present for your answers to the questions but if you came off as a "my way or the highway" kind of person then they estimate an uphill battle in your collaborative skills.

They're looking for someone with more of a "Yeah guys, I love Bill's idea, let's do this!" attitude as opposed to "Well, ackchyually..."

Answer 4

"Collaborative tone" is not a formally defined phrase and has no specific meaning in software engineering.

It's just a reason that someone gave you as to why you weren't successful getting a job. It might not even have been the real reason, or there might have been more than one reason. We can't know.

Incidentally, your reaction (wondering what it really means, contacting the company again to ask them for more information, etc.) is a good demonstration of why providing an explanation to a rejected candidate is a bad practice. Well-meaning, possibly, but pointless. All they really meant to say was: "sorry, you didn't get the job". But the way they said it leaves you second-guessing yourself and questioning them, and trying to turn "you didn't get the job" into a conversation, which they've now had to excuse themselves from by saying something about "legal reasons", which is a fairly transparent way of avoiding your follow-up question. They should have not left it open to conversation in the first place - they're not going to employ you and you're not paying them for career guidance, which means there is no benefit in continuing the conversation, so it would have been better all round for them to just say: "sorry, you didn't get the job".

Don't over-think it. You didn't get the job. They tried to explain why with some plausible-sounding but vague justification, but they really shouldn't have done, it hasn't helped either you or them. Let it go.

Answer 5

Imagine you are a company picking candidates. You know the job is one for which the technical skills are generic. ie: writing web applications

5 candidates show up and you them through the technical interview. You evaluate that 3 of the 5 can do the job.

Now how to pick between the remaining 3? Enter the "behavioral interview".

Essentially, they are probably assessing communication skills, personality, and company culture.

In a nutshell, communication skill boils down to the ability to listen and understand others, personality boils down to something like a Myers-brigs or some similar personality model paradigm, and culture is a subjective measure on how well you are going to "fit in" to the team.

There are parts you can control, and parts you can't control. You can't control the company's culture, or your personality, but I think there is one thing that you can control to great effect, demonstrating empathy.

Take the common interview question: Can you tells us about a stressful situation and how you dealt with it?

You could make up some answer about how you the company was on the line and rose to the occasion, I'm a hero... blah blah blah...

Or you could say something like..

"Bob the project manager was really panicking and being mean to everybody. I understand his situation, he was under a lot of pressure to hit a date.

I was not going to be able to deliver on time, because the specs had changed, and I had to tell him. So I got to him 1 on 1, and asked him how he was feeling. He explained how much pressure he was under. I said I feel the same, lots of pressure.

Then I told him I was sorry, but I think I was going to miss the delivery, I think I need more time. Instead of yelling at me, Bob said OK, I get it, let's work together. Why? Because he knew I was feeling the same pressure he was.. so he didn't need to pressure me by being mean"

People like people that can demonstrate empathy. This is the key skill that builds trust between humans, and trust is the basis for human co-ordination.

Take every opportunity you can during the interview process to build empathy with the interviewers. Try to make it look natural, but understand that even if your behavior feels intentional to you, people are likely to be so pleased by your interest in them, that they won't notice it's driven by intent unless they are trained, or highly suspicious types.

Hope that helps :)

Answer 6

I liked meriton's answer but I would add that, reading the question, it felt to me that the replies were "automated" in a way to answer what you think the recruiter expects. Recruiters can distinct between "genuine" and "non-genuine" answers, so maybe they felt that you were not being genuine and were simply replying what you think they expected you to.

Answer 7

To me, collaborative tone is the difference between an interview feeling like a quiz, or like pair programming with a colleague. In the latter, you explain your decisions, bounce ideas off of each other, and complement each other's strengths and weaknesses.

The problem is that interviews naturally feel very quiz-like, and many interviewers even actively treat it that way. Because of that, interviewers usually don't hold a lack of collaborative tone against a candidate. However, as a candidate, you can work to establish that tone, and it will give you an advantage over other candidates.

The idea is to think of the exercise as if the interviewer is a less-experienced colleague who dropped by your desk to genuinely ask for help reversing a linked list or whatever. Aside from the nature of the problem, that's a common occurrence for most mid to senior engineers, and junior engineers have been on the other side of that situation many times as well, so think back to one of those times.

I bet the last time a colleague asked you for help you didn't spend 10 minutes silently typing, then said, "OK, I'm done." You want the interviewer to already subconsciously think of you as a colleague, as someone they can work with, even if your code isn't textbook perfect.

Answer 8

As some people have pointed out, this may just be a made up excuse to hide the real reason for rejecting you. Maybe they didn't like your face or the boss's nephew wanted the job. But it's also irrelevant, because you won't interview for the same job again. And in general, collaboration is definitely a factor in SWE hiring.

The question refers to your knowledge of how to work effectively with your team. This can mean doing things that you both know (coding together with other coders) or not (coding based on designs from a designer who doesn't know how to code). There is a lot that goes into it. Communication, knowing how to draw the line on each person's responsibilities, deadlines, varying skill levels, and others all go into it. It cannot be summarised in a web post -- otherwise instead of rejecting you, they'd hire you and tell you to read the post on your first week.

Unfortunately, it's also not enough to be good at collaboration, you must also be able to explain what makes you good.

The most direct way to address both points is to actually have worked together with people on something. This will allow you to answer yes when they ask you if you have experience collaborating, and also provide a source of examples you can give about how you collaborated effectively. Ideally, find ways to work with other people in your current job on some project. Failing that, you can try to attend (team-based) hackathons or contribute to open-source projects.

You can also try reading about how to collaborate well. Just reading is unlikely to teach you enough to impress any interviewers, as it's something learned by doing. But it can convince them your willingness to learn and perhaps they will take a chance on you. Besides that, it will help you be more successful in the first collaborations you attempt.

Answer 9

I have fallen in some interview traps in the past. In retrospect, they did me a favour, I prefer to be direct and not manipulative

Often for gauging your team skills they will tell you, "yeah, you can use the tools you want, or you can use your favourite tool z and y".

They are expecting an reaction, and it is not saying you are happy keeping using them. More, I will use whatever tools the team is using

Answer 10

When I asked about that specifically, the recruiter told me that they do not have further details for legal reasons

If this is the line the recruiter fed you, it's a pile of manure!

The recruiter has nothing to lose by sharing honest feedback with you (unless you've displayed axe-murderer tendencies, of course). This was a brush-off. I would say that said lack of "collaborative tone" means that you're a strong individual contributor with your own way of getting things done, and such a trait isn't necessarily a negative.

When the concern is more behavioral than technical for a technical position, I'd read things as a red flag. It could indicate that such a position means a normal condition of having to deal with a other peoples' messes. Companies like these want someone who follows instructions blindly and who doesn't push back on stupidity.

Pat yourself on the back. You've dodged a bullet.