Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Tech Interviews that don't suck

52654cfef40a0579cb31843b01ba49bc?s=47 Marc Tamlyn
September 16, 2016

Tech Interviews that don't suck

For many interviewees and interviewers, hiring engineers is a difficult and stressful process. It's widely regarded that inverting a binary tree on a whiteboard is not a great approach to finding the best people to work with, but what is?

I recently had the opportunity to design an interview process from scratch. We will look at the interview process I created, its strengths, weaknesses and inspiration.

52654cfef40a0579cb31843b01ba49bc?s=128

Marc Tamlyn

September 16, 2016
Tweet

More Decks by Marc Tamlyn

Other Decks in Technology

Transcript

  1. Tech interviews that don't suck Marc Tamlyn Photocrowd

  2. Disclaimer • I am not an expert • I have

    hired about half a dozen people • This is what works for me! • Mostly relevant to small companies
  3. What makes a bad interview? • Employing the "wrong" staff

    • Formulaic and overly specific • Interviewees feeling like they haven't been able to demonstrate what they know • Misleading about what the job will entail • Biased • Diversity • Background • Time
  4. What makes a good interview process? • Good staff employed

    • Personable • A learning engineer • Attitude to perfection, prioritisation, criticism • Fair process, promoting diversity in the team • Suits the role the interviewee will fill • Adaptable to the interviewee • Positive impression of company - to successful and unsuccessful applicants
  5. Interview process • Design a process • What role are

    you interviewing for? • What are the priorities for that role • Where could they be in 6 months? • Who needs to be involved? • Future colleagues • Team leads • Non technical people • Anyone they would work directly with
  6. My interview process • Advertisement • Screening • Initial contact

    • Pre interview • Interview • Coding • Company chat • Review • Discussion • Feedback
  7. Initial contact • Don't require a complex process • Redacted

    demographics • Or, be deliberately more accepting of alternative backgrounds • Look for positives, not negatives • No Github profile does not make a bad engineer • A strong Stack Overflow profile may suggest a helpful nature, or someone who spends a lot of work time on Stack Overflow…
  8. Pre interview • Keep it short - 15 mins max

    • Give them choice of phone/video/in person • Get a feel for their background and experience • Why are they interested in your company? • Ask one or two specific knowledge questions appropriate to the level of experience they have • Give them an opportunity to ask questions • Explain how the rest of the process will work if they are successful
  9. Coding • Non-production • Short time frame • Task is

    more than is achievable in the time frame offered • Set expectations • Multiple valid approaches to the problem • Give them an opportunity to solve problems • Give them an opportunity to make decisions • Leave holes where they might ask for clarification
  10. Coding • Asking them to code at home will tell

    you how much spare time they have, not how good they are • Minimal setup • On their own machine • Allow use of any tools and libraries they think will help • Make yourself available to them during the process
  11. Review • Involve as many of your staff as possible

    • Look at prioritisation of parts and discuss with them what they didn't do and why • Tests? Documentation? Style? • The quality of their code is NOT the assessment criteria • How they respond to the review IS the assessment criteria
  12. Review • Pick up on a few things they have

    done • Something good • Something not so good • Something they haven't done • Discuss each one • Why did they do it that way? • What other approaches can they think of? • Given this other approach, which one would you choose and why? • Disagreement is fine!
  13. Bias • Accounting for interview pressure bias • Not everyone

    will perform at their best in an interview • Give an opportunity to provide an example of some code they have written, but preferably don't require it • Review that similarly, look for learning opportunities or discussions
  14. Discussion • What makes a good question? • Has a

    different answer depending on knowledge and background • Opens up the opportunity for discussion and learning • Something the interviewer knows a lot about • Something the interviewee may have an opinion on
  15. Discussion • Examples of open ended questions • What's the

    most interesting piece of code you wrote recently? • If you could master one technology in the next year, what would it be? • What's the difference between a Form and a ModelForm? • What is the purpose of a database index, and when should you use them? • Name two common security flaws a website can have and what $FRAMEWORK does to prevent them? • How could I do break that if I wanted to?
  16. Company chat • With non-engineers • Talk about ethos, company

    background, direction, product development, clients, benefits, socials… • Lots of opportunity for them to ask questions
  17. Feedback • Give an estimate of when you'll get back

    to them • Give positives and negatives, even to candidates you are offering a job to • Take the time to explain your decisions as much as appropriate
  18. Summary • It's about them as well as you •

    Design the process for the role in question • Give the candidate the opportunity to shine • Avoid bias • Be honest • Give yourself time
  19. Thank you github.com/mjtamlyn twitter.com/mjtamlyn photocrowd.com/mjtamlyn All photos by Photocrowd users