Taro Logo

Android Engineer Interview Experience - New York, New York

April 1, 2019
Neutral ExperienceNo Offer

Process

I applied, and about three months later, out of the blue, I received an email asking if I would be interested. I had already moved to another location, but the recruiter said that they hired remotely as well.

Round 1: The first round was a phone discussion with an Android engineer. It was mostly a discussion of my background and what I was looking for. There might have been a few Android questions; I don't remember.

Round 2: After that, I was given a take-home project to create a small Android app that does a few basic things, like loading data from an API. You could also share an app you had already made instead. After my project was reviewed, they told me I made it to the final onsite round.

I was told that they had arranged for me to come into the offices and received instructions on checking in when I arrived. I didn't hear back or ask directly about travel accommodations, so I booked a bus ride. For past interviews, these have been reimbursed, so I kind of assumed that was the case, but I should have asked. I have family in New York, so I didn't need a hotel or anything.

The night before the interview, as I was just arriving in New York, I got an email with a schedule change that also said that the interviews would be conducted on Google Hangouts. When I asked about this, one of the coordinators said he thought the other one had corrected the mistake (apparently remotes don't go to the office for interviews). I was not reimbursed for the travel (about $80).

Round 3: The onsite consisted of five interview rounds, two of them technical. For the tech rounds, there were two interviewers. First, a coding exercise where they asked you to add new features or tests to your take-home project. The second round was a bunch of topical questions primarily about Android development and a few general software engineering topics. Their tech interviews did not include any data structures, algorithms, or system design questions. After the two technical rounds, there were three interviews with the Software Manager, PMs, etc. These were behavioral, culture-fit, and discussed my experience, etc.

I was told a few days after that I had done well on all but the first tech interview. They said they wanted to do a follow-up 45-minute interview with a similar structure: modify your project. If I passed this one, I would have to work onsite for the first three months. This time I was asked to improve the error-handling code.

I did not do well in this format. If I were coding this in real life, I'm usually not going to just automatically start writing code. I need to look at the Retrofit docs, as well as the API being used, to see exactly what HTTP error codes and exceptions might be returned and whether they are handled in onResponse() or onFailure(). For example, error codes are actually in onResponse(), not onFailure(). I want to think about and weigh different options and approaches. Not to mention that writing code while being timed with people watching and having to verbally explain what you're doing is extremely anxiety-inducing.

There's no perfect way to interview a candidate, but I wish I wasn't rejected based solely on this format if the other four or so interviews and the project were good (which is what I was told).

I waited a couple of days after that interview and then asked the recruiter if they had made a decision. She said they were still talking and would get back to me. I waited a few more days with no update and had to ask the recruiter if they had made a decision yet. They said they were looking for someone more senior, especially since it was a remote role.

PRO: Overall, I think they have a pretty good interview process. I liked that a take-home project was a major part of it. I also appreciated that they gave me a chance for an Android role despite not having much professional experience in mobile development. Everyone there seemed really nice, too.

CON: There were a lot of issues with communication throughout the process:

  • I was told I would be coming into HQ for the interview and not told that this was a mistake until I was already in New York. It would have been a lot easier to do the interview from home, and I wasn't reimbursed for travel.
  • I had to ask multiple times about the status after the onsite. Personally, I think you should let a candidate know either way after they interview. Even if it's a canned rejection email, that would be better than having to check to make sure you're rejected...

Overall, I'd say my experience was neutral, but it would have been positive if communication were better. In terms of difficulty, I've done four onsite interviews, and this one was on the easier side but fairly comprehensive (the whole process took 4-5 weeks).

Questions

Topical Android Questions (Activity/Fragments, Asynchronous code, mostly basic-intermediate)

General Software Engineering Questions (Dependency Injection)

Behavioral Qs: fairly typical ones - e.g., why do you want to work here? Describe a time you faced adversity at your job & how you handled it?

Modify take-home project (add missing tests, improve some aspect of your code)

Was this helpful?

Interview Statistics

The following metrics were computed from 1 interview experience for the The New York Times Android Engineer role in New York, New York.

Success Rate

0%
Pass Rate

The New York Times's interview process for their Android Engineer roles in New York, New York is extremely selective, failing the vast majority of engineers.

Experience Rating

Positive0%
Neutral100%
Negative0%

Candidates reported having mixed feelings for The New York Times's Android Engineer interview process in New York, New York.

The New York Times Work Experiences