←back to thread

Please stop the coding challenges

(blackentropy.bearblog.dev)
261 points CrazyEmi | 4 comments | | HN request time: 0s | source
1. parpfish ◴[] 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 #
2. ryandrake ◴[] No.42148747[source]
Unfortunately, you often have to ask the interviewer (which is tough when it's a coding challenge and you have no way to ask for clarification on the rules). I know interviewers who will say "You didn't cover edge case A, B, and C, your solution is incomplete!" and other interviewers who will say "You are overthinking this, I'm just looking for an MVP."
replies(1): >>42149021 #
3. parpfish ◴[] No.42149021[source]
that's part of what i like about whiteboarding interviews -- you can get realtime feedback and discussion the pros/cons of your solution in realtime
4. quectophoton ◴[] 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.