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

In-house code tests

Emma Guy
August 15, 2017

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#

Emma Guy

August 15, 2017
Tweet

More Decks by Emma Guy

Other Decks in Technology

Transcript

  1. 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
  2. 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?
  3. 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
  4. 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!
  5. 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