I interviewed at Uber before they launched. Their "take home" was to create... Uber.Here's the exact challenge:UberCab Coder Challenge1) 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.

 >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.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.
 If I didn't know better, I'd interpret the question as a (pretty good) joke.
 It's a "Hello World" app for your system, the most basic app that can run on your platform.
 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.
 It's not the norm but it's not uncommon at startups. Also, it seems to be standard practice for data science interviews.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 prefer take homes if they are reasonably scoped and turn around expectations are around 1 week.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.
 The scope is important. Some of the data science take homes I've seen could be looking for a decent/good-enough solution that takes an an hour to a full-fledged research program that would keep a few FTEs busy for a year.
 What sort of take homes are you seeing for data science roles?
 Home assignments are probably not yet the norm, but are becoming more common. There's been a lot of backlash toward whiteboard coding, but most companies still want some sort of concrete work product. I would expect a reasonable home assignment would take no more than a couple hours to complete.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.
 As always, there are advantages and disadvantages to both. I've only experienced whiteboard coding (and in a limited fashion), but I'd prefer interacting with an interviewer and getting instant feedback compared to submitting a lump of code and potentially never hearing back. Communication is something key they fail to measure with this type of interview.
 I've never done a take-home either. I'm perfectly able to "pass" a whiteboarding interview, but I just find them kinda lame when it comes to actually evaluating skill.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).
 Our current assessment is about 4 hours and i think that's too long. When i was hired I remember multiple points where i seriously considered giving up. O can't help but think how many good people we lose to an excessive applicant process
 Serious question, are you not also concerned about the poor quality of worker you might take on with a less rigorous process? I think I'd accept a few false negatives to avoid the hassle of false positives (in the UK at least, where employment law protects employees above all else and people can be very hard to get rid of if they want to be).
 UK has trial periods too though, or? I've been in trial periods from 3 to 6 months, which is ample time to find out if the hire was successful. It's of course still very bad to fire someone during the trial period though (for both wasted effort and employee morale), but there is that option.
 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.
 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.
 > 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 problemI 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.
 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).
 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.
 > 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.
 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.
 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.
 > It's on par but still bullshitI'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.
 I'm on the other coast, not even in a major tech hub, and we do a take home assignment now to screen applicants.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)
 How many steps total? How long to get through the process? This may work for lower demand markets but sounds excessive in competitive regions.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
 Hm, how do you get to them? Apart from bribing an interviewer at Google I can't see how you could get the list of rejections?
 I've been in SV since 1997.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.
 Sounds like this practice successfully filters out those engineers who value their own time.
 I’ve personally seen several of these. I’m tempted to reply back with my hourly consulting rate because it’s crazy that these companies would expect someone to do a project like that uncompensated.
 If it makes you feel better go ahead. At best you're being kind of a dick to NO-REPLY@... At worst you're labeled a prima donna.Politely decline and move on with your life.
 We've used them, but these huge examples give them a bad name. Some people (myself included) are terrible at whiteboarding and we'd have lost some great engineers in screening if we had only done CS quiz/whiteboard.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.
 I've had a few. They are usually things you can do in a couple of hours. I personally prefer it to a phone code interview. "Write Uber", though, is pretty egregious.
 Why are people putting up with this?
 The worst is when you do the task and then they just don’t respond.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.
 I can't tell you how many times I've never even gotten the courtesy of a response after interviews...even though I've checked in with them to find out where they were in their process.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...
 >it said (limited remote with approval), making it sound like you had to negotiate for remote workIn 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.
 Had one with Deliveroo. They responded, but they were declining me because I didn't do what they explicitly told me not to do in the instructions. They wanted people who "went above and beyond".
 >"went above and beyond"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.
 Yup. Bullet.dodged.
 If above and beyond is required, how can it be above or beyond?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.
 Everything about the interview process is a crapshoot. My last run on the interview circuit had a few like this too, where the "code challenge" is either intrinsically contradictory, or where the interviewers give candidates a "bad score" based on their own failure to understand/process the challenge they issued. Lots of amateurs out there with a "naive cleverness" about this stuff.
 This is BS.They probably were doing interviews to satisfy ongoing visa process for already selected candidate.And the declining everyone with lame excuse.
 This is almost certainly the case.
 Going "above and beyond" in a coding assignment can be a slight negative when I'm grading. Albeit this is a security company and adding pieces on top of the requirements could lead to unthought about interactions and more surface area.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.
 A company in PA called Monetate did this to me, on a smaller scale. I did their "leetcode" style test which wasn't difficult at all but still time consuming. After 2 weeks of no response I reached out and they told me they're interested and then I heard nothing for another month. After several followups I gave up. 6 months later I got an email asking if I can send over my resume (that I sent before doing the test)... it's infuriating.
 Square did this to me many years ago. It was galling and unprofessional.
 I had an interview with a company that's mentioned from time to time here. When it was the founder's turn to grill me, he spent 90% of the time staring at his iphone while barely glancing at me.
 Give them a link to a Public Github repo on my account...I always get a reply from those... surprisingly.
 Possibility of \$250k+ total comp plus excellent benefits? It's worth it for many people.
 Not sure about this case, but you usually get compensated for these take home projects. They also give you an amount of hours you should work on it and pay you (One of them I did was ~\$200/h)
 I remember my Uber interview.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.
 I'm sure they were acting against the policy of the company. It wasn't Uber, just an asshole guy. Every company has that.
 But that no one shut down the asshole, and that this was allowed to continue happening in an interview situation means that in addition to an asshole guy, there are also a bunch of asshole employees who don't care enough to speak up, or would rather have side conversations with the main asshole guy.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.
 Interviewer was not a guy and would have been my manager.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.
 Well, you are talking about one of the most infamously toxic tech companies. Harassment and discrimination were also against their company policy: https://www.nytimes.com/2018/05/21/technology/uber-sexual-ha...
 Uber?Wasn't "asshole" their company policy?
 Was it an interview for lead position or just coder? How did this end?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.
 That is excellent point, I really like where you are going with this. It shows maturity of the applicant as well.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.
 That's clever!
 Wow. That's just abusive...
 That is devaluing the word abuse. A voluntary optional task which you can decline at any time, is not "abuse" no matter how you spin it.
 There are lots of situations that are voluntary but abusive.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.
 In fact in many abusive situations the abuse is how the abuser keeps the abusee from exercising their freedom to leave. The relationship being nominally voluntary has nothing to do with whether it is abusive.
 I still don't see how applying for a job is abuse.
 It's not that complicated. Some people are desperate for a job. They will do anything for it. You can abuse that need.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".
 [flagged]
 Just to note, it was clearly said "can be", not "always is".
 I agree in this context, but not in the broader sense. Not giving clear responses to interviewees is unprofessional and shouldn't be tolerated, but "abusive" is a bit much.
 Did you complete this? To me this sounds like they were not looking to hire but would hire someone exceptional who goes through this task and does better than their own team did.
 I got a take home assignment from a large company a few months ago, it was the whole shebang as well. Build an iOS application with full test suite, several screens, should work with their test-api, should be polished, offline/online work etc.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.
 Sometimes that's intentional. As a hiring manager I find value in seeing what someone chooses to prioritize when given an impossible task. If you have 48 hours to complete a 2 week project, what portions do you choose to complete? Can you explain why you chose that?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.
 Any sensible candidate will prioritise your job and company to the round filing cabinet.
 In my feedback they were quite clear in that I had not done everything required.
 I've been a software engineer at Uber since 2015 and have lead over a hundred onsite interviews and countless phone screens. In four years I have never seen a take-home exercise be used. Every other interviewer also holds a strong negative opinion of them.It's possible we were doing this many years ago, but that certainly isn't the case now.
 > “I interviewed at Uber before they launched”> “I’ve been a software engineer at Uber since 2015”Perhaps they need to test reading comprehension in their interviews!
 Well, that certainly selects for engineers willing to do unreasonable amounts of work without questioning it.
 If that's how you want to test potential engineers, I don't necessarily see a problem with the task itself. Just pay them! I'm sure Uber can find the budget for that.
 I'm sure they're fine with engineers who don't ask to be payed for random tasks encroaching their private life.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.
 Yup. Will anyone who cares find out that a competitor paid you to do some task? Probably not, but it seems like an iffy proposition to violate your current employment agreement to have an interview.
 I once was invited to interview for a startup to work with their (mostly remote) team for a week, for which they would compensate me at a decent rate. I never managed to find the drive to take a week off for this, but yes, it would have been tricky to explain to my then manager.
 Yes, because the only limiting for for super qualified engineers is they don't get paid for coding in their copious amounts of free time.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'm sure Uber can find the budget for that.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.
 Uh... are restricted stock units OK?
 One thing I've tried at my company is to present a complicated task with many parts and considerations, and then explicitly say that you are not required to complete all of it. Just do the the minimum required (which can be done in an hour or so) and the parts that catches your interest. Looking at which parts the prospective engineer completed, we could also determine which part of the stack he/she likely wants to work on.
 If you've never had a job as a developer before and don't have any open source contributions, then that's actually a pretty good take home project. Yes it will take a week or two of unpaid work, but no one is going to hire you for your first job without having built at least one project of that size anyway.
 Do you really think that's an appropriate question for an entry-level developer?
 For an entry-level fullstack iOS developer it's not that bad.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.
 >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.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.
 You download a list of every street address in San Francisco, pick two at random, and write one line of code to get Google Maps to tell you how long it takes to drive between them. Where exactly is the complexity?
 > Where exactly is the complexity?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 incredibly incompetent if you think the task is hard to understand.
 Op missed the part where they need to batch run their solution 200 times over and pick the quickest root. Like always ignorance begets confidence. That's not even talking about part 2 which you need to completely refactor the solution from the previous problem.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.
 Sound great. I have a job offer for you. Contact me for the two week unpaid test.
 I wouldn't have expected anything less from them, go Uber! Always the worst!
 A company which has no problem pushing beyond any conceivably reasonable bounds of exploitation.A vision to push anyone who works with/for them to the maximum possible win/lose ratio. Including drivers and riders.
 How much time did you have and which level of engineer (senior/architect etc.) were you applying to?
 How long did Uber give you to do this?

Search: