On the hunt for a new role: my experience looking for Android positions in London

07 July 2018

This year, I started looking for a new role where I could work on Android stuff. I wanted to work on something that I used every day, alongside people who are (or want to be) involved with the Android community.

I haven’t interviewed for almost five years, when I left university. Since then, I’ve learned a lot about what I appreciate as an employee, and having been on the other side of the process too, it was interesting to see how other companies approached meeting potential new teammates.

This is a post about my various interviewing experiences and what I learned from them.

Finding opportunities

I interact with a lot of folks who are active in the community (mostly via Twitter and community Slacks). I trust their judgement and appreciate their advice.

When I let a few know that I was looking for a new role, I was really grateful when they took the time to talk to me about potential roles working alongside them.

I prefer this approach for finding opportunities over applying via a website or email, but it only works with companies that have people who get involved in the community.

Companies looking to grow their teams should consider hosting and sponsoring local meet-ups.

They should encourage (and enable) their teams to attend and speak at meet-ups and conferences as a way to increase the number of organic applications.

Provide time for and praise employees that share their experiences and knowledge with others through talks, podcasts or blog posts.

Chatting to a recruiter

After applying, you’ll get to speak to an in-house recruiter! In my experience, this was a phone call where they introduced themselves and then explained how their recruitment process worked.

(In one case, this first phone call turned out to be a one-hour behavioural interview rather than an introduction. I was a bit taken aback but managed to get through it.)

The recruiters want you to perform well throughout the process. They’ll (usually) give you as much information as they can to help you understand the typical timeline and help you prepare for each stage.

I worked with two in particular who were really good and one was especially supportive. She called before each stage, highlighting what they were looking for and how I should prepare. We had a long chat after the on-site interviews to debrief and after the process was complete, she called again to give me actionable feedback which helped me secure the job I have now!

When I was talking to the recruiters, I was pretty up-front about the other interview processes I was currently involved in.

I think most of the recruiters preferred the honesty because it helped them schedule the different stages, but the perception might vary from person to person (or even company to company).

In one case, the company interpreted my decision not to accept the offer on the spot as a lack of enthusiasm for the position.

Overall, I’m glad I didn’t rush it. I took my friend’s advice (“Go on your gut feeling”) and they were right — I’m really excited about the role I landed (star-eyes-emoji)!

Take-home assignments

Take-home assignments are a bit controversial. I’ve heard from friends who’ve spent weeks on them or who were asked to complete some pretty ridiculous projects (in terms of scope or complexity).

I completed two from two different companies, and for me, I enjoyed them. Each one had an explicit time-limit of four hours and there was an explicit notice on each one that you were not expected to finish the project/assignment which I appreciated.

They were similar in concept to each other: write an Android app that fetches data from an API and display some data. The setup was different:

  • the first one included a brief and a screenshot of what the completed assignment could look like, as well as a link to the API docs, but no code.
  • the second gave you a project that already implemented some features, a Sketch file (and PNG if you didn’t have Sketch) but no requirements. You could fix bugs, refactor, or use the mock-ups to add new features.

I preferred the second project because it was more realistic. When you join a team, it’s more likely that there’ll be an existing code base that you’ll work on. You can demonstrate:

  • how well you understand the existing code
  • willingness to accept decisions have already been made e.g. libraries, architecture, design patterns - without re-writing everything Your Way
  • conscious changes to existing conventions — make sure you have a reason beyond “I prefer it”!

When you join a new team or a new company, it can be really tempting to criticise everything and change things that you perceive are wrong. Luis Valle presented a session at Codemotion Milan 2016 called “Nobody Likes Working With You” which is worth a watch. You don’t need to be right all the time and there are a thousand and one ways to build an app.

I didn’t give enough time or attention to the first project, but I planned the second one meticulously.

I decided to avoid UI work entirely (relying on logs and Toasts to “display” data) and focusing on data fetching and transformations and tests (my feedback from the first project was that I didn’t demonstrate ability to test!).

Since I had limited time, I created a list of deliverables that could each be completed in 25 minutes. This meant that I could work on the project over a few days and if I planned for eight pieces of work, then I’d have 40 minutes to tidy up.

