Initial commit

README.md

@@ -0,0 +1,117 @@
+#Interview Preparation Guide
+
+When we interview potential developers to join our team, we want to be mindful of how we use their time and how we treat them - we want to learn as much as we can about people, whilst giving them the best experience possible.
+
+###Dos
+
+- Be friendly - this person could be your colleague.
+- Assume they are competent and it is your job to help them demonstrate that.
+- Prepare - know what questions you are going to ask, have more than you think you need.
+- Leave (or make) time for them to ask you any questions they have for you.
+- Look for understanding rather than specific words (this is especially important when interviewing people in their second language).
+- Send in your feedback promptly.
+- Be mindful of potential bias in feedback - talk to Cate if you are not sure if something is / should be relevant.
+- Consider that if they have a different perspective from you that can be a *really good thing*.
+- Practice! Ask one of your colleagues to pretend to be your “interview candidate” and get feedback on how you did.
+
+
+###Don’ts
+
+- Ask personal questions (it’s OK if they volunteer information, but move on from the subject).
+- Be confrontational - this is not a battle.
+- Ask questions requiring esoteric technical detail.
+
+
+###Good Questions to Ask Before Interviewing
+
+- What kind of person are we looking for?
+- What skills would make a big difference to the team right now?
+- What perspective are we missing?
+
+
+
+## Headings for Feedback
+
+These are suggestions, you may want different ones. However breaking out different attributes explored in the interview is really useful.
+
+###Overall
+
+What is your overall sense of them? What stood out to you? Is there anything about them that needs to be understood better by other interviews? This is where you put your decision and justify it: yes or no. 
+
+###Questions Asked
+
+What did you talk about? What, if any, extension questions did you ask?
+
+###Analytical Ability
+
+How did they approach the problem? What did they run into? What connections did they make that impressed you?
+
+###Coding Skills
+
+How did they do at writing code? What about tests? When they ran into issues how good were they at debugging them? Include the code that they wrote.
+
+###Communication Skills
+
+How well did they communicate? Could they explain their thinking? Did they listen? When you gave them feedback or suggestions, how did they respond to it?
+
+###Notes
+
+If you take notes as the interview happens (and this is a good idea), include them. They will be useful for your reference, if nothing else. It’s can be really helpful to include time stamps, too.
+
+
+## Resources for Being a Better Interviewer
+
+###[How I Interview](http://www.catehuston.com/blog/2015/04/01/how-i-interview/)
+
+Overview of process for conducting an interview, from before to after. Includes things like: getting in the right headspace, how to start and end an interview, writing up feedback and removing bias.
+
+###[Things You Don’t Learn in Technical Interviews](http://www.catehuston.com/blog/2015/07/15/things-you-dont-learn-in-technical-interviews/)
+
+Discussing some of the things that you don’t learn in a technical interview, and removing conclusions that you can’t support from feedback.
+
+###[12 Challenging Steps to Being a Better Interviewer](http://www.catehuston.com/blog/2015/10/07/12-challenging-steps-to-being-a-better-interviewer/)
+
+Some overlap with the previous two, notes from a talk about being a better interview. Includes: getting into the right headspace, projecting warmth, power dynamics, and communication.
+
+###[Technical Interviews and Time Management](http://www.catehuston.com/blog/2015/12/02/technical-interview-questions-and-time-management/)
+
+Focusing on asking a good question and keeping an interview moving a long. How do you make everyone feel like they have accomplished something? There are different ways to make a question variable in size.
+
+
+## Interviews and Culture
+
+###[We Hire The Best](https://modelviewculture.com/pieces/we-hire-the-best)
+
+On the rhetoric of hiring in tech and how it is at best meaningless and at worst harmful.
+
+###[Lowering the bar](http://www.moishelettvin.com/2015/12/16/lowering-the-bar/)
+
+Metaphor of interviewing as “fill out the potato": *“One is that, when you get together with other interviewers who’ve talked to the same person, you can consider your role as “filling in pieces of the potato” – one interviewer may have a better idea of the candidate’s strengths along the communication and empathy vectors, while another might learn more about their facility with javascript. When you talk after your interviews (or when hiring committee reviews your feedback, depending on the vagaries of your particular hiring process), a “fuller picture of the potato” starts to emerge.”*
+
+###[RailsConf 2015 - Why We're Bad At Hiring (And How To Fix It)](https://www.youtube.com/watch?v=vef_ARdnqWY)
+
+Talk by [@kerrizor](https://twitter.com/kerrizor) on hiring processes, how the work, how they don’t. To do better: “Know what you’re looking for, Find people who have it, Keep improving your process.” When writing feedback, think about what would change your mind. Full of useful information and insight.
+
+###[How to Ensure You Don’t Hire Anyone](https://medium.com/@morgane/how-to-not-impress-me-during-the-interview-process-b2b99f30298b#.c9xz1y4jh)
+
+Some comments on hiring processes in SV and ridiculous processes. E.g. unrealistic NDAs, and poor communication.
+
+
+## Interviews Going Wrong
+
+###[On the unreasonable reality of “junior” developer interviews](https://samphippen.com/on-the-unreasonable-reality-of-junior-developer-interviews/)
+
+Two senior devs did a junior developer problem. 6 hours later, they still weren’t finished.
+
+###[Engineers can’t gauge their own interview performance. And that makes them harder to hire.](http://blog.interviewing.io/people-cant-gauge-their-own-interview-performance-and-that-makes-them-harder-to-hire/)
+
+Data from a service that facilitates a lot of interviews. Engineers can’t predict how they did (unsurprising) but when they feel like they did badly, they are less likely to want to work there.
+
+###[The Worst Product Manager Interview Question I Was Asked](https://medium.com/startup-study-group/the-worst-product-manager-interview-question-i-have-ever-been-asked-678f85260fbd#.xuse84hax)
+
+Example of a really bad product management question that completely misses the point. Also: adversarial, combative interviewer. Case study in how to make someone *never* want to work for you.
+
+###[Interview Humiliation](http://deliberate-software.com/on-defeat/)
+
+Example of a really terrible interview. The candidate is set up to fail with inaccurate information, and then derided, diminished, and generally treated appallingly.
+