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

In-house code tests

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest. →
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

Transcript

7 slides
  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

More Decks by Emma Guy

Other Decks in Technology