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


Emma Guy

August 15, 2017

More Decks by Emma Guy

Other Decks in Technology


  1. In-house code tests

    View full-size 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 full-size 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 full-size 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
    - 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 full-size slide

  5. What’s good about it?
    - It’s fairly close (for an interview) to the real day to day
    - 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 full-size 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 full-size slide