This is a post about my various interviewing experiences and what I learned from them.

The follow-ups for the challenges were different from each other.

In one case, it happened during the on-site. I gave an overview of the feature I implemented, then had to live-code a second feature in front of them. Without feedback on the first feature, I didn’t see much value in adding a second, since I did it the same way. I would have preferred being told “we felt you didn’t demonstrate XYZ very well but it’s very important to us, let’s do a short exercise on XYZ”.

Rather than live-coding the second feature in front of the two reviewers, I’d have preferred to pair-program to do it. At best, I’d have learned more about what’s important to their team and how they approach problems. At worst (if they’re not used to pairing), we’d both have felt awkward, rather than just me.

The review for the second project was over Google Hangouts. The reviewer had clearly taken some time to look over what I had done and had questions prepared for me which was great. They asked me what I thought of the architecture of the sample project and when I explained what I didn’t like, they seemed to appreciate that I decided to adopt it rather than change it.

I got a phone call asking me to spend an extra hour on the project to demonstrate some UI work because it looked like I was avoiding it (which was true!). I appreciated this direct approach rather than assuming that I was incapable.

In both cases, the reviews felt judgement-free and curious in nature. I’m not sure if this would be the case in all places, but the two companies in question have a reputation for hiring friendly and professional people.

Whiteboard coding

There was one interview where I was told to prepare for some whiteboard-style coding. I bought Gayle Laakmann McDowell’s Cracking the Coding Interview book, and worked through exercises from each chapter.

In my experience, the purpose of the sessions wasn’t primarily to show that you could solve problems but included:

  • showing that you can understand a problem, and that you’ll ask questions to make sure you understand before you start working on a solution
  • being able to articulate your thoughts about a technical problem clearly (before, while and after working on it)
  • demonstrating awareness and understanding of different problems sets in computer science and common approaches to solving them, as well as discussing the pros and cons of different approaches

The interviewers were friendly and engaging. They did their best to make me feel at ease and we spent about a third of each session talking about the role.

I drank a bottle of water in each session and I had to take frequent breaks but they were okay with it.

The best part of this interview was the lead-up. Everyone was supportive. I did around 20 practice interviews with people from Novoda who came into the office earlier or stayed later to help me. I was so, so tired and close to tears on multiple occasions. I talked with people from the community and made some new friends who gave me a lot of encouragement and energy when I really needed it.

That was my take-away from this experience — much love.

Talking… a lot

The other stages were all pretty much chats — either on Google Hangouts or on-site.

With the technical chats, all of the companies did really well to ask relevant questions about technology, patterns or situations that would come up in the day-to-day.

One company’s on-site consisted of meeting the whole Android team and doing the interview with all of them present (two remote and four in the room). It was nice to meet them all because it made me feel like they were all invested in their new potential teammate.

There were three on-sites which happened over lunch, but only one involved eating. This was the whiteboard coding day so even though the purpose of lunch was to meet the team and chat informally, my head was elsewhere; I accidentally ate carrots and swedes thinking they were fries/sweet-potato fries! A bad omen if ever there was one.

There was usually an opportunity to talk one-on-one with an interviewer at some point in each process. When I got the opportunity, I’d ask:

  • what do you like most about working here?
  • what do you dislike most? (This one was a little awkward in the meeting with the whole team, but to their credit, they answered it!)

Talking about negative aspects was really important to me. It works better with individuals, but it demonstrates that they value you enough to be honest.

More often than not, I found I could relate with what they shared, and this was reassuring for both me and the interviewer.

In closing

No matter how the interviews go, the recruiter is going to be in touch to conclude.

  • Always get feedback. Be nice and thank them
  • Just because they offer, doesn’t mean you have to accept
  • Take your time but be sure to acknowledge their messages and let them know when you’ll respond

If you’re looking for a new job, good luck and I hope you have as much support as I did.

I feel like I was really lucky to join Novoda when I did. I learned so much there and with help, guidance and hard work, I was presented with a lot of opportunities for which I’m really grateful.

If you have any questions about what I’ve written, or want to share your own experiences with me, feel free to reach out on Twitter.

Thanks to Maria, Emma, Zarah, Florina and Anastasia for help and feedback on this post ❤