Tell HN: Interview take home assessments without feedback are frustrating
I'm in the process of interviewing for senior and staff front end positions. I've done several multi-hour take home projects now and a couple were rejected with generic rejection messages. It's pretty insulting to be frank. Spending 2-4 hours on likely valueless work is a substantial amount of time relative to the week day. If I've spent the time making the project and they've spent the time recruiting me and reviewing the project, the recruiter and reviewer could spend 5 minutes sending constructive feedback.
Anyone else share in this frustrating experience? Have you successfully asked for feedback before?
503 comments
[ 2.9 ms ] story [ 277 ms ] threadGot a "Thanks, you're not moving on" message and that was it. Man, the rejection is totally fine, but I really do wish they could've spent a few min just explaining some details. I've gotten more thoughtful rejections from just cover letters and resumes, not to mention public PRs in strangers' repos.
After spending so much time, it just feels like a betrayal of some unspoken developer ethos (vs say talking to a generic HR screener). If you're going to make someone code for you for hours and then dismiss their work, please at least tell them why in just a few sentences. You don't need to comment line by line in a code review, just general thoughts like "better code org" or "poor architecture and readability" or "better tests would've caught this major bug" or whatever.
In my case this was a small company I was super excited to work for, and waited more than a year to finally have a chance to apply for (once my current job ended). It was definitely disheartening and makes it hard to want to try again with them in the future.
But, you know, the other side of the coin is that maybe they're just getting swamped with so many applications they can't take the time to thoughtfully answer each one. I imagine I'm competing against a horde of more qualified ex FAANGers right now and maybe they're too busy trying to decide between the top 3 or 4 vs the long tail of hundreds of us who failed the take home. Who knows...
Maybe. At the point in the process where you're seeing someone's project, you've already spent time probably phone screening them, sending them the project, hopefully reviewing it. It takes relatively little time to write a quick sentence or two in review of the assessment. It would be nice even if they didn't look at the project and just said "sorry, we didn't have time to look at your project because we're moving forward with other candidates".
Well, it's a good lesson to have gone through though. If I'm ever in a situation where I am asked to evaluate others in a similar fashion, I'll be sure to leave detailed feedback (if they want it), now that I know what it feels like.
Not just that: At every job where I interviewed candidates, HR expects some kind of feedback beyond just "hire"/"no hire". At least some bullet points of highs and lows, red flags, etc.
If nothing else, this helps protect the company from false allegations of illegal discrimination by having documentation for why a particular candidate was rejected. It also helps recruiters to know if they're finding candidates who are "close to what we want" or "not even in the ballpark".
Now, I know that some interviewers can be fairly blunt in their feedback, so you'd not necessarily want to just copy-paste it to the candidate, but the point is: that feedback already exists. The recruiter/HR just needs to (maybe) sand off some of the rough edges.
Why abuse? Well, let's say they have three solid candidates. They ask each to do an assignment. Would I do a 6-hour project for a 33% chance at a job? Maybe, especially if I really wanted that particular job.
Now let's say they have 30 candidates that they ask. Would I do 6 hours of throwaway work for a 3% chance at a job? No - not knowingly. If I'm an average candidate, I'm going to have to do that 30 times to land a job. That's 180 hours, or more than four full-time weeks of throwaway work. That's an abusive process.
Could I spend just as much time interviewing? I could, but there's a difference. If I'm interviewing with you, you're there talking to me. You can't waste my time without wasting your own. Whereas with a take-home assignment, you can waste my time but waste little or no of your own. As a result, interviewers (usually) pay some attention to not doing needless interviews, but pay less attention to not asking for needless take-home assignments.
That said, though, I also think the take-homes are a much more enjoyable use of my time than running through interview gauntlets with people who don't even work in the same team or in tech at all (recruiters, HR screeners, upper level bosses, whatever). At least code presents a somewhat objective metric I can be measured against, as opposed to random people's opinions about me after talking for ten minutes. Those sorts of interviews feel more like theater than assessments. I'm good at them, but I don't feel like they're a good way to gauge a candidate's effectiveness, including my own.
With the best take-home I did (not this 12-hour one I was just talking about), we met right afterward to discuss the pros and cons of my assignment, what went well, what could use more care, etc. It was more of a discussion, like "Why did you do X this way" and "Did you consider Y when you chose this?", followed by a segue into how the take-home relates to the actual products they were building, and a high-level discussion about how I'd implement similar patterns in a production app. I did end up getting that job and loving it. The process never felt exploitative, and the team ended up being amazing. I'm still thankful for the person who gave me that take-home to prove myself, vs the hours of pointless recruiter chats before the assignment.
But yes, they shouldn't be 6-hour take-homes... that's too much to ask of an unpaid candidate. A reasonable take-home should take 2-3 hours max for a candidate of median skill, IMO. As an aside, my 12-hour one was my own fault for not having worked on that specific problem enough (web animations in SVG or canvas), but I was happy to be figuring out a new challenge after my last job got too easy and boring.
If more engineers start to refuse these kinds of "dance, monkey, dance" processes, they'll start phasing them out.
Then the hiring manager came back, "all looks good! I need you to interview with the team, the CEO, the other team" and what not.
I declined and said that I'm not spending 10 hrs in a process you asked me for (as in I didn't apply, they reached out to me). I got an angry email saying "what do you mean? We have only met with you for two hours?". I pointed out that it takes time to do the tests, then nothing more than crickets from the company. Not even a thanks for your time.
It turns out that that position was eliminated within 12 months. If I'd been hired then I would be unemployed by now. So I'm amazed and grateful for my current position, with an incredible flexible schedule, 100% WFH, and all the rest. Sometimes things work out for the best when we least expect it.
But you feel secure to have your time and self confidence burned? Because you will be ghosted or sent generic rejection email.
If you are interviewing as a software engineer, you should be able to write FizzBuzz. Yes, it is stressful. Yes, I hate leetcode too. But, a company has every right to check that you at least know the basic skill you say you do.
If I'm presented with one, I take it as an immediate sign that I'd be a poor fit there and move on.
But really, I think that interviewers should be gracious about takehomes. And if they're not, that gives you and indication of what kind of place it is to be.
Leetcode grinding for a whiteboard is a worthless skill outside of the interview. I'd rather code up something. If the project is over burdensome you can always pass.
The best homework I got was a "working" project that purposefully had bad practices scattered throughout. You could elect to fix the mistakes or just document them for the interview.
Oh, and the project smelled like something they actually needed in prod.
As are interviews of any kind without feedback. I'm not referring to holistic feedback (let alone an explanation for why they don't move forward). I mean the kind where they grill you with question after question (often poorly phrased and sometimes insultingly basic) and don't provide any indication at all as to whether your answers are good or bad or not.
They just keep going on, poker-faced - saying, in effect: "Don't speak unless spoken to".
I mean you'd be surprised at the number of people that can't write a for-loop ...
Or even post a job req that accurately reflects the true needs of the position in the first place. Or (getting back to the subject of this thread) when giving take-homes, provide reasonable instructions as to what is expected and by when (and under some reasonable time frame), etc -- see for example this chestnut, posted just now:
https://news.ycombinator.com/item?id=36452104
A two-way street, and a bit of common sense. That's all I'm asking for.
The idea is, if you submit to company A, they rejected without any feedback, let's other companies know about it, and both of you is in a win-win position.
Long story short, the company passed on me, saying that my code was easy to understand and high quality, but I didn’t handle all of the corner cases. I listed most of the corner cases they mentioned in the readme as limitations from the time limit. It was clear that while they said to limit my time on the project, they didn’t really mean it. They wanted an exhaustively finished product in a ridiculous amount of time.
At this point in my career, I’ll just decline interviews that don’t respect my time.
I wish I had saved a copy of the assignment. It was ridiculous.
By having such an abuse and convoluted requirement for applying, you’re selecting for people in this situation. Then all you have to do is hire the best on the technical solution and you’ve got one more employee you can abuse in your company :)
The worst part was that after working there I found them to be terribly unproductive and it would have likely taken a team there a week to build what they were suggesting...
But yeah as you said, either ignore the time constraints if you really want the role or just politely decline due to the red flag / inconsiderate nature.
> ... as I wasn’t paid for the interview and I didn’t feel it was fair to me to spend any more time on it than that.
I have been paid for an interview, a coding interview where I fixed a bug and added a feature while my pair (future colleague!) chilled .. I think he surfed and I'd ask him clarifying questions occasionally? Anyhow, I got paid like $400. Best interview ever.
And I'm like.. an hour is not long enough to implement any reasonable webapp... I have no idea if other people went over or not, and it almost feels like a test of commitment (if I was serious I would take the actual 4 hours it would take and pretend I did it in 1 or something like that).
Given the diversity of FE it’s quite likely for a take home project to hit one of those criteria.
Depending on the position they may been testing specifically to filter people out who are using a tool for the first time. If I'm hiring a Senior Flutter Developer then it better not be their first time using Flutter.
If you are a senior developer and haven't seen half a dozen frameworks, tool sets, or languages under your belt. What value are you in 2 years when we shift gears
1. Write it all yourself. Express those opinions as clearly and bug free as you can. Try to get it all in as much as you can and give up on finishing all the features in the spec. Definitely give up on the UI looking nice -- despite what anyone says, default HTML is not pretty.
2. Use OSS libraries. Are you actively up to date on OSS libraries handling these things? If you're a working React professional, you probably are not, because you're using whatever system your company uses. Do those OSS libraries properly express what you think is good code? And what does it say about you to use those OSS libraries? Do you look like someone who actually understands React and understands those tradeoffs, or do you look like the kind of person that creates the type of React app that HN is always complaining about, one with a billion dependencies?
Sorry if I sound ranty. It's not directed at you. I've just been dealing with a lot of these this week.
"we have a takehome, but don't worry! it's just a quick little thing that should just take an hour to throw together. we're not like those other companies that give you a huge task"
I see two data points they could have: time when the template was downloaded (assuming it’s a unique link only you can access, and you didn’t download it > once/all downloads are logged) or emailed, and the time it was submitted.
All other time stamps can be spoofed.
I did one take home that was timed in coderpad. I thought that was a little more fair.
Honestly 2h from scratch is a rush to do anything? However simple it is, you're asking for an 'entire' greenfield project, of course I have skipped things and missed corner cases.
I obviously noped out, but am still wondering if they are aware that all the people working there 100% cheated on their take homes.
Either they don't care or they see it and figure I must be some sort of whiz. I say that because the amount of people that don't know how git works or that file attributes are arbitrarily changeable is amazing.
And no not specifically to "cheat". Just on principle. If they require BS I give them BS. Else it's just fun. Sometimes the people actually hiring/doing the interview are also not the ones that care for this but HR/senior leadership only.
And yes, lots of companies have an interview process that state these things. The process makers are not the same people as are interviewing/going to be your team. I know from the other side where I have in the past internally had to advocate for proper take home practices. They really wanted to extend the take home and to say "should take 4-8 hours" (meaning really it's 2 days of work) . I told them that's BS and I wouldn't be with them right now if that was the practice back when I interviewed.
The worst thing that can happen is that they think you are cheating and they never even call you back. Bullet dodged. The best thing that can happen is that they do call you in for an interview and the interviewer tells you that you're so far the best sport and apparently know your git very well and you bond over it.
Amazing I'm mixed on companies looking at start and end times. I think it would be ridiculous for them to actually check, but at the same time I'm curious how many people are going way over the time limit. I wonder if I should go over the time limit or not.
> And no not specifically to "cheat". Just on principle. If they require BS I give them BS. Else it's just fun.
Maybe this is controversial to say, but in reality, we're all "cheating" because we have to.
We don't fail take homes because of edge cases though. There are things we expect people to handle in the challenges that are important, but I don't think more/less time really influences those.
Those are standard enterprise CRUD salaries. I’m not trying to be demeaning. Those are the kinds of jobs I had most of my career until 2020. But they are a dime a dozen and I definitely wouldn’t do a take home test for one.
My experiences are the same that equity in private companies is not significant. Worse yet, in all of my experiences the private equity I could have bought or did buy were all 100% losses.
[1] https://www.quora.com/What-percentage-of-Tech-startups-eithe...
On a different topic, I think your response mrkurt is a violation of the commentary guidelines:
- "Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive."
- "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
What I wouldn’t do is jump through any hoops like a take home test when jobs in that pay range are (were? I don’t know what the current market is like) a dime a dozen and I could just do one phone screen and a soft skills interview for half a day and get a job making that much.
If a company expects me to jump through hoops that take more time, the resulting reward need to be commensurate with that.
But not all jobs are for all people.
But at least from around 2002- 2008 and 2012-2022, if you have experience in a mainstream stack, and you live in a major metropolitan area in the US you could easily get a job that pays in that range without even coding interview, let alone a take home test.
1. Other candidates were clearly spending 8-9 hours on the problem. I saw their commit logs. A commit every 1-2 hours for 9 hours. Several candidates public repos were like this. The assignment was like 2 pages of requirements supposed to be done in I believe 1 hour.
2. They told me (thru the recruiting firm; I never spoke with them) that it would have been resourceful to use the other candidates solutions.
This is my philosophy now. In my younger days when I had no experience I had a lot of my time wasted by recruiters and companies - never again. Now I ask up front and politely what the interview process will be like. If there are any home projects or mentions of whiteboarding I end up passing. No big deal - I know there are probably loads of developers willing to waste their time competing for the position, but not me.
It's worked very well for me and eliminated a lot of stress when I've been looking for other positions. The only negative I can see is the strategy wouldn't work great when in between positions and really needing something, which luckily I've never had to experience. I suppose in that case I would force myself to go through with the hazing process.
I bet the hiring company got a bunch of "fine" or "ok" project submissions from candidates and then made somewhat arbitrary choices on who they would move forward with.
Please cite the relevant court cases.
The irony of these claims is that the possibility of lawsuits doesn't actually stop companies from doing terrible, lawsuit-worthy things. They do such things all the time.
Occam's razor suggests the explanation is simply that companies don't care about job applicants. And this is demonstrated in many ways.
https://www.eeoc.gov/newsroom/ruby-tuesday-pay-45000-settle-...
If your feedback is "You're too old", then you probably shouldn't give that feedback to the applicant. But you also shouldn't discriminate in the first place.
If not giving feedback is an excuse to cover up illegal behavior, that's not a good excuse.
Again, unless you're talking about illegal discrimination, I'd like to see the relevant court cases cited for this "fodder".
If companies are covering up illegal discrimination, it's not a conspiracy theory, it's simply a conspiracy.
Moreover, people are claiming or speculating that there are blanket company policies against job applicant feedback. I have yet to hear anyone confirm this from the inside. Are there also blanket company policies that you must "ghost" job applicants, as many companies do? And what's the "legal" reason for that?
1) I don't think Google/Microsoft/Meta/Apple are the ones giving take home assessments.
2) I've talked to many such engineers.
> There are written rules and trainings about interview conduct at every one of these companies, and they all cover feedback - what you are or aren’t allowed to say, how much you can share.
Ok, so what are the rules? You're claiming knowledge here, so please demonstrate it.
> At every one of these companies the interviewer doesn’t even have direct contact with the candidate after the interview is done.
This varies quite a bit. Also, many smaller companies don't even have an HR department. In any case, when you're doing a live interview, you tend to get some real-time feedback, whether explicit or implicit. It's completely untrue to suggest that interviewers get no feedback. The OP was complaining specifically about take home assessments, where you can't give live feedback.
Sorry, but I don't take imaginary inventions of your own mind as real citations.
Untrue, and I'm done talking to you.
If after 3-4 rounds of systems interviewing, the company came back and said: "Hey we like you, and we're interested in making an offer, but we want to check your skills..." Yeah, I'd do the assessment. Especially if I did 1 round of 45m coding. Without that, the company can't verify that I have "FizzBuzz" level skills, and that I didn't cheat on the assessment.
When it is upfront, it is rarely worth it on either side. Companies lose a large fraction of the engineers applying into their funnel, and honestly as an engineer, it is rarely worth my time. I can spend that time interviewing at other companies that respect my time.
As with many things in life: It is when, and how things are done. Not what things are done that often matters.
Even just a "hey, we're genuinely interested and you made it to the shortlist" or something to that effect would just make a world of difference. Now I have no idea if I'm on any sort of shortlist or if they're just shotgunning this to everyone. I tried asking a few times, but I always got such vagueries in return that I might as well not have asked, so I stopped bothering.
Would also help if people made the tests at least a little bit interesting. Now it's either "do this boring CRUD thing you've done 1000 times already" or "solve several NP-hard problems that have been subject of Turing awards within an hour".
The last time I spent quite a bit of time on one of these things because it was interesting, and even put the result on GitHub (with no mention that it was for a take-home test, it "just" looks like any other project, also slightly modified to fit my needs). Then again, what's "interesting" for one person is "boring" for another.
I suspect the people weren't used to having someone hand in a basically 100% guaranteed to work program ;).
(I do know 100% code coverage doesn't mean working. But the docker container helps a good bit in making sure the code will run in the environment I wrote it for.)
I don't know what your specific code test was about so I can't really judge, but generally I've considered overcomplicated solutions to be a minus. "I asked you to write a simple CLI and I get some container environment" is not something I would consider positive anyway.
I think: I'm writing this in Python, most Python setups are a giant mess. By putting it in a container, I can guarantee it'll run right on their system. This is LESS complex.
If my employer considers "docker run" when given full instructions complex. I guess I'm not a fit.
Well, you do have a choice. You could tell them that they were rejected for copy/pasting or because the requirements were not met. You don't have to do into more detail than that.
The report can be 1-2 sentences. It doesn't need to be meticulous or a "boot camp".
If-so, you're doing yourself a favor by providing feedback so that they might improve by the next time they interview.
No one owes you anything. If these companies display poor behavior during the interview process, add them to a list, name and shame, whatever you think is appropriate and move on.
A friend and I tried to start a company around this, basically resolving three big issues we saw with take-homes:
1) No feedback. If you spend a couple hours on something you should get meaningful feedback.
2) No clear criteria. Is the hiring company going to slam you on correct syntax? If so, you should know that upfront!
3) Time guidelines that had no enforcement and thus led to an arms race where candidates would spend ever-increasing amounts of time and skew the standard of what "good" is.
So we fixed those things:
1) We provided the feedback, not the hiring companies, so legal liability was non-existent for the hiring companies. We double-blinded the process as much as we could (evaluators didn't know who the candidate was and vice-versa).
2) We told candidates upfront what they'd be evaluated on. Not down to the level of "you must implement this problem using a max heap", but we would say something along the lines of "The company is looking for an academic algorithmic solution to this problem" or similar. We would then only allow evaluators to evaluate them on these axes and nothing else.
3) We also strictly enforced time limits by basically telling candidates "hey you'll have 2 hours to submit from the time you hit start and see the prompt, so please make sure you have two hours from when you hit start." -- not ideal, obviously, but the best we could come up with to resolve #3 above.
As you can probably imagine, the market just wasn't really there for this. I think candidates generally enjoyed it in comparison to the vague, unending slog that most take-homes are but:
1) The value prop just wasn't really there for most companies: They mostly use these types of evaluations on more junior candidates, and unfortunately the hiring market for junior candidates is highly skewed towards the employer.
2) More surprisingly, we realized the time their current engineers and managers spent evaluating these takehomes just wasn't really a consideration for them. We tried to frame it in terms of "here's how much it costs you to evaluate these take-homes wrt time spent vs. us", but it was a difficult sell regardless.
We actually had the most success evaluating candidates from more non-traditional backgrounds upfront ourselves and then charging a placement fee if they were hired, but we ultimately didn't really want to continue that.
do they just want to see that yoiu know how to load a csv file and make a barplot? or do they want a showcase of advance statistical modeling to see where your ceiling is?
employers don’t know, or seem to care, how much it costs them to replace and/or onboard somebody. usually because they have no idea how they’re off/on boarding hires.
not too surprising that they wouldn’t care about the cost of one component of the hiring process.
Adjust your sights on those and it's lovely. More often than not those companies are great to work for across all metrics.
Most of these leetcode interview companies just follow what Google does for that reason alone. And Google does it because they have to cull 20,000 applicants somehow in the first wave. They just _can't_ interview that many people from the jump.
Platforms like Woven do this automatically, but they miss the mark. A good half (if not more) of the value is observing the candidate working through the problem and responding to collaborative feedback, not in actually solving the technical issue in question.