[reading-at-work]

I disagree that it's an automatic red flag. 8 hours? Yeah that's too long. But I would rather do a 2 hour take-home project than a 2 hour whiteboard coding interview.

Edit to add: as far as getting paid, nobody expects to get paid for an onsite interview so I wouldn't expect to get paid for a take home project either. As long as it takes the same amount of time that the coding portion of an onsite interview reasonably would, that is.

[dlandis]

Do any of the take-home projects actually only require 2 hours though? Maybe some of them have a recommended time around there, but isn't it basically required to spend longer?

[kamaal]

This is one more problem, programmers are really bad at estimating time required for completion. When it comes to these things programmers designing the interview tend under estimate the effort required to finish the projects.

What makes this whole thing complicated is how they go about measuring quality, extensibility, or if they measure feature completion.

Most companies that give you a take home assignment also get you onsite for one or two sessions of code review and feature addition.

If you don't take into account quality or extensibility you fail in the next rounds.

By no means are these 2 hour projects. Most of these projects take at least a few days to do well.

In some cases the person designing the questions just overshoots the measurement. I've heard sometimes they ask you do come up with a feature loaded contacts iOS app in like a weekend.

[bagacrap]

Programmers are bad at estimating time to completion for their own work, it's true. But to ask them to estimate someone else's time is unfair because that depends heavily on the individual. Some will finish in 2 hours, and that is probably who they'd like to hire.

[topkai22]

The difference between a take home project and an on site interview is that a take home costs the hiring company nothing, whereas an on site costs them hours of engineer time. With that being true, they can make a lot more candidates do take home tests then on sites for the same cost, meaning it’s a lot less efficient use of a candidates time.

[scaryclam]

Sorry, but this isn't true. We take a lot of time going over a candidates test. The point of the take home is so that we can get a feel for the candidates level of coding competence, ability to commit to a deadline, ability to read and follow instructions and it also helps to generate questions for an on-site interview. Not bothering to read the test through properly would be a waste of our own time, as we'd not achieve any of those things.

So please, stop making assumptions about companies and take home tests. Unless you've worked for that company in a hiring capacity you have no idea what their process and motivations are.

[0x445442]

What I'm curious about is what this industry thinks makes it unique with respect to practically every other industry with respect to interviewing. Almost every other field actually calls on references and relies on reputation to determine past work performance.

Also, I've conducted a number of interviews in my career and have been responsible for a number of hires and I've never needed to rely on a take home project to access a candidates worthiness of the position. Maybe it's because I was interviewing/hiring for positions which I was intimately familiar of the required tasks and I knew the right questions to ask.

[topkai22]

I believe that you put a ton of time into your test, both creating it and reviewing it.

However, as a candidate I have to make assumptions on where to put my time, and if there is a take home test prior to an interview I’m likely to pass- while you are a super diligent company that carefully reviews all the responses to the screener, I’ve definitely seen those that aren’t, including companies kept taking screeners answers despite having no positions actually open.

There is an straight forward answer to this though- don’t send the take home work till after the candidate does the interview loop, or at least has a good conversation with the hiring manager. At that point hiring org has demonstrated a clear interest in the candidate and has put up “earnest money” to prove it. The candidate also knows if the position is something they are interested in. I’ve done enough hiring in the past to be confident that the interviews are more predictive of long term success anyways.

[kstrauser]

Having been on the hiring side of that, we spent way more time coming up with and testing the take home project than our applicants ever spent on it. Among other things, we'd beta test a proposed "challenge" on each other to see how well it worked out in real life before springing it on candidate.

It would have been a lot cheaper not to have the take home project, but we decided it was worthwhile anyway.

(Disclosure: our project looked a lot like a story you'd be asked to work on in your first week with us. There was none of that "hiring for a Python backend engineer; here's a Scala data engineering project" nonsense.)

[kamaal]

You spent that much time over several dev sprints/cycles/months/whatever. Meticulously designing the expected output and quality expectations(yet not sharing any of that in the spec supplied to the candidate). All that automated testing, manual code review checklist was designed after spending that many man hours worth effort to arrive at. You have the benefit of hindsight, and insights from the process that refined over that much time. Plus you have inputs from several candidates you failed your test.

Yet now the candidate has no luxury of that, and has to guess the assumptions required to not just produce all the features, but also the quality metrics the project will be measured against. All in the deadline given by you. And he is at day 1, and that's all the day they have.

This is really like expecting some one to fix a problem in a day, what the other person spent months solving.

[0x445442]

Agreed and what your describing actually happens in a lot of work environments. I've seen a trend in the last few years where middle management is attempting to separate "programmers" from "engineers/architects". In these environments the "programmers" don't really have the luxury of sitting with the business or product teams nor the luxury of taking part in the design process.

What ensues is actually comical. During "grooming" sessions the "programmers" are meant to give accurate estimates of how long (I know time is not meant to be the metric but it always is) a story will take to complete. A story which there are many, many person hours of context baked in that the "programmer" is seeing for the first time.

Context is worth 80 IQ points --- Alan Kay.

[kstrauser]

I don't expect you to believe that we took that all into consideration, but we really did. Several people said it was genuinely fun.

[hvidgaard]

I'd take the whiteboard interview any day of the week. The instant feedback you get and ability to show how I think and attack a problem is, I believe, far more valuable.

[scaryclam]

Not to me as an interviewer it's not. All I know from that is that you interview well. I come away having no idea what you'd actually produce in a normal working environment. I have no idea about your ability to build anything. All I know is that you can whiteboard well. That's a valuable skill, sure, but it's a long way from the only one, and can be learned pretty quickly with a supportive team.

[hvidgaard]

I rarely need someone that is a master architect. They're going to be in a team of already competent people, and whatever short comings they have, we'll address. But it's my experience that critical thinking and methodical problem solving by breaking the issue at hand down into smaller logical chunks is by far the most difficult to teach. So if you demonstrate that, I'll allocate the resources needed to get you up to speed on other areas.

[beerandt]

But it's an indication of the companies value of an employees time, in that it's one sided. If they're paying an existing employee to babysit me, that's a cost to them that demonstrates at least some expended effort.

I'd consider this to be pretty important for a salaried position.

[randomdude402]

I totally agree. People say that a take home project is terrible, but most people I talk to who aren't recent graduates also dread live coding algorithms that will never be used on the job.

The place I'm at now asked me if I wanted to come in and code as round one of interviews or code up a little something on my own time for a couple engineers to review.

For me, it was a no brainier to code at my comfy desk at home for a few hours. Going into the city would have been an hour each way and about $50 worth of gas and tolls. I would much prefer not to bother with all that unless and until somebody has looked at my work closely enough to decide they are interested.

[dcow]

Yep! If it’s a question about respect as so many people seem to portray it, then the easy solution is to offer candidates a choice. But personally, I will always prefer working at my pace on my time in my style and having people judge the output once I deem it ready. If I really need/want the job I’ll make the time. What is an extra few hours relative to the new position, team, etc., that you're aiming for? For me it feels infinitely worse to not quite get through a difficult algorithmic problem on a whiteboard only to have the solution obviously materialize during later reflection when you have a clear headspace, and to know you were judged solely on that, than to give it a fair shot on your terms and be passed on because your style/work is not what they're interested in. I'd rather be somewhere that values my actual output.

[strken]

The problem with one or two hour whiteboard interviews is that they're actually one or two hours, while an inexperienced candidate can spend 8 hours on a take home project that's calibrated above their level, as can a scrupulous candidate who puts in more work than is necessary.

[dcow]

And if they complete the challenge it’s a strong indication that they are a good fit for the role where they may otherwise be presumptuously dismissed for not having an expected level of experience. Id rather hire people who put in effort that expect their tenure in an industry to buy them future jobs.

[AzzieElbab]

Who said a take-home project won't be followed by 2 hours of whiteboarding?

[jake_morrison]

Read that as "waterboarding" :-)

[meowface]

Yeah, it should either be ~2 hours, or they should pay you for it. I don't think an 8 hour project is bad if they suitably compensate you for it.