[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.