The communication with the recruiter was responsive. To my surprise, for the on-site interview, the recruiter sent a pre-defined schedule with the interviewer’s names and what they would be evaluating (i.e., past project in-depth review, system architecture, code question, and problem-solving). You could bring your laptop to use your favorite IDE and present an open-source project you contribute to. That gave me the impression it wouldn’t be yet another dull white-board coding interview (i.e., Google).
I'm not sure if that set some unrealistic expectations, but the interview experience was a total disaster.
The whole interview started late, so neither the interviewers nor I had a sense of time whatsoever. This initial delay was due to a rearrangement of interviewers (one of the senior engineers was busy apparently). To make things worse, they didn’t reorganize a new schedule to avoid overlapping topics: I was basically asked about project review, code questions, and design by every interviewer (good luck to you trying to fit all these topics into one interview slot under pressure and subjective evaluation).
To make matters even worse (it is always possible...), the first interview started only with the shadow interviewer because the main interviewer was remote, so someone had to find him and then get him into a conference room to call in, etc. After 10 minutes past the initial considerations, he arrived via Skype. I had to repeat all introductions again, then was asked to talk about a past project and go through its design.
I usually draw architectural sketches on the white board, then any in-depth discussion proceeds from there. In my case, it was just a waste of time because the main interviewer was remote, so there was no interaction whatsoever (good luck to you trying to make a white board readable via any laptop camera).
As a follow-up to the project review (per the recruiter’s email), they were supposed to ask a coding question on top of that (e.g., add a new feature). Perhaps, given the situation, I was asked a random coding question by the main interviewer. The question was very shortly defined with one single input/output sample. I.e., the sample wasn't specific in terms of interface definition (e.g., is the input sorted? Is the output a string, a list of elements, or should I define my own?).
The question was vague, either deliberately or the interviewer was poor. Anyway, I had to ask questions to frame the problem properly. On top of that, he nodded affirmatively when I asked whether a modularized OOP design was a requirement, so I spent more time defining ADTs and methods to parse, process, and output the solution. In hindsight, it feels like he confirmed whatever I asked just because he was clueless and got a random interview question from the internet a few minutes before the interview (raise your hand if you had a coworker who didn't do that!?).
Then came the coding time. After about 10 minutes of writing the code, the shadower interrupted me to write unit tests because I was running out of time. It was unfair because (1) the main interviewer should have been tracking the time since he arrived 10 minutes late and asked the question! (2) the main interviewer added several design requirements! At that point, I knew it was game over and wanted to push back for more time…
From that point onwards, I coded like a maniac with fear of running out of time.
What was the outcome? In the first interview session, the shadow said I over-engineered, and the second said I coded too fast.
Well, good luck to them hiring senior developers. Maybe a junior developer wouldn’t “over-engineer” just because they can’t. Perhaps they wouldn't code too fast because they had nothing to say in the past project review, leaving plenty of time to code your palindrome question.
For prospective candidates, it doesn't really matter how much experience you have or how great your referrals are; just read one of these technical interview books, and you should be okay. Don't over-prepare; luck is a considerable factor in these interviews.
Describe your most challenging project from both a technical and non-technical perspective.
Design a large-scale, web-based Service-Oriented Architecture (SoA) for mobile clients with location awareness (e.g., Uber, bike sharing, etc.).
Self-evaluation question: When will companies realize the current hiring process has reached exhaustion?
The following metrics were computed from 4 interview experiences for the Uber Senior Software Engineer role in New York, New York.
Uber's interview process for their Senior Software Engineer roles in New York, New York is extremely selective, failing the vast majority of engineers.
Candidates reported having very negative feelings for Uber's Senior Software Engineer interview process in New York, New York.