WTE! Another programming question ?

[Peter_in_2780]

(Only half tongue-in-cheek) Get your short list together and give them a team exercise. Observe closely.

Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012

[Jon McKee]

You need to define "team player" first. Every person has a different idea of what that means. Once you have a concise idea of what that means to your team, you'll have a list of traits to look for in a candidate. Tailor your questions to indirectly give you an idea of whether they have that trait. So if one of the traits is "willingness to pick up another person's slack" or "ability to work with difficult people", ask them about a time they were on a dysfunctional team and how they approached that problem. Or something like that. That's how I'd approach it at least. It's difficult though because candidates are conditioned to appear perfect at all times or have their applications thrown in the dumpster. Just like candidates are conditioned to place a greater emphasis on competitive programming skills than actually being able to write readable, maintainable code. In both cases, the former gets you a CS/SE job while the latter gets you a job at McDonald's. Just my anecdotal opinion though as a professional interviewee.

[Jon McKee]

This is the best answer :thumbsup: I was gonna say something similar but very few places are willing to spend the resources needed to do it.

[Greg Utas]

A lot of universities now assign projects that are done in teams. If a candidate worked on such a project, you could ask open-ended questions, such as what they liked and disliked about the experience, or what they believe are the advantages and disadvantages of working on a team. However, I wouldn't over-emphasize teamwork. Development is often done alone, and poor software drags everyone down regardless of how well its author gets along with others. Teamwork involves things like sharing information, constructively participating in design and code reviews, and helping to get new staff members up to speed.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

[PIEBALDconsult]

PHBs think "yes men" are "team players", but they're not.

[Jon McKee]

Yep. It takes way more investment in the team, product, etc to disagree.

[Mircea Neacsu]

With just some questions it's probably hard and unreliable. If feasible, I'd suggest a test where you give them a piece of oldish software, describing what goes in and what comes out and ask them to incorporate a new feature. Primadonnas will be tempted to through away all the old code and write everything from scratch (because their code is best). Others may prove utter incompetents who cannot do any work and, if you are lucky, you might spot some that can treat a piece of code with respect and adapt their way of thinking to blend in with what's already there.

Mircea

[Lost User]

I've never heard the "team" use the term "team member"; only management: "He or she wasn't" (whatever that means). I think it means being part of the herd.

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food

[GuyThiebaut]

I find perhaps one of the most difficult traits to work with in a team is someone who is inflexible and overly strongly opinionated. The reality is that most things, including software development, are nuanced and an overly opinionated person, while they might get work done and be technically brilliant, can store up a whole load of technical debt problems for later as their strong opinions may make it difficult to discuss an issue. So I would consider asking a question that will show you how they deal with something when they have a disagreement - how willing are they to listen to and understand another person's point of view?

“That which can be asserted without evidence, can be dismissed without evidence.”

― Christopher Hitchens

[megaadam]

Guaranteed to yield the cleverest bully :suss:

"If we don't change direction, we'll end up where we're going"

[megaadam]

Jon McKee wrote:

Tailor your questions to indirectly

Exactly that tailoring is what I meat to ask about.

"If we don't change direction, we'll end up where we're going"

[peterkmx]

By coincidence, I've seen recently an interesting opinion about a method of interviewing a candidate by letting him/her talk about the way how he did his favorite project and how he solved the issues which came along. The point of this method is to differentiate a smooth talker from a really useful person, as smooth talkers avoid explaining details out of fear of being caught on something, while valuable candidates do just opposite ... I'am not sure, but it seems that this method came from Elon Musk. I think that this also helps to evaluate the communication skills/style of a candidate, so there are 2 useful points in this, or perhaps more ...

[Jon McKee]

I would think about the ways they can answer your question and try to ensure answers will fall into a useful range. Try to answer the question yourself and if a lot of experiences come to mind that would be irrelevant to what you want to know about the candidate then rework the question - be more specific, change the scenario, or change the perspective (e.g. failed vs succeeded at a task).

[Greg Utas]

Or being a doormat. The term is sometimes a red flag.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

[megaadam]

:thumbsup:

"If we don't change direction, we'll end up where we're going"

[den2k88]

Extract some non critical page of code from one of your product and ask them what they understand of it and how do they find them, especially on trivial stuff like formatting. Primadonnas will invariably assert themselves as better than that.

GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++*      Weapons extension: ma- k++ F+2 X

[Dan Neely]

Jon McKee wrote:

but very few places are willing to spend the resources needed to do it.

Not just that, but a large number of candidates won't be willing to do something like that. To be useful it'd either need to be done with everyone on and interacting at the same time, or really extended in time to generate a useful number of async interactions. The former is a scheduling nightmare if done outside of working hours, and will largely exclude the currently employed if done within them. The latter being an even bigger time suck will have more people noping out; and while you could try to counter that by offering to pay participants for their time, that would run into various moonlighting restrictions (either bans or mandatory disclosure/approvals to avoid conflict of interest risks) for people who are looking to change jobs.

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius

[Slow Eddie]

Have you ever worked in a team before, and if so can you give us a reference to the team leader, so we can contact him/her?

ed

[User 13807368]

How about asking them about any obstacles they had to overcome when working in a team environment and how they were able to overcome them?

[Jon McKee]

True. I think it could be done near the end of the process assuming you're allowed to schedule outside of 8-5 and the candidate list either is all +-2 timezones or can be grouped into buckets like that. As far as willingness, a lot of engineers don't like the idea that our entire skillset is boiled down to whether we know the one trick for an optimal solution to a competitive programming question and yet we have to deal with that still. To be fair that's probably not everywhere but it does seem to be a growing trend.