Good projects start with good teams.
But what is, exactly, a good team?
At least on startup companies, good teams are the ones who work really well in group, rather than working alone. Working well in group means the team members:
Knowing how to build an efficient team is, therefore, essential and it goes all about knowing how each person will perform when working in group.
Now lets talk about the selection process. This article is not about the funneling and all other online tools one might want to use to select competent candidates. This article is about what do you do when you are on a one-to-one conversation with each eligible one -- and it works fine even for the indications from your network, which probably didn't go through the online competency filtering.
After the Resumé analysis and I get a sense of what to expect, these are the three questions I use to guide my way on selecting wonderful teams:
1. Tell me about a successful project you're proud of
2. Tell me about a project which you consider to be your worst failure
Proud people tend to wear masks and, while they may be eloquent on the first, they will have a hard time answering the second one -- the answer may be reticent or simply they will say there is none (which could only be true for the most junior candidates). They are bad in working in teams because pride is all about considering yourself better than the others and all associated sort of mess who damages team trust: don't listening to others, attempting to lecture peers, imposing punishments to the ones they think "committed a bad behavior" or "did something against them" and so on... and let's not forget that pride and forgiving don't mix together, so, adding to the list: proud people tend to resort to "black lists", where they put their "enemies", who will suffer all sorts of sabotages until they get "what they deserve" -- which is, usually, "loosing their reputation" and "recognizing the proud one's undeniable superiority". Ah, and because they are wearing a mask, they don't admit being contested and they also tend to lie -- both in favor of them and also to cover up something degrading to the "so important opinion others have about them". They, therefore, adore the practice of putting their blame in others and also stealing other's ideas and achievements. They will also minimize ideas and achievements not attributable to them.
Horrible for team work, no? The implications are so terrible that you, the interviewer, must make sure the interviewee understood that it is desirable that he/she talks about a real catastrophe. Nonetheless, humble people will answer. If they have a mindset of doing self-improvement auto-analysis and are self-motivated, they will be able to tell you what they would do, today, if they could go back in time.
Pro-active people will additionally tell you what they did to remedy the situation. The less you needed to ask about the remedies he/she employed, the more proactive they are.
Honest people will usually keep the "what needed to be different list" concentrated on themselves -- they will not try to blame nothing nor anyone else (after all, you asked them to tell you an example of a miserable failure of themselves and an honest answer should be about themselves, not others).
After that, I finally ask question 3:
3. What did the stakeholders/customers felt about the success and failed projects? -- or what do you think they felt?
Senior or engaged people will know. Juniors won't know even if they have an engaged personality (If they can imagine and give a reasonable answer, wonderful!). If they can't imagine what were customers and stakeholders' impressions, it means they cannot put themselves on the perspective of others. This kind of jealousy is terrible for team work and tend to reveal a personality who practice injustices toward others.
Now I'll talk about what some consider the most import aspect: the competency test. And, on this article, I'm also telling you how that could be done even for the ones who didn't do any tests -- or for the ones whose test results you doubt.
I prefer not to ask any out-of-context technical questions. On a one-to-one interview, my favorite questions are the "discursive" ones. Do you remember question 1, from the beginning of this article (about the successful project)? When you ask the candidate to tell you about the project, you will simply conduct him/her towards answering whatever technical questions you want. If his or her most important accomplishment doesn't include the competencies you want, you might ask about a feat using that competency and how successful or not it was.
This may require more effort from you, since you are likely never to be able to check your boxes in the order they appear... but, if you like to interview, it won't be a task, it will be a pleasure.
... and building the A-Team is very pleasant :)