I recently flunked the interview process for a Mobile Software Engineer role at American Express and thought it would be useful for future candidates coming down the pipeline to know what they are likely to be in for.

In terms of their setup and infrastructure, AmEx has two distributed mobile teams named Itchy & Scratchy. Each is headed by a boss who you'll likely talk with for your initial phone screen and introduction.

Most of the developers live near AmEx offices (e.g., Arizona, San Francisco Bay Area). However, the majority of the seven people I spoke with were definitely at home offices, or at least working from home the day they spoke with me. This suggests AmEx has an open mind when it comes to truly distributed, remote work.

Each of the teams is a mix of iOS & Android developers, product managers, QA folks, etc.

The mobile teams appear to be fully invested in using all the latest Atlassian tools (BitBucket, Jira, HipChat, etc.). Daily builds go out for QA each day, and a separate team builds the actual store release, which typically happens every six weeks. It sounds like they are trying to get to a four-week cycle per release.

While they are doing one-week sprints, it's not a super formal Agile setup, but more of a Kanban-style process (that's how it was described to me). My interpretation is that there aren't super fixed, hard deadlines for getting tasks done.

Because AmEx is a financial company handling customers' sensitive and personal financial data, a team member simply cannot use their own personal setup for their engineering work. Instead, they'd be provided with an AmEx computer. You do have admin access where you can install and work with various developer tools and utilities, but the IT department still has ultimate control over your company-issued machine.

On the flip side, iOS developers aren't able to use Interface Builder to build their interfaces. Instead, you'll need to get accustomed to an open-source tool (found on GitHub) called PureLayout. You'll be writing your user interfaces entirely programmatically in code.

In terms of the process: after the initial ("culture"?) interview with a team director, the next round consisted of three consecutive hour-long interviews with six people in total (two people per round).

It looked like the way they set it up was that each of these technical interviews had one mobile developer in my specialty (who was doing most of the questioning), plus another technical-type person (project/product manager, back-end engineer) listening in and periodically asking questions.

All of my interviews were done using a WebEx-style tool named Zoom. There are mobile apps for Android & iOS, as well as browser plug-ins for desktop machines. You'll likely need to use the desktop machines because you'll be doing Collabedit to showcase your coding skills.

It looked like a healthy range of different ages, maturity, and experience levels. The oldest guy in the interview collection was probably in his late thirties.

I didn't think the questions were too out of line for my specialty, and I finished up the day feeling really good about the discussions and interactions (i.e., the "positive experience" checkbox on this Glassdoor review).

But sadly, it was not meant to be. I received the generic "good luck finding another job somewhere else" rejection email within 24 hours of finishing the three-hour-long interview day.

Since there's traditionally no feedback from these kinds of big company interviews, I can only make guesses as to where I slipped up.

Were I to ever do this interview sequence again, I'd recommend reading up on XCTest or whatever Unit Test setup your mobile architecture uses.

I'd also be likely to not be as honest about my enthusiasm for working with a team of smart co-workers. I probably said something like, "I'm excited about working with AmEx because I'm burned out working short-term gigs as a contractor at other companies." "Burned out" might have been a phrase that turned off the two interviewers I spoke with.

This was a job I really wanted, as it looked like it had the right kind of professionalism, responsibility, and flexibility for the next phase of my career, and I'm truly sorry I blew it. Perhaps you'll have better luck?

Hopefully, my experience flunking the American Express interview will help you to prepare to pass your interview day. If you find any of the information in my interview review helpful, please let me know by voting "Yes" on the "Helpful?" question below. This helps to motivate me to be as detailed as possible.

Given an API that looks like this:

java interface EventReporter { enum Interval {SECOND, MINUTE, HOUR}; public void recordEvent(String eventName, LocalDateTime t); public Map<String, Integer> getEventCounts(String eventName, LocalDateTime start, LocalDateTime end, Interval i); }

And data that looks like this:

"x", 20:00:01 "x", 20:00:01 "x", 20:00:15 "x", 20:10:00 "x", 20:58:00

Describe a data structure and how you might implement the API's getEventCounts method for these three different Interval types.

Example Scenarios:

• Interval: Second For event counts of "x", from 20:00:00 to 21:00:00, with Interval.SECOND, you would get:

  {"20:00:01": 2, "20:00:15": 1, "20:10:00": 1, "20:58:00": 1}

• Interval: Minute For event counts of "x", from 20:00:00 to 21:00:00, with Interval.MINUTE, you would get:

  {"20:00": 3, "20:10": 1, "20:58": 1}

• Interval: Hour For event counts of "x", from 20:00:00 to 21:00:00, with Interval.HOUR, you would get:

  {"20": 5}

Design a Credit Card Parser that:

1. Will validate if a credit card is valid or not.
2. Returns the logo of the credit card (if valid) or nil in case the credit card isn't valid.

Dataset:

• User Input: 1111-1222-1112-1203, expiration date: 12/03. This is a Valid Credit Card.

Credit Card Types:

• Acme Credit Card: Starts with 1121
• Alfa Credit Card: Starts with 1111
• AmEx Credit Card: Starts with 3796