[distances]

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.

[ummonk]

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.

[meddlepal]

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.

[mattkrause]

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.

[m4x]

What sort of take homes are you seeing for data science roles?

[kelnos]

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.

[cameronbrown]

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.

[kelnos]

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

[fhbdukfrh]

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

[nimonian]

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

[distances]

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.

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

[ldoughty]

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)

[fhbdukfrh]

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

[Drdrdrq]

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?

[samstave]

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.

[pesfandiar]

Sounds like this practice successfully filters out those engineers who value their own time.

[ryandrake]

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.

[fhbdukfrh]

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.

[gedy]

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.

[Uhhrrr]

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.