←back to thread

Please stop the coding challenges

(blackentropy.bearblog.dev)
261 points CrazyEmi | 1 comments | 15 Nov 24 15:32 UTC | HN request time: 0.202s | source
Show context
parpfish ◴[15 Nov 24 16:19 UTC] No.42148290[source]▶
one of the biggest problems with coding challenges for me is the conflict between providing a good solution versus making a strong impression.

do you show them a quick'n'dirty solution that ignores edge cases but shows i'm a pragmatic and not going to overcomplicate things?

OR

do you show something fancy that you'd never actually do in an real codebase that shows off my depth of knowledge and where my ceiling is?

replies(2): >>42148747 #>>42150371 #
1. quectophoton ◴[15 Nov 24 20:05 UTC] No.42150371[source]▶
That's assuming they don't pre-bikeshed before even looking at what you did.

Candidate: writes code matching current style as much as possible to show that you can adapt

Reviewer: Rejected. Didn't even use autoformatter, which takes literally zero effort, so clearly does not follow best practices.

Candidate: autoformats

Reviewer: Rejected. Changed more code than was really needed (separate commit or not), clearly showing they didn't try to keep the change as small as possible. If this were a real PR, they would be making life more difficult to the reviewers making it harder to spot the parts that were actually modified.

Candidate: keeps existing code as-is, but writes own changes following the currently accepted conventions

Reviewer: Rejected. They clearly can't follow an existing style and prefer to be a snowflake and "leave their mark" in the codebase.

Candidate: does any of the options above, and adds comment explaining the reasoning, including mentioning the other possible options that they thought about and their tradeoffs

Reviewer: Rejected. Candidate thinks too hard about trivial stuff, showing lack of focus on what really matters.

---

Granted, being rejected for those reasons above could mean that you dodged a bullet.

But yeah, like you mentioned in a different response, a live interview (coding or not) helps reduce these kinds of uncertainties to some extent, but of course these live interviews have other trade-offs compared to take-home tests.