Improve hiring process

[zpatrick]

We need a command (or suite of commands) that helps with the hiring process. We currently have the !interview command that sets some reminders, but this can be revised/changed in order to better accommodate a larger set of features.

[andycmaj]

here are some scenarios based around the idea of a Pipeline for a candidate

at any step in the pipeline, we can bail out (decide not to proceed with the candidate).
steps in the pipeline, at the simplest level, might look like:

1. start pipeline
2. review resume
3. send take-home question
4. review take-home question
5. schedule a loop
6. loop
7. decide on candidate

Start a new pipeline for a new candidate

• action

me: !candidate add phil@genesis.com Phil Collins

bot: thanks! added Phil. Next step is to review his/her resume.

• periodic reminder

bot: hello! someone still needs to review Phil Collins's resume!

question: how to prompt for a resume upload?

Move a candidate to next step in pipeline

• action (Approve resume, move on to take-home question)

me: !candidate status Phil Collins

bot: review Phil Collins's resume.

me: !candidate continue Phil Collins

bot: ok! time to send Phil Collins the take-home question

Move a candidate to a step that requires input

me: !candidate status Phil Collins

bot: schedule an in-person loop

me: !candidate continue Phil Collins

bot: ok! time to schedule an in-person loop!
bot: <prompts for loop data (time/interviewers?)>

...?

Bail out of a pipeline

me: !candidate status Phil Collins

bot: schedule an in-person loop

me: !candidate bail Phil Collins

bot: are you sure? yes/no?

me: yes

bot: ok sorry Phil Collins didn't work out.

[zpatrick]

Perhaps we should start with an overview of the current processes and see where slackbot could make things easier:

1. Interview Process
   a) Set 0-many dates for interviews for a candidate
   b) For each interview date, schedule 0-many interviews at a specific time with 1-many interviewers (e.g. John Doe interviews with Jane Doe on 03/22 at 09:15AM)
   c) Prior to each interview, each interviewer needs to do some prep-work (typically, review the candidate's resume)
   d) Actually do the interview
   e) During/after each interview, each interviewer needs to record the interviewee's performance
   f) After all interviews have finished, aggregate all of the interviewers' scores and determine next course of action (hire, drop, or do another round of interviews).
2. Hiring Process
   a) I don't know all of the specific actions here, but from what I understand, it's essentially just a long checklist of items for a manager to complete.

With these in place, I think we can start to carve out some building blocks for what could be a useful tool:

• We will definitely need some concept of a "person"; this is a candidate during step 1, but a hired employee in step 2, so I think something more generic than "candidate" is probably for the best (not that is has to be "person", but I will continue to use that term for now).
• We will probably include a notion of an interview date. A person can have 0-many of these interview dates (most likely they will have between 1-3).
• We will also probably include a notion of an interview time, or a specific interview instance. For example, if, on 3/22, John Doe has interviews with person A at 9:00am, person B and C at 10:00am, and person D at 12:00pm, then John Doe has 1 interview date on 3/22, and 3 interview times on that date at 9, 10, and 12. Note that each interview time has 1-many interviewers (although, I assume this will just be a single person most of the time). The names for "interview date" and "interview time" are too similar in my opinion, so finding better names for those is probably a good idea.
• If we want to help with steps 1.e-1.f, we would need a mechanism for storing the "results" of an interview time.
• Step 2 seems like it could be relatively straightforward by using slack's built-in reminders.
  We could build a command that acts essentially as an alias for adding a bunch of reminders.

[andycmaj]

one consideration here is that this needs to work for teams with slightly different pipeline definitions.

i wonder if we could do something based on some kind of DSL:

pipeline:
  team: oce-mcm
  steps:
  - name: review resume
  - name: send take-home question
  - name: review take-home question
  - name: schedule a loop
     prompts: 
     - name: interviewers
        type: loop-interviewers (highly hand-wavy and probably a terrible config API)
  - name: loop
  - name: decide on candidate

pipeline:
  team: carbon
  steps:
  - name: send take-home question
  - name: review take-home question
  - name: schedule a loop
     prompts: 
     - name: interviewers
        type: loop-interviewers (highly hand-wavy and probably a terrible config API)
  - name: review resume
  - name: loop
  - name: decide on candidate

then

me: !candidate add carbon Don Johnson dj@vice.com

bot: OK! added Don. Next step: set up a loop.

maybe each step has a pre-defined handler in code that understands how to prompt/remind/follow up/etc.

Or maybe we just have different ideas about the scope of this. I was thinking it would be used end-to-end to track candidates, not just to set up loops.

[diemonster]

Improving the interview process is an important aspect of this bot, but I think where we're REALLY dropping the ball the most is during onboarding. We have employees without AD accounts, without computers, etc for 2+ weeks after their hire date. Insane. Our interviews might be a little sloppy, but I can't imagine they're nearly as bad.

As cool as a DSL and a hand-holding approach to the interview pipeline would be, I like to advocate that we knock out some very simple scheduling functionality for the interview portion using some of the primitives that @zpatrick has already implemented. This would be a very simple pipeline process that would effectively wrap /remind commands and send an early morning itinerary. Maybe we can add some other sugar from there.

As for onboarding, as @zpatrick pointed out, it's basically just a checklist of items that we need to hound hiring managers to complete. Just having a list and setting a reminder is not enough in this case.

[andycmaj]

sure i agree that onboarding is more severe when we mess it up, but also, anecdotally, we seem to take way too long from new candidate to closing the loop, and it's sometimes unclear who if anyone is on top of moving a candidate through.

but yeah i think the primitives are important and i'd just want to make sure whatever primitives you come up with can be extensible enough to support more than just checklists and reminders (though i can totally see where checklists and reminders would constitute pretty good primitives in themselves).

i think something generic/primitive that would work for tracking onboarding would probably work for hiring pipeline as well, FWIW.

/me closes and comments

[zpatrick]

splitting this up into

• Add !candidate command #38
• Add !hire command #39
• Add !interview command #40