A talk presented at https://www.meetup.com/LondonMobile/events/242592954/ detailing how the Android team at Monzo has grown and some reflections on running a hiring process
Scaling an Android team
Who am I?
- Android Engineer on the team since Sept 2016
- Company was ~50
- Today we’re 145!
- Responsible for Android hiring
- Growing the team from 2 to 6
The Android team
In the beginning...
- We were 2 Android engineers until late February this year
- This provides certain luxuries
- A phenomenal sense of ownership of the app
- Control over the code and code base
- You’re either writing or reviewing it
- No problem knowing what’s changing/new
- Code conventions, style discussions only need to
happen with 1 other person
- Lots to do - balancing shipping things vs incurring
technical debt can be tricky
- As the team grows, this changes
In the beginning...
- Code started from an agency who built the waiting list
- We had a clear plan for architecture early
- Agreed on what we liked, what we didn’t - in terms of
style, conventions, architecture and unit/UI tests
- Even in places of tech debt, we knew what to strive for
and reduced what we had to change later
- And did well to keep making it better
- Adding Kotlin and expanding usage gradually
- Learnt to live with some legacy that’s not in the way
- It might be gross, but it works!
How did the team grow?
- 3rd member joined in Feb 2017
- We had an offsite to agree amongst the 3 of us how the
app should move forwards, architecturally
- Which we documented!!
- We also introduced a weekly meeting, ‘Android Chat’
- To discuss things we don’t like, conventions, style, new
interesting things, potential improvements
- Kept notes of decisions made
- When the 4th and 5th members joined in late July, we had
great resources for onboarding
The wider team
The wider team
- On my first day, I went to the very last ‘whole engineering
- This would now be a 40 person standup
- Then we reorganised to have a product team
- 2 Android, 3 iOS, 2 backend & Head of Product
- Then/now: external product team
- Soon: splitting even more into feature teams
- Focusing around business goals, a tangible KPI to own
- Embrace change!
- If something feels painful, it’s probably because it is
- Write Request for Comments (RFC)
- For tasks which are: controversial how to implement,
affect the app architecture, unclear how to go about it
- Share large tasks around members of the team
- Teams of people can achieve things individuals can’t
- Split in a way that makes sense to avoid pain
Running a hiring process
- It’s very difficult to get great people
- There are many things to consider
- What are you actually looking for?
- What will this person do day to day?
- How will you assess them?
- How will you ensure this is fair and consistent?
- If there’s a code test, what must they do, how long
will it take, and how will you grade it?
- What will the job listing highlight?
- Once you’ve put it out there, how is the pipeline of
candidates who applied?
- Just because the interview is hard, doesn’t make it good
- Why are you not hiring the people you’re interviewing?
- Is it too hard?
- Are you asking unrealistic questions?
- Are candidates setup to perform at their best?
- Would early hires still get hired now?
- Often the process changes as you grow
- Or maybe it doesn’t… but it probably should!
- Test out changes on colleagues first
- It’s going to take time
- It’s not just about doing interviews
- Screening submissions, arranging and booking
interviews - time to hire matters
- Outreach - talking to people, blogging, speaking
- Humans have biases
- Try to be aware of what yours are and manage them
- It won’t be perfect at first
- Take the time to change what doesn’t work in the
current process - in the questions you ask and how you