I like the idea of attaching a license to it.

I will be very interested to hear how the (potential) employer responds to that. Personally, I would refuse any and all "take-home exercises" -- I think they are fundamentally wrong-headed.

It would depend, if it can be done in a couple of hours. But to do it well, it almost never can be. I might have to do a take-home exercise in the near future through..

If the employer is giving out take-home challenges that reflect actual work and they plan to use the best one for real... yeah, that's a pass 😉

I have been on both sides, sometimes it was just mandatory, sometimes you're given a pass after they see your gh, it really depends. But yeah most of the times it didn't reflect what the job would require tbh (just small puzzle/task to see mostly how you think, lay out code and so on, 1h~ of work max). Personally I don't mind them

We give a simple task to graduates, to reduce the number of telephone (and other) interviews we have to do. For more experienced candidates, they're asked to do it if after the phone interview, if they don't do very well on the technical part of the phone interview

At least, that was the old system, before covid, and before the person running it left. I think I'm in charge of the process now, but we've been shrinking rather than growing for the last 15 months, so it's not been an issue

I hate them as an applicant, as it's hard to find the time, especially if you're applying to two (or more) companies at the same time

For the take home task. I am curious how could company evaluate candidates on always changing take home tasks depending on what’s needed in the product now. On top of that, any nontrivial app has lots of context and domain knowledge needed for productive development. Even if I wanted to develop any product and build an application this way, it’s hard to imagine, how this could be productive for development & representative for hiring.

As a candidate, if I run into such a thing, I’d ask them if it’s the case or it’s a synthetic test that’s only working on their codebase. As a responsible developer, I’d probably ask for more context, etc. to develop feature well. I wouldn’t mind if my solution would end up in their codebase. It would mean I will probably get productive fast. As an employer, I wouldn’t do it as it’s not productive and comparable with other candidates. As a colleague, who would have to evaluate such a candidate, I would get into tricky situation probably seeing not optimal solutions because the candidate doesn’t have context and coding culture knowledge to be able to deliver viable pull request anyway. So it would push me to see candidates as worse than they are. So overall, it’s probably bad idea.

I am definitely not a fan of take-home tests (I think by now folks here know how I feel about the "standard" interview processes most companies use). I wish we, as an industry, would invest in training hiring managers (and some engineers) how to conduct interviews effectively instead of relying on arbitrary code-based approaches that don't reflect "real world work" (in-interview coding tests are inherently broken because the atmosphere of an interview is already unnatural, and take-home tests are hardly any better because in the "real world" a developer would have access to teammates and resources at the company to ask questions/get insights -- and you also have no guarantee that a candidate has a work-suitable computer at home of their own or has time or the environment to perform "real world" style work).

In these times of pandemic, it's more likely that a candidate would already be working in their home environment and would have the facilities to do take-home work -- but doing an interview-related task on the computer provided by your current employer/used for your current job is... less than ideal (to put it politely)... especially if the take-home work requires different tech/tooling...

The best interview I had: After the initial screening, I went to the office. There was a pairing station with two keyboards, monitors, and mice attached to a single workstation. And a real ticket in the project tracking system. So the team arbitrarily selects specific tickets and tags them with the "for interview" label. I had zero knowledge about their systems, or domain, or the frameworks they've used. I pair-programmed with one person for about an hour, then the second person for another hour. We were able to write code that addressed the problems described in the ticket. In the end, when I said: "now we need to commit these changes", they said: "Oh, no. Then we'd be legally required to pay you. Unfortunately, we're going to have to scrap all this work." I wish more companies adopted this style of interviewing.

To be clear: it was not easy. It was extremely challenging for both parties. But it worked. It worked better than anything I've seen before - better than the whiteboarding, home challenges, interrogation on algorithms, and data structures (I once had to describe a graph traversal over a phone, and that was horrible). How do I know it worked? Because I passed that interview. And then I've seen other candidates going through the same process.

I’m gathering you took the job? In which case, why didn’t they just pay you for the work instead of scrapping it?

far easier to through away two hour of work instead of worry about contracts, IP, and such. and the work might have to be held for some amount of time before a hiring decision is made

Exactly. I don't remember if I had to sign an NDA or not, but it was a fair-game: they've devoted two hours of their time, I did the same.