I rarely, if ever, get feedback on these projects. In later rounds, it's obvious most interviewers haven't seen the project or even know you did it.
Why is software engineering the only industry I'm aware of that requires you to prove that you know how to do things you've been doing for years and years? Your projects on Github, degree in your field, and resume don't matter and are rarely discussed.
Unpaid projects, over and over.
Companies are too lazy to do their own work and we are all getting screwed.
How many hours of free work have you had to do, only to get ghosted, denied without feedback, or see your work turn up in their product later?
It isn't that hard of a problem to fix: stop being cheap and pay people for their time.
"But we can't afford it..." - nonsense! Esp. big companies. Poppycock.
If it's "too expensive", you need to have a better funnel upfront before the project stage.
Properly compensating for interviews would be a huge differentiator for recruiting.
Great engineer A: "I interviewed at Company X, and didn't get it. But they paid me $1000 for a day's work. It was pretty cool."
"Rockstar" engineer B: "Wow, that sounds neat. Too bad you didn't get it!" (Maybe I'll interview there too...)
vs. ill-will from unpaid
Great engineer a: "Yeah I interviewed with company X and they made me do a 3 day unpaid project. I didn't get any feedback and they made me do a technical interview AFTER I had already submitted the project, where they just asked unrelated trivia. One line rejection e-mail."
"Rockstar" engineer B: "Yeah that sucks. They sound awful. You dodged a bullet" (continues working where they are)
If I do work for you, pay me for it. If I do work for you, give me feedback. If I do work for you, respect my time.
Our last hires were brought in for a two-part interview, on the same day. The first was an interview to ensure the personality fit was there, to ensure that the differences we all bring to the table could be a strength.
The candidates were then given a running API server, a postman collection, swagger docs, and an empty directory. We asked them to solve a specific problem - one that we already showed the candidate is solved in production, one we make clear cannot be solved in the two hours they're given. Then, the candidate is encouraged to work on the problem, and ask questions.
Multiple team members check in on the candidate throughout the period, in order to offer support, suggestions, pick things apart, and be a sounding board. Then, when things are done we sit down as a minimum of three people (candidate + 2 staff) to discuss the output and outcome.
This isn't the most fair, and can definitely be stressful. At the same time, I feel like it's pretty equitable.
For example, that permits collaborative code questions or white boarding, but not take home code challenges. Past experience has shown me those are always horribly estimated, and require more time on the candidate's part than issuers claim. Put yourself in the candidate's shoes, having 3-5 of these things to work through (unpaid, no doubt, as OP rightfully objects to). Not fun!
I've found that rule a simple, transparent, way of showing respect for candidates' time. Which I've always found admirable, from both sides of the hiring table.
Yes I've tried the other two: take home tests, work one day at company X. They all suck. They all optimized for the suffering of the software engineer candidates. You can't do multiple companies take home tests, it is a waste of time. You can't do multiple work one day at company X, Y, Z. Waste of time. And after all of those time wasters they still reject you for non obvious reasons such as cultural fit, pay, seniority level, etc.
Just cut to the chase, give me DS & A questions and be done with it.
Data Structures and Algorithms are the best mean to interview. Study once, apply multiple times to multiple companies and kill those and get multiple offers, with bonus it makes you a better engineer (at least in my case), though later it gives diminishing returns. You can jump companies every year easily with this skill.
But then people will ask, "how does that gauge software engineering skills?" or "what if you aren't good at data structures and algorithms but you are good at something else like design, product, css, etc" or "there are more to working than just data structures and algorithms" or "you will get similar people in your talent pipeline".
I don't know, that's not the problem of the software engineer candidates, that's the problem of the companies. Let them deal with it. We software engineer candidates just play the game, get the job or rejected from the job, and do the job, go home, collect paycheck, sleep, play, exercise, use our mind, talent and energy doing something else.
Not sure if there's any legal implications with this, like, say I own the code but the company owns the "idea".
If the take home project looks like something the company would actually use in their codebase, then yeah I would probably ask for compensation.
As a noob that is bad at interview programming trivia I've really enjoyed the interview projects I did.
Granted they were hardly a lot of work, but I felt they did a far better job at showing what I can do than all the programming trivia out there.
1. this follows an extensive screen, where we have a strong signal whether the candidate is a good fit
2. the project isn't "offloading a current project" to someone to do free work for us; it's marginally related to our core product but pretty generic
3. the project is explicitly meant to take at most a few hours (we even use this as a way to gauge whether a candidate tends to over-engineer things)
4. we do a proper code review and architecture discussion after the candidate has submitted an implementation; we take as much time and put as much effort as with production code reviews; we probably put in almost as much time evaluating the candidate as much as they take to do the assignment
All this has worked pretty well for us, a mostly remote team, where interviewing has its own difficulties.
If you only want to prevent companies from using your code in proprietary software, you could send them your code with a GPL license.
Copyright aside, yes, unpaid length projects during interviews are an atrocity.
also they are by far the easiest way to screen people who will fail later. isn't that ideal?
P.S - whiteboard interviews are also terrible and unpaid.
P.P.S. - "platforms" that whiteboard- e.g. Hired, A-list, etc - are also unpaid and terrible, at scale.
P.P.P.S. I'm not sure what the solution is but I know it has something to do with actually getting to know the PEOPLE you are interviewing. We're all individuals with unique histories. Pay me for an hour or two to tell you my story and you might be surprised at what you learn.
No company gets candidates to do coding tests as a way to get productive real world tasks completed.
Just don’t do it when a companies test task is too onerous.