I came across this idea, that there are two types of programmers - builders and solvers on a Reddit thread and I found it thought-provoking so wanted to share it with you:
I’m going to generalise somewhat wildly here — and there are no doubt exceptions and overlaps — but in my experience there are two distinct groups of programmers:
Solvers, who typically like games, puzzles, chess, math for its own sake, and mathematical challenges.
Builders, who typically like mechanics (cars, motorcycles, bicycles, etc.), electronics, carpentry, plumbing, art, and often music-making
I suspect Solvers are more inclined to take interest in LeetCode and the like. Builders, not so much.
Notably, neither group makes for better programmers than the other — though they may take wildly different approaches to implementing solutions — and a strong team consists of both.
I’m definitely in the latter category. I find LeetCode — and puzzles in general — insufferably dull and pointless. But I appreciate that others love LeetCode and puzzles.
Different strokes for different folks.
The original author was Dave Voorhis, on Quora - https://www.quora.com/Why-is-LeetCode-so-hard/answer/Dave-Voorhis
It's not the only way to define or group programmers, obviously, but it's an interesting lens, when thinking about team dynamics, promotions and hiring.
Some questions that come to mind:
- If you put a LeetCode gate on the front of your hiring, you could be filtering out or even discouraging highly talented and valuable devs. Do you want to do that?
- Does your personal alignment impact your ability to assess/judge the skills of the other kind of developer? Do you prefer working with / hiring solvers or builders?
- What does your current team makeup look like, what does your product or team need to succeed?
For years, I've been asking a similar question during interviews, which was trying to get to the same root. I ask, "would you consider yourself to be a results or detail oriented person? Why? (And you don't get to pick both)", I'm not trying to trip you up, I really want to know, as it will help me see what problems, tasks and teams you might gravitate towards. But perhaps I should replace it with the Builder vs Solver question.
Diverse teams are stronger, which I expect applies to builders and solvers too.