In-house code tests

As a part of the Exchange series on fixing technical hiring, I present how we do code tests as a part of the interview process at Monzo, and some advantages and disadvantages of this

https://www.eventbrite.co.uk/e/the-exchange-coding-tests-tickets-36608082761#

Transcript

1. In-house code tests
   @emmaguy
   

   View Slide

2. Who am I?
   - Android Engineer on the product team since Sept 2016
   - Been running Android Engineer hiring since Feb 2017
   - Inherited the code test (and did it myself when I applied!)
   - This is the first in-house code test I’ve done
   - Have also done pair programming interviews instead at a previous job
   

   View Slide

3. What’s the process?
   - We share a private GitHub repository
   - A small Android app written by an engineer (Baldrick!)
   - Has a Sketch file with the desired design
   - Has a readme explaining what the task is
   - They will then complete the task, and send it over
   - We review the code
   - We have a follow up phone call to discuss the exercise
   - A good opportunity for feedback from both sides
   - What did they think of the test? What are they proud of? What would
   they change? Why did you make choice X?
   

   View Slide

4. What’s the task?
   - The app is missing some features and has a few bugs
   - We ask people to prioritise their time as they think best
   - We don’t set a deadline
   - “If you’re busy right now, that’s okay!”
   - Long exercises bias against people who have more free time e.g non
   parents/carers
   - We update it - it’s quite similar to our actual codebase
   - Added Kotlin
   - Changed architecture to match what we agreed as a team
   - Which is nice to give candidates a sense of how we work
   

   View Slide

5. What’s good about it?
   - It’s fairly close (for an interview) to the real day to day
   work
   - Working with existing code
   - Adding new functionality
   - The exercise is quite open
   - This tells us what they think is important - more features or better code?
   - We identified what we’re interested in when reviewing it
   - Does the UI match the design? Is it close? Does it make sense?
   - How was feature X implemented? Does it account for Y?
   - Indication of approach to writing code
   - Their style, maintainability, etc
   - I have definitely learnt things from candidates!
   

   View Slide

6. What are some problems with this?
   - The exercise is quite open
   - Candidates don’t necessarily make the same choices they would on a job
   - sometimes they use new libraries just to try them out
   - Candidates can fall down the rabbit hole with some part of it
   - Someone who spends 3 hrs on it vs someone who really enjoyed it and
   went to town, makes comparison hard
   - Time consuming to review
   - Ensuring consistency amongst a team of 5 reviewers
   - Setting it up like our app means if you’re not familiar with
   the technologies we use, it will be harder for you
   

   View Slide

7. Thanks!
   

   View Slide