Having never worked in SV, are these home assignments common there? I know several engineers who would refuse to do any homework at all as a matter of principle, so a task of this magnitude without compensation sounds laughable on the face of it.
I personally don't put up with it, but then there are always lots of commenters in HN who bemoan whiteboard interviews and prefer take-homes. To each their own.
I would rather whiteboard about the design of the app/tool than some random question another engineer pulled out of their ass twenty minutes before the interview and has unreasonably strong opinions about the design and implementation based on whatever source they stole the problem from because they don't actually understand the problem either.
If a company gave me something as time-consuming as Uber's, I'd say no thanks. Otherwise, I'd prefer a home assignment over whiteboard coding since it will give the interviewers a much better idea of my skills.
I think pairing the take-home with the in-person interview is a nice compromise. Assuming you didn't turn in complete crap code, they can call you in for the interview and you can talk through your solution and why you made the choices you did.
Another possibility is to make the take-home a part of the in-person interview, and just give the candidate a laptop and internet access and a few hours to work on it, with an interviewer at hand to answer questions. The downside of course is that everyone gets less time just talking to each other. A plus is that this timeboxes the possible assignments so things don't get too crazy, and also weeds out people who can't complete it in that time (which could be bad, too, I guess).
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.
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).
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.
Now imagine engineers doing that, in a highly competitive landscape, with no motivation or second thoughts. It is a jungle out there.
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.
They choose from 2 languages,and an experienced coder is done in 5-15 minutes. A fresh grad maybe 45 minutes.
The tasks have no practical work application, and are just code samples.
If they pass this and a phone screening, there is a live challenge as well -- the take home version we give people 48 hours (their choice of weekday or weekend). In person is time boxed and part of the interview, but is the very last stage and usually simple functions to rule out people that needed help to get to that point or simply had someone else do all the work (which we've already had come through our small 10 person te team)
We've been super successful in mining the late round rejections from companies like Google. Getting to an on-sight is a huge signaling factor, they do the early filtering and we can move fast to an offer
I am not a coder. I am a very experienced manager/director/PM OF development/DevOPs/IT teams.
However, prior I was in architecture.
And starting out as a draftsman, it was extremely common for architectural companies to tes out your drafting skills on AutoCAD with a timed test.
I recall the two I took:
In Redmond Washington in 1994, I was given a test to draw out a site plan for a chevron gas station, whom was their primary client.
I was given 15 minutes. I drew it in 12.
They said that not only was I the most accurate, but the only person ever in the history of their company to finish it. [became a core designer on what was then the 'revolutionary' designs of marriage of gas-stations and fast-food restaurants... [[Soul killing]]
I got hired... but then I became CAD manager - and then just decided I liked "computers" and not arch... so I then moved to SF. So I moved on to hospitals... gosh...
... (became IT manager of a small firm on the peninsula)
So then I worked for a design firm, and they also tested me upon interview... in CAD...
Isometric datacenter cabling plans....
I wasnt really familiar with plane changing in AutoCAD at that point so I did it all manually designed based on switching my orthos for each thing. Finished a complete cable tray design in the allotted 30 min window.....
Got the job - which resulted in me being on the core data-center design team for the Lucas Presidio project.
(and I have many other storis such as this)
---
Challenges are good which are practical to the company's/teams goals and needs -- but bullshit if they want you to design their whole shit for them.
Now get off my lawn....
----
Oh I forgot to mention - now I am director of tech for a cannabis org... GET THE FUCK IN CANNABIS TECH.
Politely decline and move on with your life.
They are great for probing real-world development, (should) take less than an hour or two, and based on what the interviewee says they are skilled in.