[lhorie]

FWIW, this is not how Uber does interviews anymore. Now the process involves a technical phone screen and an onsite, with coding exercises that are meant to be completed in 30-45 minutes. I believe it's pretty on par with other tech companies in the Bay area.

[gcheong]

It's on par but still bullshit. I interviewed with Uber, got said phone screen, managed to solve the problem then was told Uber decided to "go in another direction" and would not be moving forward with my application. When I asked for clarification as to what that meant considering I solved the problem the recruiter called me and said some hand wavy stuff about how I didn't solve it "quickly" enough (I had plenty of time left to answer questions about it and ask question of the interviewer eventhough my first solution was not optimal and we did optimize it) but that the interviewer was up for having me try again. I declined.

[rifung]

> I interviewed with Uber, got said phone screen, managed to solve the problem then was told Uber decided to "go in another direction" and would not be moving forward with my application. When I asked for clarification as to what that meant considering I solved the problem

I understand the frustration with interviews but your comment seems to show a lack of understanding in how interviews work.

Interviews are a competition, not a pass/fail exam. Or if we're going with the exam analogy you're being graded on a curve, so you could get a 90% but if everyone else scores 95+% you didn't do well.

What matters isn't whether you solve the question but how well you do compared to everyone else.

[lhorie]

That's a great analogy. Just a small nitpick: While it's similar, in reality, interviews are not quite like being graded on a curve in school. The main point of a technical screener is to decrease the likelihood that a candidate will bomb the more demanding onsite interview loops. This is especially important because these loops typically take up most of a candidate's day, disrupt the day of a bunch of engineers, and might even cost the company hundreds or even thousands of dollars in plane tickets/accommodation costs if the candidate is flying in from out of state.

It's true that an interviewer might look at previous candidates to calibrate expectations, but they don't necessarily pit candidates for the same team against each other as would be the case in school curved grading. Usually what happens is a candidate just barely solves the technical exercise, but also raises a bunch of yellow/red flags. A common rule of thumb among tech interviewers is "if in doubt, reject". This is - in my experience - so common that a company will typically nab the first candidate that clears the expectation bar. It's actually rare that two or more candidates would be up for consideration at the same time because it's hard to even get a single one of high enough caliber in the first place, since good engineers are in extremely high demand and are almost never actively looking for jobs (recruiters reach out to them instead).

[fhbdukfrh]

This implies some sort of standardized assessment, which is seldom true. All sorts of bias is at play under the guise of culture, personality and team fit.

[rifung]

> This implies some sort of standardized assessment, which is seldom true. All sorts of bias is at play under the guise of culture, personality and team fit.

I'm not sure I understand how it does?

I just said that as an interviewer you have no idea how well you did because you can't compare yourself to other interviewers. Or, in other words, even if you somehow knew your "score" (for some made up score) that wouldn't give any indication on its own whether you passed or failed because you'd have to know what scores other people have gotten.

I agree with what you're saying about biases, but that merely affects what or how scores are given, and not whether you can make judgments about your outcomes based on score.

[gcheong]

Sure, but without knowing what the grading criteria are (coding speed?, optimality of solution?, etc.) I can only go by what appears to be the criteria according to the signals I get during the interview ("Is there a more optimal solution?", "This looks good to me.", ...). And yes it is pass/fail often times.

[retiredcoder]

That’s the ideal scenario, normalization with recalibration. Even companies doing that as their main business fail to do so and evaluate people.

Now imagine engineers doing that, in a highly competitive landscape, with no motivation or second thoughts. It is a jungle out there.

[lhorie]

> It's on par but still bullshit

I've actually had something like that happen to me too, but in a different company. From my experience as someone who's conducted a lot of interviews myself, I think this can happen due to various reasons:

- broken telephone (recruiting org rarely physically talks to eng org). If you call the recruiter after the fact, they may not have the context for the rejection and might make stuff up on the spot to get you off their back, because at that point, you're kind of "wasting their time" (given that their job description is to keep the hiring funnel greased, not maintain long-term relationships)

- technical interviewers don't always have interviewing training and may reject based on bogus reasons (e.g. feelings), then try to "justify the decision" after the fact. A few might not even keep good notes of their interviews

- sometimes candidates do solve a problem, but are legitimately rejected because they did so in a non-ideal way (e.g. performance problem, missing important edge case, struggling too much with basics like syntax, soft skill red flags such as lack of interest/proactiveness, etc). But often times the interviewer doesn't give the negative feedback to the candidate, leaving the candidate with a false sense of accomplishment.