[kube-system]

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.

[zebraflask]

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.

[kube-system]

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.