Hacker News new | ask | show | jobs
by gered 1095 days ago
It's been surprising to me to read through the comments posted here and seeing how most people seem to really despise take-home assignments during the interview process.

Speaking as someone who absolutely hates live-coding something during an interview (unless, maybe, by chance it's a practical exercise ... something like "build up this simple CRUD web service" ... not "solve this leetcode problem" ... but this is pretty uncommon in my experience, unfortunately), I rather like take-home assignments. As long as they don't take any more than 1-3 hours. I've been in situations where I've declined a take-home assignment that was given to me where I estimated it was going to take 10-20+ hours. No idea why any company would think that is reasonable.

For myself, what I hate is when the take-home assignment comes first. Like, before you talk with anyone at all, or maybe immediately after you did the 15 minute HR/recruiter screen. If I get a take-home assignment at that point, I decline.

There's no denying the fact that a take-home assignment is a large investment by the candidate on this random chance to get the job. I'm not willing to make that investment unless I've gotten a chance to talk to at least _some_ of the people I'd be working with at a company to better gauge what the situation is and whether I think it's a good fit for me. Even a 15-minute HR/recruiter screen is not going to do that. So yeah, if they just throw the take-home assignment at me right off the bat ... yeah, no thanks.

This all being said, yes, it is frustrating though to have to go through a bunch of these and get rejected with no feedback, or just ghosted, yeah.

4 comments

Take home tests are bad. Fizzbuzz questions are bad. Multiple onsite interview rounds are bad. Behavioral questions are bad. Leetcode style questions are bad. Collaborative coding tests are bad.

If you ask the majority of job seekers here, the only correct way to hire is to hand out 300K/yr offers after a casual 30 minute chat.

The actual best way is to only have a small set of senior engineers who also are very good at talking about programming, and are good with people and interviewing specifically and have a history of trust and good judgment do all of the interviews where they have a lengthy conversation about past experience, technical topics, and maybe code a little together if they think they need to and just give them total authority to make the call. It might not be that scalable but it would work the best.
This has empirically resulted in bad hiring, at multiple companies I’ve worked at. The best predictor of senior performance on the job has been the take home test or coding challenge. We frequently have seniors who suggest that the technical discussion would be enough for senior roles. We always have to let them down a bit when we tell them that the discussion is less predictive than they’ve built it up to be in their mind.
How do you know which candidates are worth your senior engineers spending all that time with?
I'm not sure. I think that's a problem to figure out. What I want to advocate for is mostly that talent scouting should be taken seriously not farmed out by scheduling random employees who aren't good at it and then collating the partial opinions of 10 people who don't really have enough time with the person to have a total view.
I agree in theory.

But engineers with good tech skills and good people are already likely to be the most valuable and time-constrained resources in the business. So taking 2 of them out to have a 2 hour interview with, say, 100 candidates is 400 hours. Even assuming they’d be willing to do that, that’s about 2 months worth of development from your best engineers.

This is why companies have processes like screening with a non-tech person and tech tests. It filters that 100 down to, say, 5 which is more feasible to put in front of those top engineers.

It hurts not to be selected for that 5, to be told you’re not good enough. Companies should do a better job at that. If they can’t give feedback because of the lawyers, they should warn you of that in advance, to set your expectations. They should be responsive and transparent through the whole process. What they can’t do - seemingly to the chagrin of many engineers here - is offer you a highly-paid job merely because you think you deserve it. I can see people on this post that likely have appalling people skills based on their comment, arguing that, since they didn’t get an offer, the company’s process was wrong. Perhaps those commenters need to look in a mirror to find the problem.

Recruiters might miss some top talent, but that’s the price they pay. All other solutions also have costs.

As they say on twitter, “this but unironically”.

My wife is a lawyer. They don’t send her a take home test, or ask her about her side project cases, or whiteboard bar exam questions. Somehow it manages to work.

> Somehow it manages to work.

It manages to work because expensive law schools and the state Bar do all of those things on behalf of her law firm. Meanwhile you can call yourself a programmer after taking a 30 minute online tutorial and writing a hello world script – and that is a good thing. We do not need gatekeeping in this profession.

We have certifications too - Azure, AWS, security ones, etc.

But a person with 15 certifications still gets asked to do a coding test

And those certifications mean absolutely nothing. There have been brain dumps for certifications for years.

Even if you don’t use brain dumps, it’s easy to memorize enough from studying something like ACloudGuru.

I got my first (of nine) AWS certifications (AWS Solution Architect) without ever logging into the console. But the only reason I get any of the certifications were to know what I don’t know and as a guided learning path.

For the first one, I was already a dev lead and wanted to know enough to know what I needed to experiment with when the company was trying to “move to the cloud”

My next 5, I was already the de facto “cloud architect” at a startup responsible for “application modernization”

And my last three (that I did within three months of each other), I was (and still am) working at AWS in the Professional Services department.

I can assure you that I don’t know but about 30%-40% of what those nine certifications cover well enough to hold an intelligent conversation with a customer and I only know the 30-40% from hands on experience.

I think the only benefit for me is that they hammered IAM concepts into my head, as they are a huge mess on AWS.
Then that sounds like we need more accurate certifications.
Have you taken any of those certificates? They can be passed from reading exam dumps and without proven hands on experience mean nothing.
And to be fair, I get it. Industry is too diverse to have one end all be all test. An AWS certificate won't mean much for my domain in games (unless you maybe work on online infrastructure for an ongoing service game).

But at the same time I wouldn't mind some fundamental license to optionally bypass many of these common tests.

Works fine as long as you went to a top-3 law school or graduated near the top of your class in a T14 school... I've explicitly seen lawyers lay that out as the criteria they hire by.

I'd rather deal with obnoxious interviews any day.

For your typical workhorse lawyer, yes.

But the legal profession, in terms of fairness for new grads, is perhaps the worst of all professions, I'm told. Basically, if you go to a top school you make 3x the average graduate based on that alone. While there is a decent correlation between school and talent, it is by no means strong enough to justify the phenomenon. Certainly it is not like this in other developed countries.

Computer Science has unfortunately been headed in that direction but at least an A+ graduate at a state school has a chance at getting the better offers.

There's no perfect way, but fizzbuzz is perfectly acceptable to me (do you really want to work somewhere with employees who couldn't pass it?), and leetcode is too, as long as it doesn't rely on some trick that selects for memorizers over problem solvers.

I don't know why HN is so against algorithms problems. It is not something I have ever needed to "grind" because I understand ds&a well. While the more exotic ds&a you won't use on the job, and IMO shouldn't be tested for, IME the most complicated datastructures you generally need for both algorithms problems and on the job are hashmaps and hashsets.

>I don't know why HN is so against algorithms problems. It

Probably because they use the ones you mention. They think an ideal engineer should be able to cold solve some level 5 leetcode problem using a Trie with some trick edge case to perfection in 90 minutes as if they are some sort of mathlete. It's not very realistic to what you do day to day and required dedicated studying simply to pass the test, not to advance myself as an engineer.

If they used level 1 questions as a fizz buzz esque filter for string manipulation, iterator tactics, and maps/sets, then I'd have no issue. I'd get why you may test a student for a junior position harder but a senior dev should have actual professional experiences to dig into.

If you can't trust them to code then maybe you should in fact do the FAANG method and describe what exact concepts you want prospective hires to be able to talk about and work with. Haven't seen that outside of FAANG tho.

> "I don't know why HN is so against algorithms problems."

Half of developers are below the median and, to paraphrase Upton Sinclair, "It is difficult to get a man to support something, when his salary depends on his not supporting it."

The best way to evaluate someone is to work with them for a year or two, yes. Everything else is full of an incredible amount of noise.
I agree with the consensus about behavioral questions, the multiple in multiple onsite interviews, and most leetcode. Fizzbuzz is great and take-homes are widely varying in quality.
> after a casual 30 minute chat.

which you have to pay them for

To give a different opinion, any company that doesn't do a take-home gets lower priority during my job search. My favorite interview was HR screen -> 30 minute chat with another programmer -> take-home -> final interview that included a take-home review.

I didn't end up getting the job but it was easily the best and least anxiety inducing interview I've ever been through.

I don't think that's a "different opinion" at all! :-) I look at it the same way basically.
Your timeline is best case scenario though. Your example timeline could happen and then they bring you onsite and ask you to do an in-person challenge as well. Now you’ve done all of that and still get ghosted.
Well, in that case, I assume you wouldn’t be interested at working for any on the top paying companies in the industry. None of them require “take home tests”.
You're right in that assumption but not because you putting words in my mouth. I said companies that don't do take-homes get lower priority during scheduling.
Why would I even schedule to work at a company that requires me to take more time than less?
>As long as they don't take any more than 1-3 hours.

Well, that's the issue. It may be because I'm a bad programmer, but I can't think of a take home that took me less than 3 hours. The take home I did for my first job took some 20 hours over 4 days, and I exaggerated and said it took 12 (which didn't garner a response so I'm guessing that wasn't an unusual answer). I could do that while I'm a student, I can't do that again as a working professional without wasting an entire weekend after a week of full time work.

I still hate leetcode more, but at least there you have an explicit timer.

>For myself, what I hate is when the take-home assignment comes first. Like, before you talk with anyone at all, or maybe immediately after you did the 15 minute HR/recruiter screen.

I've never had a test come later. 15 minute interview call to make sure the high level details are correct (pay, location, physical office vs. Remote, etc), and then I am sent an interview test.

Granted, my last 2 jobs did not employ take home tests, so I know I'm not forced to do them. But given my experiences I understand why others would be opposed to them. It sounds like you would be opposed to my experiences as well.

