Comment by vorpalhex | Hacker News Reader

Comment by vorpalhex | Hacker News Reader

I typically don't do "take home tests" anymore. I explain that in the past they have occupied a lot of my time and even when successful, usually things didn't work out. I point them to some of my recent foss work in return (with full git commit logs).

I would probably make an exception if they offered to pay me even a token per hour (or even donate the hourly to a charity - it's about incentives not money). I have made an exception when it was literally a 20 min code challenge for a promising lead.

On one hand, this does frequently stop things moving forward. On the other hand I never felt like I missed out.

One company I sent them my usual polite decline and got back an angry rant from the CEO! I responded with "Well, give me your product for free for 8 hours or so and I'll give you my time for free for the same length." He did not respond after that.

This is probably bad advice for very new engineers where a code sample can help differentiate you a lot, but I wish more senior+ engineers would refuse these dumb tests.

+1 on that.

The handful of times I've dumped a bunch of time and effort into an at-home screening assignment, it took far longer to do well than whatever the allotted time was made out to be. Emphasis on the "do well" part.

My (unscientific) sense is that these things are really just screening for people willing to jump through unreasonable hoops.

I feel like this is a mismatch of delivery expectations rather than a problem with take-homes. I explicitly tell our candidates that I don't expect them to put together a polished solution in the couple of hours they have for the take-home. That's fine. The point is to merely get an idea of someone's ability.

That's a good point.

Counterpoint: what idea can be had from rushed / time-constrained / deliberately careless work examples?

Any junior can copy / paste some functional yet poorly done code. Or make ChatGPT come up with something, I suppose, now that that's a thing.

Experiences vary, but every job I've taken and liked - no coding tests of any kind. More of a discussion about an example piece of code, for that part of the interview, but no requirement to come up with new code.

I'm a firm believer that you can evaluate exactly what you test. If you are asking someone to rush to deliver an algorithm, you are testing their ability to rush to deliver an algorithm. If you actually want to know whether they can deliver a polished solution, you asked the wrong question.

In my case, I actually do want to know how quickly people can pick up a new problem and get started writing some code, and that's how I evaluate what they deliver.

> Any junior can copy / paste some functional yet poorly done code. Or make ChatGPT come up with something, I suppose, now that that's a thing.

I have two thoughts about this.

1. If people can deliver, they can deliver.

2. If you come up with an original problem (rather than lazily copy and pasting some fizz-buzz type problem), you'd be surprised how many people fail to apply any basic problem solving.

> a discussion about an example piece of code

I do find that it is useful to keep code exercises short, but ask a few questions about their solution as a follow up. People often struggle to explain their solution if they just copy/pasted.

Take homes aren't great, they're just less bad than whiteboarding or live evaluations. I wish it was possible to judge coding ability through a resume, but you'd be amazed at how many 'senior engineers' can't write a line of code.

The best way for senior folks to get a new job is through referrals.

Also depends on the take home test. Often they are pretty large not a simple implementation of an algorithm or something

Reply on news.ycombinator.com