Created
April 22, 2015 16:03
-
-
Save anonymous/528f9325c76b7d238350 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@tectonic's notes for Kerri Miller's (@kerrizor) RailsConf 2015 talk -- http://railsconf.com/program#prop_980 | |
Interview Day | |
- Set and communicate a schedule (“two-three hours, no laptop needed, we will get lunch, no need to dress up”) | |
- Set expectations (“we will be writing some code together”) | |
- Have a diverse set of interviewers | |
- Allow for breaks | |
Make a game plan | |
- assign areas of focus (you do SQL, I’ll do OO) | |
- have a hand-off plan (allow for breaks, schedule the handoffs so the candidate doesn’t wait) | |
- coordinate questions | |
Settling in | |
- start with a simple conversation | |
- double-check for red flags | |
- learn how they communicate | |
Behavioral Interviewing | |
- Hypothetical questions are game-able | |
- Ask for the story of specific situations | |
- Keep in mind they want to get hired! | |
Collaboration Audition | |
- don’t ask “fizz buzz”, ask about specific things that they would use at work, like MVC or sockets | |
- make level-appropriate | |
Pairing Audition | |
- not everyone pairs | |
- let them use their own laptop | |
- pick a kata or project you’re both familiar (but not intimate) with | |
- give feedback and see how they handle it | |
Presentation Auditions | |
- have candidate teach you something | |
- it doesn’t need to be technical | |
- set clear expectations about length, format, and investment of time. tell them not to prepare longer than X. | |
- do they use a lot of terms without explaining them? do they convey knowledge well? | |
- could also be a blog post, or similar | |
Interviewing Lunch | |
- if you do this: | |
- check diet restrictions | |
- you pay | |
- tell them upfront | |
- don’t bring too many people | |
After Interview | |
- record impressions immediately | |
- what would change your mind? | |
In Group | |
- gather all feedback, then discuss as a group | |
- find a consensus | |
- follow-up interviews can be problematic | |
- set candidate expectations for response and meet them | |
“I will let you know by Thursday at 3pm” | |
On Thursday at 3pm: “Sorry, we’ll let you know on Monday by noon” | |
Rejection | |
- don’t make it personal | |
- be respectful | |
- don’t say “we wish you good luck” | |
- explain potential for reapplication | |
- if candidate asks for feedback, you can give it. you should have a reason, or there’s something wrong in your process | |
We improve what we measure | |
- register predictions ahead of time | |
- discover your biases | |
- keep tabs on people you turn down | |
Others | |
- Bad idea: group / speed interviews | |
- Good idea: paying someone to work with you for a week | |
- Bad: puzzle questions | |
- Bad: whiteboard coding (it’s a judging, not collaborating experience) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment