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.

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