Ask HN: What's with all the unpaid interview projects?
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.
80 comments
[ 3.8 ms ] story [ 133 ms ] threadP.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.
[0] https://introview.io/processes/codebase-project/
1. https://m.signalvnoise.com/hiring-a-programmer-ditch-the-cod...
2. "... you’ll submit some code you’re proud of, review it, and tell its story. Then on to an interview. Our interviews are one hour, all remote, with your future colleagues, on your schedule. We’ll talk through some of your code and some of ours. No gotchas, brainteasers, or whiteboard coding." from https://apply.workable.com/basecamp/j/F2CB808F33/
edit: spacing
Roughly speaking, I can get to an offer decision after:
1 recruiter call (20-30 minutes, usually, pretty softball).
1 or 2 phone screens (30-60 minutes apiece, generally).
1 day onsite for 4-6 hours.
If you're going to demand much more than that amount of time from me, you have to offer something compelling. The definition of "compelling" varies depending how much I think I need a new job.
What's this ethical, publicly traded company you work for that doesn't do BS interviews? I bet they'd get a lot of inbound if they made that known.
Ideally the candidate offers code samples, I then pick through the code samples to find things that strike me as unusual or problematic and ask questions about those parts. This gives me a great deal of insight about how people think, and their relative level of skill. I firmly believe this is the best way to interview.
Failing that, candidates frequently provide details on projects they worked on. I'll then ask questions about those projects like, "What language did you develop it in and why?" and "What do you think was the most difficult part about this project and why?" These questions are a gateway to the same kind of details you get from code samples. For example, a candidate once mentioned he had worked for the Navy, and had done water simulations for them and I asked, "What's so difficult about water simulations?" and he gave me a 20 minute lecture on how water simulations work, which won him the job. It's probably worth noting that the job had nothing to do with water simulations, but his lecture made it clear he had passion and knowledge and could do the job.
The worst interviews are ones where the candidates worked in an environment where they can't offer code samples or talk about previous projects (military contractor, for example) - these you just kind of muddle through by talking about programming in general.
Provided code samples is good, but only if the candidate has written all the code themselves and isn't just passing off other's code on a project as their own.
When I was conducting interviews I was frequently surprised by just how bad some candidates with fancy titles and a decade of experience were at actually coding. And I mean things like a understanding a simple recursive function, integer division, inheritance and other core concepts. I would never hire someone without at least a brief code comprehension check nowadays.
Code samples are not like blood or urine samples, you should have serious and public projects to sample from.
Many great programmers are not coding outside of the work environment, what should they provide according to your method ?
And for those who do, they can explain things but you can never be sure they actually wrote it or will be able to write at a similar level (well, that's partially true for take home tests as well)
I can understand it to a small degree, given the nature of software development. I wonder how other professions would take it - "Excuse me Sandra, I know your resume says you're an electrician, but I'm going to need you to wire up this house so I can just check". I'm sure some other professions do do this, but none I've heard of.
Professional musicians have to prove themselves in auditions, CPAs, auto mechanics (good ones at least), etc. The list goes on.
Musicians and actors are better examples, as they do have auditions, but lots of actors and musicians get jobs based on their previous body of work, rather than an in-person audition.
I'm curious, can you name more professions that use what is essentially auditions for hiring, besides artist-types?
I wouldn't expect to get paid for a 20 minute tech trivia screen.
Github resumes are great for some people who like working on OSS stuff but horrible for others who can't share comercial work and want to have a non-coding life outside of it.
Take home projects can be terrible if they're too early in the hiring pipeline and also exclude anyone currently working full time.
Whiteboard questions are mostly terrible because of nerves and poor input methods, at least do it on a laptop connected to a projector, then it's acceptable for some people.
The one thing you can't do is have a single process for everyone and pretend there's scientific rigor behind your decisions.
Right on.
also they are by far the easiest way to screen people who will fail later. isn't that ideal?
how much time are you expecting / "giving" candidates to work on these take-home programming tests? it sounds like you're wasting lots of people's time by putting a gap in between your certitude that someone who finishes in X amount of time will be hired and not "fail later", and the Y amount of time total. If you're not going to hire someone beyond the X value, you need to downward adjust your Y until it is the X. Otherwise you're literally wasting people's time.
No, that's not ideal.
Also: do you pay them for their time?
The irony is that the project had no value to me. I had already implemented that feature, and just wanted to understand if the candidate would be able to do the work I'd already done for myself. Indeed I picked the problem because I had solved it myself under timed conditions and knew how long it would take me. I wrote the code for the feature in about 20 mins and then tested and checked-in under an hour. I expected that a new person with less experience and skill than me would take about 3-5x the time, and that would still be okay. Even if they took a day that was not an issue for me. Which is why I paid them for one day of their time. They might have taken a whole day. But 30 days was somewhat too long. Thankfully I'd priced it at a fixed cost. So my downside was fixed.
Still the learning was not cheap. I was paying what would be considered consulting rates in India.
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.
If the take home project looks like something the company would actually use in their codebase, then yeah I would probably ask for compensation.
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.
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.
As someone who did a few interviews last year, I wish they had been like this. I walked away from most interviews when they started asking me things like:
- "I dont really have time to think up any interview questions or a test so can you bring some code from your last job and we'll take through it..."
- Asked me to do a 2 hour online test without having even spoken to me in any capacity, or asked me to do a homework quiz "it should take around 10 hours" before having spoke to me in any capacity....and they were the ones who contacted me initially.
My favorite was hiring me as a contractor on a short term basis, paying market rates, and then using this time for us to see if we were a good fit.
We absolutely don't compensate candidates for their time. From an economics perspective there's no value in the output, and the shared value is the opportunity for each side to determine if we have an alignment on fit. Each side makes an investment with an outcome based goal - that's why this is as equitable as we could make it.
a candidate 'invests' their entire day's output in it and gets paid $0.
your team 'invests' their entire day in the project and gets paid $XYZ dollars.
are these equal "investments"? obviously not.
you can afford it - paying candidates will be a business write off for you anyways.
you're just not doing it because... reasons?
really lost me with this post, it doesn't sound compassionate at all. you're using candidates the same way everyone else is, but the bar is so low that describing the process and giving feeedback got me excited.
There's an equal give and take during the interview process - at least if two parties understand that they're interviewing each other. For those that don't - neither rhetoric, nor money can instill those values.
re: YT - welp, out of the frying pan, as they say lol
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.
That's great for code + the specific execution of it... for me I often have to also do design engineering and content/concept prototyping as part of these projects. Creative work in addition to the code. I'm not sure there's a way to protect those ideas the same way you can the code.
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.
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.
I don't consider myself good in DS&A puzzles. My definition of good in DS&A puzzles is basically you can solve common/most Hard Leetcode problems in under 45 mins. I think if you can do this you'll have no problem jumping ship of FAANG-league companies every year. I am still not in FAANG.
My skill now is pretty much in Medium Leetcode problems, which I can solve common/most of them in under 45 mins. I used to be worse at this and couldn't even solve Easy problems for 2 hours. I just practiced and practiced and studied, until it becomes easier.
Now, what this skill gives me is, I can easily knock off majority of non FAANG interviews out there, in under 30 mins. In my last interviewing with companies I actually did most of their questions each in under 15 mins. This leaves them to talk about something else such as projects, past responsibilities, cultural fit, or even just dismiss the interview altogether to save everyone time.
DS&A interview is in a sense, sort of a pair programming/discussion thing because you need to voice your reasoning out loud to check with the interviewer that you are going in the right direction.
Also once you practiced these kinds of questions, then it is no longer "I need to find a new solution to this problem", but more "ah I see this question before and I know how to solve this". It is pretty much almost brain-dead at this moment. Like, dynamic programming, recursion, and BFS/DFS are pretty much very mechanical. Once you've seen a few patterns, then you can tackle most of it.
Yes this skill doesn't come easily, but once you get it, you get it. So the difficulty of attaining this skill is overrated. It is like swimming and driving. Once you get it, it takes a few weeks to ramp up again. Weighing the pros and cons of DS&A compared to other style of interviews, it is clear to me which is the winner to optimize my happiness and lessen my sufferings. It is cheap to execute, it works majority of the time.
If a software engineer realize this reality and start playing the game, he/she is already ahead in the curve by a few miles from other candidates.
Ironically, I actually don't want most software engineers to realize this, because this skill currently gives me an advantage. If everyone start doing this, then the interview bar will be raised higher and we as an industry will see other practices which are optimized for software engineering candidates suffering.
but if DS&A puzzles are a de-facto standard, why not have an actual standard? the whole thing is pretty haphazard.
it's like hiring someone to be your defense attorney because they're decent at the NYT Crossword Puzzle, or to be your doctor because they're good at Sudoku.
This game is actually really easy to play, much easier than any other corporate/job game in other fields. You just need to know the rules, study the rules and get on with your life. You don't need bachelor/master from expensive universities or any other gate-keeping bst like in medical or law.
I wasn't born rich or smart or have good connections, and I'm glad setting aside a few months to study DS&A can make me earn what most Americans or the world envy. Much more if I'm good at it so I can jump ship at FAANG every year and living the dream. Let the rich/smart/well-connected people solve harder problems such as medicine or law. I just get on with my life.
Not sure if there's any legal implications with this, like, say I own the code but the company owns the "idea".
There are more ways to skin a cat. I am not sure big ( especially software) companies (in other, more litigious countries than mine) would entertain things like this, but if you do not try...
For instance, I did a small intranet for a very large company (for my country); because it was not their core business, and as such they did not care if we kept the (c) or sold the source to others as long as they had eternal perpetual rights to do whatever with it as long as they do not sell or use it outside their company. They reasoned that if I have more clients, they might get features and/or bugfixes for free. They did, up to some point and it made me turn my 1 man services company into a product company with staff. Which was fun but a steep learning curve, especially with regards to the money required for the growth of such a company.
Their lawyers made up a very fair contract (again this was not their core business so they genuinely knew they would never want to sell this themselves) which had clauses to protect them and us if they exited etc.
I had this happen far more often; at the right level, many companies, especially none software companies, will be up for this if they benefit financially or otherwise. Recently (different company; only services again) I had a large car maker suggesting we sell a small LoB app we made for them to their competitors so they would, again, share the financial pain of bugfixes and intellectual gain of new features. Kind of a product/services mix without the pressure of roadmaps, growth etc (all companies pay per hour and get all versions, including forks for others, but not forks by others unless the other parties specifically agree). So kind of contained-closed-open-source way of working, which is far easier for the corp lawyers to wrap their heads around than throwing things into the actual open. Also the quality demands code, community wise, are far less important. Let’s be real; most LoB software is a burning heap of crap; usually first put together parttime by someone of the departmental business and then passed to an external company when growing out of bounds (getting too much uptake internally). This time we could basically do a rewrite, but that is not always the case (remember; my business is being paid for every single hour).
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.
i think this is great - time limits help both sides, but companies don't tend to use them that way.
The trick is: who do you send the invoice to, and will they ever pay it?
I've invoiced companies that made me do unpaid projects and while it makes me feel better it has never once gotten me paid.
The invoice is not the problem, handling taxes is. In most countries (I'm not an American) an Invoice means that you are self employed and that you should pay taxes on that part as self employed.
There are services around it that charge percentage of the transaction and I'm not sure will handle such small amounts.