xarvh · February 4, 2025 10:57
diff --git a/gistfile1.txt b/gistfile1.txt
 An important factor in the strength of a dev team is the breadth of solutions that it can consider.

 However, it seems like most code tests screen for "coding like the reviewer" which *reduces* the team's solution search space.

 I don't want my ego or my Opinions(TM) about code to get in the way of having colleagues I can learn from, so I want to try a different strategy when evaluating code challenges submissions.
 If the candidate's solution solves the problem, I'm going to consider only its *positives*: the good ideas, the interesting and original aproaches.

 I'm going to ignore things I don't like, because those can be addressed by discussion or code review.

 In short: as long as someone is capable of doing the work, I care about how they broaden our capabilities, not about how well they conform to my expectations.
	An important factor in the strength of a dev team is the breadth of solutions that it can consider.

	However, it seems like most code tests screen for "coding like the reviewer" which reduces the team's solution search space.

	I don't want my ego or my Opinions(TM) about code to get in the way of having colleagues I can learn from, so I want to try a different strategy when evaluating code challenges submissions.
	If the candidate's solution solves the problem, I'm going to consider only its positives: the good ideas, the interesting and original aproaches.

	I'm going to ignore things I don't like, because those can be addressed by discussion or code review.

	In short: as long as someone is capable of doing the work, I care about how they broaden our capabilities, not about how well they conform to my expectations.