41

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.

9
  • 83
    Never discount the fact they can may just say some subjective bullshit reason to avoid having to give you precise details. Apr 21 at 12:47
  • 37
    Line up 5 HR people and ask them to describe "collaborative tone". Get a coffee and enjoy reading 5 different answers.
    – Solar Mike
    Apr 21 at 18:44
  • 6
    Unfortunately it's roughly impossible for us to tell you what was lacking from the unknown answers you gave to unknown interview questions. If you have no idea where to start, I'd suggest finding someone to do mock interviews with, who should be able to point out less-than-ideal answers (especially if you highlight a perceived lack of collaboration as a sticking point). If there are specific questions which you're unsure of the correct answer of, you could also ask how to best answer those here.
    – NotThatGuy
    Apr 22 at 1:43
  • 4
    @MartinYork I have absolutely no idea why they'd have a debrief with a candidate and give meaningful information. I would just say: "You were not bad at all, we just found a better candidate." Feedback that is not accepted by the candidate can also annoy a candidate (which seems to be the case here). Apr 22 at 2:08
  • 2
    @SolarMike I thought the adage was "Ask 5 people if you want 8 different answers. Consult the manual (interviewer in this case) if you want the correct answer."
    – MonkeyZeus
    Apr 22 at 13:05

10 Answers 10

39

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

2
  • 8
    The OP may want to consider that thier team-working skills were actually adequate or better, but that someone else's were marginally better yet. As in, it was more a relative distinction than an absolute one. Apr 22 at 0:37
  • 1
    Just adding some concrete examples of how a programmer might come across as having a collaborative tone in an interview - I am thinking if they were describing a codebase they worked on in harsh terms, or they described solving an incident as a personal hero story where they saved the day when everyone else was an idiot, that a particular technology (Perl, VB, Python, whichever) is only used by morons, and so on. There's little evidence of this in the OP's question, though, which is all phrased thoughtfully and diplomatically.
    – Adam Burke
    Apr 23 at 4:46
19

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.

1
  • 3
    Ok, I incorporated the link into the answer so everyone can read the name of that game in their favorite dialect.
    – meriton
    Apr 22 at 4:47
6

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

3
  • 3
    Collaborative tone has to do with acknowledging that the answer to almost every good question is "It depends." Nobody wants a programmer who believes his way is the only true path. Companies want a programmer who has good ideas for their own code but can still operate in a setting where they have to code in someone else's style. Most projects work better when the team agrees on a style rather than each programmer doing it their own way. If you want to show this, discuss times when you followed other people's plans even if you might have done it differently if you were the lone wolf.
    – SvdSinner
    Apr 22 at 17:22
  • 2
    This is what I think to. If you're a candidate and you've been asked to solve technical questions, at the end of your answer, actually asking the interviewer if there is a better, or different way, shows that you are keen to learn and collaborate. Apr 22 at 17:41
  • 1
    As an ex-developer who nowadays has to deal with business and technical people, willingness to embrace sometimes jolting changes in a requirements is an incredibly valuable trait, that not everyone possesses. Everyone talks about agility, not many organizations or people really have it. Collaboration across diverse groups really helps here. Understanding the stakeholders, and valuing their inputs, even if they don't know what a computer is, is key.
    – Duane
    Apr 22 at 17:49
5

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

2
  • 4
    They offered to discuss it, so I took that offer. If it's pointless that I did that, how am I going to get any idea of what to do for subsequent pursuits? I was curious about this "collaborative tone" because I have seen it in quite a lot of literature pertaining to landing a position in software/web development, and it showed up in this series of interviews. Apr 21 at 13:11
  • 1
    It's pointless because you asked for a more detailed explanation and they declined to provide it. Now you're asking us what they meant, and we can't know. "Collaborative tone" simply doesn't have a formal or widely-accepted definition in software engineering. I don't know what else to tell you, sorry. If you've seen "collaborative tone" in a lot of other literature, read that literature that uses the term, I guess? Otherwise - you didn't get the job. They gave an unclear reason that didn't (and probably couldn't ever) help. Let it go. Move on. Apr 21 at 13:19
3

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 :)

2
  • 1
    I get how empathy applies in this kind of situation. When I'm the one being interviewed technically, I have no idea what empathy, or collaborative tone, should sound like if I'm not working on a project with them. That's why I posed or posted this question - to have a clue on this issue and to learn, but unfortunately, some read it being consumed from not having been hired. Apr 21 at 23:57
  • I understand. A lot of it happens in the "small talk" before you get into the technical part. that's really important. Still, it's quite possible to show empathy during the technical part of the interview. Discussing how you write code so that others can read it. Talking about documentation from a readers point of view. Asking them "Here's how I do it, how do you like to do it?". Or as simple as asking them "give me your thoughts on this?"
    – Duane
    Apr 22 at 17:35
1

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.

1

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.

1

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.

0

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

-6

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.

8
  • 11
    I don't understand the idea that turning people down for behavioural issues, for a technical position, is a red flag. In every technical job I've done over 20 years, a huge part of what I do is interacting with other people. If I don't communicate well, and collaborate with others well, or whatever, my technical contribution is worthless. Apr 21 at 15:47
  • 4
    "The recruiter has nothing to lose by sharing honest feedback with you" - and absolutely nothing whatsoever to gain. At all. Nothing. They've already rejected the candidate. They're not being paid to provide career guidance. They're not the candidate's life coach or mentor. Every minute spent explaining or justifying their decision, beyond a basic minimum for politeness, is costing the company time and money and earning them nothing in return. (Oh... and if they happen to mention something the candidate considers discriminatory, it might get them sued. So much for "nothing to lose"). Apr 21 at 16:17
  • 4
    @XavierJ, conversely, maybe it matters more to companies that value collaboration, as behavioral issues can have a negative impact there.
    – cdkMoose
    Apr 21 at 21:21
  • 2
    @mattfreake on the Workplace StackExchange, everything that someone personally dislikes is a "red flag", even if (as in this case) red flags aren't actually relevant as the candidate was rejected anyway. Also, any question can be answered with "you should be doing Scrum" or, if the question mentions they're doing Scrum already, "you are doing Scrum wrong". Another great general-purpose answer that doesn't matter what the question was, is "your workplace is toxic and you should quit your job immediately". It is known. This is the way. Apr 22 at 13:51
  • 3
    In some places team work and collaboration is massively important, just as important as technical ability. There are plenty of toxic people out there who are clever and I wouldn't want any of them on any team I am a part of.
    – Old Nick
    Apr 22 at 15:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .