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.

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?

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Read that as "waterboarding" :-)

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.

Honestly the non paid take home projects are much better. The three interviews I’ve done them for stand out as the best interview processes I’ve been a part of. They actually check for real software skills.

The time you spend on-site grinding leetcode with some Google engineer is non-paid as well, so let’s not pretend it’s really any different.

Totally agree. I can’t imagine many people enjoy studying for leetcode type interviews, either, unless they are fresh out of a CS program and already practiced with that stuff.

Do people actually accept such interviews? That seems quite disrespectful to me, tbh.

> Oh you've been working in a relevant field for 10 years? Here take this written test first, so we can check how well you can memorize hundreds of random irrelevant algorithms...

I'd walk out, unless it was maybe some simpler algorithm that you can actually figure out yourself by thinking for a few minutes.

> Do people actually accept such interviews? That seems quite disrespectful to me, tbh.

I was under the impression that pretty much any FAANG interviews will have significant data structures and algorithms components and/or whiteboarding over Leetcode-like problems. Maybe I am wrong on this.

Outside of FAANG, I've found it's hit or miss, but the smaller the company the less likely you'll have to deal with bullshit hiring practices, at least that was my experience.

> Oh you've been working in a relevant field for 10 years? Here take this written test first, so we can check how well you can memorize hundreds of random irrelevant algorithms...

Yeah, and it's even worse if you don't have a formal CS degree. People always say that it's important to know data structures or algorithms or Big O-complexity so you "don't do something horribly inefficient in production", but in retrospect, I haven't had many problems with performance in real life. When I did have problems, it was usually fixed by modifying a SQL or ORM query. Once I fixed someone's major performance issues just by recommending installing a different package to generate PDF's.

I seriously doubt anyone needs a computer-science degree and deep low-level data-structures and algorithms knowledge unless they are going to be writing databases or compilers or designing programming languages. Most of the time, some common-sense and a handful of "good practice" coding/software eng. rules will do the job.

Disclaimer: I work on typical web/server applications. I'd probably have a different opinion if I were working on life or death software, e.g. medical device software, airplane control systems software.

I recently got ambushed with one of these types of interviews. I was going for a senior dev role, in the same industry I've been working on for the last 5+ years.

Had done the normal initial phone interview (overview of experience etc), a take home code challenge (only took ~1hr) then I was asked to come in for a final interview that was to be a 15-20min presentation on project I'd worked on (that related to what I would be doing at the new role) then 15-20min of questions on that project and the technical challenges/solutions. All this sounded great until I got an email the day before informing me the presentation and follow up questions would be ~20 mins total and then there would be a 20 minute whiteboard session on data structures and algorithms.

I retracted my application asap!

> 15-20min presentation on project I'd worked on

Are you sure they didn't just try to steal intellectual property of your last employer? ._.

He probably meant the take home coding project that he worked on before the interview.

Absolutely. The one job that offered me a take home project was the best interview I've ever had, and the best working environment I've ever experienced.

I see this a lot but it seems fairly naive to expect. There’s absolutely nothing wrong with refusing to do them, but to get paid? Has anyone in the history of the world been paid for an interview take home project? Curious how it was set up and what the rate was. Did you have to file taxes? Was it 1099?

I’ve done a trial project which was after an initial (much shorter) code test which was non paid. The trial earned me a couple grand and I got a 1099 alongside my w2 at the end of the years since I was hired full time.

How long was the trial ? can you do it while being employed elsewhere? it could be forbidden by contract to be employed in two places, and you could simply don't have the time for a full time, short, project

Current place does trials. Typically two weeks long and you get paid the same amount as if you worked there.

And yep, many people do have other jobs. Some take vacation time and others do nights + weekends.

I admit that a short trial is the best way to choose a match both for employees and employers, BUT I don't see it working for most people.

I have a family and personal life, I am not going to try out a few employers until I get the right one.

My employment contract also forbids working in other businesses at the same time, vacation or not.

Very cool, thank you.

Yes. I had one company pony up $500. I was blown away.

I have. It was a few hundred bucks. There was a tax form, but I don't recall specifically what it was.

Interesting. USA?

Yep.

Yeah, I agree, the logistics are tough and the comment was really just a proxy for...

A company that must rely on a take home project to get a meaningful assessment of your worthiness and competency for a position is a huge red flag.

Any engineer worth their salt can tell from an on sight interview if a candidate is bullshitting about their past accomplishments.

I got paid as a consultant a lot for short term offsite projects -> then they want to hire you. So the random gigs can sometimes be a take home interview. I liked it because if I didn't enjoy working somewhere I could tell them I was busy with my other projects and we'd end on good terms.

It's pretty common in my experience.

Have never seen it in 25 years of working in the industry. Sounds like it's more common than I thought (who's the naive one lol).

I've mainly seen it with small companies.