That's not "Hello World" app, a "Hello World" app prints "Hello World." The purpose of a "Hello World" app is to demonstrate you've setup the environment correctly, nothing more.
Words and terms have meaning.
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.
Not even a simple, “we’re not interested”. No feedback.
Just. Left. Wondering.
It’s cruel. It’s demeaning.
Tanium was especially cruel. 6 hours of live coding interviews and the only reason I got any response from them was because I had to consistently hound them for a couple of weeks and ask a friend that worked there to internally ping someone.
The other thing that gets me, is not listing what the expected pay is upfront (and whether or not it's remote) on the job posting. We all work for pay and we all have a pretty good idea of what income it takes to live in your current (and future) circumstances. If your pay is nowhere near that expected range, why should I waste your time and why should you waste my time?
I got hit up on StackOverflow to apply for a company. After looking at their job listing, it said (limited remote with approval), making it sound like you had to negotiate for remote work. This is what I responded with, "I currently work remotely and have no intentions on moving. I have a proven track history of performance and productivity working remotely for over 7 years and it's not something I'm willing to give up or negotiate. So I can save us a lot of time by being upfront with you about that."
I didn't apply and didn't receive a response...
In all fairness, that's pretty common. For a lot of positions, companies are fine with proven employees working from home part of or most of the time. But that's not the same as signing off on 100% remote from Day 1. If that was the case here, I'm not surprised that they took your response as a polite "not interested" and moved on. In my somewhat limited experience, recruiters usually aren't that inclined to chase after people who have pretty much indicated they're not interested.
Definition: Willing to put your thumb on the work side of the scales in a work/life balance for no extra compensation.
See also: Taking advantage of your workforce.
Above and beyond can be nice, but the whole point is that it is exceptional, in every definition of the word. If all individuals went above and beyond all the time to fulfill expectation to do the same, that sounds like a recipe for a PR or legal disaster because rational limiting judgement is not applied, or intentionally suppressed, in a scenario where somebody is in over their head.
They probably were doing interviews to satisfy ongoing visa process for already selected candidate.
And the declining everyone with lame excuse.
But I'm also about work life balance, and honest day's wage for an honest day's work, so I probably defer from that company in a few ways, lol.
I always get a reply from those... surprisingly.
My interviewer was sitting in a room full of people when they called me, asked me questions and then proceeded to have conversations with the other people in the room without listening to me and would ask me to repeat my answers. And do it again.
15 minutes of this and I hung up on them. This was about 4 years ago and the equity that I have in the company I joined instead is on an upward trajectory instead of what Uber just did. Phew.
Earlier in dotcoms, I wanted to work in a then-prominent organization. The technical phone screen went well. When they asked what I'd like to work on, I said something like HCI-ish R&D (in which I also had experience) for their important product, so they scheduled me for another phone screen, with the person who was in charge of that.
I'm reasonably good at hearing tone, and the person on this second phone screen didn't seem to want to talk with me, from the start. They asked me to talk about ideas, then they muted their end. I knew this wasn't going well, but I really wanted to work there, and I was trying to figure out how to salvage it, and I had to start talking immediately, so I started going into some applicable research ideas/approaches. Still muted, no comments, no questions, no backchannel cues whatsoever, so I kept going. When apparently the time block for the interview was up, he un-muted his end, and said something like, "I'd hoped you'd talk about a GUI enhancement to <product>." And that was the end of the interview.
That gave a bad impression of the organization, that they'd have someone who'd behave like that, managing people in a key group. So I didn't pursue things with the original group, which liked me.
It's a little validation, but no consolation, that their market-leading product later got driven into the ground, losing to an innovator who entered the market.
Especially when in a new hire/interview situation, HR is absolutely involved. So the HR department is also full of assholes who won't enforce the policies of the company.
I guess I'm glad it went this way for other reasons. It was for an entirely new team within Uber to build something very specific that nobody had done successfully yet (though there was a paper about it...it's security-related). The manager was an external hire and the entire team was to be as well. This was a big warning sign to me that management didn't care very much about this team or if they accomplished what they set out to.
4 years later they still haven't delivered on that feature yet.
Wasn't "asshole" their company policy?
It looks like a good chance to outline the resource requirements for accomplishing this. No way should this be a work of team-of-one.
State the expected stages and some ideas for possible architecture and frameworks.
Then ask for resources needed to implement this with some rough-optimistic estimates, including the budget.
That should be enough for a serious conversation to begin with interested party.
Sometimes I would like to say, you know, I like to work with good devs, so if you don't mind, I would like to ask you some coding questions. It freaked out some people with that, but it is in the same range as the questions they are asking.
You can look at any job and claim it can't be abuse because people can leave the job.
You ignore that leaving the job means loss of income, status, or worse even.
Like, imagine if the TSA strip-searched everyone. Pretty abusive right? You wouldn't say "I don't see how letting people fly is abusive".
I estimated it to take at least 2 weeks. Sent it to a colleague and he estimated it the same. In reality you had 48 hours to turn it back in. I gave up halfway into the project.
I also don't think it's cool to do what I just said without letting the candidate know that's what is happening. Otherwise they might just get frustrated and decline to work on it.
It's possible we were doing this many years ago, but that certainly isn't the case now.
> “I’ve been a software engineer at Uber since 2015”
Perhaps they need to test reading comprehension in their interviews!
Snark aside, it can iffy to pay someone for a task at your company when they are still under contract in their previous job. In that sense, while your point is sensible, it can be difficult to go that route from the candidate side.
If you want to limit your pool of potential hires to rock stars who don't have jobs (pool size of approx. zero) this is a great approach.
I doubt they had the budget for that or they likely wouldn't have been essentially trying to get someone to making their MVP under the guise of a new hire interview.
Keep in mind the OP mentioned that this was pre-launch, when they were still UberCab and only had aspirations to be a peer-to-peer cab app. Long before they started marketing themselves as a logistics juggernaut or world changing self driving car creators for valuation justification purposes.
For context, for my first job as a developer the take home assignment I got was creating a web app that logged realtime CPU usage and created a graph of that CPU usage that was updated in real time.
And this all had to be done using a specific language, web framework, and database that I had never used before.
That's at worst a 4 hour job to do with a beer over the weekend. You sound incredibly incompetent if you can't tell the difference in difficulty between that and that they asked OP to do.
That assignment is 1/128th the work of point 1) from OP.
In understanding the question.
At any rate, you still haven't replied to my job offer. I need you to do two weeks of free work for me.
You sound like the type of engineer I get hired to replace at three times the rate when the project is on fire because they didn't understand the spec.
A vision to push anyone who works with/for them to the maximum possible win/lose ratio. Including drivers and riders.
Here's the exact challenge:
UberCab Coder Challenge
1) Write a program that determines the wait time, trip time, rating, and fare for a black car trip in San Francisco, given that the customer's pickup location and destination is randomly placed anywhere in San Francisco proper, and given that there are X number of cars all placed randomly across the city. Use GoogleMaps API for trip duration time. Run simulation 100 times for 1, 5, 10, 20, and 50 cars. Output average wait times and trip times for each # of cars the simulation was run on.
2) Take #1 and do the same pickup and trip time calculation given that there are Y customer requests per hour (extra credit if this is done with a Poisson distribution ;)). Take into account each car's availability (given that they may have been selected to carry a customer and are in transit on pickup or on actual trip, and thus unavailable). Run simulation given the number of cars in #1, but for each simulation in #1, run once for Y=1x, 2x, 5x, the number of requests per hour (X being the number of cars in the city, as defined in #1)
3) Take #2 and then make a GoogleMaps mashup that then shows the various trips that were taken for each simulation. Provide mashup interface showing all trips but also provide ability to only show trips for each driver.
4) Write a "Hello World" app on the iPhone that for a certain driver logging in shows all of his trips taken in the last simulation, the average rating that he got, and the total fares he collected during those trips.