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
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 - #kotlin-tips - 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 - On my first day, I went to the very last ‘whole engineering team standup’ - 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
Anything else? - 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
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?
Hiring process - 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
Hiring process - 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 ask them
emmaguy
doradora09
ganota
sumiren
ikuyamada
takufujii
carta_engineering
uzulla
foursue
lmi
megabitsenmzq
tgalopin
odasho
geoffreycrofte
chrislema
andyhume
chriscoyier
ammeep
frogandcode
mza
eileencodes
jensimmons
morganepeng
productmarketing
addyosmani