Uber phone interview

Once I had an interview with Uber. I talked with the most miserable person who just didn't understand what was just asked. I failed this interview. So don't expect much :)

Normally it’s 2 questions , if u can’t get through even 1 , sorry you aren’t gonna make it

What was the question

I got dumped today after Uber phone screen. My coding problem actually wasn’t that difficult, but I failed to clarify one point which led me to a simpler solution rather than my original idea (which was closer to what the interviewer wanted). Oh well, I may have actually dodged a bullet there. If I’m unhappy as an Amazon SDE, Uber ain’t gonna be much better.

I ask a not mathy but corner-case heavy coding question but we explore the potential set of solutions verbally based on assumption changes. It lets me get code out of them quickly (a requirement for the recruiters), but also we get half the time to discuss system design. I pass 75%. 25% overall get through onsite. My bar varies by job title. I grade them to a job level. A sr eng can code the problem perfectly and fail the discussion phase miserably. Junior engineers will be evaluated based on how they think through the variations but aren't expected to have enough experience to consider all the different ways of solving it and how they might choose among the solution set. There's no wrong answer other than code that doesn't pass the unit tests I give them for the coding part. Failure of unit tests is about 95% in the first round. They get through the corner cases in the time alotted and they pass. Asking people leetcode questions is not effective in figuring out if they can design a reliable system. The other onsite people ask the trickier questions, but they all relate directly to our problem domains. If I'm not a code evaluator in the loop but am doing the algorithms loop part, I ask questions customized to their resume and don't force code. If they have done algorithm R&D before, it's pretty clear based on a short discussion if they know what they are doing. Reading algorithm books helps, probably leetcode, too, but I won't ask them to solve a particular problem if I'm in a deep dive portion. If it's a system design loop part, I do ask them what they want to change about the product and they have to design the solution as deeply as they can go in the time provided. It's a two-way conversation as I describe what microservices they can assume exist to keep directing them down to the lowest levels.

I also recently had a phone screen for Senior SDE role and it was LC-hard and even a DP question :( (first easy one but became hard one by appending some conditions). It is quite difficult to resolve LC-hard one within 30mins unless you did same or similar problem before. Of course, I was stuck, but didn't forgive up. I tried many approaches ASAP and fortunately found a brute force way. It ran well. Right after the interview, I thought that it would be rejected because I didn't find an optimal solution, but my recruiter said that I did really well. I will have an onsite next week. I think that we need to show that we will not forgive up whatever the problem level is and try to find any solution, even brute force one. It seems like they also wanna see such behavior.