First pass at Interviewing Guidelines

[zspencer]

We need to figure out what our interviewing + hiring process looks like and get it into github.

@duckinator had some really good thoughts, care to put them here?

[duckinator]

Sure. I'll make a comment with a slightly-cleaned-up version of what I said in the email, and we can start pulling things out into issues from that.

[duckinator]

With regards to interviewing people, I believe we should:

1. Handle and acknowledge the inherent subjectivity,
2. formalize and document the process, and
3. ask interviewees a few questions about themselves via email before the entire interview process, to ensure we are being respectful.

1. Handling and acknowledging inherent subjectivity.

These are the criteria @zspencer listed evaluating candidates in an email:

1. What did we learn?
2. How did they respond to feedback and suggestions?
3. How did they give feedback and suggestions?
4. At what level do we believe they're capable of contributing on client projects?
5. Would I be comfortable working with this candidate over a reasonable period of time?

There is inherent subjectivity in somebody deciding whether or not they want to work with somebody else. Handling this does not mean completely obliterating all subjectivity so much as:

1. Explicitly acknowledging its existence.
2. Having the questions we ask have objective answers — that is, collect data, not opinions.
3. Make the process rely on that data more than on opinions. E.g., determine how we would be determining their capabilities to contribute to client projects.
4. Implement systems to counteract unconscious bias.

2. Formalize and document the process.

Document the process, starting with the rough version provided by @zspencer (see above), and iteratively improving it. While we could just trash it entirely, I think it will be good to know and document why each change was made.

3. Asking interviewees questions.

This would be a brief questionnaire sent to all interviewees before the interview process starts. The purpose of it is to ensure we are being respectful towards them, both during the interview process and afterwards. Initially, the results would be sent to the interview facilitator(s) (those who are setting up the interview), interviewer(s), and anybody else who would need to work with them during the interview process. If they are hired, it would be sent to the entire team to ensure everybody has a reference for how the person wishes to be addressed, how to contact them, and a starting point for scheduling.

The questions would includes things along the lines of:

• Name that should be used to refer to and address them.
• Pronouns that should be used to refer to them.
• Title that should be used when addressing them in more formal contexts.
• Time zone so we have a better starting point for scheduling.
• Notes on communication. E.g., I would put that I have issues with anxiety and overstimulation and, as such, will sometimes need to walk away from a conversation for a few minutes or move to slower-moving mediums (e.g., voice/video to Slack or email, or Slack to email).

Legal name, assigned gender, anything regarding mental health, and things of that sort should not be collected in this questionnaire nor requested alongside it, to avoid unintentional leaking of that information. If they willingly disclose it in their responses, the interview facilitator should ask if the interviewee would like to remove or rephrase it prior to the information being given to anybody else.

The questionnaire should explicitly state that it will be passed around to the rest of the team if they are hired. Their should be a separate way for them to pass information to the interview facilitator(s) and/or interviewer(s) privately, in case there is anything they would prefer to not have mentioned to the entire team (e.g., anything listed in the previous paragraph). If they are hired, we should verify that they are okay with the latest version we have on-hand for them being passed to the entire team, and give them a chance to update or edit it, prior to doing so.

This information should be able to be updated as necessary without question nor gatekeeping, and the latest version should always be easily accessible to other team members. E.g., by having it stored in a wiki once somebody is hired.

[duckinator]

http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community https://modelviewculture.com/pieces/technical-interviews-are-bullshit https://modelviewculture.com/pieces/we-hire-the-best https://medium.com/@shaft/the-meritocracy-myth-ce3150c2a33f

Thoughts so far:

1. We really need to figure out how to confront unconscious bias.
2. Multiple small coding exercises instead of one big coding exercises will give us a more varied look at their abilities.
3. We don't just write code — we also review it. Perhaps the interview should acknowledge that.
4. An exception to 2: Not everybody is good at this — especially more junior devs. How should we handle that fact?
5. As suggested in "Technical Interviews are Bullshit": Assuming we implement 2 (and/or other things not explicitly tied to a person's identity), we can wait until two or more interviewees do a certain exercise, then pass them off to another dev — without saying which dev wrote what code. This may not work at the smaller scale we operate at, sadly.

[duckinator]

Another MVC article: https://modelviewculture.com/pieces/25-tips-for-diverse-hiring An entire MVC issue(!) on hiring: https://modelviewculture.com/issues/hiring

[duckinator]

I pulled the part about the survey out into #2 — Personal Information Survey.

[krainboltgreene]

Should we think about formalizing a post-interview process as well?

[zspencer]

@krainboltgreene I don't think that's part of the hand-book though; unless you mean "here are the things you should know + do after being hired"

[zspencer]

@krainboltgreene split that into #4