| >> the signals I'm looking for: (1) can the candidate code fluently, (2) do they approach the problem in a systematic way, (3) can I communicate with them without friction. > Isn't this a sort of cultural preference on its own? You're looking for (and prioritizing) people who can code a certain way and communicate with you a certain way. Fluent coding doesn't imply style or something non-measurable. You can say if someone is fluent or not even if they are using a programming language that you don't know. I interpret it as: do they struggle while converting their idea to code, or not. Not how they structure the code, etc. Same for the systematic approach to the problem. If their explanation is all over the place, or failing to uncover the important bits of the problem[1], bias doesn't kick in here. We can argue about the appropriate layering of the solution (the level of detail). That's where different people are different. But you can see if their strategy works or not once they put it in code (i.e. maybe they should have put more structure in their approach). [1] (I: "Code me a string invertor". C: "Yes Sir! Here you are." I: "That's not what I had in mind."). > A brilliant programmer from a different code style background, who's maybe an introverted poor communicator (or just have a different communication style) Well, if I can't communicate with them (there's high friction), I shouldn't work with them. This is a bad fit by definition. They might find a better fit at another company. |