> I've never had a test come later. 15 minute interview call to make sure the high level details are correct (pay, location, physical office vs. Remote, etc), and then I am sent an interview test.

Depends on the company. My personal experience has luckily been (so far) that more companies I've interviewed with who do take-homes at all have given them later on in the process.

I suspect with the current job market situation given all the recent layoffs that things will probably start to shift for those companies that do take-homes, where they'll probably start giving them to candidates at the beginning of the interview process, as they'll probably see it as an easy filter for themselves. Ugh.

I’d rather do neither. That’s the main reason I have never done in person or take home coding tests in the 20+ years I’ve been conducting interviews. So far we haven’t hired a dud.
I bet while you “weren’t doing in person coding tests” as a developer you also weren’t making the type of compensation that the people who were “grinding leetCode and working for a FAANG” (tm) r/cscareerquestions.

I use to brag like you, about “not doing take home test” for 25 years. Then I landed at BigTech and saw that returning interns were making about what I made two years earlier at 45.

I’m not complaining, my goal had been to get into $BigTech in 2020 and relocate when my youngest (step)son graduated I did so without a coding interview and without relocating by pivoting to “cloud consulting/application modernization” (cloud + enterprise application architecture/development). But I tell my younger relatives to practice coding interviews and go for the most compensation possible.

If you base your success on money, sure. Maybe tests are a good filter.

Personally, I'm seeking something more furfilling and the difference between 200k and 300k doesn't matter if I don't find the work furfilling. 300k to 400k would be negligible for any material possessions I'd want.

But to each their own.

Yes, I have this insatiable addiction for food and shelter. The best way I know how to support my addiction is to trade labor for money.
Which as we all know is impossible to do without FAANG money.
Sure it is, I had my 3200 square foot home built in 2016 in the northern burbs of Atlanta when I was making $135K.

But why given the choice (theoretically) would I give up making $ALotMore just by practicing for coding interviews?

Like I said, I personally didn’t have to thanks to years of industry experience, knowing “cloud”, and having soft skills. But why would anyone without the path dependencies I had (ie children in school that I didn’t want to relocate) hold their nose up at doing what it takes to make $160K+ straight out of college and a quarter million+ a year by the time they are 25?

Or take my path, find a job that balances work and life priorities, doesn't require you to stress out on grinding rote memorized leet code problems, and work on a side business in your less stressed free time so that you can start your own company.

FAANG companies already have far too much power and influence, I'm ideologically opposed to giving them even more by subordinating myself to them for the almighty dollar.

I mean I agree with you on this, but the idea that you can gauge a person's skillset through conversation (gasp!) and talking about your craft and details about past projects, etc seems to be totally lost on people today.
I mean, it goes both ways. I feel that I am a fairly proficient engineer (built something with 10M+ downloads) but for a long period of my life I would do fine in every part of the interview except the part where you just chit chat a bit. I'd try to tell interviewers about myself and the smiles would just fall off their faces.

It took me a long time to understand that these sorts of conversations had their own "rules" to them, which I had to follow if I wanted to do well. These rules, of course, have virtually nothing to do with programming aptitude or ability, and seem to me, somewhat cynically, to be another way by which interviewers can allow their own biases to enter into the interview process. For instance, one time I got rejected because I seemed "too excited" about my personal side projects; it was deemed that I wouldn't be as excited about the work that I'd do at the company. Of course this is nonsense; I'm now happily employed and pretty excited about my work. I have plenty other examples of me saying reasonable things in interviews and being rejected for that reason.

There's really no silver bullet here. Getting rejected is always going to piss people off.

See, I take a bit of a different view in the example you've given. Like, if I got rejected because I seemed "too excited about my personal side projects" I'd come away from that thinking "if that's really their take away, I'm kinda glad I don't work with them!"

You're right that the conversational interviews (just like any social gathering, really) have their own rules. But I think the most important thing you can do during those interviews is to just be yourself. After all, you want them to get to know you, just as you want to get to know them, right? How else can you each be sure that you're a good fit for each other? If they reject you for something you said that is true but that they just didn't like (e.g. a difference of opinion on something), or they nitpicked some little thing you said even though the rest of the conversation went smoothly ... well, in my opinion, you're better off.

Normally I'd agree, but I got passed up by a large number of fairly reasonable-seeming companies for arbitrary reasons like this. If it's just one or two, sure, maybe I'm better off. But after that it starts to have a real impact; it becomes harder to negotiate, maybe one of those companies would have been just fine anyways, etc...
> gauge a person's skillset through conversation (gasp!)

I can't claim GP's 100% hit rate, but I think I can get to about 90% this way.

My most recent error is galling though, and absolutely would have been caught with a lightweight coding test.

Some people are really good talkers.

Seems fairly easily solved by letting that person go. Easily for the company at least.