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.
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.
I'd consider this to be pretty important for a salaried position.
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.
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.)
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.
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.
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.
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.
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.
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.
> 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.
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!
Are you sure they didn't just try to steal intellectual property of your last employer? ._.
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.
And yep, many people do have other jobs. Some take vacation time and others do nights + weekends.
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.
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.